https://www.ory.sh/ logo
Join Slack
Powered by
<@U04PDLR0P37> I saw there was an issue raised on ...
# contributors
m
@enough-yak-81379 I saw there was an issue raised on the new version of the helm chart, that it affects users using existing secrets. It looks like they opened an issue when the same change was made in Hydra some time ago. I wonder if there is maybe a more elegant solution that would still allow the DSN to be pulled from a separate secret. Maybe making it configurable to select a separate secret for DSN in the secret section?
👀 1
alternatively, it may just be fine to use the same pattern Hydra has been using for some time.
though I assume the use case to being able to set DSN as extraEnv is to set it from another secret entirely (which is our case.)
e
not only. The secretnameOverride allows you to use an existing secret that is sideloaded with the chart The Env overrides allows for more customization like construction of the DSN from envs injected into the system at runtime, or even supporting different dsn for the main application and for example courier (you can set different connection parameters for them, as by default they would reuse the same dsn string)
i need to expand the test scenarios to cover a wider array of options, as this is a regression that is not severe, or rather easy to workaround, but still brakes stuff for regular users 😞
i think i managed to fix it 🙂
m
but now I can't use an external secret for the other values 🤣
I think the major issue for us is that dsn is coupled into that secret in the first place
Ideally we would create an external secret containing the cookie secrets, and then one for the database url.
e
right, but you should be able to do it using envs that reference custom secrets, right?
m
yes I suppose we could do that.
actually maybe not. These gets loaded from the kratos.secretname
with no way to override them
e
could you open a issue with your config and desired state? That will make it easier for me to see how it fits into the current pattern of managing secrets
👍 1
i’m kinda reluctant to split the secret into a dsn and “the rest” while still maintaining a sane default installation path 😅
m
I agree with you. I think it might be helpful to have the possibility to do it though. As often DB secrets come from a completely different place.
The problem is we automate everything, and I want to be able to just inject in the correct thing from the DB made in Terraform, and there isn't any easy way to do this when it's all in one secret.
e
sure, i understand 🙂. Will try to see how can we provide the option without too much regressions
10 Views
Open in Slack
PreviousNext
Powered by