Cloud Security
Intermediate 20 min read Cloud Security
Container Security
Harden the container supply chain: minimal base images, signing, immutable runtime, and the host/kernel reality behind 'lightweight' isolation.
containersbase imageimage signingnon-rootread-only rootfsseccomp
Introduction
What is this?
Container security is the discipline of the image-to-runtime chain: a trusted, minimal image, verified content, and a runtime confined enough that 'contained' means what it implies.
Motivation
Why do you need it?
- Containers multiply your workloads — a tiny image flaw multiplies into thousands of identical incidents.
- Misconfigured runtime (root user, privileged, host mounts) is how 'container' becomes 'host compromise'.
- The security of 'Nginx in a box' depends on the image's base OS and the runtime's sandbox, not the Nginx config alone.
Think about it
Mental model
Imagine
Pre-packed shipping containers
Think of
Pre-packed by a stranger with a master key inside
The shipping box is great until you realize the cargo came from an unvetted packer with root.
Mechanics
How it works
- Base image: minimal, pinned, and scanned — every layer is a supply-chain claim you inherit.
- Content: signatures (cosign/Sigstore) and digests pin what runs; a floating tag can silently swap the image.
- Runtime: non-root user, read-only root filesystem, seccomp/AppArmor profiles drop privileges further.
- Capabilities: drop ALL and add only what the workload truly needs — not a namesake of CAP_SYS_ADMIN.
The image-to-runtime hardening path
Basedistroless/slim, pinned digest
Signcosign signs the image
ScanSBOM + CVE gates
Runnon-root + read-only + seccomp
Watchruntime detection ratings
Real world
In production
- A platform team enforces 'no root user' and 'read-only rootfs' in admission policy; red-team pods die at policy time.
- A startup signs every image and verifies in CI, killing backdoor-image supply-chain swaps.
- A chip vendor runs seccomp profiles generated per process, dropping syscalls the binary never uses.
Guidelines
Best practices
- Start from minimal slims (alpine/distroless) pinned to a digest, never floating tags.
- Run as a non-root UID with drop-all/cap-add-whats-needed capabilities.
- Set read-only root filesystem and a tmpfs for writes only where required.
- Scan every image and gate on high/critical findings with a signed SBOM in the artifact.
Watch out
Common mistakes
- Copying a 1GB 'full' image for a 5MB utility — the attack surface travels with the fat.
- Running as root 'because the app needs it', skipping the three-line non-root fix.
- Mounting host paths or docker.sock into containers; one exploit becomes host-admin instantly.
- Pulling from public registries on the production kubelet, untagged and unsigned.
When things break
Debugging tips
- When a container misbehaves under read-only root, find the write path ('touch /srv/x' error) and give it a tmpfs.
- Test capabilities with capsh or a scratch container that prints its bounding set.
- Scan the recursive layers: an inherited vulnerable base keeps failing scans even after your own layers are clean.
Security
Security considerations
- Images are code too — treat them like any dependency: reviewed, pinned, and patched on a cadence.
- Signing is a trust decision: know exactly which keys bind to which images before trusting a trust framework.
Interviews
Interview checkpoint
Test yourself
Quick quiz
0/2
1
Which is the strongest container runtime posture?
2
Image signing (cosign) protects against...
Go deeper