Docker Secrets for Swarm Mode

Docker Secrets for Swarm Mode

Docker Swarm mode provides built-in secrets management for service deployments. Secrets are encrypted at rest and in transit, distributed only to nodes running services that require them. The secrets appear as files in a temporary filesystem, avoiding environment variable exposure. This native integration simplifies secrets management for Swarm deployments while providing strong security guarantees.

Creating and managing Docker secrets requires careful operational procedures. Secrets should be generated using cryptographically secure methods. Secret names should follow naming conventions for easy identification. Version management enables secret rotation without service disruption. Access control lists restrict secret access to authorized services. Regular audits ensure secrets remain properly configured.

#!/bin/bash
# Example: Docker Swarm secrets management workflow

# Generate secure passwords
generate_password() {
    openssl rand -base64 32 | tr -d "=+/" | cut -c1-25
}

# Create database secrets
DB_PASSWORD=$(generate_password)
echo -n "$DB_PASSWORD" | docker secret create db_password_v1 -

# Create API keys with metadata
API_KEY=$(generate_password)
echo -n "$API_KEY" | docker secret create api_key_v1 - \
    --label environment=production \
    --label rotation_date="$(date -I)" \
    --label owner=backend-team

# Create TLS certificates as secrets
docker secret create server_cert_v1 ./certs/server.crt \
    --label type=certificate \
    --label expires="2024-12-31"

docker secret create server_key_v1 ./certs/server.key \
    --label type=private_key \
    --label certificate=server_cert_v1

# Deploy service with secrets
docker service create \
    --name webapp \
    --secret source=db_password_v1,target=db_password,mode=0400 \
    --secret source=api_key_v1,target=/run/secrets/api_key,uid=100,gid=100,mode=0400 \
    --secret source=server_cert_v1,target=/etc/ssl/certs/server.crt \
    --secret source=server_key_v1,target=/etc/ssl/private/server.key,mode=0400 \
    webapp:latest

# Implement secret rotation
rotate_secret() {
    local secret_name=$1
    local current_version=$2
    local new_version=$3
    
    # Create new secret version
    generate_password | docker secret create "${secret_name}_${new_version}" -
    
    # Update service to use new secret
    docker service update \
        --secret-rm "${secret_name}_${current_version}" \
        --secret-add "source=${secret_name}_${new_version},target=${secret_name}" \
        webapp
    
    # Wait for update to complete
    docker service ps webapp --filter "desired-state=running"
    
    # Remove old secret after successful rotation
    docker secret rm "${secret_name}_${current_version}"
}

# Rotate database password
rotate_secret "db_password" "v1" "v2"

Secret access patterns require application modifications for optimal security. Applications should read secrets once during initialization rather than repeatedly accessing secret files. Secret caching reduces filesystem access but requires secure memory handling. Error handling must avoid exposing secret values in logs or error messages. Health checks should verify secret accessibility without revealing values.