How To Handle Secrets in Docker
DevOps engineers must handle secrets with care. In this series, we summarize best practices for leveraging secrets with your everyday tools, including code.
Join the DZone community and get the full member experience.Join For Free
Secrets management in Docker is a critical security concern for any business. When using Docker containers, it is essential to keep sensitive data, such as passwords, API keys, and other credentials, secure.
This article will discuss some best practices for managing secrets in Docker, including how to store them securely and minimize their exposure. We will explore multiple solutions: using Docker Secrets with Docker Swarm, Docker Compose, or Mozilla SOPS. Feel free to choose what’s more appropriate to your use case. But most importantly is to remember to never hard-code your Docker secrets in plain text in your Dockerfile!
Following these guidelines ensures your organization’s sensitive information remains safe even when running containerized services.
4 Ways To Store and Manage Secrets in Docker
1. Using Docker Secrets and Docker Swarm
Docker Secrets and Docker Swarm are two official and complimentary tools allowed to securely manage secrets when running containerized services.
Docker Secrets provides a secure mechanism for storing and retrieving secrets from the system without exposing them in plain text. It enables users to keep their credentials safe by encrypting the data with a unique key before passing it to the system.
Docker Swarm is a powerful tool for managing clusters of nodes for distributed applications. It provides an effective means of deploying containerized applications at scale. With this tool, you can easily manage multiple nodes within a cluster and automatically distribute workloads among them. This helps ensure your application has enough resources available at all times, even during peak usage periods or unexpected traffic spikes.
Together, these two tools provide an effective way to ensure your organization’s sensitive information remains safe despite ever-evolving security needs. Let’s see how to create and manage an example secret.
Creating a Secret
To create a secret, we need to first initialize Docker Swarm. You can do so using the following command:
docker swarm init
Once the service is initialized, we can use the
docker secret create command to create the secret:
ssh-keygen -t rsa -b 4096 -N "" -f mykey
docker secret create my_key mykey
In these commands, we first create an SSH key using the
ssh-keygen command and write it to
mykey. Then, we use the Docker secret command to generate the secret. Ensure you delete the
mykey file to avoid any security risks.
You can use the following command to confirm the secret is created successfully:
docker secret ls
We can now use this secret in our Docker containers. One way is to pass this secret with
–secret flag when creating a service:
docker service create --name mongodb --secret my_mongodb_secret redis:latest
We can also pass this secret to the
docker-compose.yml file. Let’s take a look at an example file:
- type: bind
In the example compose file, the secrets section defines a secret named
my_secret_key (discussed earlier). The
myapp service definition specifies that it requires
my_secret_key , and mounts it as a file at
/run/secrets/my_secret in the container.
2. Using Docker Compose
Docker Compose is a powerful tool for defining and running multi-container applications with Docker. A stack is defined by a
docker-compose file allowing you to define and configure the services that make up your application, including their environment variables, networks, ports, and volumes. With Docker Compose, it is easy to set up an application in a single configuration file and deploy it quickly and consistently across multiple environments.
Docker Compose provides an effective solution for managing secrets for organizations handling sensitive data such as passwords or API keys. You can read your secrets from an external file (like a TXT file). But be careful not to commit this file with your code:
3. Using a Sidecar Container
A typical strategy for maintaining and storing secrets in a Docker environment is to use sidecar containers. Secrets can be sent to the main application container via the sidecar container, which can also operate a secrets manager or another secure service.
Let’s understand this using a Hashicorp Vault sidecar for a MongoDB container:
- First, create a Docker Compose (
docker-compose.yml) file with two services:
- In the
secretsservice, use an image containing your chosen secret management tool, such as a vault.
- Mount a volume from the secrets container to the
mongocontainer so the
mongocontainer can access the secrets stored in the secrets container.
- In the
mongoservice, use environment variables to set the credentials for the MongoDB database, and reference the secrets stored in the mounted volume.
Here is the example compose file:
command: ["vault", "server", "-dev", "-dev-root-token-id=myroot"]
4. Using Mozilla SOPS
Mozilla SOPS (Secrets Ops) is an open-source platform that provides organizations with a secure and automated way to manage encrypted secrets in files. It offers a range of features designed to help teams share secrets in code in a safe and practical way. The following assumes you are already familiar with SOPS, if that’s not the case, start here.
Here is an example of how to use SOPS with
command: ["sops", "--config", "/secrets/sops.yaml", "--decrypt", "/secrets/mysecrets.enc.yaml"]
# Optional: specify the path to your PGP private key if you encrypted the file with PGP
In the above, the
myapp service requires a secret called
secrets section uses a secret called
mysecrets, which is expected to be stored in an external key/value store, such as Docker Swarm secrets or HashiCorp Vault.
sops service uses the official SOPS Docker image to decrypt the
mysecrets.enc.yaml file, which is stored in the local
./secrets directory. The decrypted secrets are mounted to the
myapp service as environment variables.
Note: Make sure to create the secrets directory and add the encrypted
mysecrets.enc.yaml file and the
sops.yaml configuration file (with SOPS configuration) in that directory.
Scan for Secrets in Your Docker Images
Hard coding secrets in Docker is a significant security risk, making them vulnerable to attackers. We have seen different best practices to avoid hard-coding secrets in plain text in your Docker images, but security doesn’t stop there.
You Should Also Scan Your Images for Secrets
All Dockerfiles start with a
FROM directive that defines the base image. It’s important to understand when you use a base image, especially from a public registry like Docker Hub, you are pulling external code that may contain hardcoded secrets. More information is exposed than visible in your single Dockerfile. Indeed, it’s possible to retrieve a plain text secret hard-coded in a previous layer starting from your image.
In fact, many public Docker images are concerned: in 2021, we estimated that **7% of the Docker Hub images contained at least one secret.**
Fortunately, you can easily detect them with
ggshield (GitGuardian CLI). For example:
ggshield secret scan docker ubuntu:22.04
Managing secrets in Docker is a crucial part of preserving the security of your containerized apps. Docker includes several built-in tools for maintaining secrets, such as Docker Secrets and Docker Compose files.
Additionally, organizations can use third-party solutions, like HashiCorp Vault and Mozilla SOPS, to manage secrets in Docker. These technologies offer extra capabilities, like access control, encryption, and audit logging, to strengthen the security of your secret management.
Finally, finding and limiting accidental or unintended exposure of sensitive information is crucial to handling secrets in Docker. Companies are invited to use secret scanning tools, such as GitGuardian, to scan the Docker images built in their CI/CD pipelines as mitigation to prevent supply-chain attacks.
If you want to know more about Docker security, we also summarized some of the best practices in a cheat sheet.
Published at DZone with permission of Keshav Malik. See the original article here.
Opinions expressed by DZone contributors are their own.