bitnami / bitnami/sealed-secrets
pod restart required to detect a new/updated secret with label 'sealedsecrets.bitnami.com/sealed-secrets-key: active'
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 9.3k
- Forks
- 777
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 30
Description
**Which component**:
controller
**Is your feature request related to a problem? Please describe.**
If I create/update a key/secret for sealed secrets to use, with the appropriate label (see above), sealed secrets should pick up on that new key. Instead, I have to delete the sealed-secrets pod before it will notice the secret.
Imagine the secret is being created via an external-secret so it may not exist when the sealed-secrets pod is started. At some point, the external-secret may be updated, and sealed-secrets will not notice the secret has been updated.
**Describe the solution you'd like**
sealed secrets could have a controller thread which watches for changes to secrets and handles loading/updating them as appropriate
**Describe alternatives you've considered**
- using reloader/skater to delete the sealed-secrets pod to force a reload
- i used an initContainer to wait for the secret to appear, before starting allowing the pod to load ... this was good but didn't handle the use case where the secret was updated
**Additional context**
we shouldn't have to rely on a third-party solution
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the controller's handling of Secrets labeled sealedsecrets.bitnami.com/sealed-secrets-key: active and trace how keys are loaded at startup. Check how the controller currently responds to Secret changes; done means newly created or updated labeled Secrets are detected and used without restarting the pod.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100