container-security-hardening

Harden Docker images and Kubernetes deployments with scanning, signing, and runtime security controls.

Updated Jun 12, 2026
One-click install
npx skills add https://github.com/bilacchi/agents-skills --skill container-security-hardening-bilacchi
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: container-security-hardening
Source: https://github.com/bilacchi/agents-skills/tree/main/skills/container-security-hardening
Command: npx skills add https://github.com/bilacchi/agents-skills --skill container-security-hardening-bilacchi

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Container images often ship with bloated base images, root users, embedded secrets, and unscanned CVEs, leaving production deployments exposed. This Skill provides a five-layer hardening workflow covering Dockerfile security, image scanning, runtime controls, supply chain integrity, and Kubernetes pod security. ## Core Features & Use Cases - Dockerfile Hardening: Apply minimal base images (distroless, alpine, slim), multi-stage builds, non-root users, digest pinning, and BuildKit secret mounts. - Image Scanning & Supply Chain: Scan with Trivy, Grype, and Hadolint, generate SBOMs, and sign images with Cosign keyless signing in CI pipelines. - Runtime & Kubernetes Security: Enforce read-only filesystems, dropped capabilities, seccomp profiles, Pod Security Admission, NetworkPolicy, RBAC, and Kyverno policies. - Use Case: A team preparing a Node.js service for production can use this Skill to rewrite its Dockerfile to a distroless multi-stage build, add Trivy scanning to GitHub Actions, and deploy with a restricted Pod Security context and default-deny NetworkPolicy. ## Quick Start Review my Dockerfile and Kubernetes manifests for security issues and harden them for production deployment.

Frequently Asked Questions about container-security-hardening

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I harden a Dockerfile for production?▼

Use a minimal base image like distroless or slim, add a multi-stage build to exclude build tools, create a non-root USER, pin the base image to a sha256 digest, and never store secrets in ENV or RUN commands. Add a HEALTHCHECK and a .dockerignore excluding .git and .env files.

How do I scan Docker images for CVEs with Trivy?▼

Run trivy image myapp:latest to scan for vulnerabilities, and add --exit-code 1 --severity HIGH,CRITICAL to fail CI on serious findings. Trivy also scans Dockerfiles for misconfigurations with trivy config and generates SBOMs in CycloneDX or SPDX formats.

Distroless vs Alpine vs slim base images, which should I use?▼

Distroless offers the smallest attack surface with no shell or package manager and a built-in nonroot user, making it best for production. Alpine is small but uses musl libc which can break some native modules. Slim variants keep glibc compatibility when distroless is not an option.

Why does my container crash with a read-only filesystem?▼

Applications often write to /tmp or their app directory, which fails when the root filesystem is read-only. Mount a tmpfs volume for writable paths, such as --tmpfs /tmp:noexec,nosuid in Docker or an emptyDir volume in Kubernetes.

How do I enforce non-root containers in Kubernetes?▼

Set runAsNonRoot: true with an explicit runAsUser in the pod securityContext, plus allowPrivilegeEscalation: false, readOnlyRootFilesystem: true, and capabilities drop ALL. Enforce cluster-wide with Pod Security Admission at the restricted level or a Kyverno require-non-root policy.

When should I not use this container hardening approach?▼

Seccomp and AppArmor profiles are Linux-only and do not apply the same way on macOS or Windows Docker Desktop. For application-level threats like SQL injection or XSS, use an application security skill instead, and treat this guidance as a complement to formal penetration testing.