Phase 1: The Build – Forging a Secure Foundation

Security starts with the source code and the Dockerfile. A vulnerability introduced here will be replicated across every environment. This phase is about minimizing the attack surface from the very beginning.

1.1. Choose Minimal Base Images

Every package, library, and binary in your container image is a potential attack vector. The larger the image, the larger the attack surface. Start with the smallest possible base image that can run your application.

• Distroless Images: Created by Google, these images contain only your application and its runtime dependencies. They lack shells, package managers, and other utilities, making them extremely small and secure.
• Alpine: A popular choice due to its small size (~5MB). However, be aware it uses `musl libc` instead of `glibc`, which can cause compatibility issues with some applications.
• Slim Variants: Many official images (e.g., `python:3.9-slim`) offer a “slim” version that removes unnecessary build tools and documentation.

1.2. Implement Multi-Stage Builds

A multi-stage build uses multiple `FROM` statements in a Dockerfile. This allows you to use a larger image with build tools and compilers to compile your application, then copy only the compiled artifact into a smaller, clean production image. This prevents build tools, compilers, and intermediate files from being included in your final container, drastically reducing its size and attack surface.

# --- Build Stage ---
FROM golang:1.19-alpine AS builder
WORKDIR /app
COPY . .
# Build the application statically
RUN CGO_ENABLED=0 GOOS=linux go build -o myapp .

# --- Production Stage ---
FROM gcr.io/distroless/static-debian11
WORKDIR /
# Copy only the compiled binary from the builder stage
COPY --from=builder /app/myapp .
# Set the non-root user (see next section)
USER 65532:65532
ENTRYPOINT ["/myapp"]

1.3. Run as a Non-Root User (CRITICAL)

By default, containers run as the `root` user. If an attacker compromises a root-run container, they have root privileges inside the container and potentially an easier path to escalating privileges on the host node. Running as a non-root user is arguably the single most important security practice.

• In the Dockerfile: Create a dedicated user and group, then switch to that user with the `USER` instruction.
• In Kubernetes: Enforce this with a `securityContext` in your Pod spec: `runAsUser: 1001`, `runAsGroup: 1001`, `runAsNonRoot: true`.

1.4. Scan for Vulnerabilities Early and Often

Vulnerability scanning should be an automated step in your CI/CD pipeline. Scan your base images, application dependencies, and final images for known Common Vulnerabilities and Exposures (CVEs). A robust process will fail the build if high-severity vulnerabilities are detected.

Phase 2: The Ship – Securing the Supply Chain

Once an image is built, it must be stored and distributed securely. This phase is about ensuring the integrity and authenticity of your container images, preventing tampering and the deployment of unauthorized code.

2.1. Use a Secure Private Registry

Public registries like Docker Hub are convenient but offer limited control. For enterprise use, a private registry is mandatory. It provides a secure, controlled environment to store your container images.

• Managed Services: AWS ECR, Google Artifact Registry, and Azure Container Registry are excellent, fully-managed options.
• Self-Hosted: Harbor is the de-facto open-source standard, offering vulnerability scanning, access control, and replication.

2.2. Sign Your Images (CRITICAL)

How do you know the image running in production is the exact same one your CI pipeline built? Image signing provides this cryptographic guarantee. It proves an image’s origin and ensures it hasn’t been tampered with.

# Generate a key pair
cosign generate-key-pair

# Sign your container image
cosign sign --key cosign.key your-registry/your-image:tag

2.3. Enforce Image Provenance with Admission Controllers

Signing images is only half the battle; you must enforce that only signed images can run in your cluster. This is done using a Kubernetes admission controller.

• Kyverno & OPA Gatekeeper: These policy engines can be configured with a policy that intercepts every pod creation request. The policy uses `cosign verify` to check for a valid signature against a public key. If the signature is missing or invalid, the admission controller rejects the pod, preventing it from running.

Phase 3: The Run – Securing Containers in Production

Even a perfectly built and signed image can be exploited through a zero-day vulnerability or interact with the host in unintended ways. Runtime security is about limiting the blast radius of a compromise and detecting threats as they happen.

3.1. Enforce Least Privilege with `securityContext`

The `securityContext` field in your Pod and Container specifications is your most powerful tool for hardening containers at runtime. It allows you to control the privileges and permissions of your running processes.

• `allowPrivilegeEscalation: false`: Prevents a process from gaining more privileges than its parent.
• `readOnlyRootFilesystem: true`: Prevents an attacker from writing to the container’s filesystem.
• `capabilities: { drop: [“ALL”] }`: Drops all Linux capabilities, then add back only the specific ones your application needs (e.g., `NET_BIND_SERVICE`).

# Example of a hardened securityContext
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
  - name: my-app
    image: my-secure-image
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      runAsNonRoot: true
      runAsUser: 1001
      capabilities:
        drop:
        - ALL

3.2. Isolate Workloads with Network Policies

By default, all pods in a Kubernetes cluster can communicate with each other. This is a huge security risk. Network Policies act as a firewall for your pods, allowing you to define explicit rules about which pods can communicate with each other. The best practice is to start with a default-deny policy that blocks all traffic, then explicitly allow only the required communication paths.

3.3. Detect Threats with Runtime Security Tools

Runtime security tools monitor your running containers for suspicious activity. They can detect threats that static scanning misses, such as a process trying to access sensitive files, make unexpected network connections, or spawn a shell.