Container and Kubernetes isolation

Why this area matters

Containers share the host kernel, so isolation depends on configuration: running as non-root, dropping capabilities, not mounting the Docker socket or host paths, and avoiding privileged mode. Each of those is a one-line setting, and each one removed widens the path from an application bug to the node (CWE-250).

Trivy and Checkov flag these reliably, but not every flag is a problem — a CI build container or a node agent may legitimately need elevated access. The container agent checks whether the elevated setting is justified and documented, and suggests the narrowest alternative.

What goes wrong in real applications

• Root and privileged containers

  Running as root, or with privileged: true, removes most of the barriers between a compromised process and the host.

• Docker socket and host mounts

  Mounting /var/run/docker.sock or host directories gives the container control of the host's containers or files.

• Excess capabilities

  Added Linux capabilities such as SYS_ADMIN or NET_ADMIN grant kernel-level powers most applications never need.

• Unpinned base images

  Images referenced by :latest or a moving tag change underneath you, so a rebuild can pull in a different — or compromised — image.

Sample: the risky pattern and the fix

services:
  app:
    image: acme/app:latest
    user: root
    privileged: true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /:/host

services:
  app:
    image: acme/app:1.8.2@sha256:<digest>
    user: "10001:10001"
    read_only: true
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true
    volumes:
      - app-data:/var/lib/app
volumes:
  app-data:

The original runs a moving image as root in privileged mode with the Docker socket and the whole host filesystem mounted — a bug in the app is effectively a bug on the host. The fix pins the image by digest, runs as an unprivileged user with a read-only filesystem and no capabilities, and mounts only a named volume.

Illustrative code, simplified for clarity — not taken from a customer repository.

What OpenRouting checks in your repository

• Dockerfiles: USER, base image pinning, secrets in build args or layers
• docker-compose: privileged, user, cap_add, socket and host-path volumes
• Kubernetes manifests and Helm charts: securityContext, hostPath, hostNetwork, hostPID, RBAC
• Whether elevated access is required for the workload (CI runner, node agent) and documented

Scope and limits

• It reviews manifests as committed; it doesn't inspect running clusters, admission policies or node configuration.
• It doesn't scan image contents for vulnerable packages — dependency CVE lookup (SCA) is planned, not shipped.

Coverage areas reflect OpenRouting's check library. Code, secret and infrastructure scanning run today; other areas are rolling out. Scanners surface candidates and a review agent decides whether each one is real — it doesn't promise to find every issue.

Review agents for this area

• Container & Kubernetes — Checks Dockerfiles and Kubernetes manifests for root, privileged and host-level access.
• Privilege & file permissions — Checks file permissions, temp files, symlinks and unnecessary root.
• Supply chain — Checks dependency and build-time trust: pinning, lockfiles, registries and remote code.