Support workload-bound secrets
Open
Nobody has claimed this yet.
authentication
enhancement
tech-debt
- Dominant language
- Go
- Stars
- 2.2k
- Forks
- 300
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 184
Description
Summary
Support secrets that are tied to and managed by a single workload.
Current pain points
- There is no differentiation between user created secrets and workload created secrets. This makes it impossible to clean up workload created secrets after a workload is removed.
- Secrets are available to be shared across workloads, preventing us from storing certain types of credentials, like access tokens.
Related Issues
Namespaced secrets are the first step to solving the following issues:
Implementation
This requires an RFC before starting implementation.
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
Begin with the requested RFC rather than implementation, using issues #1747 and #3377 as context for namespaced secrets. Define how workload-created secrets differ from user-created secrets, how sharing is restricted, and how cleanup works when a workload is removed. The issue is ready for implementation only after the RFC is agreed upon.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100