Ability to trigger secret refresh about external-secrets HOT 9 CLOSED

I absolutely see the use-case! Is there something which you can not do through the Kubernetes API server? I'm a little hesitant adding this kind of feature because it involves duplicating a lot of features that are already present in the API server (authentication, authorization, TLS, list by label, cross-referencing resources).

I mean, it's a simple kubectl annotate externalsecret foobar rotate=$(date +%s) away. You can do this via CronJob or some Kubernetes SDK.

Every other user presumably needs other rotation criteria (rotate by secret path/label/namespace/ns-by-selector/es-name/...) and in the end all that ends up in this operator while it can already be done through the API server.

I definitely see a lack of documentation here like a guide with examples or a blog post explaining how to do that.

from external-secrets.

From the docs

This command will compare the version of the configuration that you're pushing with the previous version and apply the changes you've made, without overwriting any automated changes to properties you haven't specified.

Apply basically ensures that the stuff from your repo is exactly how you intend it to be while leaving all other fields as they are.

from external-secrets.

@moolen @mcavoyk is this somethink that makes sense in ESO?

@cep21 Would you be willing to implement this an sending us a PR?

from external-secrets.

This project has the advantage of a refreshInterval that is definable per ExternalSecret rather than at a controller level, so polling can more easily be reduced compared to the polling in KES. I think some more controls over the provider rate limiting could be added to the SecretStore spec, but I'm unsure how well a webhook fits into our current operator.

from external-secrets.

We have a very large cluster and lots of secrets. What's the problem with webhooks like

• /refresh&secret= that refreshes the external secret at this namespace/name
• /refresh&external_path=<secret_path> that refreshes all external secrets that reference a secret at a path

from external-secrets.

I agree @moolen, I should have been more specific that my previous statement was in-regards to supporting a specific webhook service for the operator.

A refresh action is already support based on the current implementation of ExternalSecret. Any update to the ES, like an annotation being added/updated, will trigger a refresh of the secret. This should be added to the documentation as mentioned.

from external-secrets.

We manage our kubernetes objects via gitops (Flux). It's a bit more annoying to setup a pipeline from SecretsManager -> Clone Repo -> Modify file ->Git Push -> Bot PR accept -> Git Merge -> Push than it is to setup SecrestManager -> webhook, and it will pollute our git repository with a bunch of commits, but it's not the end of the world.

It's good to know the annotation does a refresh. I agree with others it would help to move it from "implementation detail" to "guaranteed behavior".

from external-secrets.

I think the annotation doesn't need to be committed in the repo, i'd say it's kind of similar to the kubectl/last-applied-configuration annotation or generated values (uid, creationTimestamp, managedFields..). Yes, they are important for the cluster and something makes use of it but it shouldn't be stored in a git repo because it's something that belongs to the cluster where the resource is located at.

Flux and ArgoCD use apply semantics to update resources, so i don't think it's an issue to just add a label. I suppose it won't even notice something has changed.

from external-secrets.

This is great information. So annotations are ignored by apply and not unsynced normally by gitops? Thanks for the info!

from external-secrets.