Docker Threat Model

Concept Description
Docker host and kernel security Risk:
  • If host is compromised, the container isolation won’t make much of a difference
  • Kernel exploits
Best practices:
  • Keep base system updated
  • Use minimal, container-centric host systems (CoreOS)
  • Enforce Mandatory Access Control to prevent undesired operations -both on the host and on the containers- at the kernel level (Seccomp, AppArmor, SELinux)
Container resource abuse Risk:
  • If resource limits are not configured, DoS can be caused by software bugs, design miscalculations or malware attacks
Best practices:
  • Control groups (cgroups) are a feature of the Linux kernel that allow you to limit the access processes and containers have to system resources
  • Load testing by replicating the production loads on pre-production
  • Implement Docker monitoring and alerting
Container image authenticity Risk:
  • Running unverified software and/or from sources not trusted explicitly
Best practices:
  • Download images from trusted sources, like trusted Docker registry
  • Enable docker trust enforcement (export DOCKER_CONTENT_TRUST=1)
  • Enforce mandatory signature verification for any image that is going to be pulled or run
Container image vulnerabilities Risk:
  • Security vulnerabilities present in the static image
    • A container is running version X.Y.Z of the web server which happens to suffer from a critical security flaw
    • This flaw has been fixed long ago upstream, but not in the local image
  • Inconsistent update and patching
Best practices:
  • Update and rebuild images periodically to grab the newest security patches
  • Integrate a vulnerability scanner (Trivy) as a mandatory step of the CI/CD
Compromised secrets Risk:
  • Compromised secrets
Best practices:
  • Do not use environment variables for secrets
  • Do not embed any secrets in the container image
  • Use a credentials/secrets storage (Vault)
Container network traffic Risk:
  • Unsecured communication and unrestricted network traffic
  • By default all network traffic is allowed between containers on the same host
  • This increases the risk of unintended and unwanted disclosure of information to other containers
Best practices:
  • Communications with Docker registries should be encrypted over TLS
  • Only allow intercommunication that is necessary by linking specific containers
Ports:
  • Port 2375/TCP & 2376/TCP: docker daemon
  • Port 5000/TCP: registry
Container breakout Risk:
  • Privilege escalation
Best practices:
  • Drop capabilities that are not required (see Docker Capabilities)
  • Monitor dangerous mountpoints from the host
    • e.g., the Docker socket (/var/run/docker.sock), /proc, /dev
    • exposing the file system with read-only privileges should be enough, don't give RW
  • Create an isolated user namespace
    • to limit the maximum privileges of the containers over the host to the equivalent of a regular user