Container Escape on Digitalocean

In DigitalOcean environments, a container escape typically occurs when a workload running inside a container gains the ability to execute code on the host node or access host resources that should be isolated. The most common vectors are:

• Privileged containers – running a container with privileged: true or with broad Linux capabilities (e.g., SYS_ADMIN, NET_RAW) gives the container almost unrestricted access to the host kernel.
• HostPath mounts – mounting host directories such as /var/run/docker.sock, /proc, or /sys inside a container allows an attacker to interact with the Docker daemon or manipulate kernel parameters.
• Exposed Docker or Kubernetes APIs – if the Docker daemon is listening on an unsecured TCP socket (e.g., tcp://0.0.0.0:2375) or the Kubernetes API server is reachable without authentication, an attacker can issue privileged commands like docker run --privileged or kubectl create pod with hostPath volumes.
• Known kernel exploits – CVEs such as CVE-2019-5736 (runc) and CVE-2021-22555 (Linux kernel overlayfs) can be triggered from within a container to achieve host code execution when the container runs with sufficient privileges.

On DigitalOcean, these risks appear in specific services:

• DigitalOcean Kubernetes (DOKS) – node pools are standard Droplets. If a pod is scheduled with securityContext.privileged: true or mounts hostPath: /var/run/docker.sock, an escape can compromise the underlying Droplet and potentially other workloads on the same node.
• App Platform – while the platform runs containers in a sandbox, misconfigured build-time services that expose the Docker socket (e.g., a custom buildpack that runs dockerd) can still lead to escape.
• Droplets running Docker directly – a common pattern is to expose the Docker daemon via TCP for remote CI/CD. Without TLS and authentication, this socket becomes a privileged entry point.

Example of a risky Dockerfile that could be used on a Droplet or DOKS node:

# Dockerfile – DO NOT USE in production
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y docker.io
# Exposes Docker socket without authentication
EXPOSE 2375
CMD ["dockerd", "-H", "tcp://0.0.0.0:2375", "-H", "unix:///var/run/docker.sock"]

And a corresponding Kubernetes manifest that mounts the socket:

apiVersion: v1
kind: Pod
metadata:
  name: attacker-pod
spec:
  containers:
  - name: docker-client
    image: docker:20.10
    volumeMounts:
    - name: docker-sock
      mountPath: /var/run/docker.sock
  volumes:
  - name: docker-sock
    hostPath:
      path: /var/run/docker.sock
      type: File

These patterns give an attacker the ability to run arbitrary containers on the host, effectively escaping the container boundary.

Detecting a potential container escape starts with identifying the exposed surfaces that allow privileged host access. middleBrick helps by scanning the unauthenticated attack surface of any API endpoint you provide and reporting findings that map to the BFLA/Privilege Escalation category.

When you run a scan, middleBrick performs checks such as:

• Testing for open Docker daemon TCP sockets (GET /v1.24/version on port 2375) without TLS or authentication.
• Probing for unauthenticated Kubernetes API endpoints (/api/v1/nodes, /apis/apps/v1/deployments) that allow privileged pod creation.
• Checking for excessive HTTP methods or misconfigured headers that could be abused to issue privileged container management commands.
• Reporting any findings where the API returns detailed error messages or version information that could aid an attacker in crafting a container‑escape exploit.

Example CLI usage:

# Scan a Docker daemon exposed on a Droplet
middlebrick scan http://203.0.113.45:2375

The output will include a risk score (A–F), a breakdown per category, and prioritized findings. A finding such as “Docker daemon accessible without TLS – potential privilege escalation” would appear under the BFLA/Privilege Escalation section with a severity rating and remediation guidance.

Beyond middleBrick, you can also:

• Enable DigitalOcean Monitoring alerts for unusual CPU spikes on nodes that could indicate a malicious container running on the host.
• Review VPC Flow Logs for unexpected outbound connections from node IPs to external Docker registries.
• Use the DigitalOcean Cloud Firewall to block inbound traffic to port 2375 from anywhere except trusted CI/CD IP ranges.

By combining middleBrick’s automated API scanning with native DigitalOcean observability tools, you gain visibility into the specific attack vectors that could lead to a container escape.

Remediation focuses on removing the privileged access paths that enable escape. The following steps use DigitalOcean‑native features and standard container‑security best practices.

1. Run containers as non‑root and drop unnecessary capabilities

Dockerfile example:

FROM node:20-alpine
# Create a non‑root user
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
WORKDIR /app
COPY . .
RUN npm ci
CMD ["node", "index.js"]

Kubernetes pod securityContext:

apiVersion: v1
kind: Pod
metadata:
  name: safe-app
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: app
    image: myrepo/myapp:1.0
    securityContext:
      capabilities:
        drop:
          - ALL
      readOnlyRootFilesystem: true

2. Avoid hostPath mounts, especially the Docker socket

If you need to interact with Docker from within a container, use Docker‑in‑Docker (DinD) with a privileged build step only in isolated CI pipelines, never in production workloads. In DOKS, enforce Pod Security Standards (or PodSecurityPolicies where available) that disallow hostPath volumes.

3. Secure exposed APIs

• If you must expose the Docker daemon, bind it to a Unix socket only, or enable TLS with client certificate authentication.
• For Kubernetes, ensure the API server is behind the DigitalOcean Load Balancer with strict authentication (OIDC or token) and disable anonymous access.
• Use DigitalOcean Cloud Firewalls to restrict inbound traffic to ports 2375 (Docker) and 6443 (Kubernetes API) to known CIDR blocks.

4. Keep the host and runtime patched

Regularly apply security updates to the Droplet OS and the container runtime (containerd, runc). DigitalOcean provides automatic security updates for Droplet images; enable them via the control panel or apt-get upgrade schedules.

5. Leverage DigitalOcean platform defaults

• App Platform runs containers with a non‑root user by default and does not expose the Docker socket.
• Managed Databases and Spaces are accessed via SDKs, removing the need to mount host paths for credential access.
• When using DOKS, enable the built‑in node pool auto‑upgrade feature to stay on patched kernel versions.

By applying these controls, you eliminate the most common routes to container escape on DigitalOcean while still allowing legitimate workloads to run securely.