Docker Security: 5 Risks and 12 Best Practices for Securing Your Containers

What Is Docker Security?

Docker security relies on isolating applications using Linux kernel features such as namespaces and cgroups, which means containers are only as secure as their configuration, base images, and runtime parameters. Because containers share the host system’s kernel, an exploited container can lead to host compromise if proper boundaries are not established.

Docker security encompasses the runtime, build, and orchestration of containers. Security aspects include base images, the Dockerfile, the container runtime, and securing the Docker daemon. You should also ensure proper configuration of container isolation, user privileges, and security best practices for container orchestration at scale.

Additional aspects of container security are securing Docker Hub to mitigate supply chain risks, and securing Helm charts and Kubernetes clusters used to orchestrate Docker containers.

Secure your builds (Dockerfiles and images):

Run as a non-root user: define a specific user with the USER instruction so a container breakout cannot map to root on the host.
Use minimal, trusted base images: build on hardened, slim images such as Alpine or Chainguard to shrink the attack surface.
Leverage multi-stage builds: keep compilers and build tools out of the final production image.
Never bake secrets into images: inject API keys, passwords, and certificates securely at runtime instead of hardcoding them.

Harden the runtime and host:

Avoid the privileged flag: running with full system privileges bypasses isolation and exposes the host kernel.
Do not expose the Docker daemon socket: mounting /var/run/docker.sock grants full administrative control of the host engine.
Set strict resource limits: cap CPU, memory, and processes to prevent denial-of-service conditions.
Enforce read-only file systems: use the read-only flag so attackers cannot write malicious files to disk.

In this article:

5 Security Risks in Docker Container Deployment and How to Mitigate Them
12 Docker Container Security Best Practices
Docker Security with Calico

5 Security Risks in Docker Container Deployment and How to Mitigate Them

Here are some of the major security risks affecting Docker deployments.

Unrestricted Traffic and Unsafe Communication

What is the risk?

Some Docker versions allow all network traffic on the same host by default, which can result in unintentional exposure of data to the wrong containers.

How to mitigate
Link the desired containers to restrict container access and reduce the attack surface, enabling only necessary and desired communication.
Encrypt Docker registry communication using TLS to protect network traffic integrity and confidentiality.
Evaluate the effectiveness of your existing controls and apply controls specific to Docker to mitigate business risks.

Vulnerable and Malicious Container Images

What is the risk?
There are more than 100,000 open-source container repositories hosted in the Docker Hub registry, including modified and unofficial versions of common images. Docker Hub is open to everyone, so you should make sure you trust the publisher when you deploy a new repo.

How to mitigate
Avoid untested or untrusted builds to prevent the introduction of vulnerabilities and malicious code.
A safe option is to use Docker certified and Docker Store packages.
Paid plans on Docker Hub offer a security scanning tool that checks for known vulnerabilities in images.
You can also use a trusted third-party registry with built-in scanning.

Unrestricted Access

What is the risk?
Attackers can often gain access to multiple containers once they’ve gained a foothold in the host. If a container can access the system file directory, it can undermine security enforcement. Attackers with root access to containers can sometimes gain root access to the host.

How to mitigate
Apply the principle of least privilege and eliminate root access where possible. For instance, you can enable the user namespace feature to provide separate user accounts for isolated containers to restrict movement between containers.

Host Kernel Vulnerabilities

What is the risk?
The kernel is exposed to the host and all containers, so kernel vulnerabilities are especially critical. If a container causes a kernel panic, it can take down the entire host.

How to mitigate
Ensure host operating systems are up to date and vigilantly apply security updates
Use a minimal operating system with hardened configuration
To prevent attackers from exploiting the kernel, you can leverage virtual machines (VMs), which require any attack to be routed through both the hypervisor and VM kernel to reach the host kernel.

Breaking Out of Containers

What is the risk?
While container breakouts are rare, they are not impossible. Attackers should not be able to access the host or other containers from a compromised container. Users are not namespaced by default, so if a process breaks out of a container, it maintains container host privileges. Root access in the container will become root access on the host—enabling privilege escalation.

How to mitigate
Never grant root access on the host to a container process. Containers should always run as non-root users. Refer to the Docker CIS Benchmark for additional ways to securely configure a Docker container to prevent container breakout.

12 Docker Container Security Best Practices

When using Docker containers, you should use the following practices to ensure maximum security.

1. Avoid Root Permissions

Running a Docker container with root permissions may be the easiest way to get it to function properly, as you don’t have to deal with complex permission management. However, there are few justifications for running containers as root in a production environment.

By default, containers run as root, which creates a direct path to host system hijacking during a container breakout. Define a specific non-root user using the USER instruction in your Dockerfile, and avoid giving root permissions in production. When using Kubernetes, you can increase security by creating a pod security policy with the MustRunAsNonRoot directive, which explicitly blocks admins from starting containers with root privileges.

2. Use Secure Container Registries

Container registries allow you to download container images easily from a central repository, making them both convenient and potentially risky. For this reason, it is better to stick to trusted registries like Docker Trusted Registry. You should assess the security of any registry you use and install it behind a firewall to protect against web-based breaches.

Avoid letting anyone download or upload container images from your registry. Implement role-based access control (RBAC) to define which users can access what resources, and block all other access. It may be inconvenient to manage and configure access rules for new users, but this can help you prevent a registry breach.

3. Limit Resource Usage

Docker allows you to set resource quotas for each container, limiting its memory and CPU resource consumption. Resource quotas help keep the Docker environment efficient by preventing a single container from consuming too many system resources. They also enhance security by blocking attacks that seek to disrupt your services by hogging a large number of resources. Restrict CPU, memory, and process consumption using flags such as –memory, –cpus, and –pids-limit. This prevents a compromised or buggy container from creating a denial-of-service (DoS) condition on the entire host.

4. Scan Your Images

Keep your Docker images secure with regular vulnerability scans. It is important to scan all images when you download them and continue scanning them to reduce exposure. Periodic scanning allows you to keep your images updated and audit critical directories and files. Integrate scanning directly into your CI/CD pipelines using tools such as Snyk or Trivy, and automatically halt builds when critical Common Vulnerabilities and Exposures (CVEs) are detected.

Related content: Read our guide to container security scanning

5. Build Your Networks and APIs for Security

Docker containers use networks and application programming interfaces (APIs) to communicate with each other. This communication allows containers to run properly but also requires proper monitoring and security policies. You should design these resources to facilitate monitoring and allow you to block breaches quickly.

6. Docker Container Monitoring

Monitoring is an essential part of any security strategy. In a containerized application, monitoring can be challenging, because of the large number of moving parts and the use of immutable components. Specialized container monitoring tools can help you gain visibility and achieve observability over containerized workloads.

Related content: Read our guide to Docker container monitoring

7. Use Minimal, Trusted Base Images

Build your applications on minimal, trusted base images such as Alpine Linux or hardened options like Chainguard Images. Smaller images shrink the attack surface by eliminating unneeded packages and tools, leaving fewer components that can contain vulnerabilities.

8. Leverage Multi-Stage Builds

Use multi-stage builds to separate your development dependencies from the final execution environment. This keeps compilers, build tools, and other artifacts out of the production image, reducing both its size and its attack surface.

9. Never Bake Secrets into Images

Do not hardcode API keys, passwords, or certificates into your Dockerfiles or image layers. Instead, use Docker Secrets or environment variables injected securely at runtime, so sensitive credentials are never stored in the image where they could be extracted.

10. Avoid the Privileged Flag and Docker Socket Exposure

Running a container with the –privileged flag grants full system privileges and bypasses almost all isolation, allowing an attacker to load malicious kernel modules directly into the host. Mounting the Docker daemon socket (/var/run/docker.sock) is equally dangerous, as it gives a container complete administrative control over the host engine. Avoid both, and where orchestration genuinely needs daemon access, use APIs wrapped in TLS.

11. Enforce Read-Only File Systems

Spin up containers with the –read-only flag so the root filesystem cannot be modified at runtime. This stops attackers from altering binaries or saving malicious scripts to disk if they break in. Provide writable tmpfs mounts only for the specific directories an application genuinely needs.

12. Verify Image Signatures and Audit Configurations

Enable Docker Content Trust (DCT) to guarantee you only deploy verified and signed image layers, protecting against tampered or malicious images. In addition, periodically run the Docker Bench for Security script to test your running containers against the CIS Docker Benchmark.

Docker Security with Calico

Calico Enterprise and Calico Cloud offer the following unique features for container and cloud-native security:

Microsegmentation across host/VMs/containers – Deploy a scalable, unified microsegmentation model for hosts, VMs, containers, pods, and services that works across all your environments.
Workload access controls – Securely and granularly control workload access between Kubernetes clusters and external resources like APIs and applications.
Intrusion detection and prevention (IDS/IPS) – Detect and mitigate Advanced Persistent Threats (APTs) using machine learning and a rule-based engine that enables active monitoring.
Firewall integration – The Calico Egress Gateway provides universal firewall integration, enabling Kubernetes resources to securely access endpoints behind a firewall. This allows you to extend your existing firewall manager and zone-based architecture to Kubernetes for cloud-native architecture.
Encryption – Calico utilizes WireGuard to implement data-in-transit encryption. WireGuard runs as a module inside the Linux kernel and provides better performance and lower CPU utilization than IPsec and OpenVPN tunneling protocols. Calico supports WireGuard for self-managed environments such as AWS, Azure, and Openshift, and managed services such as EKS and AKS.

Next Steps