What if the biggest hole in your container stack isn’t in the code at all, but in the defaults you never changed? Most teams ship containers with the same permissive settings they used in a quick tutorial, then bolt on security later. That order is backwards, and attackers know it. This guide walks through a practical, layered container security setup. It covers the image, registry, orchestrator, container, and host layers, and it points out the mistakes that quietly undo good intentions. (Best internet security australia) (Kubernetes Documentation: Security)
Why container security needs a layered setup
Containers are not miniature virtual machines. They share the host kernel, which means a single misconfigured container can expose everything running beside it. The classic reference here is NIST SP 800-190, the Application Container Security Guide, published in September 2017, which models risk across five layers: image, registry, orchestrator, container, and host. That framework still shapes most hardening advice today.
The practical takeaway is simple. No single control saves you. A signed image running as root on an unpatched host is still a problem. A hardened host running a bloated image with secrets baked in is also a problem. Security improves when every layer gets at least basic attention.
This is the same principle behind good physical security, where layers of deterrence matter more than one expensive lock. If you have ever compared approaches in home security systems, the logic will feel familiar: the goal is making the attacker’s job expensive at every step. (How much social security will i get at 62)
Step 1: Start with a minimal, trusted base image
The first decision that matters is what goes into the image. Every package you add is another thing to patch. Every tool you leave in is another thing an attacker can use.
Practical rules that work in the real world:
- Use a minimal base such as a distroless image or a slim Alpine variant.
- Pin images by digest, not by a floating tag like `latest`.
- Build with multi-stage Dockerfiles so compilers and build tools never reach the final image.
- Never bake secrets, API keys, or `.env` files into layers. They persist in image history even if you delete them later.
- Scan images in CI and block builds that fail a severity threshold.
A common mistake is treating a passing scan as a finish line. Scans catch known CVEs, not logic flaws or leaked credentials. Pair scanning with a secret scanner and a dependency review.
Step 2: Sign images and generate an SBOM
Supply chain attacks target the gap between “we built it” and “we run it.” Two controls close that gap.
Image signing with tools like Sigstore’s cosign lets you verify that an image came from your pipeline and was not swapped out. SBOMs (software bills of materials) in SPDX or CycloneDX format give you a record of every component, which is exactly what you need when the next Log4Shell-style disclosure lands and you must answer “are we affected?” in minutes rather than days.
The SLSA framework provides a maturity model for build integrity. Most teams do not need the highest level. They need a build pipeline that is reproducible, access-controlled, and produces provenance that can be checked at deploy time.
Step 3: Lock down the registry
The registry is the distribution layer, and it is frequently the weakest link. Practical hardening steps:
| Control | What it does | Common mistake |
|---|---|---|
| Private registry | Keeps internal images off public indexes | Mixing public and private images without policy |
| Immutable tags | Prevents silent overwrites | Allowing tag reuse in production |
| Role-based access | Limits who can push | Shared admin credentials across teams |
| Image retention policy | Removes stale, vulnerable images | Keeping years of untagged layers |
| Pull-through cache | Centralizes upstream images | Pulling directly from the internet at deploy time |
Immutable tags matter more than people expect. If an attacker can overwrite a tag your cluster trusts, signing gains you little.
Step 4: Harden the host and the container runtime
The host is the foundation. If it is compromised, nothing above it is trustworthy.
For the host, apply CIS Benchmarks, which are consensus hardening baselines maintained by the Center for Internet Security. They cover kernel settings, filesystem permissions, and audit logging. Automated scanning tools can check a host against the benchmark and report drift.
For the container runtime, these settings deliver the most value per unit of effort:
- Run containers as non-root users with a fixed, high UID.
- Keep the default seccomp profile enabled and add an allowlist for sensitive workloads.
- Apply AppArmor or SELinux profiles.
- Set the root filesystem to read-only wherever possible.
- Drop all Linux capabilities and add back only what is needed.
- Disable privilege escalation with `allowPrivilegeEscalation: false`.
- Prefer rootless containers or user namespaces on hosts where the runtime supports them.
A frequent mistake is copying a `–privileged` flag from a troubleshooting session into production. It disables nearly every isolation control at once. Another is mounting the Docker socket into a container, which is effectively handing over root on the host.
Step 5: Enforce Kubernetes pod security standards
If you run Kubernetes, the Pod Security Standards define three levels: Privileged, Baseline, and Restricted. They replaced Pod Security Policies, which were deprecated in Kubernetes 1.21 in April 2021 and removed in 1.25 in August 2022. Teams still running old manifests against those policies often discover, painfully, that their workloads violate Baseline.
Start by running the Restricted profile in audit mode, fix what fails, then enforce. The NSA and CISA Kubernetes Hardening Guidance, first published in August 2021 and updated in March 2022, remains a useful companion document covering network policies, audit logging, and secrets management.
Network policy deserves special mention. Default Kubernetes networking allows every pod to talk to every other pod. A default-deny network policy with explicit allow rules is one of the highest-value changes you can make, and it is routinely skipped.
For secrets, avoid storing them in environment variables where possible. Mount them as files from a dedicated secrets manager, and rotate them. Environment variables leak into crash dumps, logs, and child processes.
Step 6: Add runtime detection and monitoring
Prevention fails eventually. Detection is what limits the blast radius.
Falco and Tetragon are common choices for runtime threat detection. They watch system calls and flag behavior like a shell spawning inside a container, unexpected outbound connections, or writes to sensitive paths. The rules matter less than the response plan. A detection nobody acts on is just log noise.
Practical tips from teams that get this right:
- Alert on a small set of high-signal behaviors first, then expand.
- Route alerts to the same on-call channel as application incidents.
- Test detections with safe simulated attacks before trusting them.
- Keep audit logs on the API server and ship them off-host.
One overlooked detail is log integrity. If an attacker can delete logs from the host they compromised, your investigation starts blind. Ship logs to a separate, append-only destination.
Step 7: Automate policy in CI/CD
Manual review does not scale. Policy-as-code tools such as Open Policy Agent and Kyverno let you express rules once and enforce them at build time and at admission time. Examples of rules worth enforcing:
- No `latest` tags in production namespaces.
- No containers running as root.
- No hostPath mounts except from an approved list.
- Resource limits required on every workload.
- Only signed images from trusted registries.
An important practical note: enforce in warn mode first. Turning on strict admission control without a grace period is the fastest way to cause an outage and lose organizational trust in the security program.
Common mistakes that undermine an otherwise solid setup
After the controls are in place, a handful of habits still cause most incidents:
- Treating scanning as a one-time gate. New CVEs appear against unchanged images. Rescan continuously.
- Ignoring base image updates. A pinned digest is good, but it must be refreshed on a schedule.
- Over-permissioned service accounts. Workloads should not have cluster-admin because it was convenient during setup.
- Secrets in CI logs. Masking is not enough; do not print them at all.
- Skipping the host. Container security advice often stops at the orchestrator, but an unpatched kernel defeats everything above it.
The pattern behind all of these is the same. Security controls decay without maintenance. A setup is only as good as the schedule that keeps it current.
A realistic rollout order
Teams that succeed usually sequence the work rather than doing everything at once:
- Minimal base images and pinned digests.
- Image scanning and secret scanning in CI.
- Non-root users, read-only filesystems, and dropped capabilities.
- Pod Security Standards in audit mode, then enforce.
- Default-deny network policies.
- Image signing and SBOM generation.
- Runtime detection with a tested response plan.
- Policy-as-code enforcement and continuous host scanning.
That order front-loads the controls with the best effort-to-risk-reduction ratio. It also produces visible wins early, which keeps the project funded. For readers who also think about layered protection outside the data center, the same incremental logic applies to home security systems: start with the basics that actually work, then add sophistication.
Conclusion
Container security is not a product you install. It is a set of defaults you change, a pipeline you trust, and a monitoring habit you keep. The layers from NIST SP 800-190 still describe the terrain well: image, registry, orchestrator, container, and host. Cover each one with proportionate controls, enforce policy automatically, and assume that prevention will eventually fail somewhere.
The teams that get this right share a trait. They treat hardening as routine maintenance rather than a one-off project. They pin and refresh images, scan continuously, keep hosts patched, and respond to runtime alerts. None of that is glamorous. All of it works.
Frequently asked questions
What is the single most important container security setting?
Running containers as non-root with a read-only root filesystem and dropped capabilities prevents the most common privilege escalation paths. If you can only change one thing this week, change that. It blocks a large share of real-world container escapes without requiring new tooling.
Do I need Kubernetes to have good container security?
No. Docker, Podman, and other runtimes can be hardened with the same fundamentals: minimal images, non-root users, seccomp profiles, and host patching. Kubernetes adds orchestration-specific controls like Pod Security Standards and network policies, but the core principles are identical.
How often should container images be rescanned?
Continuously, or at minimum daily. New vulnerabilities are disclosed against components that have not changed, so a scan that passed last month says little about today. Many registries now rescan stored images automatically and notify you when a new CVE affects something you already deployed.
Are signed images enough to stop supply chain attacks?
Signing proves provenance, not safety. A signed image can still contain a vulnerable dependency or a leaked secret. Combine signing with SBOM generation, dependency scanning, and admission control that only accepts images from trusted registries and pipelines.
What is the difference between Pod Security Standards and Pod Security Policies?
Pod Security Policies were the older Kubernetes mechanism and were removed in version 1.25. Pod Security Standards are the replacement, defining three cumulative levels (Privileged, Baseline, Restricted) that are enforced through the built-in admission controller or through policy engines.
How do I convince my team to adopt stricter container defaults?
Start in audit or warn mode and show the findings. Concrete data about which workloads run as root or lack resource limits is far more persuasive than abstract arguments. Fix the easy violations first, publish the wins, and only then move to enforcement.
