feat: Add mechanism to disable `externalSecret` metadata propagation about external-secrets HOT 9 CLOSED

spec.template was implemented and merged. The secrets created by the controller use the labels/annotations from the template field and not from the ExternalSecret.metadata.

Thank you for your insights!

from external-secrets.

Are we propagating labels and annotations set on the externalsecret resource ie (.metadata.labels and not .spec.template.metadata.labels)? If yes, wouldn't it be better to only propagate those? Similar to how a Deployment and resulting Pod would only use the template.

I agree, if automatic propagation presents a problem, then we can use the nested fields to selectively propagate labels and annotations. My understanding from a bit of debugging of crossplane/crossplane#2121 (comment) was that setting ownerReferences avoided this, so I would want to check a bit further before changing our current implementation.

from external-secrets.

Hmm.. we may need to test this out, but the created secret will have metadata.ownerReferences set, this should prevent ArgoCD from desiring to prune the secret resource. If this is not the case then we can disable propagation through another field.

from external-secrets.

Are we propagating labels and annotations set on the externalsecret resource ie (.metadata.labels and not .spec.template.metadata.labels)? If yes, wouldn't it be better to only propagate those? Similar to how a Deployment and resulting Pod would only use the template.

from external-secrets.

In the case of ArgoCD, the controller can live in another cluster. That's probably why is not using ownerReferences, because the "owner" lives outside the cluster and I think it uses kubectl to manage the resources.

If the ExternalSecret implementes the spec.template for secrets, allowing the users to set the labels, what's the utility of propagating the metadata from the ExternalSecret instance?

@Flydiverny currently both annotations and labels are carried over at

IMHO, Replicate the behaviour of a ReplicaSet with the pod template is more user friendly, as ExternalSecrets will behave the same way as other k8s resources and will allow the user to set just the labels they need for their use case. Having automatic (and unavoidable) propagation of metadata may lead to undesired scenarios like the one discussed in this issue and make the controller unusable.

from external-secrets.

@moolen any way to work around this from the operator's end? We have a very similar usecase with pruning based on labels and I'd rather avoid changing every single kind: ExternalSecret to workaround this if I could avoid it 😄

from external-secrets.

Hey @bcha, there's no controller-level mechanism like a flag to change the behaviour.
Out of curiousity, what's your use-case / context?

from external-secrets.

We're using GitOps & deploy with https://github.com/Shopify/krane

Now the problem is that krane also does pruning that could be controlled with labels, but as the kind: Secret created by ESO by default get the labels from kind: ExternalSecret -> They're always up for pruning when we do deployments. It isn't a massive issue as ESO just creates the secrets again, but in practice it results in some "failed" deployments & extra headache.

We could use this spec.target.template.metadata workaround, but we've got a lot of ExternalSecrets & I was kinda hoping that there was some other way to do it.

from external-secrets.

No, there isn't. If you're running a policy engine like kyverno or OPA/Gatekeeper then you can implement that with a mutating webhook.

from external-secrets.