https://dagster.io/ logo
Join Slack
Powered by
Hey, I would like to commit my helm values files t...
# deployment-kubernetes
s
Hey, I would like to commit my helm values files to git, but I'm not feeling comfortable to commit passwords. Is it possible to turn off secret generation for helm generated secret files like 
postgresql-password
in the official helm chart?
n
I'm not sure I see any generation?
I populates the secret if a value is present but that's it
s
If I remove the password it still generates a secret config regardless (using the default secret 
test
)
n
Sure, I guess I'm not sure what you're asking for
Helm doesn't really offer a way around having secrets in the clear in your values. Best bet is the helm-secrets plugin and encrypting them before committing (usually leave the bulk of it in plain and have just the secret values in their own encrypted file)
s
That's fine, what I want is the ability to exclude the generated secret or override it.
n
The chart does not support that directly. You can override it with an output filter though
s
thanks this is exactly what I'm thinking about using kustomize to post process the manifest
thanks a lot for helping 👍
n
👍 Just beware that Kustomize mostly can't knock out whole objects.
Which can be annoying if you want to use SealedSecrets or similar
s
I just need to add an annotation that the secret is managed by kubeseal
so the sealedsecret can overwrite it
n
If you're using Helm manually, yes. If you're using something like Argo or Flux you can get cranky sync behavior 🙂
(with argo you can set a Skip annotation on the secret)
s
n
Okay so what you probably want instead is 
<http://argocd.argoproj.io/hook|argocd.argoproj.io/hook>: Skip
That makes Argo pretend the object is always in sync and ignore it 🙂
s
but I still need kustomize to put on the secret, right?
n
Yeah, I mean you need some kind of post render filter and kustomize is probably the easiest 🙂
👌 1
If you want to write a "sed command from hell", more power to ya 😉
s
tempting, but I already spent too much time on this 😄
n
Piecing together a good secrets workflow is definitely one of my least favorite parts of k8s
Not sure I would even call sealed-secrets "good" but it's what we have, so it goes.
s
same here, sealed secrets make it work, but if you want to change it something....
m
the "sed command from hell" solution isn't actually that bad if you use 
envsubst
... There's probably a better way to do this, but I've been using local env variable substitution (and made some scripts for pulling env values to a .env file). e.g.: 
source ./.env && helm upgrade --install dagster-release dagster/dagster -f <(envsubst < values.yaml)
👌 1
values.yaml just has env variables in it for substitution - e.g.: 
postgresqlPassword: "${DAGSTER_PG_PASSWORD}"
s
thanks for sharing
w
i also ran into this; I ended up just forking the helm chart and making some changes to allow passing in an independent secret for postgres: https://github.com/PenguinToast/dagster/commit/c99d2f34c15aa7fec29d25e7294a8fa5d9699365
👌 1
but never got around to making a proper PR for this change
r
ah nice @William Sheu - made a similar change with the introduction of 
.Values.global.postgresSecretName
to pass down the secret name to one of our subcharts https://github.com/dagster-io/dagster/blob/master/helm/dagster/values.yaml#L8-L9
just need to add a toggle to disable generating the secret in our helm chart
👍 1
w
@rex made a pull request here: https://github.com/dagster-io/dagster/pull/3941 -- wasn't sure where to put the toggle value; didn't really make sense in either 
global
or in 
postgresql
(since that specifies subchart values) -- happy to make changes here if you think there's a better place for it
3 Views
Open in Slack
PreviousNext
Powered by