Container Security: Image Hardening and Runtime Protection

Containers package application code and its dependencies into isolated units that share the host OS kernel, unlike VMs which include a full guest OS. This sharing makes containers lightweight and fast, but introduces a different security model: a container escape vulnerability could allow an attacker to break out of the container and access the host kernel directly, affecting all other containers. Container security focuses on three layers: the image (what is baked in), the runtime (what the container can do while running), and the orchestration platform (how containers are managed).

Every package installed in a container image is a potential attack surface. The principle of minimal base images means starting from the smallest possible foundation: Alpine Linux (5MB, minimal packages), distroless images (Google's images that contain only the runtime and application, no shell or package manager), or scratch (completely empty, for statically compiled binaries). A container with no shell means an attacker who achieves code execution cannot easily run wget, curl, or other tools to escalate their attack — a principle called defense through minimal exposure.

By default, Docker containers run as root (UID 0). If an attacker exploits a vulnerability in the containerized application, they gain root privileges inside the container. If the container shares a volume or has host mounts, root inside the container can equal root on the host. The fix is simple: create a dedicated user in the Dockerfile and switch to it with the USER directive before the final CMD/ENTRYPOINT. Many container security scanning tools will flag any image without a non-root user as a finding.

Immutable containers are containers whose filesystem cannot be modified at runtime. Enabling --read-only in Docker (or readOnlyRootFilesystem: true in Kubernetes) prevents attackers from writing malware to disk, modifying configuration files, or installing tools inside a running container. Applications that genuinely need to write data (logs, temp files) can mount specific tmpfs volumes for ephemeral writes. Immutable containers enforce the principle that runtime state should come only from the image and configuration, not from in-container modifications that bypass your CI/CD security pipeline.

Container image scanning tools analyze the packages installed in a Docker image against vulnerability databases (NVD, CVE) and report known CVEs. Leading scanners include Trivy (Aqua Security, fast and free), Grype (Anchore), Snyk Container, and AWS ECR image scanning. Scanning should be integrated into the CI/CD pipeline so that any image with critical or high CVEs fails the pipeline before being pushed to a registry. Scanners should also check for secrets (API keys, passwords) accidentally embedded in image layers.

A common and dangerous mistake is embedding secrets (API keys, database passwords, TLS certificates) inside Docker images — either in environment variables baked into the image, or in files added via COPY. These secrets are visible to anyone with access to the image via docker history or by extracting image layers. Even if a subsequent layer deletes the file, it remains in the image history. Secrets should be injected at runtime via environment variables from a secrets manager, Docker secrets, or Kubernetes Secrets mounted as volumes.

Runtime security tools monitor container behavior while it is running and alert or block anomalous activity. Falco (CNCF project) hooks into the Linux kernel using eBPF or kernel modules to intercept system calls and compare them against rules. For example, a rule can alert if a container spawns a shell (execve('/bin/sh')), opens a network connection on an unexpected port, or reads /etc/shadow. These behavioral indicators often signal an active attack even if no known CVE was exploited. Sysdig Secure and Aqua Security provide commercial runtime protection platforms.

Docker containers by default drop many Linux capabilities but still retain more than most applications need. Capabilities partition root privileges into distinct units (e.g., CAP_NET_ADMIN, CAP_SYS_ADMIN). Best practice is to drop all capabilities and add back only what is required with --cap-drop=ALL --cap-add=NET_BIND_SERVICE. Seccomp (Secure Computing Mode) profiles whitelist which system calls a container is allowed to make — Docker includes a default seccomp profile that blocks ~44 dangerous syscalls. Custom seccomp profiles for specific applications can restrict this further, blocking all syscalls the application never legitimately uses.

Container registries (Docker Hub, AWS ECR, Google Artifact Registry) store and distribute images. Securing the registry involves: enabling vulnerability scanning on push, restricting push access to CI/CD service accounts only, enabling image signing using Sigstore/Cosign or Docker Content Trust (Notary) so that runtime environments only pull cryptographically signed images from trusted sources, and configuring image immutability so that tags cannot be overwritten (eliminating tag mutation attacks where an attacker replaces a trusted :latest tag with a malicious image).

Attackers who gain code execution inside a container may attempt container escape to reach the host. Common techniques include: exploiting vulnerable privileged containers (--privileged gives nearly unrestricted host access), abusing exposed Docker sockets (/var/run/docker.sock mounted into a container gives full Docker API access including creating privileged containers), exploiting kernel vulnerabilities via unsecured capabilities. Defenses: never use privileged mode unless absolutely necessary, never mount the Docker socket into application containers, keep the host kernel patched, and use gVisor or Kata Containers for workloads requiring strong isolation.

The Center for Internet Security (CIS) Docker Benchmark provides detailed security configuration guidelines for Docker hosts and containers, covering daemon configuration, image hygiene, container runtime settings, and network controls. Tools like Docker Bench for Security automate compliance checking against the CIS benchmark, producing a scored report of pass/fail items. Running this benchmark periodically and integrating it into CI/CD ensures that security configuration drift is detected quickly. Security+ candidates should know that CIS Benchmarks are a primary reference for OS and platform hardening in the exam context.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: minimal base images and non-root users reduce the attack surface and privilege level of containerized workloads, runtime protection tools like Falco detect anomalous syscall patterns indicative of active attacks within containers, and never use privileged containers or mount the Docker socket into application containers as these configurations enable container escape. Next up we explore Kubernetes security including RBAC, network policies, and pod security standards.