Owasp Docker

OWASP® Docker Top 6 — Skill Entry

This SKILL.md is the entrypoint for the OWASP Docker Top 6 skill.

The skill encodes the OWASP Docker Security Top 6 as structured, machine-readable references that an agent can query to identify, assess, and remediate Docker container security risks.

Normative references (Docker Top 6)

1. 00 Vulnerability Index 2. 01 Secure User Mapping 3. 02 Patch Management Strategy 4. 03 Network Segmentation and Firewalling 5. 04 Secure Defaults and Hardening 6. 05 Maintain Security Contexts 7. 06 Resource Protection

Skill layout

• SKILL.md — this file (skill entrypoint).
• references/ — the Docker Top 6 normative documents.
• 00-vulnerability-index.md — index of all vulnerability identifiers, categories, and cross-references.
• 01 through 06 — one document per vulnerability aligned with OWASP Docker Security numbering.

Third-Party Attribution

Copyright © OWASP Foundation. OWASP® Docker Top 10 content is derived from works by the OWASP Foundation, licensed under CC BY-NC-SA 4.0 (<https://creativecommons.org/licenses/by-nc-sa/4.0/>). Source: <https://owasp.org/www-project-docker-top-10/> Modifications: Vulnerability descriptions restructured into agent-consumable reference documents with added detection and remediation guidance. OWASP® is a registered trademark of the OWASP Foundation. Use does not imply endorsement.

00 Vulnerability Index

This document provides the index for the OWASP Docker Security Top 6 vulnerabilities. Each entry includes its identifier, title, and primary category.

Vulnerability catalog

Cross-reference matrix

Each vulnerability document follows a consistent structure:

1. Description — what the vulnerability is and how it manifests in Docker container environments. 2. Risk — concrete consequences of exploitation and business impact. 3. Vulnerability checklist — indicators that the environment is exposed. 4. Prevention controls — defensive measures and rectification steps. 5. Example attack scenarios — realistic exploitation narratives. 6. Detection guidance — signals and methods to identify exposure. 7. Remediation — immediate and long-term actions to contain and resolve.

Category groupings

Privilege Management

• D01 Secure User Mapping

Patch Management

• D02 Patch Management Strategy

Network Security

• D03 Network Segmentation and Firewalling

Configuration Management

• D04 Secure Defaults and Hardening

Isolation

• D05 Maintain Security Contexts

Resource Management

• D07 Resource Protection

01 Secure User Mapping

Identifier: D01 Category: Privilege Management

Description

Insecure user mapping occurs when container microservices run under the root user inside the container. If the service contains a weakness the attacker gains full privileges within the container. While default protections such as Linux capabilities, AppArmor, or SELinux profiles remain, running as root removes one layer of defense. This broadens the attack surface and violates the principle of least privilege. Privileged containers started with the --privileged flag are especially dangerous, as a breakout from the microservice into the container is nearly equivalent to running without any container isolation.

Risk

• Full root-level access within the container upon exploitation of any service vulnerability.
• Privileged containers grant access to all Linux capabilities, host devices under /dev, and the

/sys and /proc filesystems.

• Kernel module loading on the host becomes possible from a privileged container.
• Lateral movement to the host or other containers is significantly easier from a root context.
• Violation of least privilege principle increases blast radius of any compromise.

Vulnerability checklist

• Container processes run as root (UID 0) rather than a dedicated non-root user.
• Dockerfiles lack a USER directive before the service entrypoint.
• The --privileged flag is used when starting containers.
• No Linux user namespace remapping is configured on the Docker daemon.
• SUID/SGID binaries exist in the container image and are not neutralized.
• Pod security policies or equivalent controls do not enforce non-root execution.

Prevention controls

1. Never use the --privileged flag; containers are unprivileged by default. 2. Add a dedicated user and group in the Dockerfile with RUN useradd <username> or RUN adduser <username>. 3. Switch to the non-root user before the entrypoint with the USER <username> directive. 4. Bind services to ports above 1024 and map them externally with the EXPOSE command. 5. Use setcap to grant specific capabilities to binaries that require elevated access rather than full root privileges. 6. Enable Linux user namespaces via the Docker daemon --userns-remap option to remap container root to an unprivileged host user. 7. Disable SUID/SGID bits with --security-opt no-new-privileges or drop capabilities with --cap-drop=setuid --cap-drop=setgid. 8. Enforce non-root execution through pod security policies in orchestrated environments.

Example attack scenarios

Scenario A — Root-running microservice

A web application container runs its service as root. An attacker exploits a remote code execution vulnerability in the application layer. Because the process runs as root inside the container, the attacker gains full access to the container filesystem. The attacker discovers the container has additional capabilities and pivots to probe the host network and adjacent containers.

Scenario B — Privileged container breakout

A development team deploys a container with --privileged for convenience during debugging. The flag persists into the production deployment. An attacker exploits a vulnerability in the containerized service, loads a kernel module on the host through the container, and achieves full root access to the host machine and all sibling containers.

Detection guidance

• Inspect running containers for root execution: docker top <containerID> or

docker inspect $(docker ps -q) --format='{{.Config.User}}'.

• Review process ownership on the host with ps auxwf.
• Check for user namespace configuration in /etc/subuid, /etc/subgid, and whether the Docker

daemon was started with --userns-remap.

• Audit Dockerfiles for the presence of the USER directive.
• Scan for the --privileged flag in deployment configurations.

Remediation

• Add a non-root user to all container images and set the USER directive in the Dockerfile.
• Remove the --privileged flag from all production container run configurations.
• Enable user namespace remapping on the Docker daemon.
• Audit and remove unnecessary SUID/SGID binaries from container images.
• Reconfigure services to bind to unprivileged ports (above 1024).
• Validate remediation by inspecting the runtime user of all deployed containers.

02 Patch Management Strategy

Identifier: D02 Category: Patch Management

Description

Failure to patch container infrastructure in a timely fashion remains one of the most frequent security problems. Container environments introduce four distinct patch domains: container images, container runtime software (Docker), orchestration software (Kubernetes, Mesos, OpenShift), and the host operating system. Each domain requires an independent patching strategy covering regular and emergency patch cycles. Unpatched components expose the environment to known vulnerabilities that scanning tools and public exploit databases can discover and weaponize.

Risk

• Full host compromise through unpatched kernel vulnerabilities exploited from within a container.
• Compromise of the orchestration tool grants control over all containers on all managed hosts.
• Known vulnerabilities accumulate over time with increasing severity as more exploits become

publicly available.

• End-of-life software components receive no security updates, leaving no remediation path.
• Weak default configurations in orchestration tools (e.g., etcd, kubelet APIs) compound the

risk when left unpatched.

Vulnerability checklist

• No documented patch management strategy exists for all four domains (images, container runtime,

orchestration, host OS).

• Regular patch cycles are not defined or not automated.
• Emergency patch procedures for critical vulnerabilities are absent.
• Software components have reached or are approaching end-of-life without a migration plan.
• Patches are applied but services are not restarted, leaving the old vulnerable code in memory.
• Vendor security advisory feeds are not monitored for deployed components.

Prevention controls

1. Define and document a patch management strategy for each of the four domains: images, container runtime, orchestration software, and host operating system. 2. Set a regular patch cycle cadence for each domain; automate where possible. 3. Define emergency patch procedures for critical vulnerabilities with a target application window of days rather than weeks. 4. Track end-of-life dates for all components and maintain migration plans for each. 5. Ensure patches that require service restarts, new deployments, or host reboots are followed through to completion. 6. Plan for redundancy so that patching and reboots do not cause service outages. 7. Subscribe to vendor security advisory feeds and security mailing lists for all deployed components. 8. Deploy freshly built container images rather than patching running containers in place.

Example attack scenarios

Scenario A — Unpatched host kernel

A container environment runs on a host with an outdated Linux kernel. A kernel vulnerability similar to Dirty COW (CVE-2016-5195) allows a container process to exploit a syscall flaw and escalate to root on the host. The attacker gains control of the host and all containers running on it.

Scenario B — Exposed orchestration interface

An orchestration tool runs with weak default credentials on its etcd data store. The interface is reachable from the container network because no patch or configuration update has been applied. An attacker who compromised a single container discovers the interface, accesses the etcd store, and gains control over the entire cluster.

Scenario C — Stale container image

A company does not rebuild container images regularly. An image running in production contains a library with a known remote code execution vulnerability published months ago. Internet-facing scanning bots fingerprint the service version and exploit the flaw to gain a foothold inside the container.

Detection guidance

• Check host uptime and last patch dates: uptime, rpm --qa --last, or

tail -f /var/log/dpkg.log.

• List pending patches: RHEL/CentOS yum check-update, Debian/Ubuntu apt-get upgrade --dry-run.
• Compare running kernel (uname -a) against installed kernels (ls -lrt /boot/vmlinu*).
• Inspect runtime of critical processes: dockerd, containerd, and kube* via top.
• Use authenticated vulnerability scanners (e.g., OpenVAS) against hosts and container images.
• Monitor container image build dates and compare against current base image releases.

Remediation

• Apply all pending patches to host operating systems and restart affected services.
• Rebuild and redeploy container images from updated base images.
• Update container runtime and orchestration software to the latest supported versions.
• Establish automated patch scanning and notification for all four domains.
• Decommission or isolate components that have reached end-of-life.
• Validate that patches are effective by confirming new binary versions are running.

03 Network Segmentation and Firewalling

Identifier: D03 Category: Network Security

Description

Container environments frequently lack the network segmentation that traditional DMZ architectures enforce. Without explicit configuration the container network may be flat, allowing any microservice to communicate with all other microservices and with the management backplane of the orchestration tool. Internet-exposed management interfaces of orchestration tools represent an especially severe risk, as gaining access to them grants control over the entire container environment. The microservice-per-container paradigm increases the number of network endpoints that must be controlled.

Risk

• Full environment compromise through internet-exposed orchestration management interfaces.
• Lateral movement from a compromised frontend container to backend services, databases, and

management APIs.

• Access to host services (NFS, Samba, CI/CD, databases) from within a compromised container.
• Cross-tenant network access in multi-tenant environments sharing the same network.
• Exploitation of unnecessarily exposed microservice ports within the LAN or DMZ.

Vulnerability checklist

• Orchestration management interfaces (dashboards, etcd, kubelet API) are reachable from the

internet.

• Orchestration management interfaces are exposed in the DMZ without strict access controls.
• Containers can reach host services that they do not need.
• Microservices that do not need to communicate share the same network segment.
• Classical services (NFS, Samba, CI/CD tools, databases) are unnecessarily exposed in the

container network.

• Multiple tenants share the same container network without isolation.
• No ingress or egress network policies are defined for the container environment.

Prevention controls

1. Never expose orchestration management interfaces (dashboards, etcd, API servers) to the internet; if remote access is required restrict it to a whitelist of trusted source IPs. 2. Place management interfaces on a dedicated management network with strict whitelist-based access controls. 3. Choose the appropriate network driver for the environment. 4. Segment the DMZ so that frontend, middleware, and backend services reside in separate network segments. 5. Ensure multiple tenants use separate networks with no cross-tenant connectivity. 6. Define explicit ingress network and routing policies for all container traffic. 7. Define egress network policies to restrict outbound internet access from containers. 8. Allow only whitelisted inter-container communication; deny all other traffic by default. 9. Protect host services with the same network-level controls applied to orchestration interfaces.

Example attack scenarios

Scenario A — Internet-exposed dashboard

An orchestration dashboard is reachable from the public internet without authentication. An attacker discovers the dashboard through internet scanning, gains access, and deploys cryptocurrency mining containers across the entire cluster.

Scenario B — Flat container network

A company runs frontend and backend containers on the same flat network without segmentation. An attacker exploits a vulnerability in the internet-facing frontend container. From the compromised container the attacker scans the network and discovers the etcd interface and an internal database, both reachable without further authentication. The attacker reads secrets from etcd and exfiltrates data from the database.

Scenario C — Cross-tenant access

A Container-as-a-Service provider hosts multiple clients on shared infrastructure without network isolation. One client deploys a container with a remote code execution vulnerability. The attacker exploits the flaw and, because all tenants share the same network, probes and accesses containers belonging to other clients.

Detection guidance

• Scan the environment from a random external IP to verify no management interfaces are

internet-reachable.

• From within a container, probe for orchestration management interfaces and host services using

netcat or nmap.

• List host network interfaces and routing tables: ip a, ip ro.
• Enumerate container networks: docker network ls and docker inspect <network_id>.
• Scan container IPs from the host:

nmap -sTV -p1-65535 $(docker inspect $(docker ps -q) --format '{{.NetworkSettings.IPAddress}}').

• Repeat scans from within containers to validate that inter-container traffic is restricted.

Remediation

• Remove internet exposure of all orchestration management interfaces immediately.
• Implement network segmentation between frontend, middleware, backend, and management networks.
• Apply whitelist-based network policies for inter-container communication.
• Isolate tenant networks in multi-tenant environments.
• Define and enforce ingress and egress network policies.
• Schedule recurring external and internal network scans to detect configuration drift.

04 Secure Defaults and Hardening

Identifier: D04 Category: Configuration Management

Description

Container environments expose services across three domains: the orchestration tool (dashboards, etcd, APIs), the host (RPC services, OpenSSHD, avahi, systemd network services), and the containers themselves (microservice endpoints and distribution-bundled tools). Default configurations frequently leave unnecessary services running or insufficiently protected. Network-based mitigations (see D03) address the symptom rather than the root cause; disabling or hardening an unneeded service eliminates the attack surface entirely. Linux kernel syscalls accessible from within containers present an additional vector; a defective syscall can escalate privileges from a container user to root on the host.

Risk

• Compromise of the orchestration tool through unprotected management interfaces with weak or no

authentication.

• Host compromise through unnecessary or misconfigured services exposed in the container network.
• Privilege escalation from within a container through unrestricted Linux capabilities or syscalls.
• Expanded attack surface from unnecessary packages and binaries inside container images.
• Loss of defense-in-depth when AppArmor or SELinux protections are disabled to resolve

configuration conflicts.

Vulnerability checklist

• Orchestration management interfaces run with default credentials or without authentication.
• The host runs non-essential services (desktop applications, compilers, unneeded daemons).
• The host OS is a general-purpose distribution rather than a container-optimized minimal build.
• Container images include unnecessary packages, compilers, or debugging tools.
• Docker capabilities are not restricted beyond the default set of 14.
• Seccomp profiles are set to unconfined or AppArmor is set to apparmor=unconfined.
• SUID/SGID binaries remain in container images without mitigation.
• AppArmor or SELinux has been disabled on the host to resolve operational issues.
• The host OS has reached or is approaching end of support lifetime.

Prevention controls

1. Select a minimal, container-optimized host distribution; avoid general-purpose desktop or server distributions. 2. Install only the packages required for container hosting on the host OS. 3. Verify the support lifetime of the host OS and plan for migration before end of life. 4. Audit all network-listening services on the host; disable those that are not required. 5. For services that must run, bind them to localhost or a restricted interface where possible and enable authentication. 6. Review orchestration tool documentation for security-relevant configuration and apply authentication to all management interfaces. 7. Use minimal or distroless base images for containers to reduce available binaries an attacker could leverage. 8. Drop unnecessary Linux capabilities with --cap-drop; never use --cap-add=all. 9. Apply seccomp profiles (--security-opt seccomp=<profile>.json) to restrict syscalls beyond the default 44 disabled; never use unconfined. 10. Disable SUID/SGID bits with --security-opt no-new-privileges. 11. Never disable AppArmor or SELinux; diagnose and relax specific rules instead.

Example attack scenarios

Scenario A — Unprotected orchestration API

An orchestration tool exposes its kubelet API without authentication by default. An attacker who gained access to the container network discovers the API, executes commands on nodes, and backdoors the cluster.

Scenario B — Bloated container image

A container image is built from a full Ubuntu base and includes wget, curl, gcc, and netcat. An attacker exploits an application vulnerability and breaks out into the container. Using the available tools the attacker downloads additional exploit payloads and establishes a reverse shell to an external command-and-control server.

Scenario C — Unrestricted capabilities

A container runs with the default set of 14 capabilities, including NET_RAW. An attacker exploits a vulnerability in the containerized service and uses NET_RAW to craft raw network packets, perform ARP spoofing on the container network, and intercept traffic between other containers.

Detection guidance

• Scan the host network for exposed services: netstat -tulpn | grep -v ESTABLISHED or

lsof -i -Pn | grep -v ESTABLISHED.

• Scan the container network from within a container using nmap to discover reachable services.
• List capabilities of running containers with pscap on the host.
• Inspect container security options: docker inspect <containerID> to check seccomp and

AppArmor profiles.

• Verify host firewall rules: iptables -t nat -L -nv and iptables -L -nv.
• Audit container images for unnecessary packages and SUID/SGID binaries.

Remediation

• Enable authentication on all orchestration management interfaces.
• Remove unnecessary packages from host systems and container images.
• Rebuild container images from minimal or distroless base images.
• Drop all unnecessary capabilities and apply restrictive seccomp profiles.
• Enable --security-opt no-new-privileges on all production containers.
• Re-enable AppArmor or SELinux if previously disabled and address specific rule conflicts.
• Decommission or replace host operating systems approaching end of support.

05 Maintain Security Contexts

Identifier: D05 Category: Isolation

Description

Mixing containers with different security statuses or contexts on the same host undermines isolation. A single host may run production containers alongside test or development containers, containers with different information security classifications (frontend vs. backend), or containers from separate tenants in a Container-as-a-Service environment. If a lower-security container is compromised, the attacker may pivot to higher-security containers on the same host through shared resources, kernel vulnerabilities, or access to the orchestration management plane. The desire to maximize hardware utilization often drives organizations to co-locate containers that should be separated.

Risk

• Compromise of a development or test container leads to lateral movement into production

containers on the same host.

• A single tenant's vulnerability in a multi-tenant environment endangers the availability,

confidentiality, and integrity of all tenants.

• Kernel-level exploits (e.g., Dirty COW) from one container grant root access to the host and

all sibling containers.

• Insecure orchestration interfaces reachable from any container on the host expose the

management plane.

• Mixing security classifications (databases, middleware, authentication services, frontend)

on one host increases blast radius.

Vulnerability checklist

• Production and non-production (test, development, staging) containers share the same host.
• Containers handling data of different sensitivity classifications run on the same host.
• Multi-tenant containers share the same physical or virtual host without VM-level separation.
• No formal policy defines which container types may be co-located.
• The orchestration control plane components run on the same host as application containers.
• Hardware utilization concerns override security separation requirements.

Prevention controls

1. Deploy production containers on dedicated hosts and enforce strict controls on who may deploy to those hosts; no non-production containers allowed. 2. Separate containers by information security classification: databases, middleware, authentication services, frontend, and orchestration control plane components on different hosts. 3. Use virtual machines to separate security contexts when physical hardware is limited; this is the minimum requirement for running different tenants on shared hardware. 4. Never mix multi-tenant workloads on the same host without VM-level isolation. 5. Define and enforce a formal policy that specifies which container types and security contexts may coexist on a given host. 6. Review system architecture regularly to validate that host assignments reflect current security context requirements.

Example attack scenarios

Scenario A — Test container compromises production

A company runs test and production containers on the same host due to limited hardware. A developer deploys a test container with a remote code execution vulnerability. Scanning bots discover and exploit the vulnerability, granting the attacker access to the container. The attacker exploits a kernel vulnerability to escape the container and gains root access to the host, compromising all production containers.

Scenario B — Multi-tenant CaaS breach

A Container-as-a-Service provider runs all clients on shared hosts without VM-level separation. One client deploys a container with a vulnerability that an attacker exploits. The attacker reaches the orchestration management interface from the compromised container and gains access to the entire environment, affecting all clients' containers.

Detection guidance

• Request and review the system architecture to understand which containers share hosts.
• Log in to bare metal hosts and check for virtualization processes (qemu-system-x86_64,

virsh list --all) to confirm whether VMs provide isolation.

• If only Docker processes run on the host without VM separation, verify that all containers

share the same security context.

• Inspect container labels and metadata to identify which environment (production, test,

development) each container belongs to.

• Verify that the separation of systems reflects their security context requirements.

Remediation

• Relocate production containers to dedicated hosts with no non-production workloads.
• Introduce VM-level isolation for multi-tenant and mixed-environment hosts.
• Separate containers by security classification onto distinct hosts or VM boundaries.
• Document and enforce a host assignment policy based on security context.
• Audit host assignments on a recurring schedule to detect drift.

06 Resource Protection

Identifier: D07 Category: Resource Management

Description

By default, containers may have no restrictions on CPU, memory, network, or disk I/O consumption. A container that exhausts physical resources — whether through a software defect, misconfiguration, or deliberate attack — affects the underlying host and all other containers sharing that host. The Linux kernel's OOM (Out of Memory) killer activates when the host is short of memory and terminates processes to recover; the killed processes are not necessarily the ones responsible for excessive consumption. Even containers that are otherwise well-isolated still share physical resources with sibling containers and the host.

Risk

• A single container exhausting CPU or memory causes degraded performance or outages for all

containers on the same host.

• The OOM killer may terminate critical processes in unrelated containers or on the host itself.
• Denial of service against the host operating system when a container consumes all available

memory or CPU.

• Disk I/O saturation by one container blocks storage operations for others.
• Network bandwidth exhaustion by one container starves network access for sibling containers.

Vulnerability checklist

• Containers are deployed without memory limits (--memory and --memory-swap not set).
• Containers are deployed without CPU limits.
• No memory reservation (--memory-reservation) is configured for soft limits.
• The OOM killer is not managed for critical containers (--oom-kill-disable not evaluated).
• Host RAM is oversubscribed without resource limits on individual containers.
• No monitoring is in place to detect resource exhaustion trends.

Prevention controls

1. Set hard memory limits on every container using --memory and --memory-swap. 2. Configure soft memory limits with --memory-reservation for graceful resource management. 3. Set CPU limits on every container to prevent individual containers from monopolizing CPU. 4. Evaluate use of --oom-kill-disable for containers running critical processes; note that the container daemon itself has a lower OOM score and is normally not killed. 5. Avoid oversubscribing host RAM; ensure the sum of container memory limits does not exceed available physical memory. 6. Monitor resource consumption of all containers and the host to detect saturation trends.

Example attack scenarios

Scenario A — Memory exhaustion denial of service

An attacker exploits a vulnerability in a containerized application to trigger unbounded memory allocation. The container has no memory limits configured. The container consumes all available host memory, triggering the OOM killer. The OOM killer terminates processes in a different production container, causing a service outage for an unrelated application.

Scenario B — CPU starvation

A container running a computationally intensive workload has no CPU limits. The workload consumes all available CPU cycles on the host. Other containers on the same host experience severe performance degradation, and time-sensitive operations fail due to CPU starvation.

Detection guidance

• Check configured resource limits: docker inspect <containerID>.
• Monitor live resource consumption: docker stats.
• Inspect memory cgroup details: /sys/fs/cgroup/memory/docker/$CONTAINERID/*.
• Review host-level resource utilization for signs of oversubscription.
• Alert on containers approaching their configured limits or on OOM events in kernel logs.

Remediation

• Apply memory and CPU limits to all running containers.
• Update deployment configurations and orchestration templates to include resource limits by

default.

• Review and adjust limits based on observed resource consumption patterns.
• Configure monitoring and alerting for resource exhaustion and OOM events.
• Validate that the aggregate of all container resource limits does not oversubscribe the host.