Don't enforce DSN in secret

[toonvanstrijp]

Preflight checklist

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

Describe your problem

Right now a lot of ory products use a DSN to connect with the database. This is fine, however it's causing configuration issues when you want to use a existing secret that only contains the username and password for example.

Describe your ideal solution

The ideal solution would be to modify the helm chart so that it doesn't enforce the DSN. This way we could set it manually and have more control over how this DSN is provided.

Workarounds or alternatives

The current workaround involves creating the DSN secret beforehand or with a initContainer or job.

Version

v0.20.0

Additional Context

No response

[Demonsthere]

Hello there, The core thing causing this behaviour is that the value of DSN is required at startup of the container/pod. You could technically set the DSN to be memory with helm install, edit the secret and then rollout the deployment. Could you explain a bit more what is your scenario?

[toonvanstrijp]

@Demonsthere thanks for the quick response. I can understand that the DSN is required. Your solution however doesn't provide the same direct usability of and existing database secret created by our operator.

There are indeed work around but this requires extra steps etc. To solve this it would be cool if we can extend this helm chart so that settings this DSN property is more flexible.

I've already worked on a fix for this, this makes use of the tpl function of helm so that we can combine multiple secrets in the DSN environment variable like this:

  kratos:
    autoMigrate: true
  deployment:
    extraEnv: |
      - name: DATABASE_HOST
        value: {{ .Values.database.host }}
      - name: DATABASE_PORT
        value: "{{ .Values.database.port }}"
      - name: DATABASE_NAME
        value: kratos
      - name: DATABASE_PASSWORD
        valueFrom:
          secretKeyRef:
            name: {{ .Values.database.secretName }}
            key: {{ .Values.database.passwordKey }}
      - name: DATABASE_USER
        valueFrom:
          secretKeyRef:
            name: {{ .Values.database.secretName }}
            key: {{ .Values.database.usernameKey }}
      - name: DSN
        value: postgres://$(DATABASE_USER):$(DATABASE_PASSWORD)@$(DATABASE_HOST):$(DATABASE_PORT)/$(DATABASE_NAME)

[Demonsthere]

I do have the feeling that this is over engineering a bit. So, in your situation, your DB provider gives you a set of values that you'd like to supply on installation? If that is the case, maybe a better solution would be to generate your own secret with the constructed DSN and use it in the chart with .Values.secret.nameOverride

Alternatively I'd see a template function which would construct the DSN from supplied data like

{{ if .Values.secret.constructFromValues }}
- name: DSN
  value: {{ include "kratos.constructDSN" }}
{{ else }}
  valueFrom:
    secretKeyRef:
      name: {{ include "kratos.secretname" . }}
      key: dsn

[toonvanstrijp]

@Demonsthere Well the thing is that our DB provider postgress-operator provides a kubernetes secret. So to pass this down to kratos. We either need to create the secret manually, or change this chart to be a bit more flexible. The reason I went with using tpl instead of toYaml is that this offers more freedom in how we compose the env's for the deployment.

We currently have the kratos chart in a subchart. Withing this chart we add extra template files such as routing rules etc. (We're using istio as our api gateway).

[Demonsthere]

I understand, in your case the best approach would be to have an intermediate job that prepares stuff for kratos, but I can understand why you may not to do it this way and have the logic in the chart. My idea would be then to enable 2 functions in the chart

• constructDSNFromValues
• constructDSNFromSecret

Both would use a predefined template <db>://<username>:<password>@<service>:<port>/<database>?<db_params> and we can either construct it from values given into the chart (which can be an antipattern, as you have secrets there) or point at keys in a secret and get the values from there (possibly with a simple init container).

This would allow for much more flexibility imho

[MOZGIII]

The most flexible way is to simply allow omitting the DSN, and letting the user to pass it via extraEnv

[github-actions[bot]]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️