Mapping STRIDE Onto Kubernetes

In one line

Threat modeling is a method of sweeping through with a classification system, leaving nothing out, instead of listing "what is scary" by gut feeling. If you apply the six STRIDE items to Kubernetes objects, the check items come out on their own.

Why this was needed

The reason security reviews reach different conclusions from person to person is that each looks only at the threats they know. A network person sees firewalls, and a developer sees injection. STRIDE gives you the checklist "did we ask about all six of these?" The aim is to reduce omissions structurally.

How it works

The six items translated to Kubernetes

STRIDE	Meaning	What it looks like in Kubernetes	Main response
Spoofing	Identity spoofing	SA token theft, forged certificates, --as impersonation	Strong authentication, shorter token lifetimes, control over impersonate permission
Tampering	Modification	Image swapping, direct writes to etcd, manifest manipulation	Image signing, etcd access control, GitOps
Repudiation	Denying an action	Being unable to prove who did it	Audit logs, individual identities (no shared accounts)
Information Disclosure	Information exposure	Secret leaks, the kubelet read-only port, credentials in logs	Encryption at rest, RBAC, log hygiene
Denial of Service	Denial of service	Resource exhaustion, apiserver flooding, webhook outages	ResourceQuota, LimitRange, PDB, API priority
Elevation of Privilege	Privilege escalation	privileged Pods, hostPath, RBAC misconfiguration	PSA, least privilege, admission policy

Privilege escalation paths — the core of KCSA

Privilege escalation is not "being handed admin permission directly" but "a path from a non-admin permission to admin." Memorize the four representative paths.

1) pods/exec or pods/attach If you can get into a Pod, you can read that Pod's ServiceAccount token. If that SA has more permission than you, you get that permission as it is. Permission granted for debugging convenience becomes a ladder to "the strongest of all the SAs in the cluster."

2) Reading secrets Secrets contain other SAs' tokens, DB credentials, and external API keys. If you have get secrets in a namespace, you read every Secret in that namespace.

3) create on rolebindings/clusterrolebindings You can grant yourself higher permissions. Kubernetes knows this, so by default it prevents you from granting permissions you do not hold yourself (escalation prevention). Breaking through that defense is the next item.

4) The escalate, bind, and impersonate verbs

• escalate — a meta permission that lets you put permissions you do not hold yourself into a Role
• bind — lets you bind a Role you do not hold yourself
• impersonate — impersonating another user, group, or SA. If you impersonate system:masters, it is over

And the Pod spec itself is an escalation path.

• privileged: true → effectively node root
• Mounting / with hostPath → the entire node filesystem (including the kubelet certificate)
• hostNetwork/hostPID → the node's network and process namespaces
• capabilities.add: [SYS_ADMIN] → a container escape toolbox

"Being able to create a Pod" is, potentially, close to "being able to own that node." That is why restricting Pod specs with PSA or a policy engine is as important as RBAC.

Supply chain threats

No matter how well I lock down my cluster, it does not help against what I voluntarily pull and run.

• Base images — vulnerable libraries come in as they are
• Tag movement — myapp:1.4.2 may point to different content today than yesterday
• Dependency poisoning — typosquatting, and malicious versions published through account takeover
• Build pipeline — CI has cluster deployment permission, so a CI compromise = a cluster compromise
• Build argument residue — a secret put in with --build-arg shows up as it is in docker history --no-trunc. Even if you delete the file in a later layer, it remains in the earlier layer, and if it was pushed, everyone who pulled that image can read it

The response is provenance and integrity — allow only trusted registries, pin by digest, verify image signatures, and list what is inside with an SBOM.

Techniques for establishing persistence

An attacker who breaks in successfully builds a way to come back in. Once organized, these become detection items.

• DaemonSet placement — one on every node, automatically following when nodes are added
• CronJob — a backdoor that revives periodically
• Registering an admission webhook — can intercept the creation of every object and secretly mutate it
• Adding a ClusterRoleBinding — attaching cluster-admin under an inconspicuous name
• Securing an SA token — if you create a long-lived token Secret, it can survive even when the account is deleted (especially in a cluster with --service-account-lookup=false)
• Static Pods — if you place a file in the node's manifest directory, it runs without going through the apiserver. In kubectl it looks like a normal mirror Pod

What it looks like in the field

The most common of the RBAC incident patterns the author's blog compiled is the discovery of "an abnormal state in which every ServiceAccount can read cluster resources." The diagnosis is kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name=="cluster-admin")', an exhaustive survey of cluster-admin binding subjects, and this is exactly the same query as detecting persistence techniques.

On the supply chain side, there is a more vivid case. A token put in with docker build --build-arg NPM_TOKEN=... shows up as it is in docker history --no-trunc. Even if you delete the file in a RUN stage, it remains in the earlier layer. The right way is to use a build secret mount such as RUN --mount=type=secret,id=npmrc,....

And the author's point about order in secret leak response ties in with threat modeling. The most common reaction is rewriting Git history, but the order is wrong. A credential pushed to a public repository is collected by automated scanners within seconds to minutes, and even if you erase the history, it remains in forks, existing clones, PR references the platform keeps, search caches, and CI artifacts. Revocation comes first, and cleaning up history is hygiene work that reduces recurrence. It is an example of threat modeling changing even the order of response.

What to check in the next quiz

This module ends with a quiz. In the next module we cover PSA, the mechanism that actually blocks Pod-spec-based privilege escalation, and in the labs you directly confirm that a restricted-violating Pod is rejected.