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

Attacker Persistence Mechanisms

Getting in is one problem; staying in is a different one, and in Kubernetes it is solved with ordinary objects that look like configuration. This guide plants three of them, shows why each survives a reboot, and ends with the one query that finds the first.

Kubernetes Threat Model Guide 30 of 42 Intermediate

Manually created kubernetes.io/service-account-token Secrets are still populated by the token controller in v1.36 and the JWT they contain carries no exp. Auto-creation of these Secrets ended in 1.24; creating one by hand did not.

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 the question is how an intruder stays in. This matters because persistence in Kubernetes is usually an ordinary object rather than malware - a binding, a non-expiring token, or a CronJob that recreates whatever you delete.

Before you start

  1. A backdoor that is one object

  2. A credential that does not expire

  3. For contrast, the modern token

  4. A beacon that is not a running process

  5. The query that finds the first one

Official sources

← All KCSA guides