Ability to append values to the secret name within a namespace about sealed-secrets HOT 4 CLOSED

I've updated to title to clarify that our case the differently named secrets are always required in the same namespace. I believe some other companies deploy feature branches to new namespaces so this would not deal with that problem but it's a start.

from sealed-secrets.

Brainstorming:

• we have "exact namespace/name" (default) and "cluster-wide=true" (with annotation) at present. I think it would make sense to add "namespace-wide=true", and that such an option would be reasonably easy to understand the tradeoffs.
• we could add a pattern match/substitute for name and/or namespace, that effectively encompasses everything between "exact match" and "don't care". I like the generality, but in practice I don't know of any common RBAC policies/mechanisms that allow creating namespace/resources within specified name prefixes (or patterns) like this. Afaik, the available k8s mechanisms are either "can't create $resource", "can create $resource called $this", or "can create $resource with any name", so I share your concern that adding a pattern match adds complexity and false security.
• we could add an annotation that enumerated specific allowed namespaces/names. This is kind of like the pattern match, but I think is closer to the capabilities of what RBAC policy can also describe. Not sure if that usefully covers your use-case though.

from sealed-secrets.

Out of those ideas, I think the first option about namespace wide secrets makes the most sense. That's generally how permissions are modelled anyway and the context switching to that option seems relatively straight forward from an analysis point of view. So we'd end up with 3 different permission models. Perhaps even the annotation could be something like sealedsecrets.bitnami.com/permission-model or similar with allowed values of cluster, namespace, secret (default)?

Even though it was my initial idea, I've gone off the pattern thing. I think it's too complex. I agree with your assessment about other RBAC mechanisms. Kubernetes RBAC supports exact match resourceNames and probably won't support such expressions. See kubernetes/kubernetes#56582 and kubernetes/kubernetes#56603.

The last idea sounds interesting but would not work for our particular case since the version changes frequently, for some repos on every commit. So it'd be pretty much the same in terms of how many times we need to re-seal a secret.

from sealed-secrets.

Will look to submit a PR for this soon to allow setting different access control modes.

from sealed-secrets.