Feature Request: Multiple key support

[mikebryant]

We have many kubernetes clusters. For lots of secrets, we encrypt them per-cluster, as they're unique to that cluster.

For some secrets, we would like to encrypt them once, and have all clusters be able to decrypt those secrets. Examples might be, the newrelic or pagerduty API keys. Each cluster would have the dynamically generated key that's unique to it, and we would like to use that key to encrypt the global decryption key.

This could be modelled by allowing SealedSecrets to optionally reference a different decryption key, potentially?

[anguslees]

Interesting use case - makes sense. Previously I had considered multiple key support to be important for key rotation, but this implies we will want other keys that persist indefinitely for other reasons.

My plan is to replace the current single key with a k8s label selector, and use all the keys that match (just try them all until one succeeds - we know when it works because the RSA-OAEP input param will match)

[mellena1]

I'd like to throw another use case in here too that I think would work with the suggested solution as well.

We would like to have a key per namespace basically. Our projects are planned to be separated by namespace, and we don't want every project to have the same key (as to not have people on one project be able to grab secrets from another). So I think a label selector would work well here for us. Could put a key in each namespace and label it based on that.

Any thoughts?

[scottrigby]

I was about to make an issue from the chat at #TGIK8S at kubecon - but this is already here 👍 Also cross referencing https://github.com/bitnami-labs/sealed-secrets/issues/101#issuecomment-389380289. Looking fwd to checking this out more soon!

[johnraz]

@mellena1 Isn't this usecase already covered today as the namespace used to generate the initial secret resource(the cleartext one) is used at encryption time to make sure that the secret can't be decrypted to another namespace by the controller later on. /cc @anguslees to be sure I'm not mistaken here 😉

[mellena1]

@johnraz Yeah I think you are correct in that. I realized that after I made that post. So more info on how that works would be cool!

[anguslees]

@mellena1 right, your case above is covered by the existing namespace verification when decrypting. See everywhere that mentions "namespace" in the README (in Usage and Details sections) ;)

I would be interested in where you (and the 3 +1's) wanted to find more information on this, because the existing README isn't working very well - this is the number-1 most misunderstood aspect of sealed-secrets. If you have suggestions, perhaps reply in a new issue so we don't further pollute this one... (and thanks in advance)

[johnraz]

I created #136 to address the documentation issue.

[github-actions[bot]]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[aslafy-z]

Issue is not stale