Container Hardening

Secure container images and runtime configurations.

When to Use This Skill

Use this skill when:

• Building secure container images
• Hardening container deployments
• Meeting container security requirements
• Implementing defense in depth

Dockerfile Security

# Example for an application binary already built for this Alpine/musl runtime.
# Pin an approved immutable digest for real builds; refresh supported base images.
FROM alpine:3.24
RUN addgroup -g 1001 -S appgroup && \
    adduser -u 1001 -S appuser -G appgroup
WORKDIR /app
# Copy only the intended reviewed build artifact, not credentials or the entire repo.
COPY --chown=appuser:appgroup myapp /app/myapp
USER 1001:1001
ENTRYPOINT ["/app/myapp"]

Runtime Security

# Run with security options
docker run -d \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  --security-opt=no-new-privileges:true \
  --cap-drop=ALL \
  --user 1001:1001 \
  myapp@sha256:<reviewed-image-digest>

Kubernetes Security Context

apiVersion: v1
kind: Pod
metadata:
  name: hardened-example
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1001
    fsGroup: 1001
  containers:
  - name: app
    image: myapp@sha256:<reviewed-image-digest>
    resources:
      requests: {cpu: "100m", memory: "64Mi"}
      limits: {cpu: "500m", memory: "256Mi"}
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

Image Scanning

# Scan with Trivy
trivy image --severity HIGH,CRITICAL myapp@sha256:<reviewed-image-digest>

# Consider a maintained distroless image only when the actual application is compatible;
# FROM belongs in a Dockerfile, not this shell scanning example.

Best Practices

• Use minimal base images
• Run as non-root user
• Enable read-only filesystem
• Drop all capabilities
• Scan images regularly
• Sign and verify images
• Use secrets management

Related Skills

• container-scanning (container-scanning) - Vulnerability scanning
• kubernetes-hardening (kubernetes-hardening) - K8s security

Limitations

• The Dockerfile needs a reviewed executable myapp built for the selected ABI; it is not bundled. Build dependencies were never installed in this stage, so do not run apk del against a nonexistent virtual group. Prefer a separate builder stage when compilation is needed.
• Replace digest placeholders with verified image identities before execution. The Pod YAML is a template; tune actual resource budgets and approved volumes, network policy and workload permissions. No Docker build, cluster application or scanner execution is claimed.
• Read-only filesystems and dropped capabilities reduce privileges but are not a complete sandbox. Add writable paths only where required; low ports do not justify NET_BIND_SERVICE by default. Scanning can disclose artifacts or use network databases, so review data paths and policies first.
• Docs-only import: upstream scripts and templates not bundled.

Example

# Read-only first: inventory before any active step.
command -v docker
docker --version

Adapted from BagelHole/DevOps-Security-Agent-Skills (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: helper scripts and templates not bundled.