Allow DSN to retrieved some a separate secret

[dlahn]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe your problem

We would like the ability to retrieve the DSN from a separate secret. As it is all bundled into one secret, this isn't really possible if we are using an external secret for all Ory secret values. We aren't even able to override the environment variable when an external secret is defined. We define an external secret in the chart so that we can feed in our own values for the SECRET_* values.

Describe your ideal solution

The ability to specify a separate external secret for DSN would resolve this issue.

Workarounds or alternatives

The only way to workaround this (from what I can see) would be to let Ory create its own secret, but then we would lose control of being able to send in the other values.

Version

0.42.1

Additional Context

No response

[Demonsthere]

Hello there!
After some consideration, I think the current chart does support your use-case, even though it may require a slight workaround:

1. Using the chart values define the required secrets and a initial, fake DSN (basically set it to a foobar value)
2. Using the extraEnv inject into the pods a new DSN value which takes data from your pre-defined secret
3. The result should be that the DSN env overrides the config value and the application consumed your supplied DSN value, only defaulting to the foobar if the target secret is missing or not accessable.

[dlahn]

The issue is that if we add extraEnv, it will create duplicate environment variables and it will not validate.

[dlahn]

@Demonsthere Any thoughts on this? If you see a good way forward here, I am happy to raise a PR.

[Demonsthere]

Hi there!
To be honest, I have been trying to reproduce the setup without changes to the chart (yet), and was able to get it to work. As you say, you get duplicated envs, which can raise a warning during manifest rendering, but the order of the envs is idempotent. Meaning that you actually can use a base fake dsn and override it using the extraEnv clause.

As for a more elegant solution, i was designing something in the pattern

secret:
  enabled: true
  create: true
  dsn:
    enabled: true
    create: true

where enabled means that we use/manage the value using the chart and create means that we create the secret using the chart. This should allow for more granular control and split the dsn from the rest of the secrets. My only issue is how to do it without a breaking change, so that the default behaviour is as now 🤔

[Demonsthere]

fix released in https://github.com/ory/k8s/releases/tag/v0.44.0