How to Handle Secrets in Docker
Tags: docker, webdev, beginners, tutorial
Published: 2023-02-16 07:51:38

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 blog post 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 plaintext in your Dockerfile!

Following these guidelines ensures that your organization's sensitive information remains safe even when running containerized services.

# 4 Ways to Store & Manage Secrets in Docker

## Using Docker Secrets & Docker Swarm
Docker Secrets and Docker Swarm are two official and complimentary tools allowing 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 plaintext. 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 that 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 that your organization's sensitive information remains safe despite ever-evolving security needs.

Let’s see how 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
rm 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 that you delete the mykey file to avoid any security risks.

You can use the following command to confirm that 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 `docker-compose.yml` file. Let’s take a look at an example file:

```
version: '3.7'
services:
  myapp:
    image: mydummyapp:latest
    secrets:
      - my_secret
    volumes:
      - type: bind
        source: my_secret_key
        target: /run/secrets/my_secret
        read_only: true
secrets:
  my_secret:
    external: true
```

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.

## 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!

```
version: '3.7'
services:
  myapp:
    image: myapp:latest
    secrets:
      - my_secret
secrets:
  my_secret:
    file: ./my_secret.txt
```

## 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: mongo and secrets.
- In the secrets service, use an image containing your chosen secret management tool, such as a vault.
- Mount a volume from the secrets container to the mongo container so the mongo container can access the secrets stored in the secrets container.
- In the `mongo` service, 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:

```
version: '3.7'

services:
  mongo:
    image: mongo
    volumes:
      - secrets:/run/secrets
    environment:
      MONGO_INITDB_ROOT_USERNAME_FILE: /run/secrets/mongo-root-username
      MONGO_INITDB_ROOT_PASSWORD_FILE: /run/secrets/mongo-root-password
  secrets:
    image: vault
    volumes:
      - ./secrets:/secrets
    command: ["vault", "server", "-dev", "-dev-root-token-id=myroot"]
    ports:
      - "8200:8200"
      
volumes:
  secrets:
```

## 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](https://blog.gitguardian.com/a-comprehensive-guide-to-sops/).

Here is an example of how to use SOPS with `docker-compose.yml` :

```
version: '3.7'

services:
  myapp:
    image: myapp:latest
    environment:
      API_KEY: ${API_KEY}
    secrets:
      - mysecrets

  sops:
    image: mozilla/sops:latest
    command: ["sops", "--config", "/secrets/sops.yaml", "--decrypt", "/secrets/mysecrets.enc.yaml"]
    volumes:
      - ./secrets:/secrets
    environment:
      # Optional: specify the path to your PGP private key if you encrypted the file with PGP
      SOPS_PGP_PRIVATE_KEY: /secrets/myprivatekey.asc

secrets:
  mysecrets:
    external: true
```

In the above, the myapp service requires a secret called `API_KEY`. The 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.

The 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 plaintext 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 that 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 plaintext 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](https://blog.gitguardian.com/hunting-for-secrets-in-docker-hub/) contained at least one secret**.

Fortunately, you can easily detect them with `ggshield` (GitGuardian CLI). For example:

```
ggshield secret scan docker ubuntu:22.04
```

## Conclusion
To sum up, 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](https://blog.gitguardian.com/codecov-supply-chain-breach/).

If you want to know more about Docker security, we also summarized some of the best practices in a [cheat sheet](https://blog.gitguardian.com/how-to-improve-your-docker-containers-security-cheat-sheet/).