-
Notifications
You must be signed in to change notification settings - Fork 979
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flux compatibility - service account annotations #3030
Comments
…trollerConfig Flux will garbage collect the ServiceAccount if we copy the flux annotations from the ControllerConfig. Background: We sometimes see bursts of Unauthorized for calls from crossplane providers to the kubernetes apiserver. After some debugging we've found that the UID in the service account does not match the token on the file system. We noticed that the service account has a "fluxcd.io" annotation, even though it is not managed by flux. This is because crossplane copies all annotations from the `ControllerConfig` to the `ServiceAccount` object. This is probably required for ArgoCD, and it is used for IRSA in AWS. But for flux, this does not work. We believe flux will consider this as a situation where a former `Kustomization` managed this object, and delete it as it is no longer managed. crossplane will quickly recreate it, but the token mounted in the container will for some time have the old UID and the API server will reject the requests. I'm not sure if this is a race condition in the kubelet when a token is rotated while a pod is created, or if it is simply not a supported way to rotate the tokens by deleting the service account while it is in use, but Kubernetes does recover from this situation after a while. Fixes crossplane#3030 Signed-off-by: Carl Henrik Lunde <[email protected]>
Workaround (thanks @haarchri): |
Cross-linking to #2468 |
Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as |
Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as |
/fresh This is still an issue that should be addressed. Hopefully we can get some related PRs merged soon. |
Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as |
What happened?
We sometimes see bursts of Unauthorized for calls from crossplane providers to the kubernetes apiserver. After some debugging we've found that the UID in the service account does not match the token on the file system. We noticed that the service account has a "fluxcd.io" annotation, even though it is not managed by flux. This is because crossplane copies all annotations from the
ControllerConfig
to theServiceAccount
object. This is probably required for ArgoCD, and it is used for IRSA in AWS.But for flux, this does not work. We believe flux will consider this as a situation where a former
Kustomization
managed this object, and delete it as it is no longer managed. crossplane will quickly recreate it, but the token mounted in the container will for some time have the old UID and the API server will reject the requests. I'm not sure if this is a race condition in the kubelet when a token is rotated while a pod is created, or if it is simply not a supported way to rotate the tokens by deleting the service account while it is in use, but Kubernetes does recover from this situation after a while.The specific annotation is
"kustomize.toolkit.fluxcd.io/checksum": "3583e44b78adb421bd53fcb43edfcd5d39b287b8"
How can we reproduce it?
Flux-managed
ControllerConfig
, see aboveSuggested fix
I think we should exclude annotations with keys
fluxcd.io/
or prefixkustomize.toolkit.fluxcd.io/
when creating the deployment and serviceaccount incrossplane/internal/controller/pkg/revision/deployment.go
Lines 174 to 177 in 1344a86
We might also want to skip key
kubectl.kubernetes.io/last-applied-configuration
or prefixkubectl.kubernetes.io/
as it is fairly misleading to copy it.Long term crossplane should probably implement "bring your own service account" instead (see issue #2295 etc)
What environment did it happen in?
Crossplane version: 1.6.3, EKS 1.21, flux 0.17
The text was updated successfully, but these errors were encountered: