Support Secrets Store CSI Driver

[fernferret]

Preflight Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Problem Description

I'd like to keep my dex config in Vault rather than in a Kubernetes secret. Now that the Secrets Store CSI Driver is stable I'd like to use this mechanism to mount my secret in.

This all works without issue but it's not compatible with the current chart.

Proposed Solution

I'd like to be able to specify a CSI volume to load the secret from.

It might be a good idea (initially?) to enforce this as a secrets-store.csi.k8s.io type volume so other CSI drivers are not used. I assume the reason that dex only supports secrets for mounting the config is for security reasons, so allowing any CSI driver could potentially allow people to inadvertently store their config on, say, a public store of some kind.

I'm not too fussed personally, but I could understand if that requirement was enforced.

I made a few changes to the deployment and was able to get this working:

--- a/templates/deployment.yaml
+++ b/templates/deployment.yaml
@@ -111,8 +111,13 @@ spec:
           {{- end }}
       volumes:
         - name: config
+          {{- if .Values.configSecret.csi.enabled }}
+          csi:
+            {{- toYaml .Values.configSecret.csi.tpl | nindent 12 }}
+          {{- else }}
           secret:
             secretName: {{ include "dex.configSecretName" . }}
+          {{- end }}
       {{- with .Values.volumes }}
         {{- toYaml . | nindent 8 }}
       {{- end }}

--- a/oss/dex/values.yaml
+++ b/oss/dex/values.yaml
@@ -47,6 +47,19 @@ configSecret:
   # Must point to secret that contains at least a `config.yaml` key.
   name: ""

+  # -- Enable use of a CSI driver to mount the secret instead of using a kubernetes secret
+  # If configSecret.csi.enable is true, this will be used instead of the normal
+  # kubernetes secret. The provider must contain a `config.yaml` file.
+  csi:
+    enabled: false
+    tpl: {}
+    # tpl:
+    #   driver: secrets-store.csi.k8s.io
+    #   readOnly: true
+    #   volumeAttributes:
+    #     secretProviderClass: "dex-config"
+
+
 # -- Application configuration.
 # See the [official documentation](https://dexidp.io/docs/).
 config: {}

Alternatives Considered

I could use regular secrets but for policy reasons (and ease of edit/backup) I'd like to keep my secrets in vault (this also would allow anyone to use GCP or AWS secrets engines too).

Additional Information

I have a working version of this with a few minor changes but would be looking for guidance on how this can work with the existing secret mounts. It's a bit awkward globbed on as there would be 3 conditions:

• create secret
• mount existing secret
• mount csi volume

This is a bit strange/confusing to deal with and explain that the create secret option is only valid if the csi volume is not used.