Control Plane Static Pod Manifests
Domain 2 is about the security of each cluster component, and the first thing to understand is where they come from. On a kubeadm cluster the entire control plane is four YAML files in one directory, and the trust that follows from that is the whole shape of the domain.
Cluster Component Security Guide 9 of 42 Beginner
- Kubernetesapiserver v1.36.4, kubelet v1.36.3
- Runtimecontainerd 2.2.6
- CNICilium 1.18.1
- Built withkubeadm v1.36.3
- TimeAbout 14 min
kubeadm v1.36.3 built this cluster, so the manifest paths and flags are kubeadm's defaults. A managed cluster hides all of this - you cannot read the apiserver's flags on EKS or GKE - which is itself worth knowing.
- Host kernel7.0.0-29
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA5001 | 192.168.0.41 | Ubuntu 26.04 LTS | Control Plane Node (tainted NoSchedule) | 2 Core | 4 GB | 50 GB |
| CKA5001-NODE01 | 192.168.0.42 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA5001-NODE02 | 192.168.0.43 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA5001-NODE03 | 192.168.0.44 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when you have to reason about control plane security at all. This matters because on a kubeadm cluster the entire control plane is four files on disk, owned by root at mode 600 - and the Pods you see through the API are mirrors that no controller manages.
- reading the four manifests, their ownership and their mode
- seeing why write access to that one directory is equivalent to owning the cluster
- asking the API what created those Pods, and finding a Node rather than a controller
Before you start
- guide 3 - the cluster this inspects.
-
Four files, mode 600, owned by root
-
Owned by a Node, not a controller