L1. Kubernetes Architecture and the Attack Surface
Video generating
Check back soon for the video lesson on Kubernetes Architecture and the Attack Surface
Understand the core components of a Kubernetes cluster and where attackers target each layer: from the API server and etcd to kubelets, container runtimes, and the pod network.
How a Kubernetes Cluster Works
A Kubernetes cluster has two planes. The control plane runs the API server, etcd, scheduler, and controller manager. The data plane (worker nodes) runs the kubelet, kube-proxy, and the container runtime that actually executes your workloads.
Every interaction flows through the API server. kubectl, controllers, the scheduler, and kubelets all authenticate to it. This makes the API server both the brain of the cluster and the single most critical attack target.
The Attack Surface Map
| Component | What It Does | Attack Vector |
|---|---|---|
| API Server | Central gateway for all operations | Unauthenticated access, RBAC misconfig |
| etcd | Stores all cluster state and secrets | Direct access bypasses all authz |
| Kubelet | Node agent that manages pods | Unauthenticated kubelet API |
| Container Runtime | Runs containers (containerd, CRI-O) | Container escape via kernel exploits |
| Pod Network | Flat network between all pods | Lateral movement, no default isolation |
| Cloud Provider | Underlying IaaS (AWS, Azure, GCP) | IMDS credential theft from pods |
Common Entry Points
Exposed API server: Clusters with anonymous auth enabled or API servers reachable from the internet without proper authentication are the most common initial access vector. Vulnerable workloads: A compromised application pod gives attackers a foothold inside the cluster network. From there, they can query the metadata service, scan for other services, and attempt privilege escalation. Supply chain: Malicious or vulnerable container images pulled from public registries introduce code execution before your security controls even engage.The IMDS Problem
On cloud-managed clusters, every pod can reach the cloud provider's Instance Metadata Service (IMDS) by default. On AWS, that is 169.254.169.254. An attacker in any pod can request IAM credentials attached to the node, potentially gaining access to S3 buckets, databases, or other cloud resources.
Best practice: Block IMDS access at the network level or use IMDSv2 (AWS) with hop limits. On EKS, use Pod Identity. On GKE, use Workload Identity. On AKS, use Workload Identity Federation.
Defense in Depth Layers
Securing Kubernetes is not a single configuration change. It requires layered controls:
- Cluster hardening: API server flags, etcd encryption, node isolation
- Identity and RBAC: Least-privilege roles, no cluster-admin for workloads
- Pod security: Non-root containers, read-only filesystems, dropped capabilities
- Network policies: Default-deny, explicit allow rules per namespace
- Supply chain: Image scanning, signing, admission control
- Runtime monitoring: Detecting anomalous syscalls, file access, network connections
- ✓The API server is the single gateway for all cluster operations and the most critical component to secure
- ✓etcd stores all cluster state including secrets in plaintext by default: direct access bypasses all authorization
- ✓The pod network is flat by default with no isolation between namespaces or pods
- ✓Cloud IMDS allows any pod to request node-level IAM credentials unless explicitly blocked
- ✓Defense in depth requires layered controls: cluster hardening, RBAC, pod security, network policies, supply chain, and runtime monitoring
1. Which Kubernetes component stores all cluster state and secrets?
2. What is the primary risk of the default pod network in Kubernetes?
3. How can an attacker in a compromised pod access cloud provider credentials?