Replies: 2 comments 3 replies
-
First of all, you'll probably have more then enough time to move to a new solution. I'll not drop SealedSecrets support immediately. I understand where you're coming from and you're actually not the first one to articulate the same issues with the deprecation. Being able to split secrets access and deployment into two phases is worth a lot to some people. You're right, the SOPS integration right now requires you to have access to the key/encryption-service while deploying. I'm considering multiple options on how to bring this back with SOPS (or a completely independent solution). The main reason I decided to remove the SealedSecrets integration was actually not the SOPS support. It was the realisation that most parts of it can be achieved with simple templating already (and maybe one or two new generalized features). For example, consider the following kustomzation.yaml resources:
- my-secret-for-{{ my_env_type }}.yaml
# or:
- my-secret-for-{{ target.name }}.yaml This already allows you to include manifests depending on the target. With that alone, you can already implement a solution based on SealedSecret, simply by having multiple SealedSecret manifests manually pre-encrypted with This of course moves the burden of the actual sealing step onto you. It also means that you have to make sure that you put in the correct secret values into the correct secrets before you run Long term, I might implement a feature that allows to run something like "generators" or "preprocessors" on targets. These would be able to fully leverage templating and transform something into something else, e.g. encrypted SOPS var files into SealedSecrets, while respecting all the target settings (e.g. context, args, ...). All this is a manifestation of a philosophy that I try to follow: Only support a core set of features and thus keep the tool as simple as possible, while making these core features as flexible as possible. The SealedSecrets integration did not follow this philosophy very well and was too specific/special in my eyes. |
Beta Was this translation helpful? Give feedback.
-
@Nayruden I'm about to create a PR that adds support for "generators", which will serve as a replacement for the |
Beta Was this translation helpful? Give feedback.
-
First of all, thanks for all your hard work on this, @codablock. I use kluctl at work and at home and it has made my life so much easier -- literally saving me at least a few hours of work each week now.
I saw that the latest version of kluctl (2.17.0) has deprecated support for sealed-secrets in favor of Mozilla SOPS. Admittedly, SOPS is new to me and it definitely does seem powerful/flexible, but it doesn't support our current use case with kluctl, Vault, and sealed-secrets.
Right now we're storing our plaintext secrets in Vault. We use the kluctl Vault source to bring them in when we call
kluctl seal
. Needing to callkluctl seal
is relatively rare, usually just once per deployment after the deployment structure is determined. This also allows for some separation of duties -- not everyone needs access to the plaintext secrets in Vault.Unless I misunderstand something, SOPS won't support this. It looks like kluctl would need to reference the underlying plaintext secrets each time the project is rendered. Thus using SOPS would require us to provide Vault credentials to kluctl every time (we limit Vault logins to 1h), prevent role separation, and complicate our "offline Kubernetes" (and "offline Vault") CI/CD pipeline. A possible workaround would be to move all the secrets into a separate folder, tag, or selectively apply
kluctl.io/delete
(with dummy secret values) in order to skip them unless we explicitly want to create the secrets -- but that brings its own complications.Put another way, the best part of sealed-secrets is the one-way nature of it while remaining a completely valid Kubernetes deployment. I can put the sealed secrets in our source control and anyone with the appropriate permission can throw it onto the Kubernetes cluster with zero knowledge of the underlying plaintext secret or how to get the plaintext secret.
Would it be possible to keep support for sealed-secrets in the future?
Beta Was this translation helpful? Give feedback.
All reactions