Kubernetes API abuse exposes the limits of RBAC-only defenses

At a glance

What this is: This is a Kubernetes audit logging and detection guide showing how API abuse, secret enumeration, service account token theft, and privileged role creation can be surfaced in cluster telemetry.

Why it matters: It matters because RBAC alone does not stop misuse of valid credentials or privileged API actions, so IAM and platform teams need auditability, correlation, and lifecycle controls around Kubernetes identities.

Context

Kubernetes relies on a centralized API to manage most cluster actions, which means the security model is only as strong as the permissions, credentials, and telemetry around that API. When permissions are misconfigured or credentials are exposed, attackers can move directly through the control plane rather than attacking the workload layer first.

For IAM and platform teams, the governance gap is not just authorisation. It is whether the organisation can observe secret access, token creation, role binding changes, and other API-level actions quickly enough to distinguish normal administration from abuse.

Wazuh uses Stratus Red Team emulation to show that audit logging and correlation are necessary to make Kubernetes API abuse visible in practice. The article’s starting point is typical for modern clusters, where API-driven operations create both operational efficiency and identity risk.

Key questions

Q: What breaks when Kubernetes security depends on RBAC alone?

A: RBAC can grant or deny actions, but it does not explain whether a connection is expected or whether a workload is moving laterally in a suspicious way. In Kubernetes, that creates a control gap because permissions may still look valid after the original task is complete. Teams need traffic context and containment controls, not authorization records alone.

Q: Why do service accounts and tokens complicate Kubernetes access governance?

A: Service accounts and tokens complicate governance because they turn access into a secret-management problem as much as an identity problem. If the token is copied, the cluster cannot tell intent from reuse. That means teams need strict scope control, short lifetimes where possible, and a reliable offboarding process for every workload identity.

Q: What are the signs that Kubernetes privilege escalation is being attempted through pods and workloads?

A: Warning signs include unexpected RoleBinding or ClusterRoleBinding creation, unusual token generation, access from pods that should not administer cluster resources, and workload changes that spread across nodes or namespaces. Suspicious DaemonSet edits, pod exec activity, or taint manipulation can also indicate an attacker is trying to move laterally or force rescheduling onto a controlled node.

Q: How should teams respond to Kubernetes API abuse in a cluster with audit logging?

A: Treat the event as a control-plane identity incident and review the sequence of API calls that led to it, including token use, role changes, and resource modifications. The goal is to determine whether access was legitimate, over-broad, or created for persistence.

Technical breakdown

Why RBAC alone does not stop Kubernetes API abuse

RBAC answers whether an identity is allowed to perform an action, but it does not answer whether the action is legitimate, expected, or part of an abuse chain. In Kubernetes, service accounts, tokens, and cluster roles all interact through the API server, so a valid credential can still be used to enumerate secrets, create bindings, or probe cluster resources. That is why API-layer abuse often looks like normal administration unless the cluster is logging the right objects and verbs. The article’s emphasis on audit logging reflects a simple technical reality: authorisation without visibility leaves too much room for misuse of permitted access.

Practical implication: log the API actions that matter, not just the final allow or deny decision.

How Kubernetes audit policy turns API requests into detections

Kubernetes audit policy controls which request types are captured and at what level of detail. Metadata-level logging can show that a request happened, while Request and RequestResponse levels preserve enough context to detect sensitive actions such as token creation, certificate abuse, subject access reviews, and privileged pod changes. The article’s policy separates low-value endpoints from high-value ones so the telemetry stays useful without drowning operators in noise. This is the technical bridge between raw API activity and alerting logic, because detection rules can only work when the underlying event stream preserves the right fields.

Practical implication: tune audit policy around the abuse paths you actually want to detect, then validate the resulting event content.

Why service account tokens and cluster roles create a persistence path

Service account tokens and cluster role bindings are not just access artefacts. They are persistence mechanisms when attackers can create new identities, bind elevated permissions, or mint longer-lived credentials than the cluster intended. The article notes that modern Kubernetes uses ephemeral tokens through the TokenRequest API, but that does not remove the persistence risk if an attacker can create fresh privilege-bearing objects or attach new bindings. In practice, the abuse chain shifts from stealing a static secret to manufacturing a durable access path through the control plane itself.

Practical implication: monitor creation of service accounts, cluster roles, and bindings as persistence indicators, not routine admin noise.

Threat narrative

Attacker objective: The attacker wants durable control of the Kubernetes control plane so they can enumerate secrets, expand privileges, and operate across the cluster with legitimate-looking API activity.

1. Entry begins when an attacker reaches the Kubernetes API with a misconfigured permission or exposed credential that can be used against the control plane.
2. Credential access follows when the attacker enumerates secrets or steals a mounted service account token from a running pod.
3. Escalation occurs when the attacker creates cluster roles, service accounts, or bindings that expand access beyond the original identity scope.
4. Impact is achieved when the attacker can perform cluster-wide reconnaissance, manipulate resources, or maintain durable API access through newly created credentials and privileges.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Cisco DevHub breach 2024: A misconfigured script left non-public files on Cisco's DevHub; IntelBroker took them and claimed reuse of hard-coded SSH credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

RBAC is an authorisation boundary, not a governance boundary: The article shows that allowed API actions can still be abused when credentials are exposed or permissions are too broad. In Kubernetes, the attacker does not need to break the access model if the model already permits secret reads, role creation, or token minting. The practitioner conclusion is that control design must include telemetry, not just policy.

Kubernetes auditability is the missing control plane for identity misuse: Secret enumeration, subject access reviews, token creation, and role binding changes are all identity events even when they occur through a platform API. Without audit logs at the right level, security teams cannot separate normal administration from malicious privilege construction. The practitioner conclusion is that detection must be built around identity-relevant API verbs and resources.

Standing privilege inside the cluster creates a reusable attack surface: Service accounts, cluster roles, and long-lived tokens turn a one-time compromise into repeatable access if they are not governed as lifecycle objects. That is a classic NHI problem inside a cloud-native platform, where the identity is the workload or service account, not the human operator. The practitioner conclusion is that Kubernetes identities need lifecycle ownership, not just deployment-time configuration.

Identity blast radius is the right concept for Kubernetes control plane risk: A single exposed credential can expand into cluster-wide reconnaissance or resource manipulation if bindings and token lifetimes are not constrained. That is why the article’s detection approach matters beyond one cluster: it shows that API-driven environments need visibility into who can create identity objects, not just who can consume them. The practitioner conclusion is to treat Kubernetes API privilege as blast-radius control, not a simple allow list.

Stratus-style emulation is valuable because it tests the control path, not the theory: The article demonstrates abuse patterns that map to credential access, persistence, and privilege escalation without relying on a bespoke exploit. That matters because many Kubernetes programmes overestimate RBAC coverage and underestimate how easily valid API access can be repurposed. The practitioner conclusion is to validate controls against realistic adversary actions, not only configuration baselines.

What this signals

Identity events inside Kubernetes need to be governed like any other privileged access path: when service account token creation, role binding changes, and secret enumeration are all visible in the same audit stream, the cluster finally becomes governable as an identity system rather than a black box of YAML objects. That shift matters because RBAC rules without event correlation leave too much room for valid-looking abuse.

Cluster-wide audit visibility changes the response model: once security teams can see who requested a token, who created a role, and which pod actions followed, they can distinguish noise from abuse much earlier in the chain. That reduces the chance that a short-lived compromise becomes persistent API access.

Kubernetes controls fail differently from human IAM controls: the issue is often not password weakness or interactive login failure, but machine-to-machine trust that is too easy to extend through the control plane. Practitioners should expect identity blast radius to grow from API verbs, not just from obvious privilege assignments.

For practitioners

• Instrument sensitive Kubernetes API verbs Prioritise audit coverage for secret reads, service account token creation, subject access reviews, cluster role creation, and cluster role binding changes. Those are the API actions that most clearly separate benign administration from identity abuse.
• Treat service account tokens as lifecycle-managed credentials Track token issuance, scope, and expiry as governed identity events rather than background cluster mechanics. Where workloads can mint or inherit powerful tokens, bind ownership and offboarding to a named system owner.
• Correlate API telemetry with role and binding changes Use detection logic that links a sensitive request to follow-on changes in RBAC objects, because privilege escalation in Kubernetes often appears as a sequence of individually valid calls.
• Test the cluster with adversary emulation Replay secret enumeration, token theft, privileged role creation, and long-lived token scenarios to confirm that audit logs and alert rules fire on the exact behaviours you care about.

Key takeaways

• Kubernetes API abuse is often a governance problem, not a pure exploit problem, because valid credentials can still be turned into secret access and privilege expansion.
• The article shows that audit logs can surface the exact behaviours that RBAC misses, including secret enumeration, token abuse, and cluster role creation.
• Teams that want to limit blast radius need lifecycle ownership for service account credentials and detection around the API actions that create persistence.

Key terms

• Kubernetes Audit Log: A record of API activity generated by the Kubernetes control plane. It captures who requested what, when, and at what level of detail, which makes it essential for spotting secrets access, privilege changes, and other identity-driven abuse.
• Cluster Role Binding: A cluster role binding links a subject, such as a user, group, or service account, to a cluster-wide role. In Kubernetes security, this object deserves close review because it can elevate a default or shared identity into privileged access across namespaces, creating widespread exposure if misapplied.
• Bound Service Account Token: A service account token that is tied more closely to a specific pod or workload context. This binding improves traceability and reduces the usefulness of a stolen token, because the token is less transferable and easier to constrain to its intended runtime scope.
• Control Plane Abuse: Control plane abuse occurs when an attacker uses legitimate administrative interfaces to perform destructive or high-impact actions. In NHI terms, the problem is not malware execution but trusted authority that can scale changes across many systems at once.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.