In this post I want show how to use Docker Secrets providing a real scenario example using Redis.

What do you need before reading this article?

• Basic knowledge of Docker technology
• Basic knowledge of Docker Swarm orchestrator
• Basic knowledge of Redis
• Docker installed
• Access to a Bash shell

What are Docker secrets?

I just quote the definition provided from documentation:

"In terms of Docker Swarm services, a secret is a blob of data, such as a password, SSH private key, SSL certificate, or another piece of data that should not be transmitted over a network or stored unencrypted in a Dockerfile or in your application’s source code. ..."

How to create them?

To create a secret you have to run the following command:

am@animusna:~$echo "myPlainSecret" | docker secret create mysecret
acvs814nso28yn105wqc32o8e

The output of this command is the id (acvs814nso28yn105wqc32o8e) of the secret.

To check if your secret has been created run the following command:

am@animusna:~$docker secret ls
ID                          NAME       DRIVER    CREATED         UPDATED
acvs814nso28yn105wqc32o8e   mysecret             5 seconds ago   5 seconds ago

How to use them?

To use a secret you have to map it during the creation of a service (in this case redis like in the documentation:

am@animusna:~$docker service create --name redis --secret mysecret redis:alpine

When you map secret in a service, Docker creates a file named like the secret name (in this case mysecret) in the folder /run/secrets and to prove that we can run the following command:

am@animusna:~$docker container exec $(docker ps --filter name=redis -q) cat /run/secrets/mysecret
myPlainSecret

where the output will be the plain text of the secret that we have created (myPlainSecret).

Real scenario example: Redis authentication with Docker secret

In case we want protect our Redis server we could use the secret created previously as password to connect to our server.

Let's prepare our docker compose file :

version: "3.1"
secrets:
  mysecret:
    external: true  #external=true means we've created the secret before. 

services:
  redis:
    image: redis 
    secrets:
      - mysecret   #We are declaring we are using this secret in this service. 
    command: bash -c "/startup/up-redis.sh" #The command we use to start our Redis server (we execute a shell script).
    ports:
      - "6379:6379"
    volumes:
      - "/home/am/up-redis.sh:/startup/up-redis.sh" # Mapping in the container our script.
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure

Let's prepare the start up script for our server up-redis.sh in a specific path (in my case /home/am/):

#!/bin/sh
#Script to startup Redis Server.

#Reading secret in a temporary variable.
REDIS_PASSWORD=`cat /run/secrets/mysecret`

#Start Redis server
redis-server --appendonly yes --requirepass "$REDIS_PASSWORD"  

In this script we set the password for our server using the option --requirepass recovering the secret from /run/secrets/mysecret and putting it inside the variable REDIS_PASSWORD.

Now that is everything ready we can start service:

am@animusna:~$docker stack deploy --compose-file=docker-compose.yaml myapp_stack
Creating network myapp_stack_default
Creating service myapp_stack_redis

To check if we've set the secret to access to our Redis service let's run the following command:

am@animusna:~$echo -e "AUTH myPlainSecret\nPING" | redis-cli
OK
PONG

where we run in the redis-cli the command AUTH for authenticate with our plain secret myPlainSecret and then the command PING to check if we are authenticated (in our case yes because we get a PONG).

Conclusion

In this article I've shown a possible and easy use of Docker secrets to protect sensitive data like it could be a connection password. The use of secrets are very useful in deployment scenario as much as in development scenario where developers should use their own secrets to configure their development environment. According my experience Docker secrets are useful and easy to manage and it's worth to use them if you choose Docker Swarm as orchestrator for your (micro) services.