remove SecretGenerator due to security concern

[Liujingfang1]

Need to address the security concerns of Kustomize in order to integrate it into Kubectl
kubernetes/enhancements#684

SecretGenerator is one concern since it can trigger arbitrary command that users put in.
The solution is to remove it from Kustomize.

[jcassee]

@Liujingfang1 I'm kind of shocked to learn SecretGenerator is going away. Do you intend to replace it with a substitute? My use-case is using sops to load encrypted secrets into Kubernetes.

(I tried to access the security document you linked to in kubernetes/enhancements#684, but could not read it.)

[Liujingfang1]

@jcassee The doc is available to kubernetes-sig-cli@googlegroups.com

[jcassee]

Okay, I was mostly interested in the context of the decision and whether you have any advice for current users of SecretGenerator. (I thought the plan was to only remove commands from the kubectl integration, but keep it in kustomize. But maybe the plan is to drop kustomize completely?)

[Liujingfang1]

The plan is to remove SecretGenerator entirely from Kustomize.

[jcassee]

Okay. So what is your advice to users of the feature? I currently rely on it for my Kubernetes deployments.

[oboukili]

Hello, we have a similar approach using sops, a nice workaround regarding this issue would be to allow secretGenerator to behave exactly like configMapGenerator (e.g. providing a 'files' list), so that we could leverage out-of-band automation to generate those files.

That would export the reponsability of executing the creation commands out of kustomize, while still being able to use the secretsGenerator.

[jcassee]

@oboukili Yes, that could work. The nice thing about commands is that the unencrypted values never hit the disk, so there is nothing to clean up after deployment. I do see the danger with commands (especially in remote bases), but I thought they were only removed from the kubectl build (#683), which I thought was a good compromise. I'm sad to see them go.

[oboukili]

@jcassee I think you're planning on exposing those decrypted files onto a kubernetes secret, in that case that's true it does hit the disk.

As a workaround, I thought of having a different deployment workflow that would allow us to store those encrypted files onto a kubernetes secret and use an init container to decrypt and send those to an Hashicorp Vault KV backend on-the-fly (very specific use case I concur, and one that pulls yet another dependency).

I understand that 'command' concern as well however.
It would still be nice to have such a 'files' feature support for secretGenerators to retain using secrets and all the goodies that come with them.

[monopole]

Initially (back at the beginning) the notion was to have kustomize generate a k8s Secret the same way it generates a ConfigMap - by reading data from disk (as @oboukili and @jcassee suggest).

Placing the secret on disk offends certain folks because it raises fundamental questions of security - who has access to the file, how do we know it's deleted, etc. Having kustomize read a command to run to get the secret, rather than demand the secret be on disk, addressed that risk by introducing a different one.

The secret eventually ends up on disk (in etcd), plain to see to an operator with access to etcd (or to any backups of etcd), or with the ability to run a pod (they can just fire up something to read the secret and print it). If that operator is the person trusted to apply resources to the cluster, one could argue that this person should be able to use text tools to generate k8s objects from disk data and manage cleanups.

I'm (still) in favor of treating them like ConfigMaps, since I see k8s Secrets as the cluster equivalent of a cheap padlock. Don't use them for anything you really care about. As an operator, would you store an access password to a bank database in a k8s Secret?

I don't know how conclude this debate with something everyone agrees is secure (other than feature removal obviously).

[chrishiner]

I also use the SecretGenerator functionally, but I've been tinkering with extending kustomize to handle SealedSecrets from https://github.com/bitnami-labs/sealed-secrets by making a SealedSecretGenerator.
I'm not using the command options, just using the generator to rename the object from a patch file and all the references, so I get the nice re-deploy when the secret changes feature.
Could the security issue be fixed by removing the command options and leave the generator to create blank secrets to fill in from patches?

[monopole]

@chrishiner So the patches still need to come from somewhere (disk, command, whatever) so seems like the same secret mgmt problem exists. Plus mutating a secret or configmap already in k8s is usually a bad idea. That's why we make new ones with new names (generated from a hash of the contents), then change deployments to point to them. Please feel free to start an issue (or KEP) for how one might use kustomize in a SealedSecret workflow. Sounds good, but this isn't the place for those details.

[Liujingfang1]

Two approaches are proposed to fix the security risk in SecretGenerator.

• remove SecretGenerator entirely remove SecretGenerators from Kustomization.yaml #694
• make SecretGenerator load data from files replace commands/envcommand by DataSource in SecretGenerator #703