Questioning wisdom of making ciphertexts public. about sealed-secrets HOT 2 CLOSED

I agree with your general point about defence-in-depth. However, the goal of sealed-secrets is precisely to turn Secrets into a form that is as "safe" to expose as the rest of your k8s configuration - so it can be used by (eg) open organisations that manage configuration by publicly readable git repositories.

If you have a suggestion, I would welcome some text for the README that communicates a more nuanced level of concern here. Perhaps we talk about the dangers of future-exploits (as you suggest), and then recommend users make the SealedSecret as available as the rest of their config? (ie: a paranoid organisation also wouldn't make their infrastructure setup details generally available, whereas an open-by-default distributed/transparent community project might choose to do so)

Regarding forward-secrecy, my hope with SealedSecrets was that it would encourage faster password rotation, since it enables automated "write-only" pipelines. I don't know of anyone who has actually done this using sealed-secrets however (and password rotation is generally an issue across our industry). Again, I would welcome some text for the README to talk about the importance of this too (or more specific bugs/PRs to better enable this use case).

from sealed-secrets.

I don't there are action items here, closing.

from sealed-secrets.