container-security-hardening – Security skill for AI agents

Container Security Hardening Skill

A production-focused guide for building, scanning, and running containers securely — from Dockerfile authoring through runtime enforcement and supply chain integrity.

---

Detailed Guide

Read [the detailed guide](references/detailed-guide.md) before executing this skill. It retains the complete procedure and reference material. Treat its safety, prerequisites, and validation requirements as mandatory. For focused work, load the relevant sections; for end-to-end work, read the guide completely.

When to Use This Skill

• User mentions Docker security, container hardening, or Dockerfile security review
• User asks about distroless images, non-root containers, or read-only filesystems
• User wants to scan images for CVEs with Trivy, Grype, or Snyk
• User mentions seccomp, AppArmor, Linux capabilities, or runtime security
• User asks "is my Dockerfile secure?" or "how do I reduce my image attack surface?"
• User wants to sign/verify images with Cosign or generate SBOMs
• User asks about Kubernetes pod security, NetworkPolicy, or RBAC hardening
• User says "fix container CVEs" or "harden my container for production"

When NOT to Use This Skill

• The user is primarily asking about GitHub Actions CI/CD → recommend github-actions-advanced
• The user needs general Docker usage help (not security) → recommend docker-expert
• The user is working with Kubernetes orchestration beyond security → recommend kubernetes-architect
• The user needs application-level security (SQL injection, XSS) → recommend api-security-best-practices

---

Security Checklist

Dockerfile

• [ ] Supported minimal base image compatible with the application
• [ ] Multi-stage build — no build tools, devDependencies, or compilers in runtime image
• [ ] Non-root USER declared before CMD/ENTRYPOINT
• [ ] Base image pinned to @sha256:... digest (not just tag)
• [ ] No secrets in ENV, ARG, or RUN commands
• [ ] HEALTHCHECK defined
• [ ] OCI labels present (org.opencontainers.image.*)
• [ ] .dockerignore excludes .git, .env, secrets, tests
• [ ] ENTRYPOINT uses exec form, not shell form

Image Scanning

• [ ] Trivy or Grype scan in CI (fails on HIGH/CRITICAL)
• [ ] Hadolint passes with no warnings
• [ ] Secret scan run on image (trivy --scanners secret)
• [ ] SBOM generated and stored
• [ ] .trivyignore has justified entries for accepted CVEs

Runtime

• [ ] --read-only filesystem
• [ ] --cap-drop ALL (add back only what's documented as required)
• [ ] --security-opt no-new-privileges:true
• [ ] Runtime default seccomp applied; custom profile only after isolated validation
• [ ] Resource limits set (--memory, --cpus, --pids-limit)
• [ ] Image signed with Cosign; verified before deploy

Kubernetes

• [ ] readOnlyRootFilesystem: true
• [ ] allowPrivilegeEscalation: false
• [ ] runAsNonRoot: true with explicit UID
• [ ] capabilities.drop: ["ALL"]
• [ ] Resource requests and limits defined
• [ ] automountServiceAccountToken: false
• [ ] Namespace PSA enforced at restricted level
• [ ] NetworkPolicy default-deny applied
• [ ] RBAC uses specific resource names and minimal verbs

---

Limitations

• Cluster-wide admission policies, registry settings and runtime restrictions can disrupt workloads. Review the intended scope, test in staging and provide rollback before applying. Bundled profiles and manifests are examples, not a security certification.

• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific penetration testing or a formal security audit.
• Seccomp and AppArmor act on the Linux host/kernel; Docker Desktop may apply them inside its Linux VM depending on runtime support.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.