Kubernetes API abuse exposes the limits of RBAC-only defenses

At a glance

What this is: This is a Kubernetes security walkthrough showing how API-level attack simulation and audit logging can detect secret enumeration, token theft, and privilege misuse.

Why it matters: It matters because Kubernetes permissions, service accounts, and tokens are identity controls in practice, so IAM and NHI teams need visibility into how those identities are abused at runtime.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Wazuh's blog on detecting Kubernetes API abuse with audit logging

Context

Kubernetes is an identity-controlled system as much as it is an orchestration platform. Once an attacker can reach the Kubernetes API, the practical security boundary is no longer the cluster node, but the permissions attached to secrets, service accounts, roles, and certificates.

This article shows why RBAC by itself is not a complete control plane defense. Audit logging and behavioural detection become necessary because many high-risk actions in Kubernetes look like ordinary API calls until they are correlated across time and resource types.

For IAM and NHI programmes, the important takeaway is that Kubernetes workloads carry non-human identities that can be enumerated, impersonated, and chained into wider access. That makes lifecycle governance and auditability central, not optional, in container security.

Key questions

Q: How should security teams detect Kubernetes secrets abuse through the API server?

A: Security teams should alert on repeated list and get activity against secrets, especially when it spans many namespaces or occurs outside normal administrative windows. The key is to correlate API verb, resource, and actor identity, because a single request can be benign while a short burst of access usually signals enumeration.

Q: Why do service account tokens increase lateral movement risk?

A: Because they authenticate as valid identities without human interaction and often carry access that persists beyond the original task. If the token is over-scoped or poorly monitored, an attacker can reuse it across systems and clouds while appearing authorised. The risk grows when teams treat service accounts as infrastructure details instead of governed identities.

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: How should teams respond when they see suspicious role or token creation in Kubernetes?

A: Teams should treat role, binding, and token creation as a possible escalation sequence and contain the affected workload before the attacker can chain those permissions. Validate whether the identity is expected, review recent audit events, and revoke the credential path if the activity is not part of a known deployment change.

Technical breakdown

Kubernetes API abuse through secrets enumeration

Kubernetes stores sensitive material in API-addressable resources, so list or get permissions against secrets can become a direct credential discovery path. In practice, an attacker does not need shell access if they can query the API with a valid token or over-permissive role. Audit logs can distinguish normal administrative activity from cluster-wide enumeration when request volume, verb patterns, and namespace scope shift abruptly. The article’s detection logic demonstrates that secrets access is observable when logs are captured at the right level and correlated with suspicious request URIs.

Practical implication: log and alert on secrets enumeration at the API layer, not just on node compromise or malware activity.

Service account token abuse and privilege escalation

Service account tokens are non-human identities that Kubernetes uses to authorize pods and workloads. When those tokens are exposed or long-lived, they can be replayed directly against the API server and used to create higher-privilege objects such as roles, bindings, or pods. The distinction matters because the attack is not password theft in the human IAM sense. It is credential misuse inside a machine identity system, where the token’s effective power is defined by RBAC scope and token lifetime.

Practical implication: treat service account tokens as governed machine credentials with explicit scope, expiry, and revocation paths.

Audit log correlation for RBAC misuse and cluster manipulation

Kubernetes audit logging becomes useful when it records related actions together, such as role creation, role binding creation, and pod changes. Single events often look harmless, but chained events reveal persistence or privilege escalation intent. This is why the article’s Wazuh rules correlate verbs, resources, and time windows rather than relying on one-off signatures. In a Kubernetes environment, detection quality depends less on raw log volume and more on whether the policy captures the resources attackers actually touch during abuse.

Practical implication: tune audit policy and correlation rules around RBAC changes, token requests, and pod manipulation paths.

Threat narrative

Attacker objective: The attacker wants durable cluster control through credential discovery, privilege expansion, and persistence inside the Kubernetes API plane.

1. Entry occurs through valid Kubernetes API access obtained via exposed credentials or an over-permissive service account token.
2. Escalation follows when the attacker enumerates secrets, creates privileged roles or bindings, or abuses pod and node permissions to extend control.
3. Impact is achieved when cluster-wide access, host filesystem exposure, or persistent authentication material gives the attacker durable operational control over the environment.

Breaches seen in the wild

• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Kubernetes security is identity security, not just platform security. The API server is the enforcement point for service accounts, roles, bindings, and tokens, which means Kubernetes abuse is fundamentally an NHI governance problem. When those identities are not inventoried, scoped, and lifecycle-managed like other non-human credentials, attackers can turn ordinary API permissions into cluster control. Practitioners should treat Kubernetes as part of the identity estate, not a separate tooling silo.

Secret enumeration is a governance failure, not a detection edge case. The article’s attack simulation shows that one exposed or over-broad API credential can reveal secrets, certificates, and higher-privilege resources. That is the same structural issue seen in broader NHI programmes: access is often provisioned faster than it is retired, reviewed, or constrained. The implication is that secret sprawl and RBAC sprawl must be governed together, because each amplifies the other.

Auditability is the control that turns Kubernetes from opaque to governable. Audit logs do not prevent misuse, but they make privileged API behaviour visible enough to detect credential access, role creation, and pod manipulation in sequence. Without that visibility, service account abuse can look like routine automation. Practitioners should consider API audit depth a prerequisite for identity governance in container environments.

Ephemeral tokens change the shape of the risk, but not the governance burden. The article notes that modern Kubernetes no longer automatically issues long-lived service account secrets in the same way, yet token-based access still enables persistence and privilege abuse if the surrounding controls are weak. This is a reminder that shorter-lived credentials reduce exposure windows only when they are paired with least privilege, monitoring, and offboarding discipline. The practical conclusion is that token format is not the control; lifecycle enforcement is.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to the State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• This pattern reinforces the Guide to the Secret Sprawl Challenge, which helps teams reduce exposed credentials before they become durable access paths.

What this signals

Kubernetes clusters are becoming identity-rich attack surfaces, which means teams can no longer separate platform security from NHI governance. The more workloads rely on service accounts, ephemeral tokens, and API-driven automation, the more the programme needs lifecycle control, audit depth, and ownership mapping for every machine credential.

Identity blast radius: the practical question is not whether a token exists, but how far it can move when abused. When RBAC and secrets management are handled separately, the cluster inherits the same failure mode seen in wider NHI sprawl: access is technically present long after it is operationally justified.

Practitioners should expect attack emulation and audit correlation to become standard validation for Kubernetes identity controls, not an advanced exercise. A usable control is one that can prove it would see secrets enumeration, token misuse, and privilege chaining before an adversary finishes the sequence.

For practitioners

• Inventory Kubernetes service accounts as NHI assets Map every namespace, workload, and automation path that uses a service account token, then assign an owner, purpose, and expiry expectation. Include ephemeral tokens, workload-mounted credentials, and any object that can authenticate to the API server.
• Tune audit policy to capture abuse paths Record secrets access, token requests, subject access reviews, role and binding creation, and privileged pod changes at a level that preserves investigative value. Correlate those events into sequences so that enumeration plus escalation is visible as a single attack path.
• Review RBAC for cluster-wide blast radius Identify roles that allow broad list, create, patch, or delete actions across secrets, pods, and RBAC objects, then remove unnecessary cluster-scope permissions. Pay particular attention to bindings that let workloads create new identities or rebind existing ones.
• Treat token lifetime as a governance control Shorten the usable window for service account credentials and define a revocation path for compromised workloads, deleted namespaces, and offboarded automation. Pair expiry with monitoring so a reused token is observable before it becomes durable access.
• Test detection against realistic API abuse chains Use adversary emulation to validate whether your monitoring catches secret enumeration, pod exec abuse, and persistence creation in the same session. The goal is to detect the chain, not isolated events, because attackers move quickly through the API plane.

Key takeaways

• Kubernetes API abuse is an identity problem because service accounts, tokens, and RBAC define the real security boundary.
• Audit logging and correlation are what make secret enumeration and privilege chaining visible inside a noisy cluster.
• Teams need lifecycle control for machine credentials, or a single exposed token can become durable cluster access.

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.
• Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
• ClusterRole: A ClusterRole defines permissions that can apply across namespaces or to cluster-scoped resources. It creates wider blast radius than a namespace Role, so it needs tighter approval and review. For NHI governance, cluster-wide access should be rare, explicit, and continuously justified.

What's in the full article

Wazuh's full blog covers the operational detail this post intentionally leaves for the source:

• The complete Minikube and audit-policy configuration used to instrument the Kubernetes cluster.
• The full Wazuh DaemonSet manifest and the node-level volume mounts required for audit log collection.
• The Stratus Red Team commands used to emulate secrets dumping, token theft, RBAC abuse, and hostPath breakout.
• The exact Wazuh rule expressions and correlation logic used to detect each API abuse pattern.

👉 Wazuh's full post includes the Minikube setup, audit policy, and detection rules used in the simulation.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.