Module 4 · Kubernetes Attack Surface 🔒

Kubernetes is where 2024-2026 cloud security action is happening. Every Indian fintech, every serious SaaS, and most mature enterprises now run workloads on Kubernetes. And Kubernetes, by design, has the most complex security surface of any modern platform. The control plane, the worker nodes, the network fabric, the service mesh, the supply chain, the secrets, and the workloads themselves — all of them need dedicated security thinking.

This module is the attacker’s-eye-view of Kubernetes combined with the defender’s hardening playbook. By the end you will:

• Understand the K8s control-plane components and which ones are high-value targets
• Know the standard privilege-escalation paths from a compromised pod to cluster admin
• Apply the CIS Kubernetes Benchmark mental model to real clusters
• Recognise supply-chain attack vectors specific to container images and Helm charts
• Use the mature tooling (kubescape, kube-bench, Falco, Trivy) to audit and monitor

Control plane — the crown jewels

The Kubernetes control plane runs on master nodes (or as a managed service in EKS/AKS/GKE). Key components:

• kube-apiserver — the gateway. Every component talks to it. If compromised, everything is compromised
• etcd — the cluster state database. Stores every Secret, ConfigMap, Pod spec. Read access = cluster credential dump
• kube-scheduler — decides which node a pod runs on
• kube-controller-manager — runs controllers (deployment, replication, node lifecycle)
• cloud-controller-manager — integrates with cloud provider APIs

All of these communicate via mTLS. Compromising any one typically means the cluster is lost. In managed clusters (EKS/AKS/GKE), the provider runs the control plane. For self-managed clusters, protect master nodes at Tier-0 level: no interactive access, dedicated subnet, MFA-required SSH, continuous patching.

Worker plane — where workloads run

• kubelet — node agent that manages containers. Has privileged credentials; has pod-exec capabilities
• kube-proxy — implements service networking (iptables or IPVS)
• container runtime — containerd, CRI-O; actually starts/stops containers
• CNI plugin — networking: Calico, Cilium, Flannel, etc.
• CSI plugin — storage provisioning

A pod that escapes its container into the node hits the kubelet — which has enough privileges to do almost anything. Container escape is therefore the primary attack vector on K8s.

The standard pod-to-cluster escalation path

Attackers with code execution in a single pod typically pursue this chain:

1. Enumerate the pod’s own privileges — check the service account token at /var/run/secrets/kubernetes.io/serviceaccount/token. Use it to query the API server: can this SA create pods, exec into other pods, read secrets?
2. Check for cloud metadata access — from a pod, can you reach the node’s Instance Metadata Service? In EKS, if IMDSv1 is available and the pod lacks egress restrictions, you can steal the node’s IAM role credentials. In AKS / GKE, similar flows exist via their respective metadata services
3. Break out of the container if privileged — privileged pod or excessive capabilities (SYS_ADMIN, NET_ADMIN) enables kernel-level operations that escape container isolation
4. Abuse misconfigured RBAC — default ClusterRoles like “edit” or “admin” granted to over-broad subjects
5. Exec into other pods — if the compromised SA has pods/exec permission, attacker hops into other workloads and pivots
6. Dump secrets — if SA has secret access, read all Secrets in the namespace (often contains database credentials, API keys, certificates)
7. Escalate to cluster-admin via role binding manipulation, service-account-token theft from nodes, or etcd direct access

The speed from “compromised pod” to “cluster admin” on a poorly-configured cluster is minutes. On a well-configured cluster, it’s typically not possible — the escalation paths are closed.

Key security controls

Pod Security Standards (replacing PodSecurityPolicy)

PSS defines three namespaced profiles:

• Privileged — no restrictions. Reserved for trusted system workloads only
• Baseline — minimally restrictive; prevents known privilege escalation (no privileged, no hostNetwork, no hostPID, etc.)
• Restricted — highly hardened; drops all capabilities, requires non-root, readOnlyRootFilesystem, etc.

Label every namespace with the profile and enforcement mode:

apiVersion: v1
kind: Namespace
metadata:
  name: app-production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: v1.28
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: app-production
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]