CertGrid CertGrid
Hands-on Lab·Kubernetes and Cloud Native Security Associate

Trust Boundaries: Authentication and Authorization

A threat model is a map of boundaries, and Kubernetes has four that matter: the human at a terminal, the Pod holding a token, the apiserver deciding twice about every request, and the node underneath. This guide crosses each one from inside a running Pod, using curl rather than kubectl so that nothing is hidden.

Kubernetes Threat Model Guide 26 of 42 Intermediate

Anonymous requests reach the apiserver as system:anonymous on a default kubeadm cluster, which is why the refusal below is a 403 and not a 401. Projected ServiceAccount tokens are the default since 1.24.

The cka5001 cluster: one control plane and 3 schedulable workers, on Cilium.
Server NameIP AddressOSRolesCPURAMHDD
CKA5001192.168.0.41Ubuntu 26.04 LTSControl Plane Node (tainted NoSchedule)2 Core4 GB50 GB
CKA5001-NODE01192.168.0.42Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA5001-NODE02192.168.0.43Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA5001-NODE03192.168.0.44Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB

This guide includes

Use this when a threat model has to be more than a diagram. This matters because Kubernetes has four boundaries that matter, and every request crosses two separate gates - authentication says who you are, authorization says what you may do, and the two fail quite differently.

Before you start

  1. The human identity, and what it actually is

  2. The Pod identity, mounted without being asked for

  3. What the token says about itself

  4. Crossing into the apiserver, and being stopped at the second gate

  5. The same request with no credential at all

  6. The boundary that holds with no policy at all

Official sources

← All KCSA guides