sagikazarmark
commented
2 years ago I'd be happy to work on this if it speeds things up and if we can decide which way to go.
I have a third option to consider: introduce an entirely new option for a secret that defines both access and secret key. The advantage is that it's probably easier to implement and that we can introduce a secret type for validation.
OrlinVasilev
Is your feature request related to a problem? Please describe. When using S3 for registry storage, the access key can currently only configured inline in the CRs (the secret key can be configured from a Kubernetes secret).
This is a bit problematic from a secret rotation perspective: updating the secret is not enough, the CR needs to change as well. There are tools that can synchronize secrets from external stores, but they generally can't change CRs (and that wouldn't really work well with GitOps either)
Describe the solution you'd like Allow configuring the access key from a secret as well.
Describe the main design/architecture of your solution I can imagine a number of different solutions:
Introducing a new secret type has the advantage that it can be validated (similarly to other secret types). It's also more future proof, although it does introduce a breaking change down the line (deprecation first, so can be easily added).