1

I'm working on an app and I would like for specific fields / tables in my database to be encrypted because I will be storing sensitive information.

I was looking into options and have landed at two possible solutions: storing the encryption secret in Environment Variables or in Docker Secrets.

I've just learned about Docker Secrets– so I'm not totally sure about what it entails.

Are environment variables an alright place to store an encryption secret for database fields?

What about using Docker Secrets instead? Why is it more secure than environment variables– could an attacker inspect it in the same way as they do environment variables?

aroooo
  • 4,726
  • 8
  • 47
  • 81

1 Answers1

2

At the end of the day, your process needs to have the encryption key in a decoded form to be able to use it. In standard Docker, there are only two options to get it there: pass it in an environment variable, or store it in a file that gets bind-mounted into the container.

Traditional wisdom is that passing secrets via files is more secure than via environment variables. It's sometimes possible to see another process's environment (ps -E, xargs -n1 -0 echo < /proc/12345/environ) and that will reveal those secrets. A file can be set to mode 0400 unreadable by anyone other than its owner and that's a little more fool-proof. In Docker space, on the one hand docker inspect can also show environment variables; on the other anyone who can run any Docker command can trivially get root access; and getting filesystem permissions set up correctly is tricky.

The various clustering systems have other ways to transport secret values. You mention Docker secrets but they're specifically a feature of Docker's Swarm cluster manager; Kubernetes has Secrets; Nomad has tight integration with the Vault secret manager. The ways these get installed into containers differs, but (except for Swarm secrets) you can pick either files or environment variables. For Kubernetes Secrets it's especially common to store some credential in a Secret object, and have processes (Pods) consume it as an environment variable.

The two big questions are, what are you trying to protect yourself from, and are you in a clustered environment?

  • If you're on a single node and you're the only user, environment variables are just fine; they can't be recovered without a local shell.

  • If you're on a single node with multiple users, you probably can't protect the secret: anyone who can run any docker command can docker inspect your container to find its environment variables, but they can also docker run themselves a root shell mounting the host filesystem and poke around as much as they'd like. If the Docker socket and sudo access are locked down then a file-based approach might be better.

  • If you're in a clustered environment, go ahead and use its secret mechanism, but consume it in whatever form is more convenient. Typically only cluster administrators can directly log into the nodes and the cluster APIs won't present the secret values (unless you have permission to read back the secret object).

David Maze
  • 130,717
  • 29
  • 175
  • 215
  • I am on a single node– by `user` do you mean admin? I am the only admin also. I am specifically trying to secure my system against potentially sensitive information being leaked if something like a database breach happens. This isn't financial information, but it is information users would likely want to be private. – aroooo Dec 31 '19 at 22:29
  • 1
    "User" in the bullet points here means people who have shell access to the system. If only trusted admins can log into the system itself then you're probably fine. There are somewhat regular SO questions about systems where multiple people log in and, for example, run Jupyter notebooks via Docker, and all of those users have root-equivalent access if they care to take advantage of it. – David Maze Jan 01 '20 at 10:34