config: all sensitive fields should be configurable through a file or env var

[ericchiang]

trafficstars

Spun out of https://github.com/coreos/dex/issues/968 and to address https://github.com/coreos/dex/pull/943

Currently we let parts of dex config reference environment variables:

storage:
- type: postgres
  config:
    password: $PASSWORD

We restrict this to storage and connectors since '$' can show up in things like bcrypt hashes. There have been additional request to add this to other parts of the config https://github.com/coreos/dex/pull/943. I'd like to propose we stop doing this.

Overall this is really bad since it lets the environment inject arbitrary bytes directly into the config. You could put an entire YAML object in that environment variable and it'd replace the environment variable reference. This is both hacky and prevents other tools from sanely parsing dex's config (https://github.com/coreos/dex/issues/968).

Add additional typed fields to sensitive config fields which let them be filled in by a file or env var explicitly. I should be able to configure a password like:

staticPasswords:
- email: [email protected]
  username: john
  hashFromFile: /var/run/dex/john-bcrypt-hash
- email: [email protected]
  username: jane
  hashFromEnv: JANE_BCRYPT_HASH

[ianconsolata]

Agreed this is a cleaner approach. How do you plan to handle backwards compatibility? Or do you plan to continue to allow expansion where it exists now.

[ericchiang]

Agreed this is a cleaner approach. How do you plan to handle backwards compatibility? Or do you plan to continue to allow expansion where it exists now.

• Don't add new env var expansion logic.
• Continue to accept the literal values e.g. hash
• Add new optional fields like hashFromFile and hashFromEnv

Or we could do something like

- email: [email protected]
  username: john
  password:
    file: /var/run/dex/john-bcrypt-hash
- email: [email protected]
  username: jane
  password:
    env: JANE_PASSWORD

Either way, we'll continue to be backward compatible. New fields will be optional.

[dnascimento]

Any updates?

[dafelipe130]

+1'ing here as well. I'm coming from #1158 and I could not put the identity configmap to source control with this still lingering around

[AlexMorreale]

would love this feature! :+1:

would be glad to look at code if it has already been started and potentially take this over the finish line if my company can spare the cycles.

[SongGithub]

please, please, push this forward. I would love to see this feature got released soon.

Currently there is so much pain to setup init container in k8s just to set the clinet secret without exposing it in our source code repo.

[captncraig]

as a workaround, I made a little script that I mount in my container and run as the command. All it does is run sed to rewrite the config file to a memory volume, then launch dex as normally. Its a bit of a hack, but it lets me load client secrets from kubernetes secrets via environment variables, which is all I wanted.

[krishnadurai]

@ericchiang I've implemented hashFromEnv for staticPasswords configuration as a starting point for this issue. Could you please take a look at it?

[paul-theorem]

Also appears that static client secrets can't be ref'd from env vars. My example would be:

staticClients:
- id: kubelogin
  redirectURIs:
  - http://localhost:28000
  name: 'kubelogin'
  secret: $KUBELOGIN_SECRET

dex does not resolve the env var. the dex config yaml will find its way into our git repo - and we'd prefer to put no secrets at all into source control. I'd love to reference it from a kube secret resolved from an env var.

[sagikazarmark]

Personally, I'm not a huge fan of the xyzFromEnv style config. It complicates the config file itself, complicates config loading a LOT, makes it harder to test, etc.

I'd probably prefer some sort of config templating solution. For example, adding dockerize to the docker image would allow users to evaluate a config template and fill in certain values from environment variables when the container starts.

The same can be done with consul template.

I know it writes the resulting config file to ephemeral storage, but anyone who has access to the node filesystem can easily enter containers and check the environment variables as well.

[justinas-b]

+1

[Kampe]

+1

[damian-keska]

That would simplify usage with e.g. https://github.com/kubernetes-sigs/secrets-store-csi-driver

[benjamin-bergia]

Is there any update on this?

Dex is barely usable on kubernetes as it is right now. The only workaround I found is to store the whole config as a secret.

[nabokihms]

@benjamin-bergia starting from the version v2.28.0 Dex official docker image uses gomplete to render the config before execution.

Thus, it is possible to utilize env variables in the config like this https://github.com/dexidp/dex/blob/20e2e429b34086bc4ffbfbbae888f644ca1f1377/config.docker.yaml#L20

[benjamin-bergia]

@nabokihms Perfect! Thank you

[pinpox]

@benjamin-bergia starting from the version v2.28.0 Dex official docker image uses gomplete to render the config before execution.

Thus, it is possible to utilize env variables in the config like this

Does this apply to the non-docker version aswell? I'm still trying to provide a secret for staticClients via environment variable as described in #943 on NixOS

[sagikazarmark]

Under the hood, Dex still uses a config file generated by gomplate. gomplate only makes operations easier (ie. you don't have to add sensitive values to install manifests), but it still gets written to the container filesystem.

[pinpox]

written to the container filesystem.

Yes, but my question is if it works without docker aswell? I'm running

dex serve /run/dex/config.yaml

with config.yaml containing:

staticClients:
- id: forum-app
  name: forum-app
  redirectURIs:
  - http://myhost.tld/authenticate
  secret: '{{ .Env.CLIENT_SECRET_RUST_FORUM }}'

But the secret is not set correctly

[pinpox]

Okay, i found the solution: You can use secretEnv like this:

staticClients:
- id: forum-app
  name: forum-app
  redirectURIs:
  - http://myhost.tld/authenticate
  secretEnv: 'CLIENT_SECRET_RUST_FORUM' # Variable name without the leading $

This should be documented better, I had to search a lot to find this in this issue

[sagikazarmark]

Yes, but my question is if it works without docker aswell? I'm running

Have you looked at gomplate? If you run it, it works without Docker.

This should be documented better, I had to search a lot to find this in https://github.com/dexidp/dex/pull/1664

Feel free to send a PR to the documentation.

[dermicus-miclip]

Bit flabbergasted that this is not solved. I mean, 2017! This issue makes it really annoying to use static config in combination with k8s. Why is this not getting some more love?

[sagikazarmark]

There is a reasonably good solution provided that allows you to use environment variables for your configuration explained above.

The reason why we haven't done anything more (ie. implementing this inside Dex) is because

a) we believe this is good enough and most people seem to agree b) configuration needs some larger revamps and we may not want to commit to a solution that we would break later

[dermicus-miclip]

@sagikazarmark, I did not yet understand enough of exactly how the solution was supposed to work. But all seems to work now indeed :). Can't this ticket be closed then, as it is probably only confusing people getting started with dex.

[sagikazarmark]

Yeah, it probably makes sense to do so.

I've opened #2915 to track writing better docs for the feature.