← Back to Blog

Security · 9 min read · August 5, 2026

How to Secure Docker and Kubernetes in 2026: A Container Security Checklist

Containers are not a security boundary. In 2026, 82% of DevSecOps teams suffered a container-related breach, and worm campaigns scan for exposed Docker daemons around the clock. Here's the checklist that keeps Docker and Kubernetes locked down.

Why Containers Are Prime Targets in 2026

Containerization makes deployment fast, but it does not make your infrastructure secure. Containers share the host kernel, and the default posture of most clusters — exposed daemons, over-privileged workloads, unpatched base images — turns them into the easiest target on the internet.

The 2026 numbers are blunt:

• 82% of DevSecOps leaders experienced a container-related breach in the past year, and 87% expect one in 2026 (ActiveState 2026 Container Edition report).
• Only ~9% of organizations patch critical flaws within 24 hours — breach likelihood reaches 97% after a week of exposure.
• ~90% of container vulnerabilities come from the base image, not your application code.

Attackers have automated this. In 2026, worm campaigns like TeamPCP, PCPJack, and the CAI botnet scan the internet for exposed Docker APIs (ports 2375/2376), Kubernetes components, Redis, and Ray, then deploy cryptominers and steal credentials — including cloud provider keys and AI API keys.

Start with the Base Image: ~90% of Vulnerabilities Live There

Most teams update their application code and forget the foundation underneath it. Outdated full-distro base images drag thousands of CVEs into every deployment, and a generic latest tag makes each rebuild a gamble.

• Pin image versions — never deploy with latest. Use a specific digest for reproducible builds.
• Use minimal images — Alpine, distroless, or scratch instead of full Linux distributions. Hardened minimal images cut CVEs by up to 95%.
• Build with multi-stage builds — keep compilers and dev dependencies out of the runtime image.
• Scan in CI — run Trivy or Grype on every image before it ships, and fail the build on critical findings.
• Sign images with cosign and verify signatures at deployment time to block tampered images.

Never Expose the Docker Daemon

The single most dangerous configuration on the internet in 2026 is an unauthenticated Docker daemon listening on TCP. It gives anyone root-level control of the host, equivalent to a local docker CLI. Worms scan ports 2375/2376 constantly.

• Use the Unix socket only (unix:///var/run/docker.sock). If remote access is truly required, enforce mutual TLS — never plain TCP.
• Run rootless Docker where possible, so a daemon compromise does not equal a host compromise.
• Prefer containerd or CRI-O as the Kubernetes runtime instead of Docker.
• Never mount the host filesystem (-v /:/host) or run --privileged containers. A July 2026 write-up, "One Exposed Docker API and the Host Is Gone," documented the exact chain: exposed API to privileged container to full host takeover.

Harden the Kubernetes Control Plane and Workloads

Kubernetes does not make you secure by default — it gives you the tools to be secure, and most clusters never configure them.

• Enforce least-privilege RBAC. In a widely shared penetration test, an exposed dashboard plus a view-only service account that could list secrets escalated to full cluster root in ~15 minutes.
• Apply Pod Security Standards — use the restricted profile, or admission controllers like OPA Gatekeeper or Kyverno, to block privileged pods, hostPath mounts, and host namespaces.
• Stop storing secrets in plain Kubernetes Secrets. Use the External Secrets Operator or a vault, and prefer native cloud identity (IRSA / workload identity) over long-lived keys.
• Never bind dashboards or control-plane components to 0.0.0.0. Exposure plus an over-privileged service account is the classic 15-minute cluster pwn.
• Add network policies with default-deny, plus resource limits so a compromised pod cannot mine or flood.

Detect at Runtime: Assume You Have Already Been Scanned

Worm campaigns hit clusters within hours of exposure. Runtime detection is not optional in 2026.

• Deploy Falco or Tetragon to alert on privileged container creation, host filesystem mounts, and unexpected process behavior.
• Watch for mining signals — sustained high CPU, containers you did not create, connections to mining pools.
• Scan continuously, not just at build time. Run kube-bench against CIS benchmarks, Trivy on the cluster, and an external scanner like RootCrak that checks exposed ports and misconfigurations the way an attacker would.
• Patch fast. Only ~9% of organizations patch critical vulnerabilities within 24 hours — and breach likelihood hits 97% after a week.

The Bottom Line

Docker and Kubernetes are not a security boundary — they are a deployment tool. In 2026, the difference between a safe cluster and a cryptomining node is configuration discipline.

Follow the checklist: minimal pinned images, no exposed daemons, least-privilege RBAC, Pod Security Standards, runtime monitoring, and continuous scanning. The clusters that survive are the ones that assume they are already being scanned.