Support Kubernetes Secrets

[keirl]

Do you want to request a feature or report a bug?
Feature

What is the current behavior?
Database URLs include username and password as part of URL. When constructing Kubernetes deployments this encourages plaintext username and passwords and does not support Kubernetes secrets for DB credentials.

What is the desired behavior?
Allow DB_USERNAME and DB_PASSWORD environmental variables that can be set. This would allow you to use Kubernetes deployments that reference Kubernetes secrets.

Such as
env:
- name: DB_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password

Reference: https://kubernetes.io/docs/concepts/configuration/secret/

Which version of the software is affected?
1.0.0-beta8

[aeneasr]

You could just store the database url in the secret. That's one less secret and env var you have to configure.

[keirl]

You could just store the database url in the secret. That's one less secret and env var you have to configure.

Yes, you could, but that couples your username, password, and host. In many production and environments, credential management is done separately from deployment management. It seems like the best practice would be to optionally allow them as separate env variables.

[aeneasr]

Is there no way to substitute the variables in the form of postgres://$DB_USER:$DB_PASSWORD@$DB_HOST:$DB_PORT? I'd really like to have only one way of specifying things.

[keirl]

@aeneasr The entrypoint in the dockerfile does not simply support variable substitution. We plan look at overriding the entrypoint to do the variable substitution in the container, but it will be a hack and take us further from the default use cases.

[fredbi]

IMHO, this request for enhancement unduly puts additional burden on hydra's configuration tasks.

It is rather straightforward to configure Postgres and avoid any disclosure of credentials in the connection string by using password files. You are then free to use K8 secrets (or in my case, just docker secrets) to store these files.

Example:

    - PGPASSFILE=/var/certs/pgpass
    - DATABASE_URL=postgres://dbuser@postgres:5432/accesscontroldb?sslmode=verify-full&sslrootcert=/var/certs/ca.crt

And your pgpass file contains the credentials for your user.

[fredbi]

The entrypoint in the dockerfile does not simply support variable substitution. We plan look at overriding the entrypoint to do the variable substitution in the container, but it will be a hack and take us further from the default use cases.

Yes you can substitute variables at build time: docker build -e DB_USER=dbuser ...
And in Dockerfile:

ENV DATABASE_URL=postgres://$DB_USER:$DB_PASSWORD@$DB_HOST:$DB_PORT

[keirl]

The entrypoint in the dockerfile does not simply support variable substitution. We plan look at overriding the entrypoint to do the variable substitution in the container, but it will be a hack and take us further from the default use cases.

Yes you can substitute variables at build time: docker build -e DB_USER=dbuser ...
And in Dockerfile:

The entrypoint in the dockerfile does not simply support variable substitution. We plan look at overriding the entrypoint to do the variable substitution in the container, but it will be a hack and take us further from the default use cases.

Yes you can substitute variables at build time: docker build -e DB_USER=dbuser ...
And in Dockerfile:

ENV DATABASE_URL=postgres://$DB_USER:$DB_PASSWORD@$DB_HOST:$DB_PORT

This substitution is at build time. I need it at runtime passed in through Kubernetes. I don't want the credentials baked into the image.

[aeneasr]

We could probably have a docker image with a custom entrypoint that does something along the lines of:

#!/bin/bash

export DATABASE_URL=postgres://$DB_USER:$DB_PASSWORD@$DB_HOST:$DB_PORT

hydra $1

That way, we don't need to deal with this in hydra and there is no need to think about precedence as well as no need to add more environment variables which make it harder to configure this, but still have something that integrates well with kubernetes.

[keirl]

IMHO, this request for enhancement unduly puts additional burden on hydra's configuration tasks.

I disagree based on looking at the source code. But I'm not the maintainer.

It is rather straightforward to configure Postgres and avoid any disclosure of credentials in the connection string by using password files. You are then free to use K8 secrets (or in my case, just docker secrets) to store these files.

Example:

    - PGPASSFILE=/var/certs/pgpass
    - DATABASE_URL=postgres://dbuser@postgres:5432/accesscontroldb?sslmode=verify-full&sslrootcert=/var/certs/ca.crt

And your pgpass file contains the credentials for your user.

This may be a viable option in Kubernetes, we'll try it out.
The other option of storing the DATABASE_URL should also work.

[aeneasr]

I disagree based on looking at the source code. But I'm not the maintainer.

It's not about the changes in the code, those are easily done within a few lines. But we already have a bunch of environment variables that configure things, I really want to avoid adding more and more stuff to accommodate every use case. The solution for the task you're facing is either env substitution (see my previous comment) or storing the DATABASE_URL as a whole or using TLS. All of those are viable solutions and I agree that we should have better integration with kubernetes. But we shouldn't add more and more config to the already (kinda) bloated config, instead we should opt to reduce it.

[keirl]

I disagree based on looking at the source code. But I'm not the maintainer.

It's not about the changes in the code, those are easily done within a few lines. But we already have a bunch of environment variables that configure things, I really want to avoid adding more and more stuff to accommodate every use case. The solution for the task you're facing is either env substitution (see my previous comment) or storing the DATABASE_URL as a whole or using TLS. All of those are viable solutions and I agree that we should have better integration with kubernetes. But we shouldn't add more and more config to the already (kinda) bloated config, instead we should opt to reduce it.

We will make one of these work. And thank you for the productive conversation. I still think the suggestion would work better with Kubernetes. Unfortunately environment variables are the way these things are done, so it will be a challenge to reduce them.