Handling sensitive properties such as database and key variables?

Rancher 1.x
1

I’m curious what others are doing to handle sensitive information in Rancher deployments. I am trying to keep application properties such as database password and API keys out of the Docker images. I’d prefer to pull the data at deploy time (such that a release version is paired with a configuration / properties file).

Wondering if anyone is currently handling this in some fashion with Rancher and how you go about it?

2

I’m also interested on how people are doing it. I think it’s not only specific to rancher since it’s an infrastructure management system not a platform for deployment, although anyway here I’m giving you all the ways I found to deal with this :

  • In the Dockerfile at build time on the host machine
  • at run time in the rancher interface (in the docker-compose/rancher-compose that is)
  • in the image in a private docker registry hooked to a private git repository
  • as a shared file/directoy between the host and the container

all of those methods have drawbacks

3

here are a couple of related github work items that seem to be progressing. Maybe they cover your scenarios.


If not, you may want to get in there and request enhancements.

4

Those linked issues help for keeping the sensitive information hidden once it gets into the system, so those are definitely worth following.

These are probably overkill. But for the cases where you cannot modify the application to deal with environment variables, some more ideas:

  • Ability to ship arbitrary files during rancher-compose up that get deployed next to the container on the filesystem.
  • A label that says a service needs to “prompt” for sensitive information and waits for this sensitive information / files to be entered in the UI or API (and then maybe kept in memory for subsequent deploys until manually invalidated).
  • Ability to build properties files form existing environment or the environment that was prompted (confd as a service / outside the image?).

Mostly just thinking out loud here :smile:

5

We use spring here so have a config server. For the non-spring components we still use the config server with a simple curl command to pull config in and then use either sed or better still augeas to insert config into config files. I know others have used an external ansible service to poke config in from outside.

6

My containers have customize start up scripts which pulls the secrets from HasiCorp Vault at start up and sets them whichever way the app needs it (config file, environment variable, etc).