createOrReplace Service Account leaks secret tokens

Hi,

We are facing an issue that our code is regularly calling createOrReplace on a service account to make sure that it stays up to date, but it seems that on each call we are generating a new token without clearing out the old:

elastic-operator-token-stx62                kubernetes.io/service-account-token   3      97d
elastic-operator-token-svl9g                kubernetes.io/service-account-token   3      201d
elastic-operator-token-swv6z                kubernetes.io/service-account-token   3      120d
elastic-operator-token-sztz2                kubernetes.io/service-account-token   3      70d
elastic-operator-token-t47x6                kubernetes.io/service-account-token   3      247d
elastic-operator-token-t4ccc                kubernetes.io/service-account-token   3      75d
elastic-operator-token-t4mfl                kubernetes.io/service-account-token   3      124d
elastic-operator-token-t584b                kubernetes.io/service-account-token   3      108d
elastic-operator-token-t6pg5                kubernetes.io/service-account-token   3      252d
...

Is this expected behavior? I would expect that createOrReplace also deletes this service account token when deleting the service account? Or is there an alternative function call that we should use?

[shawkins]

So my question would be - why are we creating a new secret on each update to the service account?

The yaml you are using to create the service account does not have the secrets specified correct? This is a similar issue to #3122 - the kubernetes logic acts upon the PUT independently of the existing item. My guess is that to workaround you need to use a patch, or that some logic - either in your application, or through an enhancement here - would need to check for the existence of the service account and update the object with the existing secrets if none were specified. Related to using a patch instead is that you may be expecting createOrReplace to behave like kubectl apply, but it does not #3420 - kubectl’s logic, which will produce patches, rather than puts, does not trigger the creation of a new secret.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!