Are there any recommendations for how to configure secrets within the

selfservice.methods.oidc.config.providers

list for the Kratos helm chart? As mentioned here: https://www.ory.sh/docs/self-hosted/kratos/configuration/oidc#environment-variables The only option seems to be exporting the whole config via:

export SELFSERVICE_METHODS_OIDC_CONFIG_PROVIDERS='[<bunch of json>]'

which isn't recommended in the docs due to the complexity. Is there a recommended alternative? If I can't override a secret that's nested within that list, and overriding the entire list isn't recommended, I wonder if there's a more reasonable option 🤔

Have you used the

secret.enabled: true

flag in your helm values.yml? This should wrap your entire config in a secret

Are you sure that's how it works? I'm looking at the helm values file for

secret.enabled

here: https://github.com/ory/k8s/blob/master/helm/charts/kratos/values.yaml#L60-L65 and it only seems to create a secret with the

secretsDefault

,

secretsCookie

, etc, attributes: https://github.com/ory/k8s/blob/master/helm/charts/kratos/templates/secrets.yaml which mounts them onto the

kratos

deployment as env vars: https://github.com/ory/k8s/blob/master/helm/charts/kratos/templates/deployment-kratos.yaml#L153-L170 but it doesn't seem to manage any of the config itself... unless I'm missing something?

It’s worth trying out. I use that flag and my cookie configs are secret. Unfortunately the secret in k8s is encrypted so I’m not really sure what they consist of when base64 decoded. I’d try it out in a test env. My deployment contains:

- name: SECRETS_DEFAULT
          valueFrom:
            secretKeyRef:
              key: secretsDefault
              name: kratos
              optional: true
        - name: SECRETS_COOKIE
          valueFrom:
            secretKeyRef:
              key: secretsCookie
              name: kratos
              optional: true
        - name: SECRETS_CIPHER
          valueFrom:
            secretKeyRef:
              key: secretsCipher
              name: kratos
              optional: true

hi there 🙂 as @astonishing-morning-18498 mentioned, the secrets should support the file:// clause. I think the recommended approach here would be to load the secret as extra mounts to the pod and set the location in the config. That way you should be able to set the config in the yaml file and don’t need to override it as an env

Thanks for the replies! Sorry I'm still wrapping my head around this... if someone doesn't mind posting a more detailed example? I would really help! Here's what I'm not quite understanding about the suggested approach: Would I no longer define the

kratos.config

in the helm chart's values.yaml? https://github.com/ory/k8s/blob/2dd8b03e7963bbb8664903a3ca1b9a2bfcac6e39/helm/charts/kratos/values.yaml#L179 Would I move all that config into a secret, and mount that secret as a volume? If so, then it sounds like I'd add something like this in my Kratos deployment manifest:

spec:
  template:
    spec:
        containers:
          volumeMounts:
            - name: kratos-config
              mountPath: /etc/config/kratos/kratos.yml
      volumes:
        - name: kratos-config
          secret:
            secretName: kratos-config-secret
            items:
              - key: config.yaml
                path: config.yaml

But if I'm managing the whole config inside a single secret, how would I codify that as code? Seems like it would be hard to separate the configuration parts from the confidential parts. For context, my goal is to manage my config in a git repo, while eliding confidential configs such as

client_id

and

client_secret

like so:

kratos:
  config:
    version: v1.0.0
    ... lots more config...
    selfservice:
      methods:
        oidc:
          enabled: true
            providers:
              - id: okta-test
                provider: generic
                client_id: ${CLIENT_ID}
                client_secret: ${CLIENT_SECRET}
                issuer_url: <https://login.example.com>
                scope:
                  - openid
                  - profile
                  - email

Hi there! No, you could still manage the whole config through helm, and define the secrets like this:

yaml
kratos:
  config:
    version: v1.0.0
    ... lots more config...
    selfservice:
      methods:
        oidc:
          enabled: true
            providers:
              - id: okta-test
                provider: generic
                client_id: FOO
                client_secret: <file://path/to/mounted/secret>
                issuer_url: <https://login.example.com>
                scope:
                  - openid
                  - profile
                  - email

And use volumemounts to mount supply the secret

I would go with option 1. You keep the config in the location you want, but add the

<file://path/to/mount/secret>

like Demonsthere said. If you manually created the secret, it would look like this:

apiVersion: v1
kind: Secret
metadata:
  name: additional-kratos-secrets
type: <http://kubernetes.io/basic-auth|kubernetes.io/basic-auth>
stringData:
  okta-client-id: my-client-id
  okta-client-secret: my-client-secret

In your kratos config:

kratos:
    selfservice:
      methods:
        oidc:
          enabled: true
            providers:
              - id: okta-test
                provider: generic
                client_id: file:///etc/secrets/okta-client-id
                client_secret: file:///etc/secrets/okta-client-secret
                issuer_url: <https://login.example.com>
                scope:
                  - openid
                  - profile
                  - email

In your Helm values.yaml:

deployment:
  extraVolumes:
    - name: additional-kratos-secrets
      secret:
        secretName: additional-kratos-secrets
  extraVolumeMounts:
    - name: additional-kratos-secrets
      mountPath: /etc/secrets  # folder to place secret file
      subPath: okta-client-id # name of key in secret
      readOnly: true
    - name: additional-kratos-secrets
      mountPath: /etc/secrets
      subPath: okta-client-secret
      readOnly: true

Ah, I see - this makes a lot more sense now! Thanks for the details 😁 I'll give it a shot and post an update

@most-river-7586 any updates on this; did you get it working? 🙂

Unfortunately this doesn't work... When I follow the instructions above, my browser is redirecting to a url like this:

<https://login.example.com/oauth2/v1/authorize?client_id=file:///etc/secrets/okta-client-id&>...

where Kratos seems to interpret the

client_id

to be the literal string

file:///etc/secrets/okta-client-id

. Seems like the

file://

clause is not supported? Any ideas on how I can get this working? Additional details: 1. I'm using the helm chart version

0.37.0

and kratos version

1.0.0

. 2. These values are getting mounted correctly on the pod, because I can shell into the

kratos

pod and run

cat /etc/secrets/okta-client-id

, which returns the expected client id. 3. I tried using 2 slashes, and 3 slashes after

file:

(ie:

file:///etc/...

and

<file://etc/>...

), and neither works

Hmm that’s strange. I literally use this config in my deployments of kratos. Let me try to pull my real config tonight or tomorrow and I’ll get back to you.