-
Notifications
You must be signed in to change notification settings - Fork 401
Trigger from CloudWatch Events -> SNS topic or Lambda rather than polling #127
Comments
This sounds great. We'd ❤️ a PR :) |
Slightly related to this, is it possible to trigger refreshes on a webhook of the service? Then I could set my poll interval really high and do the SNS topic stuff out of band. (It's unclear if SNS subscription needs to be core to the project since a webhook is enough). |
Currently no webhook available but I think it would make sense to add one in some way. Not sure how it should be specified tho. |
Either is fine. The best catch all solution would be a "refresh everything" webhook (also easiest to trigger since you just hit an endpoint and don't care about HTTP body formatting). Honestly secrets update so rarely that it would probably be just fine. It could later be extended to support specific secrets. |
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
/notstale |
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
Nostale |
I don't think this is something we'll include in KES and I think it would be better to start a discussion and possible contribution in the go rewrite https://github.com/external-secrets/external-secrets |
Polling every external secret seems like a lot of unnecessary transactions.
SSM will tell you when a secret is updated via a CloudWatch Event. That event can either:
kubernetes-external-secrets
is subscribed tokubernetes-exernal-event
endpoint.kubernetes-external-secrets
would still poll on start-up, and maybe once every hour or two, just in case.The text was updated successfully, but these errors were encountered: