Skip to content
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

copy explicitly named labels from vault-crd to secret #53

Closed
wants to merge 1 commit into from

Conversation

akloss-cibo
Copy link
Contributor

This change requires that the vault-crd explicitly list labels to copy rather than implicitly copying them. There's a label added by ArgoCD that implies that the secret was managed by ArgoCD which creates a synchronization difference. ArgoCD will happily remove the secret, and then moments later vault-crd will add it back, ad-infinitum.

@DaspawnW
Copy link
Owner

Can you please elaborate a bit more?

@akloss-cibo
Copy link
Contributor Author

Sure. When ArgoCD creates a Kubernetes resource, it labels it so that it knows which resources it is managing and which ones it is not. If ArgoCD creates a vault-crd resource, it will have this label. Vault-crd 1.5.0 will then copy that label into the secret it creates. This makes ArgoCD think that the secret is under ArgoCD management, and since the secret isn't represented in the sources for the application, it assumes some prior revision in git created it. Since (as far as ArgoCD is concerned) the secret doesn't belong in the cluster, ArgoCD will delete it. Vault-crd then notices it's missing, and recreates it, and so on.

@akloss-cibo
Copy link
Contributor Author

Any more thoughts about this, or something like it?

@akloss-cibo
Copy link
Contributor Author

Can I do anything to help a solution for #54 to move forward?

@DaspawnW
Copy link
Owner

sorry for the delay, I'm still not happy with this approach. Can we maybe switch to another approach via an application.property / env variable where we enable / disable the "copy" label feature? THis is then for sure enabled / disabled for all but maybe its then a bit cleaner.
WDYT?

@akloss-cibo
Copy link
Contributor Author

At least in our environment, we do have some secrets with some labels that we'd like to copy, so having a feature flag around the entire capability isn't useful for us. Listing labels to copy in an environment variable or JVM system property would work okay for us, but it takes control over what labels are copied out of the users hands, which seems less useful. I couldn't find the use case #41 is trying to address, so I'm not sure what would make the most sense there.

@akloss-cibo
Copy link
Contributor Author

We've replaced the key parts of this functionality with a mutating webhook which removes the undesirable labels. We're just accepting that the generated Secret doesn't have an ownerReferences entry for the Vault that created it. :sadpanda:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants