Container Security

What it is

Container security is a set of practices, tools, and policies designed to protect containerized applications throughout their lifecycle. It spans from secure image building to runtime threat detection, through secure orchestration and regulatory compliance.

Unlike traditional application security, container security must consider multiple layers: the base image, dependencies, container runtime, orchestration, and underlying infrastructure. Each layer introduces unique attack vectors that require specific controls.

Container security is not an optional add-on — it's an integral discipline that must be integrated into the CI/CD pipeline from first commit to production.

Image security

Secure construction

Security begins in the Dockerfile. Base images should be official, minimal, and up-to-date. Distroless or Alpine Linux-based images significantly reduce attack surface by eliminating shells, package managers, and unnecessary tools.

# ❌ Insecure image
FROM ubuntu:latest
RUN apt-get update && apt-get install -y curl
COPY . /app
USER root
CMD ["node", "app.js"]
 
# ✅ Secure image
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
 
FROM gcr.io/distroless/nodejs20-debian12
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/src ./src
USER 65534
CMD ["src/app.js"]

Vulnerability scanning

Scanning should run at multiple stages: during build, before deployment, and periodically in registries. Tools like Trivy, Grype, or Snyk identify known vulnerabilities (CVEs) in the base OS and application dependencies.

# GitHub Actions - Trivy scanning
- name: Run Trivy vulnerability scanner
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'myapp:${{ github.sha }}'
    format: 'sarif'
    output: 'trivy-results.sarif'
    severity: 'CRITICAL,HIGH'
    exit-code: '1'  # Fail build if critical vulnerabilities found

Image signing and verification

Image signing with cosign ensures integrity and provenance. It implements a zero-trust model where only images signed by authorized keys can run in production.

# Sign image
cosign sign --key cosign.key myregistry/myapp:v1.0.0
 
# Verify in admission controller
cosign verify --key cosign.pub myregistry/myapp:v1.0.0

Runtime security

Threat detection

Falco monitors kernel behavior in real-time, detecting anomalous activities like sensitive file access, privilege escalation, or suspicious network connections.

# Custom Falco rule
- rule: Unexpected Network Connection
  desc: Detect unexpected outbound connections
  condition: >
    (spawned_process and container and
     (fd.typechar = 4 and fd.net != "127.0.0.1" and not fd.net in (allowed_networks)))
  output: >
    Unexpected network connection (user=%user.name container=%container.name 
    dest=%fd.rip:%fd.rport)
  priority: WARNING

Pod security policies

Kubernetes Pod Security Standards define three policy levels: Privileged, Baseline, and Restricted. The Restricted level should be the standard for production workloads.

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 65534
        fsGroup: 65534
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: app
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          capabilities:
            drop: ["ALL"]
        resources:
          limits:
            memory: "128Mi"
            cpu: "100m"

Network policies

Network policies implement microsegmentation, limiting communication between pods based on labels and namespaces. By default, all traffic should be denied (deny-all) with explicit exceptions.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-network-policy
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

Secrets management

Secrets should never be embedded in images or plain environment variables. Tools like AWS Secrets Manager, HashiCorp Vault, or Kubernetes Secrets with encryption at rest provide secure credential management.

# Secure secrets usage in Kubernetes
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: app
        env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: password
        volumeMounts:
        - name: tls-certs
          mountPath: /etc/ssl/certs
          readOnly: true
      volumes:
      - name: tls-certs
        secret:
          secretName: tls-certificates

Tools and comparison

Why it matters

Containers amplify both security benefits and risks. A vulnerable image replicates instantly to hundreds of instances. A compromised container can laterally escalate through cluster networks. Container immutability is a security advantage, but only if base images are secure from the source.

For staff+ engineering teams, container security isn't just compliance — it's architecture. Decisions about registries, admission policies, and threat detection directly impact organizational security posture. Automating security controls in the pipeline reduces developer friction while maintaining consistent standards.

The cost of remediating vulnerabilities grows exponentially: significantly more expensive in production than in development. Shift-left container security transforms security from a reactive blocker into a proactive accelerator.

References

• SP 800-190, Application Container Security Guide | CSRC — NIST, 2017. Definitive container security guide from the US government.
• Best practices | Docker Docs — Docker, 2024. Official practices for secure image building.
• Pod Security Standards | Kubernetes — Kubernetes, 2024. Official security standards for pods.
• The Falco Project | Falco — CNCF, 2024. Official Falco documentation for runtime threat detection.
• Overview - Sigstore — Sigstore, 2024. Project for software artifact signing and verification.
• 17 comprehensive container security best practices for 2026 | Sysdig — Sysdig, 2024. Updated container security practices.
• Everything You Need to Know to Get Started With Container Security | Container Security Basics | Snyk — Snyk, 2024. Comprehensive guide to container security fundamentals.