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

Base
Sign
Scan
Run
Watch
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

Official documentation