-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Description
Describe the solution you'd like
Enable a mechanism to disable externalSecret label and annotation propagation (total or selective).
What is the added value?
In some scenarios, labels are used to determine ownership of resources, especially when they are managed from outside the cluster. For example, some GitOps operators, like ArgoCD, use labels to identify what resources are part of a particular ArgoCD application. Propagating the labels to the resources created by the externalSecret instance will transfer the ownership of the Secrets created to ArgoCD.
Give us examples of the outcome
When the externalSecret, created by the GitOps operator, propagates the labels, it adds metadata to the Secret resource that will end up with ArgoCD taking the "ownership" of the resource. In a GitOps scenario, that leads to the deletion of the resources, as is not present in the repository. That triggers the recreation of the secret by the external-secrets operator, and the loop goes on. Using proper ownerReferences is not viable as in multi-cluster scenarios, the GitOps operator manage the resources from an external cluster. This is one of the scenarios that we found, put probably there are other scenarios where this propagation may lead to an undesired behaviour.
Observations (Constraints, Context, etc):
Is not really tied to a particular version.