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

[ericchiang]

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.