Kubernetes security architecture for beginners: API server, etcd, kubelet, and the 4Cs

The moving parts

The control plane runs the API server, which every client talks to; etcd, the key-value store that holds all cluster state including Secrets; the scheduler; and the controller manager. Each worker node runs the kubelet, which starts containers through a container runtime such as containerd, and usually kube-proxy for service networking.

Almost everything is an API call. kubectl, controllers, the kubelet, and your CI pipeline all authenticate to the API server, are authorized by RBAC, and pass through admission control before an object is stored in etcd. That single choke point is where most cluster security is enforced and logged.

The 4Cs

The Kubernetes documentation frames security in layers: Cloud (the account and network the cluster runs in), Cluster (API server access, RBAC, admission, network policy), Container (image contents, runtime privileges), and Code (the application itself). A weakness in an outer layer undermines the inner ones: perfect pod settings do not help if the API server is open to the internet with anonymous access.

Lab: tour a local cluster

Create a throwaway cluster with kind or minikube on your laptop. List the control-plane pods, find which flags the API server runs with, and ask the API who you are. On kind, the control plane is itself a container, so you can inspect the static pod manifests directly.

kind create cluster --name sec-lab
kubectl get pods -n kube-system -o wide
kubectl auth whoami
docker exec sec-lab-control-plane cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep -E 'authorization-mode|anonymous-auth|audit|encryption'

Where to start

For a new cluster, check these first: the API server is not publicly reachable or is restricted by IP, RBAC is the authorization mode, nobody uses cluster-admin day to day, Pod Security admission is enforced on application namespaces, and audit logging is enabled. The rest of this hub covers each of those.