Disable Secret Generation

[bmarick]

Hello and thanks for all of your hard work on enabling stackstorm-k8s. Our team uses GitOps to deploy and update our instance of Stack Storm. We would like to use Sealed Secrets to store the secrets used in our deployment. However, the Helm chart currently does not support that.

I am happy to submit a PR to disable secret generation if turned off in the Values file. But I would like to confirm if that type of change would be appreciated?

[arm4b]

We have a lot of the configuration at this moment where the secrets could be injected into StackStorm, like https://github.com/StackStorm/stackstorm-k8s/blob/a2a9e1c6e5a2c6e5d8cf03f0b6086c7864688d4a/values.yaml#L90-L94 and more.

Would be definitely great to make the chart work nicely with the https://github.com/bitnami-labs/sealed-secrets.

Looks like sealed-secrets can manage the existing secrets: https://github.com/bitnami-labs/sealed-secrets#managing-existing-secrets Did you try to explore that? Let us know what's still missing and let's find something that would work. Looking for ideas on how to make that with minimal changes and consistent with the Helm Values.

[bmarick]

I will test it out using sealed secrets. In particular I was looking at disabling the following file:

• secrets_st2auth.yaml

[bmarick]

@armab So I just confirmed that the secrets are regenerated/change each time a release occurs. The problem is that Sealed Secrets does not update/revert the secret after it is changed. Because I deploy my solution via GitOps using ArgoCD. That means i will have to revert the password on each change. So consideration of disabling the generation of secrets for st2auth and datastore-crypto-key would help resolve this issue

[arm4b]

Thanks for looking closer at this!

I see overall we're generating values for password, datastore_crypto_key and ssh_key: https://github.com/StackStorm/stackstorm-k8s/blob/a2a9e1c6e5a2c6e5d8cf03f0b6086c7864688d4a/values.yaml#L49-L66

@bmarick any other secrets you're overriding in your environment?

https://github.com/bitnami-labs/sealed-secrets#managing-existing-secrets allows managing existing secrets if there is an annotation sealedsecrets.bitnami.com/managed: "true".

What if we change the behavior to skip auto-generation if this specific annotation is present for these secrets? https://github.com/StackStorm/stackstorm-k8s/blob/master/templates/secrets_st2auth.yaml#L20 This also means there's a need to allow injecting custom annotations for the secrets.

Will it help or does an option to disable secrets autogeneration altogether looks better?

[arm4b]

@cognifloyd any other ideas on how to compose it nicely together? Maybe providing custom secret names in Helm values that are managed outside of the chart?

Let's think about the options.

[bmarick]

@armab

1. any other secrets you're overriding in your environment? Our team currently only sets the password, but we would like to start using the datastore_crypto_key as well

2. I like the Idea of supplying secret names to the helm chart as a way to manage them outside of the chart! I actually use this process for other helm harts I use/manage.

[arm4b]

I actually use this process for other helm harts I use/manage.

Nice! Yeah, it sounds like a conventional way of doing things in the Helm chart community. +1 then

@cognifloyd thoughts on naming and placement for the potential new helm values?

[cognifloyd]

I'm not opposed to allowing definition of external secrets. We would just need to document requirements for those secrets so that things like our initContainers can still work.

[bmarick]

I'm not opposed to allowing definition of external secrets. We would just need to document requirements for those secrets so that things like our initContainers can still work.

I will work on a PR based on other helm charts I have used that allow external secrets

[cognifloyd]

@bmarick How is it going? Have you been able to work on adding external secret support to the chart? Is anything blocking you? Thanks!

[bmarick]

@bmarick How is it going? Have you been able to work on adding external secret support to the chart? Is anything blocking you? Thanks!

My work took me in a different direction for a while. I am about to start working on this right now

[guzzijones]

I would be willing to work on adding external secret support for the datastore_crypto_key if we can remove the autogeneration on install. I would add documentation on how to generate the secret to the docs as well so it can be used on installation.

Having the datastore_crypto_key deleted on uninstall and then recreated on install is a pain . I recently had to uninstall and reinstall due to ingress changes that wouldn't apply using helm upgrade I ended up setting the datastore_crypto_key manually from a back up of it. (I had read the docs that it gets recreated on installation)

[guzzijones]

Ah, I see your note here I can add a new key to values.yaml for datastore_crypto_key_secret_name and if that is set skip creation of the secret altogether and just use the supplied name everywhere.