Swarm mode is inherently secure. Communication among all the nodes is encrypted, and the swarm provides an encrypted data store that is distributed among the manager nodes. You can use this store for application secrets. Secrets work in exactly the same way as config objects—you create them in the swarm, and then you make them available to services. The difference is that the secret is encrypted in the swarm's data store, and it's encrypted in transit from the manager to the worker node. It's only decrypted inside the container running the replica, where it gets surfaced as a file in the same way as config objects.
Secrets are created with a name and the contents of the secret, which can be read from a file or entered into the command-line. I'm going to move my sensitive data to secrets, starting with the SQL Server administrator account password. In the ch07-app-config folder, I have a folder called secrets that contains a secret files for the database password. I'll use that to securely store the password in the swarm, but I need to do some work to my database image before it can support secrets.
I packaged my latest SQL Server database schema in the Docker image dockeronwindows/ch06-nerd-dinner-db. That image uses environment variables to set the administrator password, which is fine for developers, but not good in a test environment where you want to restrict access. I have a new version for this chapter with an updated Dockerfile and startup script for the database, so I can read in the password from a secret file.
In the InitializeDatabase.ps1 script for ch07-nerd-dinner-db, I've added a new parameter called sa_password_path and some simple logic to read the password from the file, if one exists in that path:
if ($sa_password_path -and (Test-Path $sa_password_path)) {
$password = Get-Content -Raw $sa_password_path
if ($password) {
$sa_password = $password
Write-Verbose "Using SA password from secret file: $sa_password_path"
}
The Dockerfile uses an environment variable with a default value for the path to the password file:
ENV sa_password_path="C:secretssa-password"
This still supports different ways of running the database. Developers can run it without specifying any configuration settings, and it will use the default password built into the image—which is the same default built into the connection strings for the application images. In a clustered environment, admins can create the secret separately from deploying the app and secure access to the database container.
I need to create the secret and then update the database service to use the secret and the new image that applies the password from the secret:
docker secret create nerd-dinner-db-sa-password .secrets erd-dinner-db-sa-password.txt;
docker service update `
--secret-add src=nerd-dinner-db-sa-password,target=C:secretssa-password `
--image dockeronwindows/ch07-nerd-dinner-db:2e `
nerd-dinner-db;
Now the database is using a strong password that is protected by Docker Swarm. Users with access to the Docker Engine can't see the contents of the secret, as it's only ever decrypted inside a container for a service that explicitly uses the secret. I can inspect the secret, but I only see metadata:
> docker secret inspect --pretty nerd-dinner-db-sa-password
ID: u2zsrjouhicjnn1fwo5x8jqpk
Name: nerd-dinner-db-sa-password
Driver:
Created at: 2019-02-14 10:33:04.0575536 +0000 utc
Updated at: 2019-02-14 10:33:04.0575536 +0000 utc
Right now my application is broken, because I've updated the database password without updating the connection strings in the applications that use the database. This is the danger of managing distributed applications imperatively, by issuing commands to the Docker Swarm. Instead, you should manage your applications declaratively, using a Docker Compose file to define all the services and other resources and deploying them as a Docker stack.