Hands-on Lab·Certified Kubernetes Security Specialist
Identifying the Phases of an Attack
One compromised Pod, three phases, and then the same three phases from the defender's side. The competency asks you to identify phases of attack, so this guide runs one on a real cluster and looks for it afterwards.
Monitoring and Runtime Guide 36 of 40 Advanced
- Kubernetesapiserver v1.36.4, kubelet v1.36.3
- Runtimecontainerd 2.2.6
- CNICilium 1.18.1
- Built withkubeadm v1.36.3
- TimeAbout 17 min
Cilium 1.18.1 with Hubble, on a cluster with no NetworkPolicy and no audit logging - which is the default state and the reason the trace looks like this.
- Host kernel7.0.0-29
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA6001 | 192.168.0.46 | Ubuntu 26.04 LTS | Control Plane Node (tainted NoSchedule) | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE01 | 192.168.0.47 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE02 | 192.168.0.48 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when an incident has to be described in phases rather than as one event. This matters because the same three phases look completely different from the defender's side - and one layer saw it while another did not.
- setting the scene - a Secret worth taking, an internal API, and a Pod next door
- running the three phases in order: find it, reach it, take it
- querying what the network layer saw, and then the attacker's own traffic
- finding what the API layer saw, and the flags that were never set
Before you start
-
The scene
-
Three phases, in order
-
What the network layer saw
-
What the API layer saw, and did not