Securing Docker Microservices: Key Strategies from DockerCon 2016

Aaron Grattafiori presented “Golden Ticket: Docker and High‑Security Microservices” at DockerCon 2016 in Seattle, recommending a set of security measures for container‑based microservices.

He introduced a defense‑in‑depth model built on layered protections and attack‑surface reduction, noting that while microservices increase architectural complexity, they can reduce single‑point security failures compared with monolithic applications.

Key principles such as least privilege, “least surprise”, and “least access” help prevent over‑privilege and complexity, enabling architects to establish trust boundaries, minimize and harden attack surfaces, reduce scope and permissions, and apply layered defenses.

1. Establish trust boundaries
2. Identify, minimize, and harden attack surfaces
3. Reduce scope and access privileges
4. Apply layered protection and defense

Advantages of monolithic AppSec include simplicity and well‑understood “known‑knowns”, while its drawbacks involve single‑point compromise and global authentication challenges. Microservice security benefits include adherence to Unix’s single‑responsibility principle, reduced exposed attack surface, independent patching, easier application of least‑privilege controls, and simpler establishment of a trusted computing base.

Disadvantages include the “known unknown” nature of microservice security, required cultural shifts (DevOpsSec), need for deep system understanding, difficulty with legacy projects, and added complexity from scaling.

Network security considerations suggest using TLS at layer 4/5 or IPsec at layer 3, beyond the typical application‑layer authentication.

Containers such as Docker, rkt, or LXC share similar security characteristics. Reducing the threat model involves leveraging capabilities, user namespaces, read‑only rootfs, immutable files, mount flags, and mandatory access control (MAC) to limit damage from application vulnerabilities.

User namespaces can map container root to a non‑root host UID, mitigating container escape. Seccomp, kernel hardening, and MAC restrict system calls; combined with network hardening, trust isolation, logging, and alerting they further limit impact.

Grattafiori recommends starting with a minimal host OS (CoreOS, Alpine Linux, Project Atomic, RancherOS) and understanding its upgrade process, binary packaging, default security settings, and kernel parameters.

Container images should be minimal (e.g., FROM debian:jessie or FROM debian:wheezy), avoiding unnecessary libraries and binaries that increase patching, disk usage, and attack surface.

Examples demonstrated building minimal containers with Docker and runC, and using scratch images to run statically compiled binaries such as Go applications.

Mandatory Access Control (MAC) should be applied from the OS level, using AppArmor or SELinux (or grsecurity) to enforce least‑access policies. While Docker’s default AppArmor profile is comprehensive, custom profiles tailored to each service are preferable, generated via tools like aa-genprof or projects such as Jessie Frazelle’s Bane.

Avoid black‑list (deny) AppArmor rules; instead, use allow‑list policies and verify them with unit and regression testing.

Seccomp provides a sandboxing mechanism that restricts system calls to a whitelist; the extended seccomp‑bpf allows fine‑grained filtering via BPF programs. Docker 1.10+ enables a default seccomp filter covering ~75% of syscalls, but microservices should define custom profiles using tools like strace, sysdig, auditd, or SECCOMP_TRACE.

High‑level recommendations for running secure Docker‑based microservices include:

Enable user namespaces Use application‑specific AppArmor or SELinux profiles Employ application‑specific seccomp whitelists Harden the host operating system Restrict host access permissions Consider network security policies Use immutable containers

Secrets should be injected via temporary mounts or dedicated secret‑management tools (e.g., HashiCorp Vault, Square Keywhiz) rather than environment variables or plain files.

Additional guidance: create a security specification, generate threat models, ensure service‑level security, and integrate security into the CI/CD pipeline using tools such as OWASP ZAP, bdd‑security, Brakeman, or Gauntlt.

Grattafiori’s full talk is available on DockerCon’s YouTube channel, and his whitepaper “Understanding and Hardening Linux Containers” provides further detail.