domains / families / security / container-hardening

container-hardening

combined

Secure Docker images and container runtime configurations. Implement non-root users, read-only filesystems, and security contexts. Use when building secure container images or hardening container deployments. Secure Docker images and container runtime configurations.

When to use

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

When not to use

• 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 sta…
• 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 sc…
• 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 d…
• Docs-only import: upstream scripts and templates not bundled.

Skill page

Conflict

The second copy is a direct adaptation of the first, but it changes the procedure in ways that conflict with the original rather than merely shortening it. The original Dockerfile installs and then removes build dependencies and adds NET_BIND_SERVICE at runtime; the adapted copy removes the build-dependency step entirely (and explicitly warns against it), drops NET_BIND_SERVICE, pins digests, and adds resource limits and tmpfs flags. Because the copies disagree on concrete steps, crowning one would hide a real alternative.