Kubernetes Architecture
You cannot attack a cluster you cannot map, so start with the parts that hold the keys.
What you will learn
- -Name the control plane and node components and what each one guards
- -Explain how a pod is really just a process on a Linux node
- -Identify the highest-value targets in a running cluster
The whole runs off one database. Everything knows, every , , , and role, lives inside etcd as key-value pairs. Read etcd and you have read the cluster. That is why the exists: to guard that database and turn what it holds into running .
A Kubernetes cluster splits into two halves. The control plane makes decisions. The worker run your actual containers. When you attack a cluster you are usually standing on a worker node inside a pod, trying to climb toward the control plane, because that is where the power sits.
The control plane
Four components do the thinking, and they usually run on their own set of machines.
The (kube-apiserver) is the front door. Every command, from kubectl, from a controller, from a compromised pod, goes through it. It listens on 6443 by default. It authenticates the caller, checks , then reads or writes etcd. If you can talk to the API server with a that has rights, you can do anything that token allows.
etcd is the database, on 2379. It stores secrets -encoded, not encrypted, unless someone turned on -at-. Direct etcd access is game over. There is no layer in front of it, only reachability and .
The scheduler decides which node a new pod lands on. The controller manager runs the loops that keep reality matching etcd: if a deployment wants three replicas and one dies, the controller manager notices and asks for a replacement. Neither is a common direct target, but both hold worth stealing.
The worker node
Every node runs a . It is the agent that talks to the API server, pulls the pods assigned to this node, and tells the container runtime to start them. The kubelet listens on 10250, and a misconfigured one that allows anonymous access is one of the cleanest paths from network access to code execution inside every pod on the box.
Below the kubelet sits the container runtime, usually containerd these days, which does the real work of runc spinning up and cgroups. A kube-proxy on each node programs iptables or IPVS rules so that service traffic reaches the right pods.
A pod is one or more containers sharing a network namespace and a couple of Linux cgroups. It is a process tree on the node, isolated by kernel features, not a separate machine. Every isolation boundary you will attack in this module is a Linux namespace, a capability, or a mount, not real hardware separation.
Where the value is
Map any cluster by what a component can reach, not by its name on an org chart.
The service account token mounted into your pod at /var/run/secrets/kubernetes.io/serviceaccount/token is your starting credential. The kubelet on your node can run commands in neighboring pods. The API server is the hub that grants everything. Node access, if you can break out of a container, gives you every secret and token of every pod scheduled there.
$kubectl cluster-infoPractice on clusters you own or are cleared to test: a local minikube or kind cluster, a lab like Kubernetes Goat, or an engagement with written . Poking a production cluster you were not hired to test is unauthorized access, and cloud record every API call you make.
You get raw read access to etcd on port 2379 with the right client cert. What have you effectively compromised?