Secrets already b64 encoded in values.yaml?

[cognifloyd]

I'm migrating an st2 cluster over to this helm chart. I have several secrets that are already b64 encoded, and I'd rather leave them b64 encoded in the values file that I save in git.

Is there a good way to support secrets that are already encoded instead of running all the secrets through b64enc ?

A few examples lines:

https://github.com/StackStorm/stackstorm-ha/blob/aabf3dcb201a86d5ddf6717cffc9dd76267181b5/templates/secrets_datastore_crypto_key.yaml#L19

https://github.com/StackStorm/stackstorm-ha/blob/aabf3dcb201a86d5ddf6717cffc9dd76267181b5/templates/secrets_ssh.yaml#L18

https://github.com/StackStorm/stackstorm-ha/blob/aabf3dcb201a86d5ddf6717cffc9dd76267181b5/templates/secrets_st2chatops.yaml#L18-L19

https://github.com/StackStorm/stackstorm-ha/blob/aabf3dcb201a86d5ddf6717cffc9dd76267181b5/templates/secrets_st2apikeys.yaml#L17

A PR that fixes this might also address: #14, #16

[cognifloyd]

203 addresses #14 and #16, but doesn't quite address migrating secrets created outside of helm into this. I might have to just do some manual finagling for the initial migration to stackstorm-ha. Any other ideas on making #203 more robust?

[cognifloyd]

helm-secrets is a much better solution than passing base64 encoded strings through values. So, that's what I did. Passing base64 encoded strings offers a false sense of security because base64 "looks" encrypted without being encrypted. As such, I'm going to close this.

[ericreeves]

Honestly, what really should happen is these things should be pulled from proper Kubernetes secrets. That is the most flexible solution using the appropriate mechanism. helm-secrets is a bit of a hack IMO. I deploy with Flux, and cannot use helm-secrets, so I had to resort to encrypting a patch file with sops and applying it with kustomize prior to the helm deploy.

Raw secrets in values.yaml is just a bad practice. Kubernetes secrets exist for a reason! We should use them!