Why Standards Matter for Container Security
Without standards, each team makes their own security decisions: one runs containers as root, another restricts privilege escalation. One disables security scanning, another enforces it. Inconsistent security creates gaps that attackers exploit. Standards like the CIS Docker Benchmark define "secure" explicitly: run as non-root, disable privilege escalation, scan images, limit capabilities. These aren't guidelines—they're requirements that can be automated and verified. With benchmarks, you move from "we hope security is good" to "we can prove all containers meet standard X."
Container hardening benchmarks are standardized security requirements for containers. The major ones are CIS Docker Benchmark (general containers), CIS Kubernetes Benchmark (Kubernetes clusters), DISA STIG (Department of Defense), and NIST guidance. They define "secure" explicitly so organizations can implement, verify, and automate compliance.
graph TB Standards["Hardening Benchmarks"] Standards --> CIS["CIS Docker<br/>Benchmark"] Standards --> K8S["CIS Kubernetes<br/>Benchmark"] Standards --> DoD["DISA STIG<br/>DoD Standard"] Standards --> NIST["NIST<br/>Guidance"] CIS --> Check1["Host Config<br/>Daemon Config<br/>Runtime"] K8S --> Check2["Control Plane<br/>Worker Nodes<br/>Policies"] DoD --> Check3["Government<br/>Compliance"] NIST --> Check4["Federal<br/>Best Practices"] Check1 --> Verify["Automated<br/>Verification"] Check2 --> Verify Check3 --> Verify Check4 --> Verify Verify --> Compliant["Prove<br/>Compliance"] style Compliant fill:#ccffccCIS Docker Benchmark
The Center for Internet Security (CIS) publishes the most widely-used Docker benchmark. It covers Host Configuration, Docker Daemon Configuration, Docker Daemon Files and Directories, Container Images and Build Files, Container Runtime, Docker Security Operations, and Docker Swarm Configuration.
Example CIS Requirements
Container Image Security
# ❌ NOT compliant: Runs as rootFROM ubuntu:22.04RUN apt-get update && apt-get install -y curlENTRYPOINT ["curl"] # ✅ COMPLIANT: Runs as non-root userFROM ubuntu:22.04RUN groupadd -r appuser && useradd -r -g appuser appuserUSER appuserENTRYPOINT ["curl"]Read-Only Root Filesystem
# ❌ NOT compliant: Writable filesystemapiVersion: v1kind: Podmetadata: name: myappspec: containers: - name: app image: myapp:latest # No securityContext # ✅ COMPLIANT: Read-only root filesystemapiVersion: v1kind: Podmetadata: name: myappspec: containers: - name: app image: myapp:latest securityContext: readOnlyRootFilesystem: trueDrop Capabilities
# ❌ NOT compliant: Unnecessary capabilitiesapiVersion: v1kind: Podmetadata: name: myappspec: containers: - name: app image: myapp:latest # ✅ COMPLIANT: Drop all capabilities, add only neededapiVersion: v1kind: Podmetadata: name: myappspec: containers: - name: app image: myapp:latest securityContext: capabilities: drop: - ALL add: - NET_BIND_SERVICE # Only if neededCIS Kubernetes Benchmark
For Kubernetes clusters, the CIS Kubernetes Benchmark covers Control Plane Configuration, etcd Configuration, Control Plane Configuration Files, Worker Node Configuration, and Kubernetes Policies.
Key Kubernetes Security Controls
# Pod Security Policy (enforce strict controls)apiVersion: policy/v1beta1kind: PodSecurityPolicymetadata: name: restrictedspec: privileged: false allowPrivilegeEscalation: false requiredDropCapabilities: - ALL volumes: - 'configMap' - 'emptyDir' - 'projected' - 'secret' - 'downwardAPI' - 'persistentVolumeClaim' hostNetwork: false hostIPC: false hostPID: false runAsUser: rule: 'MustRunAsNonRoot' seLinux: rule: 'MustRunAs' seLinuxOptions: level: "s0:c123,c456" supplementalGroups: rule: 'MustRunAs' fsGroup: rule: 'MustRunAs' readOnlyRootFilesystem: trueDISA STIG (Security Technical Implementation Guide)
DISA STIG provides Department of Defense security requirements. For containers, the key requirements encompass authentication for enforcing container image verification, encryption for using encrypted channels for all communication, audit logging for logging all container activities, access control for using role-based access control (RBAC), vulnerability management for scanning images regularly, and network security for using network policies to restrict traffic.
DISA Compliance Example
# Kubernetes deployment meeting DISA requirementsapiVersion: apps/v1kind: Deploymentmetadata: name: disa-compliant-appspec: template: spec: serviceAccountName: app-sa containers: - name: app image: registry.example.com/myapp:v1.0.0@sha256:abc123... securityContext: runAsNonRoot: true runAsUser: 1000 allowPrivilegeEscalation: false capabilities: drop: - ALL readOnlyRootFilesystem: true resources: limits: cpu: "500m" memory: "512Mi" requests: cpu: "250m" memory: "256Mi" affinity: # Pod anti-affinity for availability podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - myapp topologyKey: "kubernetes.io/hostname"NIST Container Security Guidance
NIST provides federal guidance in Special Publication 800-190: Application Container Security Guide.
NIST Five Principles
NIST's framework emphasizes Image Assurance and Security by verifying image integrity and provenance. It requires Image Configuration and Deployment with hardened configurations. Organizations must perform Container Platform Hardening on the host OS and orchestration platform. Supply Chain Security demands trusted components and build processes. Monitoring and Incident Response must detect and respond to threats.
NIST Compliance Checklist
# NIST-compliant container configurationapiVersion: v1kind: Podmetadata: name: nist-secure-appspec: containers: - name: app image: gcr.io/myproject/app:v1.0.0@sha256:deadbeef... # 1. Resource limits (prevent DoS) resources: limits: cpu: "1" memory: "512Mi" requests: cpu: "500m" memory: "256Mi" # 2. Security context (principle of least privilege) securityContext: runAsNonRoot: true runAsUser: 1000 readOnlyRootFilesystem: true allowPrivilegeEscalation: false capabilities: drop: - ALL # 3. Volume mounts (minimal writable paths) volumeMounts: - name: tmp mountPath: /tmp - name: var-log mountPath: /var/log # 4. Pod-level security securityContext: fsGroup: 2000 seccompProfile: type: RuntimeDefault # 5. Network policies (external traffic control) # Use NetworkPolicy to restrict network traffic volumes: - name: tmp emptyDir: {} - name: var-log emptyDir: {}OpenSCAP: Scanning and Compliance
OpenSCAP is an open-source framework for scanning containers against benchmarks.
Running OpenSCAP Scans
# Scan container against CIS Benchmarkoscap container image scan \ --profile xccdf_org.ssgproject.content_profile_cis_docker \ myapp:latest # Output: Detailed compliance report# Shows which controls pass/fail# Provides remediation guidanceAutomated Compliance in CI/CD
# GitHub Actions: Scan for CIS compliancename: Container Security Scan on: [push] jobs: scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Build container image run: docker build -t myapp:latest . - name: Run OpenSCAP scan run: | docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \ aquasec/trivy image \ --severity HIGH,CRITICAL \ myapp:latest - name: Fail if critical issues found run: | # CI/CD fails if critical vulnerabilities found exit $?Benchmark Comparison
Benchmark | Focus | Use Case | Automation |
|---|---|---|---|
CIS Docker | General containers | Industry standard | ⭐⭐⭐ |
CIS Kubernetes | Kubernetes clusters | Kubernetes deployments | ⭐⭐⭐ |
DISA STIG | DoD compliance | Federal contracts | ⭐⭐ |
NIST 800-190 | Federal guidance | Government organizations | ⭐⭐ |
OpenSCAP | Scanning/audit | Automated compliance | ⭐⭐⭐ |
Common Hardening Controls
1. Run as Non-Root User
# Create non-root userRUN groupadd -r appuser && useradd -r -g appuser appuserUSER appuser ENTRYPOINT ["/app"]2. Use Distroless or Alpine Base Images
# Small, minimal attack surfaceFROM gcr.io/distroless/base-debian12 COPY --from=builder /app/binary /appENTRYPOINT ["/app"]3. Drop All Linux Capabilities
securityContext: capabilities: drop: - ALL add: - NET_BIND_SERVICE # Only add if needed4. Read-Only Root Filesystem
securityContext: readOnlyRootFilesystem: true # Create writable volumes for logs, temp filesvolumeMounts:- name: tmp mountPath: /tmp- name: var-log mountPath: /var/log5. Resource Limits
resources: limits: cpu: "1" memory: "512Mi" requests: cpu: "500m" memory: "256Mi"6. Network Policies
apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: app-network-policyspec: podSelector: matchLabels: app: myapp policyTypes: - Ingress - Egress ingress: - from: - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 8080 egress: - to: - podSelector: matchLabels: role: database ports: - protocol: TCP port: 5432CleanStart and Hardening Benchmarks
CleanStart Source Intelligence Core provides comprehensive benchmark support. It analyzes container configurations against CIS/NIST/DISA benchmarks, generates hardening reports showing which controls are met, enforces policies through OPA/Gatekeeper, provides remediation guidance for failing controls, and tracks compliance over time for audit reports.
Benchmark Best Practices
When selecting which hardening benchmark to implement, choose based on your organizational context and regulatory requirements. Use CIS benchmarks for general industry applications, DISA STIGs for Department of Defense contracts and military work, and NIST guidance for federal agencies. Most organizations should start by implementing the CIS Docker Benchmark as a baseline, since it represents industry-wide consensus on reasonable security controls.
Automate the scanning process by integrating OpenSCAP or Trivy scanning tools into your CI/CD pipelines. This ensures every image is evaluated against hardening benchmarks automatically without requiring manual intervention. Enforce compliance through policy admission control mechanisms that prevent non-compliant deployments from being accepted by your Kubernetes clusters.
Take an iterative approach to hardening, starting with baseline compliance and progressively moving toward stricter profiles over time as your organization matures its security practices. Maintain documentation of any approved exceptions or deviations from benchmarks, including business justifications so that future audits and reviews can understand why specific controls were not implemented.
Conduct regular audits by periodically rescanning containers and configurations to ensure sustained compliance over time, particularly after infrastructure changes or updates. Stay current with benchmark evolution by monitoring for updates from CIS, DISA, and NIST, since benchmarks are periodically updated to reflect emerging threats and best practices.
Related Concepts
Container Security: Benchmarks implement container hardening. Admission Control: Enforces compliance with benchmarks. OPA/Gatekeeper: Policy-as-code implementation of benchmarks. Vulnerability Scanning: Complements benchmark compliance. Supply Chain Security: Hardening is part of overall supply chain integrity.
Further Reading
CIS Docker Benchmark - Official Docker benchmark. CIS Kubernetes Benchmark - Official Kubernetes benchmark. NIST 800-190 Guide - Federal container security. OpenSCAP Documentation - Compliance scanning tool. DISA STIGs - DoD security requirements.