Topic starter
18/08/2026 2:54 pm
TL;DR: Secret enumeration, service account token abuse, and privileged role creation can still occur when RBAC is the main defense, Wazuh says. Kubernetes needs telemetry, correlation, and lifecycle controls to spot valid credentials being used for abuse.
Editorial analysis by NHI Mgmt Group, based on content published by Wazuh: “Detecting Kubernetes attacks with Wazuh”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
- Treat service account tokens as lifecycle-managed credentials Track token issuance, scope, and expiry as governed identity events rather than background cluster mechanics.
- 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.
Bottom line: 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.
Glossary terms: Kubernetes Audit Log, Cluster Role Binding, Bound Service Account Token, Control Plane Abuse
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
18/08/2026 3:37 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Kubernetes API abuse exposes the limits of RBAC-only defenses