Lion Cipher Lab
Harden a container: non-root, drop capabilities, seccomp
- Cloud Security
- Intermediate
- ~50 min
- Free · no account required
Why it matters
Getting a container to run is easy; making it hard to escape is the part that keeps an attacker who lands inside from reaching your host. A container shares the host kernel, so the amount of damage a compromised process can do is decided by exactly one thing: how much power you handed the container at launch. The default is far more power than any app needs — root inside the box, the full set of Linux capabilities, a writable filesystem, and no restriction on gaining new privileges. This lab flips each of those to the safe setting and proves it worked by making the dangerous action fail with…
What you'll learn
- container runtime hardening
- least privilege for containers
- running containers as non-root
- dropping Linux capabilities
- no-new-privileges / blocking setuid escalation
- read-only root filesystem + tmpfs
- seccomp syscall filtering
- defence-in-depth
- mapping Docker hardening to Kubernetes securityContext
Steps in this lab
- The model: your launch flags decide the blast radius
- Baseline: build the over-privileged container and see the danger
- Control 1 (highest value): stop being root inside the container
- Control 2: drop every capability, add back only what's needed
- Control 3: forbid gaining new privileges (--security-opt=no-new-privileges)
- Control 4: make the root filesystem read-only
- Control 5: filter syscalls with seccomp
- One layer beyond seccomp: AppArmor / SELinux (MAC)
- Put it together: the fully hardened run command
- Where this goes next: Kubernetes securityContext
- What you just did — and the judgment to keep