SelfSubjectRulesReview is a Kubernetes API that returns the exact set of actions the calling identity can perform in a namespace. After stealing a token or impersonating an identity, an attacker calls it to map their capabilities instantly, skipping noisy trial and error. It is available to all authenticated users by design, so the defence is least-privilege identities and detection of post-compromise recon, not disabling the API.
What SelfSubjectRulesReview abuse is
SelfSubjectRulesReview exists so a workload can ask the cluster what it is allowed to do. That same introspection is a gift to an attacker: instead of probing actions one by one and generating audit noise, they ask the API directly and get a precise list of what a stolen identity can execute.
How it works and example
Having compromised a token or impersonated an identity, the attacker calls SelfSubjectRulesReview and immediately learns which verbs and resources are in reach, so they target only actions that will succeed. In a 2026 cluster intrusion this capability mapping let the agent move straight to useful actions without tripping the alarms that failed attempts would raise.
How to defend against it
You cannot meaningfully block self-review, so make what it can reveal small: give every identity least privilege so a mapped capability set is minimal, and separate duties across identities. Monitor for SelfSubjectRulesReview and SelfSubjectAccessReview calls from unusual clients as a post-compromise recon signal, and investigate when a workload suddenly introspects its own rights.
References
- [1]MITRE ATT&CK Cloud Matrix(MITRE ATT&CK)
- [2]HuggingFace, Agent intrusion technical timeline(HuggingFace)
- [3]Kubernetes authorization: checking API access(Kubernetes)
An attacker can read exactly what a stolen identity can do, so make that as little as possible. Talk to a security expert about tightening cluster RBAC.