Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow DSN to retrieved some a separate secret #683

Closed
4 of 5 tasks
dlahn opened this issue May 16, 2024 · 5 comments
Closed
4 of 5 tasks

Allow DSN to retrieved some a separate secret #683

dlahn opened this issue May 16, 2024 · 5 comments
Labels
breaking change Changes behavior in a breaking manner. feat New feature or request.

Comments

@dlahn
Copy link
Contributor

dlahn commented May 16, 2024

Preflight checklist

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

@dlahn dlahn added the feat New feature or request. label May 16, 2024
@Demonsthere
Copy link
Collaborator

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
Copy link
Contributor Author

dlahn commented May 21, 2024

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

@Demonsthere Demonsthere added the breaking change Changes behavior in a breaking manner. label May 28, 2024
@dlahn
Copy link
Contributor Author

dlahn commented Jun 5, 2024

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

@Demonsthere
Copy link
Collaborator

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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change Changes behavior in a breaking manner. feat New feature or request.
Projects
None yet
Development

No branches or pull requests

2 participants