Container Security Compliance

The Container Threat Model

Containers introduced a new set of security concerns that traditional server hardening does not address. Your attack surface now includes the container image (vulnerable base OS packages, embedded secrets), the container runtime (escape vulnerabilities, privilege escalation), the orchestrator (Kubernetes API server exposure, RBAC misconfigurations), and the supply chain (compromised base images, tampered build artifacts). Each layer needs specific controls.

Image Security

Start with base image selection. Every package in your base image is a potential vulnerability. Distroless images from Google contain only your application and its runtime dependencies. No shell, no package manager, no utilities an attacker could leverage. Alpine Linux is a lighter alternative to Debian or Ubuntu, with a smaller package set but still includes a shell. For production workloads, the less you include, the less you need to patch.

Scan images at two points: in CI when the image is built, and continuously in your registry. Trivy is open-source and covers OS packages and application dependencies. Snyk Container and Prisma Cloud add commercial features like base image upgrade recommendations and risk-based prioritization. The key is enforcement. Configure your CI pipeline to fail builds when critical or high CVEs are detected. Configure your admission controller to reject unscanned images.

Kubernetes Security Hardening

Pod Security Standards define three profiles. Privileged allows everything (only for system-level workloads). Baseline blocks the most dangerous configurations: host networking, host PID, privileged containers. Restricted enforces best practices: non-root users, read-only root filesystem, dropped capabilities, seccomp profiles.

Apply Restricted to application namespaces using the built-in Pod Security Admission controller or a policy engine like Kyverno or OPA Gatekeeper. For each workload, set explicit security contexts:

securityContext:
  runAsNonRoot: true
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

Network policies default to allow-all in Kubernetes. This means any compromised pod can talk to any other pod, including your database. Define NetworkPolicy resources that restrict ingress and egress to only the communications each workload requires. Start with a default-deny policy per namespace, then add specific allow rules.

Runtime Security

Static scanning catches known vulnerabilities. Runtime security catches exploitation. Falco monitors system calls at the kernel level and alerts on suspicious behavior: shell spawned in a container, unexpected network connection, sensitive file access. Tetragon (from Cilium) provides eBPF-based runtime enforcement that can block malicious actions, not just detect them.

Supply Chain Integrity

Sign your container images after building them using Cosign (part of the Sigstore project). Verify signatures at deployment time using an admission controller. This creates a chain of trust: only images built by your CI pipeline, from your approved source code, can run in your cluster. The SLSA framework formalizes this with four levels of increasing rigor. Level 1 requires build provenance documentation. Level 2 requires a hosted build service. Level 3 requires a hardened build platform with non-falsifiable provenance. Most teams should target Level 3 as a practical goal that meaningfully reduces supply chain risk.