Module 5 · Kubernetes — The Platform That Multiplies Attack Surface

Last updated: April 29, 2026

Kubernetes is a platform that runs other platforms. Complexity = attack surface. Every component — kubelet, API server, etcd, CoreDNS, service mesh proxies, ingress controllers, admission webhooks, operators — has its own attack surface. Misconfigurations span identity (RBAC), network (policies), workload (pod security), supply chain (images), and runtime (privilege escalation from pod).

Why K8s is complex to secure

• Default permissive — ServiceAccount tokens mounted into every pod, default namespace has broad defaults
• Every namespace is a boundary; not every team treats them as one
• RBAC has many verbs and resources; compound permissions unclear
• Admission controllers need careful configuration to prevent bypass
• Runtime privilege escalation paths exist for pods (hostPath mounts, privileged containers, CAP_SYS_ADMIN)
• Mesh side-car containers bypass many pod-level controls

Common attack patterns

Pod → Node → Cluster

# Compromised pod with hostPath mount
# Attacker writes to /host/etc/cron.d/evil
# Cron on node executes attacker code as root
# Node credentials (kubelet) accessed → cluster-wide access

# Privileged pod
# securityContext.privileged: true → full access to host
# CAP_SYS_ADMIN → mount operations → read any host file

# Host network
# hostNetwork: true → pod uses host's network namespace
# Can reach services otherwise network-policy-restricted

Service account abuse

# Inside compromised pod
cat /var/run/secrets/kubernetes.io/serviceaccount/token
# Use this with kubectl
curl -k https://kubernetes.default.svc/api/v1/namespaces \
    -H "Authorization: Bearer $(cat /var/run/secrets/.../token)"

# If service account has cluster-admin (common default in older tutorials):
# Full cluster access from compromised pod

Exposed kubelet

Kubelet port 10250 with anonymous auth enabled = direct pod execution on every node. Older installations had this; current kubeadm disables by default but legacy clusters remain.

Exposed etcd

etcd contains all cluster state including secrets (sometimes encrypted at rest, sometimes not). Reachable from inside cluster by default; sometimes externally. Compromise = full secret extraction.

RBAC attack paths

kube-hunter, kubeletctl, peirates automate discovery. Key escalation paths:

• create pods → launch privileged pod with host mount → node RCE
• update pods/exec → exec into other pods
• get secrets in kube-system → kube-api admin tokens
• impersonate → impersonate cluster-admin user
• bind → bind service account to cluster-admin role

# Check own permissions
kubectl auth can-i --list

# Find over-permissive bindings
kubectl get clusterrolebindings -o yaml | grep -B5 cluster-admin

# Recon tool
kube-hunter --remote KUBERNETES-IP
peirates   # interactive K8s attack framework

Real incidents

• Tesla 2018: Public Kubernetes dashboard without authentication → cryptomining on Tesla’s AWS account.
• Shopify 2019: Server-side request forgery in workload + privileged pod → compromise of Kubernetes cluster (reported as bug bounty).
• Kinsing cryptominer (2020-2024): consistently exploits exposed Kubernetes dashboards, Docker API, etcd.
• 2024 SSRF → K8s service account → cluster compromise at multiple companies (public post-mortems).

Defenses

1. Pod Security Standards: restricted profile on production namespaces
2. No privileged pods; no hostNetwork/hostPID/hostIPC; no hostPath mounts to sensitive paths
3. RBAC least-privilege per service account; no cluster-admin for workloads
4. Network Policy default-deny + explicit allows
5. Admission controllers: OPA Gatekeeper or Kyverno enforcing policies
6. automountServiceAccountToken: false when pod doesn’t call K8s API
7. Workload Identity / IRSA for cloud credentials — not static keys in pods
8. Image scanning (Trivy, Grype) in CI + at admission
9. Signed images (Sigstore Cosign) + verification at admission
10. Runtime security: Falco, Tracee, or commercial CWPP
11. CKS-level hardening (Certified Kubernetes Security Specialist reference)

Mindset takeaway

Kubernetes multiplies your attack surface per cluster. Every new cluster = new attack surface. Every new namespace with default settings = new privilege escalation path. Treat K8s like any other IaaS layer — hard defaults, strict admission, continuous monitoring. The complexity doesn’t go away; the discipline to manage it is the work.