9. Hardening Security for Containers

For those new to security, hardening is about “Less is More.” By reducing what a container can do, you reduce what a hacker can steal.

• Rootless Mode: Traditionally, Docker runs with “Admin” (Root) powers. Rootless mode lets Docker run as a standard user. If the container is hacked, the hacker doesn’t get control of your whole computer.
• Seccomp & AppArmor: Think of these as “Digital Handcuffs.” They act as a filter that blocks dangerous commands (like “delete system files”) even if the user inside the container tries to run them.
• CIS Benchmarks: This is a professional “Security Audit Checklist.” It provides a set of best-practice rules to ensure your Docker configuration meets industry safety standards.

hardening is about implementing Defense in Depth and Principle of Least Privilege (PoLP) across the container lifecycle.

• User Namespace Remapping: Maps the container’s root user to a non-privileged UID on the host, preventing container escape from granting host-level root access.
• Kernel Security Modules (LSM):
  • Seccomp (Secure Computing Mode): Filters syscalls. A custom Seccomp profile can block ptrace, mount, and unshare to stop 90% of breakout attempts.
  • AppArmor/SELinux: Mandatory Access Control (MAC) systems that define what files and network ports a specific container process can access.
• Read-Only File Systems: Deploying containers with --read-only prevents attackers from downloading malware or modifying application code during a breach.
• Image Distroless: Using Google’s Distroless images removes shells (sh/bash) and package managers, making it nearly impossible for an attacker to run commands.

This is a comprehensive breakdown of Docker Hardening for devsecopsguru.in. I have improvised the sections to blend SEO-friendly language with high-level architectural strategies.

9.1. Rootless Mode: The Privilege Escalation Killer

In standard Docker, the daemon (dockerd) runs as Root. If a hacker escapes the container, they gain full control of your host. Rootless Mode is the ultimate defense against this.

• Think as: A Rented Office Space. In standard Docker, the tenant has the keys to the entire building. In Rootless Mode, the tenant only has keys to their specific office. Even if they lose their keys, the building’s electrical room and other offices remain safe.
• Rootless mode allows you to run the Docker engine without administrative powers. It uses “User Namespaces” to trick the container into thinking it has root powers, while the host sees it as a regular, limited user.
  • Tools: RootlessKit (Core engine), slirp4netns (User-mode networking).
• Implement userns-remap. This maps UID 0 inside the container to a high-range UID (e.g., 100,000) on the host. This ensures that even “privileged” container processes lack permission to interact with host-level syscalls or files.
  • Tools: Docker Rootless Official, Podman.

—

9.2. Seccomp & AppArmor: The “Invisible Shield”

Hardening isn’t just about who runs the process, but what the process is allowed to say to the Linux Kernel.

• Think as: A Safety Filter. If the container tries to say something dangerous (like “Shut down the server”), Seccomp acts as a filter that ignores that specific command.
• Seccomp: A security profile that blocks dangerous “System Calls” (Syscalls). Docker blocks about 44 out of 300+ syscalls by default.
  • AppArmor: A guard that watches the filesystem. It stops a container from looking into folders it shouldn’t, like your host’s password files.
• Strategy: Move beyond default profiles. Use Falco to profile your application’s behavior in a staging environment. Once you know exactly which syscalls your app needs, create a “Allow-list” only Seccomp profile to achieve a Zero Trust runtime.
  • Tools: Sysdig Falco (Runtime Monitoring), AppArmor Official.

—

9.3. CIS Benchmarks: The Standard of Truth

The Center for Internet Security (CIS) provides the “Gold Standard” checklist for hardening.

• Think as: A Building Inspection. Just like a fire marshal checks if your smoke detectors work, the CIS Benchmark checks if your Docker settings are safe.
• Instead of guessing if you are safe, you run a tool that checks your settings against a list of 100+ security rules.
  • Tools: Docker Bench for Security (The auditor script).
• “Policy as Code.” Do not audit manually. Integrate Checkov or Trivy into your Jenkins/GitHub Actions pipeline. If a developer tries to push an image that violates a CIS rule (e.g., running as root), the build should automatically fail.
  • Tools: Aqua Security Trivy, Checkov.

—

• Docker Rootless Mode Guide
• Seccomp Profiles for Docker
• CIS Docker Benchmark PDF

—

Practical Lab: “Hardening the Walls”

Task 1: Verify your Syscall Shield

Docker blocks reboot by default. Let’s test the Seccomp shield:

docker run --rm alpine reboot

The Result: You will see reboot: Operation not permitted. This proves Seccomp is active.

Task 2: Run the Security Audit

Scan your local environment against the CIS Benchmark:

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  -v /usr/lib/systemd:/usr/lib/systemd:ro \
  -v /etc:/etc:ro \
  --label docker_bench_security \
  docker/docker-bench-security

Goal: Fix every [WARN] until you reach 100% [PASS].

—

Cheat Sheet