# Docker Top 10 Misconfigurations

> **Intro:** Docker mistakes are dangerous because they blur boundaries between build, runtime, host, and registry trust. A secure program treats Docker as a system, not just a Dockerfile.

| #  | Misconfiguration                                         | Why it is dangerous                              | Better pattern                                                       |
| -- | -------------------------------------------------------- | ------------------------------------------------ | -------------------------------------------------------------------- |
| 1  | Runtime as root                                          | Easier privilege abuse after compromise          | Run as non-root and validate at deploy time                          |
| 2  | Floating base images                                     | Uncontrolled drift and hard-to-reproduce builds  | Pin intentionally and refresh on schedule                            |
| 3  | Secrets copied into layers or passed via weak build args | Secrets survive in image history or CI output    | Use runtime secret injection or build secret mounts                  |
| 4  | No image provenance or signing                           | Hard to know what artifact is really running     | Sign promoted images and verify before deploy                        |
| 5  | Pulling from untrusted registries                        | Increased malware and poisoned-image risk        | Use curated registries and trusted image sources                     |
| 6  | No patch/rebuild discipline                              | Known CVEs remain deployed too long              | Rebuild, rescan, and redeploy immutable images                       |
| 7  | Shared hosts across incompatible trust tiers             | Breakout or noisy-neighbor impact grows          | Segregate sensitive and public-facing workloads by host or node pool |
| 8  | Overly broad Docker daemon access                        | Docker control often equals host root            | Restrict daemon access and remote API exposure                       |
| 9  | Weak host hardening                                      | Container controls inherit weak host posture     | Keep kernel updated, keep LSMs enabled, harden daemon and host OS    |
| 10 | No limits on resources or runtime behavior               | DoS and post-exploitation activity become easier | Apply memory, CPU, filesystem, and syscall limits                    |

## The five risks every team should know by heart

A useful way to teach Docker risk is to keep five recurring failure modes visible:

* **kernel exploit**;
* **denial of service**;
* **container breakout**;
* **poisoned image**;
* **compromised secrets**.

Those five categories explain most “why does this hardening control exist?” conversations.

## Signs of a mature Docker operating model

* images are rebuilt instead of patched manually;
* base image ownership is explicit;
* registry promotion path is curated;
* host security is treated as part of container security;
* runtime privileges are intentionally small;
* detection exists for unusual daemon, registry, and container activity.

## Quick review prompts

* which users can control the Docker daemon?
* which registries are allowed for production workloads?
* which images can cross from dev to prod?
* which workloads are allowed to run with elevated privileges?
* which hosts or node pools can run sensitive workloads?

## Cross-links

* [Dockerfile Security Best Practices](/cloud-kubernetes-and-infrastructure-security/index-1/dockerfile-security-best-practices.md)
* [Trusted Images, Harbor, and Signing](/cloud-kubernetes-and-infrastructure-security/index-1/trusted-images-harbor-and-signing.md)
* [Linux Base Image and Host Security Baseline](/cloud-kubernetes-and-infrastructure-security/index/linux-base-image-and-host-security-baseline.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/cloud-kubernetes-and-infrastructure-security/index-1/docker-top-10-misconfigurations.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.