Sealedsecrets controller unseal namespace-scope secrets with a list of namespaces about sealed-secrets HOT 5 CLOSED

This defeats the purpose of sealing scopes altogether, as it would allow users to deploy SealedSecrets they should not have access to in their namespaces and see the contents. If you require your sealed secrets to be read in different namespaces, you can use the cluster-wide sealing scope.

from sealed-secrets.

We do want the namespace scoped sealing strategy, but we have some shared secret values(of course also have namespace specific secret values.). For those shared secret values, it is just don't make sense to seal them repeatedly for all the namespaces.
For example, I modified the shared secrets' values, I have to change sealed values for all namespaces.

from sealed-secrets.

But what you propose defeats the purpose of the namespace scoped sealing strategy. When you use the namespace scope you want your secret to only be decrypted in that namespace, so that if a user deploys your Sealed Secret on a different namespace they can't decrypt the secret.

If we add an annotation like the one you propose, that user could just annotate your Sealed Secret with the name of the namespace the secret was sealed for, deploy it on their namespace and decrypt it. You have lost that extra security the namespace scope provides and your Sealed Secret has effectively become cluster scoped.

Sealed Secrets are intended to have one scope, it's a security feature. If you want to share Sealed Secrets among namespaces, you have to use a cluster wide scope.

from sealed-secrets.

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.

from sealed-secrets.

Due to the lack of activity in the last 7 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.

from sealed-secrets.