Notifications
Clear all
Topic starter
18/08/2026 2:54 pm
TL;DR: Kubernetes audit logging can surface secret enumeration, service account token abuse, and privileged role creation, according to Wazuh’s analysis of Stratus Red Team attack emulation. The finding is that API-driven clusters need telemetry, correlation, and lifecycle controls, because RBAC alone does not stop credential misuse or privilege misuse.
NHIMG editorial — based on content published by Wazuh: detecting and analysing Kubernetes attack techniques with audit logs and Wazuh
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.
Questions worth separating out
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.
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.
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
- 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.
- 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.
- 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.
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.
👉 Read Wazuh's blog on detecting Kubernetes API abuse with audit logging →
Kubernetes API abuse and RBAC gaps: are your controls keeping up?
Explore further
18/08/2026 3:37 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Kubernetes API abuse exposes the limits of RBAC-only defenses
