Docker Security Checklist: Container Escapes, Hardening & K8s Comparison

A Docker Security Checklist covers six core areas: hardening base images, running containers as non-root users, restricting kernel capabilities, scanning for vulnerabilities, controlling network access, and keeping secrets out of Dockerfiles. Get these right and you eliminate the majority of real-world container attack vectors.

Docker Security Checklist: 6 Core Steps

1. Harden your base image — use Alpine or distroless, pin to a digest
2. Run containers as a non-root user — add a USER instruction in your Dockerfile
3. Drop all Linux capabilities, add back only what the app needs
4. Scan every image with Trivy or Grype before it reaches production
5. Isolate containers on user-defined bridge networks, not the default bridge
6. Never store secrets in ENV variables or image layers — use a vault

• Key Takeaway 1: Container escapes are real and exploitable, especially when containers run as root or with excessive Linux capabilities.
• Key Takeaway 2: Hardening Docker images starts at the Dockerfile level, not after deployment.
• Key Takeaway 3: Kubernetes adds its own security layer on top of Docker, but it does not replace Docker-level hardening.
• Key Takeaway 4: Free tools like Trivy and Docker Bench for Security give you a solid starting point without any budget.

What a Docker Security Checklist Actually Covers

Most developers treat Docker security as an afterthought. They get the app running, push the image, and move on. That is exactly how breaches happen. A proper Docker Security Checklist is a pre-deployment gate, not a post-incident review.

The checklist breaks down into five practical categories. Work through each one before any container touches a production environment.

Image Hardening: How to Harden Docker Images Step by Step

Start with the smallest base image that works. Alpine Linux images are typically under 5 MB versus a full Ubuntu image at 70+ MB. Fewer packages mean fewer vulnerabilities. According to Snyk’s 2023 State of Open Source Security report, 84% of Docker Hub’s most popular images contained at least one high-severity vulnerability, and most of those came from bloated base images.

Pin your base image to a specific digest, not just a tag. Tags like latest are mutable. A digest like sha256:abc123 is not. This prevents silent upstream changes from breaking your security posture overnight.

User and Permission Controls

Never run your container process as root. Add a USER instruction in your Dockerfile to switch to a non-root user before the final CMD or ENTRYPOINT. It is a one-line fix that closes a massive attack surface.

Drop Linux capabilities explicitly. Docker grants 14 capabilities by default. Most applications need two or three. Use –cap-drop=ALL and then add back only what you need with –cap-add. The Center for Internet Security (CIS) Docker Benchmark v1.6 recommends this as a Level 1 control.

Secrets Management

Hard-coded credentials in Dockerfiles are one of the most common mistakes DevOps teams make, particularly in Indian startup environments where speed often beats process. Never use ENV to pass secrets at build time. Use Docker Secrets for Swarm, Kubernetes Secrets with encryption at rest enabled, or a dedicated vault like HashiCorp Vault.

India’s CERT-In mandatory incident reporting guidelines, which require breach notification within six hours for critical infrastructure providers, make secrets hygiene a compliance issue, not just a best practice.

Network and Runtime Controls

Isolate containers using user-defined bridge networks instead of the default bridge. Containers on the default bridge can communicate with each other by default, which is rarely what you want. Set –read-only on the filesystem where possible and mount only the volumes you actually need.

Container Escape Prevention Techniques

A container escape is when a process inside a container breaks out of its isolation boundary and gains access to the host operating system or other containers. Think of it as a prisoner tunnelling out of a cell. The container is the cell. The host kernel is the prison yard.

Container escapes happen because containers share the host kernel. They are not virtual machines. If an attacker exploits a kernel vulnerability or a misconfiguration from inside a container, they can interact directly with the host.

Real-World Escape Vectors

Privileged containers are the most common culprit. Running a container with –privileged gives it almost full access to the host. CVE-2019-5736, the runc vulnerability, allowed attackers to overwrite the host runc binary from inside a container. It affected major cloud providers including AWS, Google Cloud, and Azure. The fix was a patch, but the root cause was excessive privilege.

Mounted Docker sockets are another classic. If you mount /var/run/docker.sock inside a container, any process in that container can spawn new containers on the host with full privileges. This is equivalent to giving a guest in your house a master key.

According to the CNCF’s 2022 Cloud Native Security Report, 37% of organisations had experienced a container security incident in the previous 12 months. Misconfiguration was the leading cause, not zero-day exploits.

How to Prevent Container Escapes

• Never use –privileged unless there is absolutely no alternative.
• Do not mount the Docker socket inside containers in production.
• Enable Seccomp profiles to restrict system calls. Docker’s default Seccomp profile blocks around 44 of the 300+ Linux syscalls.
• Use AppArmor or SELinux profiles for mandatory access control.
• Keep the host kernel patched. Most escape exploits target known kernel CVEs.

Docker vs Kubernetes Security: Key Differences and What Overlaps

Docker and Kubernetes solve different problems, and their security models reflect that. Docker is a container runtime. Kubernetes is a container orchestrator. You can harden Docker perfectly and still have a vulnerable Kubernetes cluster, and vice versa.

The table below summarises the key differences in their security controls.

Security Control	Docker (Standalone)	Kubernetes
User namespaces	Opt-in, manually configured	Configured via Pod Security Admission
Secrets management	Docker Secrets (Swarm only)	Kubernetes Secrets with etcd encryption
Network policies	Manual network segmentation	NetworkPolicy objects, CNI plugins
RBAC	Not natively available	Built-in Role-Based Access Control
Runtime security	Seccomp, AppArmor, capabilities	Same, plus OPA/Gatekeeper policies
Image scanning	Manual or CI/CD integrated	Admission controllers, OPA, Kyverno
Audit logging	Docker daemon logs	Kubernetes API server audit logs

The biggest practical difference is that Kubernetes gives you RBAC and NetworkPolicy as first-class features. In standalone Docker, you have to build equivalent controls yourself. Kubernetes also lets you enforce security policies at admission time, meaning a non-compliant pod never even starts.

That said, Kubernetes does not fix bad Docker images. If your image runs as root and contains critical CVEs, Kubernetes just orchestrates that problem at scale. The two layers of security are complementary, not substitutes. If you are working toward a professional role in cloud security, understanding both is non-negotiable. The Certified Penetration Testing Professional (CPent) programme at 3.0 University covers cloud and container attack surfaces in practical depth.

Where Indian Engineering Teams Typically Get This Wrong

A lot of engineering teams in India’s startup ecosystem adopt Kubernetes early because it is what the job descriptions ask for. They set up the cluster, deploy apps, and assume Kubernetes handles security. It does not handle everything. According to the CIS Kubernetes Benchmark v1.8, most default cluster installations fail at least 30% of the benchmark’s controls out of the box. Indian fintech and SaaS companies operating under RBI cloud guidelines face additional compliance exposure when these defaults go unchecked.

Start with Docker-level hardening, then layer Kubernetes controls on top. Do not skip the foundation.

Tools That Scan Containers for Vulnerabilities

You do not need to manually audit every layer of every image. Several mature tools do this automatically and integrate cleanly into CI/CD pipelines.

Trivy

Trivy, built by Aqua Security, is the most widely adopted open-source container scanner right now. It scans OS packages, language-specific dependencies, and Kubernetes manifests. It is fast, has zero configuration overhead for basic use, and outputs results in multiple formats including JSON and SARIF. Run trivy image your-image:tag and you get a full CVE breakdown in seconds.

Docker Bench for Security

This is a shell script that checks your Docker host configuration against the CIS Docker Benchmark. It does not scan images but audits your daemon settings, container runtime options, and file permissions. It is the right first tool to run on any new Docker host. The CIS Docker Benchmark v1.6 identifies passing all Level 1 checks as the baseline for eliminating the most commonly exploited misconfigurations in production environments.

Grype and Syft

Grype, from Anchore, is a fast vulnerability scanner that works alongside Syft, a software bill of materials (SBOM) generator. Generating an SBOM for every image is becoming a compliance requirement in regulated sectors. India’s CERT-In guidelines increasingly reference SBOM practices for critical infrastructure providers, and MeitY’s cloud security framework for government systems points in the same direction.

Falco

Falco, a CNCF project, handles runtime security rather than image scanning. It monitors system calls in real time and alerts you when a container does something unexpected, like spawning a shell, reading /etc/passwd, or making unexpected network connections. It is the difference between detecting a vulnerability before deployment and catching an active exploit in progress.

If you want to understand how attackers actually use these vulnerabilities before defenders patch them, a structured ethical hacking course gives you that context. The Cybersecurity 101 course at 3.0 University is a practical starting point for anyone building this foundation.

Combining at least one image scanner (Trivy or Grype) with a runtime monitor (Falco) and a host benchmark tool (Docker Bench) gives you coverage across the three phases where attacks happen: build time, push time, and runtime.

Frequently Asked Questions

What should a Docker security checklist cover?

A Docker Security Checklist should cover image hardening, non-root user enforcement, capability restrictions, secrets management, network segmentation, and vulnerability scanning. At minimum, run a CIS Docker Benchmark check on your host and a Trivy scan on every image before it reaches production. These steps together address the most commonly exploited weaknesses in containerised environments.

What is a container escape attack?

A container escape happens when a process inside a container breaks out of its isolation boundary and accesses the host OS or other containers. It typically exploits privileged container configurations, mounted Docker sockets, or kernel vulnerabilities. CVE-2019-5736 is a well-known real-world example. Preventing escapes means dropping privileges, avoiding –privileged, and keeping host kernels patched.

How does Docker security differ from Kubernetes security?

Docker security focuses on the individual container runtime: image hardening, user permissions, capabilities, and host configuration. Kubernetes security adds cluster-level controls like RBAC, NetworkPolicy, Pod Security Admission, and audit logging. They are complementary layers. Hardening Docker images is still required even in Kubernetes, because Kubernetes orchestrates whatever you give it, secure or not.

How do you harden Docker images?

Use a minimal base image like Alpine, pin it to a specific digest, run processes as a non-root user, drop all Linux capabilities and add back only what is needed, avoid storing secrets in environment variables or image layers, and scan the image with Trivy before deployment. These steps cover the majority of the CIS Docker Benchmark’s image-level controls.

Which tools scan containers for vulnerabilities?

Trivy (Aqua Security) and Grype (Anchore) are the leading open-source image scanners. Docker Bench for Security audits host configuration against the CIS benchmark. Falco provides real-time runtime monitoring. For teams in regulated sectors, combining image scanning with SBOM generation using Syft is becoming a compliance baseline, especially under frameworks like India’s CERT-In guidelines.

Container security is not a one-time task. It is a continuous practice that covers how you build images, how you configure your runtime, and how you monitor containers once they are running. Start with the checklist above, automate scanning in your CI pipeline, and revisit your configurations every time you upgrade your base image or Kubernetes version.

If you want to take this further professionally, the Certified Cybersecurity Technician programme at 3.0 University covers container security, cloud attack surfaces, and hands-on defensive techniques in a structured curriculum built for working professionals and career changers across India.

Last updated: January 2025. Reviewed by the 3University editorial team.