Skip to content

Hardening Configs

Docker configuration files, such as the daemon configuration (/etc/docker/daemon.json) and container runtime settings, are critical attack surfaces if left unsecured. Misconfigurations can expose sensitive data, allow privilege escalation, or enable unauthorized access to Docker APIs. This section outlines strategies to harden these files by limiting permissions, restricting API access, and disabling unused features.

Securing Docker Daemon Configuration

The Docker daemon configuration file (/etc/docker/daemon.json) defines critical runtime parameters. Ensure it is protected against unauthorized modifications and configured to minimize attack surfaces.

Key Hardening Steps

  • Avoid root privileges: Run Docker as a non-root user (e.g., nobody or a dedicated service account).
  • Limit storage drivers: Use secure, production-ready storage drivers like overlay2.
  • Secure the Docker socket: Restrict access to the Unix socket (/var/run/docker.sock) to trusted processes.
  • Disable insecure registries: Avoid exposing internal registries to untrusted networks.

Example: Secure daemon.json

{
  "user": "nobody",
  "storage-driver": "overlay2",
  "registry-mirrors": ["https://registry-1.docker.io"],
  "hosts": ["unix://var/run/docker.sock"]
}

Additional Safeguards

  • Systemd capabilities: Use systemd to drop unnecessary capabilities: 
    [Service]
AmbientCapabilities=CAP_NET_BIND_SERVICE
  • File permissions: Ensure the config file has strict permissions: 
    sudo chmod 640 /etc/docker/daemon.json
sudo chown root:docker /etc/docker/daemon.json

Restricting Docker API Access

The Docker API provides powerful control over containers but must be secured to prevent unauthorized access.

Key Hardening Steps

  • Bind the API to localhost: Avoid exposing the API over TCP/IP.
  • Enable TLS: Use encrypted connections with client certificates.
  • Limit API endpoints: Restrict access to specific endpoints (e.g., GET /containers).

Example: TLS Configuration

  1. Generate TLS certificates (e.g., server.pem and server-key.pem).
  2. Configure daemon.json: 
    {
  "tls": true,
  "tlscacert": "/etc/docker/ca.pem",
  "tlscert": "/etc/docker/server.pem",
  "tlskey": "/etc/docker/server-key.pem"
}
  3. Use client certificates to authenticate: 
    docker --tlscacert=ca.pem --tlscert=client.pem --tlskey=client-key.pem ps

Access Control

  • Use reverse proxies (e.g., NGINX) with authentication layers to gate access to the Docker API.
  • Avoid exposing the API over public networks unless absolutely necessary.

Disabling Unused Features

Unused Docker features can introduce vulnerabilities. Disable or remove them to reduce the attack surface.

Key Hardening Steps

  • Disable experimental features: These are often unstable and insecure. 
    {
  "experimental": false
}
  • Remove unused plugins: Use docker plugin rm to uninstall unused plugins.
  • Limit container capabilities: Use --cap-drop to restrict capabilities (e.g., CAP_NET_ADMIN).

Example: Restricting Capabilities

docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE my-image

Additional Recommendations

  • Audit running containers: Use docker ps --format "table {{.ID}}\t{{.Image}}\t{{.Status}}" to identify unnecessary containers.
  • Prune unused resources: Regularly clean up stopped containers and unused images: 
    docker system prune -af

Key takeaways

  • Secure the Docker daemon configuration by using non-root users, secure storage drivers, and strict file permissions.
  • Restrict Docker API access to localhost and enforce TLS for remote connections.
  • Disable unused features like experimental modes and unnecessary plugins to minimize risks.