TL;DR: Kubernetes audit logging gives security teams visibility into control-plane activity by forwarding API server events to Wazuh for alerting and analysis, according to Wazuh. The practical value is not just log collection but the ability to spot suspicious resource changes, privilege abuse, and unauthorised actions before they become hard-to-trace incidents.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Wazuh's blog post: Forwarding audit events from the API server to Wazuh improves visibility into control-plane activity.
Why it matters: It matters because control-plane events are where changes to workloads, permissions, and resources are authorised, making audit coverage a core governance control for platform, IAM, and security teams.
Context
Kubernetes audit logging is the record of who did what to the cluster control plane, especially through the API server. Without that layer, teams may see workload symptoms but miss the change request, identity, or privilege path that caused them.
This article focuses on forwarding those audit events into Wazuh so they can be analysed and turned into alerts. That intersection matters for NHI governance as much as human IAM, because service accounts, automation, and cluster-admin actions all leave the same operational trail.
Key questions
Q: What breaks when Kubernetes API server audit logging is not enabled?
A: When audit logging is absent, teams lose the chronological trail needed to explain administrative actions, API calls, and component changes inside the cluster. That gap weakens incident response, slows root-cause analysis, and can leave compliance controls without evidence. In practice, security teams are forced to infer activity from incomplete signals instead of reviewing authoritative records.
Q: Why do Kubernetes audit logs matter for unauthorised resource changes?
A: They make destructive or privileged actions visible at the point where the API server approves them. That matters because many risky cluster changes look like ordinary administration unless the log captures the actor, verb, object, and source together. With that context, teams can distinguish expected operations from misuse or compromise.
Q: What are the signs that Kubernetes configuration auditing is failing to protect workloads?
A: A common sign is that workloads continue to violate baseline checks after deployment, especially around privilege, resource requests, limits, or image expectations. Another signal is that audit results exist but are not being reviewed or acted on. If findings do not change deployment behavior, the control is producing reports but not improving posture.
Q: What should security teams do when audit events show privileged cluster activity?
A: They should validate whether the actor, source, and action align with approved change windows and service ownership. If the event involves a service account or admin identity outside expected behaviour, the response should focus on scope, provenance, and follow-on changes before assuming the action was routine.
Technical breakdown
How Kubernetes audit events are generated and filtered
The Kubernetes API server is the control point for cluster state changes, so audit logging is built around API requests rather than node-level telemetry. Audit policy lets teams assign different detail levels to different request types, such as omitting health checks, reducing token-related logging to metadata, and keeping create, update, patch, or delete operations at a richer level. That separation matters because not every request deserves the same storage cost or investigative value. The article shows the practical pattern: define what to suppress, what to retain, and what needs full request and response context for later review.
Practical implication: define audit policy by resource sensitivity and action type, not as a blanket capture rule.
Why webhook forwarding changes control-plane visibility
Webhook forwarding moves audit events out of the cluster and into a security analysis pipeline, which creates a second place to observe cluster actions. In the article, the webhook listener receives JSON POST requests over TLS and forwards them into the Wazuh analysis engine through a local socket. That design gives the security team a centralised place to alert, correlate, and retain events even when cluster administrators can alter workloads quickly. It also makes the monitoring layer more durable than logs left only on the control plane host.
Practical implication: route audit logs to a separate security system so control-plane activity remains observable outside the cluster boundary.
What the example alerts actually detect
The example rules focus on observable administrative actions such as creating, patching, updating, and deleting resources. Those events are not suspicious by default, but they become important when they involve privileged users, unusual sources, or resource classes that should be tightly controlled. The article’s sample delete event shows the value of preserving user, verb, namespace, object, source IP, and response data in a single record. That is the difference between knowing a deployment disappeared and being able to trace who removed it, from where, and with what authorization outcome.
Practical implication: alert on high-impact verbs for critical resource types and preserve identity context in every event.
NHI Mgmt Group analysis
Audit logging is a control-plane governance layer, not just a logging feature. Kubernetes gives teams enormous operational leverage, which means the control plane is where risky changes are authorised. When that layer is not auditable, the organisation loses the ability to reconstruct who changed what, and that weakens both security investigation and administrative accountability. The practical conclusion is that control-plane visibility should be treated as a governance requirement for Kubernetes, not a convenience feature.
Control-plane blind spots affect both human and non-human identities. The article’s setup depends on API server activity, which is exactly where service accounts, automation jobs, and administrators all converge. That makes Kubernetes audit logging relevant to NHI governance as well as human IAM because the same path can be abused for privilege misuse or unauthorised changes. Practitioners should treat audit completeness as part of identity control, not only platform monitoring.
Cluster change monitoring needs identity context to be useful. A delete or patch event only becomes actionable when the record carries user, verb, object, source, and result together. That is why isolated event counts are weaker than correlated audit trails. The named concept here is control-plane accountability gap: the gap that appears when teams can see that a change happened but cannot reliably attribute it to an identity, source, or authorisation outcome. The practical conclusion is to build monitoring around attributable actions, not raw event volume.
Audit policies should be selective, not indiscriminate. The article shows different handling for token reviews, subject access reviews, and pod changes, which reflects a mature logging posture rather than “log everything” thinking. That matters because audit systems drown when sensitive and low-value traffic are treated identically. The practical conclusion is to calibrate audit depth to the action’s risk and investigative value.
Kubernetes control-plane telemetry belongs in broader security operations. Audit data becomes much more useful when it feeds alerting, correlation, and investigation workflows instead of sitting only in the cluster. That aligns with broader NIST-CSF-style monitoring expectations and with the operational reality that container environments change too fast for manual review. The practical conclusion is to make audit logs part of the security analytics pipeline, not a standalone troubleshooting artifact.
From our research library:
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
What this signals
Kubernetes audit logging turns control-plane actions into reviewable security evidence, which is essential when workload changes happen faster than manual oversight can keep up. For practitioners, the key shift is to treat API server visibility as part of the access-control model rather than as an optional operational add-on.
Control-plane accountability gap: when log data cannot tie a resource change back to an identity, source, and authorisation outcome, security teams lose both detection value and investigative confidence. The practical response is to design monitoring around attributable actions, not around raw event counts.
For practitioners
- Define audit policy by action risk Separate low-value health and version checks from sensitive requests such as token reviews, subject access reviews, and workload changes so the log stream stays usable.
- Forward control-plane logs to a security analysis system Send Kubernetes audit events to a dedicated monitoring pipeline so cluster administrators cannot remove the only evidence trail for resource changes.
- Preserve identity and source context in every event Retain username, source IP, verb, object reference, response status, and timestamp so investigators can reconstruct who approved or executed a change.
- Alert on destructive and privilege-sensitive verbs Create detection rules for delete, patch, and update activity on deployments, ConfigMaps, and other high-impact resources, then tune severity by namespace and actor.
Key takeaways
- Kubernetes audit logging closes a governance blind spot by capturing who changed cluster resources, what they changed, and whether the request was allowed.
- The most useful audit records are those that preserve identity, source, verb, object, and response context for high-impact control-plane actions.
- Audit logging is strongest when it feeds a security analysis pipeline, because that makes privileged cluster activity detectable outside the cluster itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0007; TA0008 — Discovery; Lateral Movement | Audit logs expose reconnaissance and movement across cluster resources after control-plane access. |
| Recommendation — Map suspicious control-plane actions to TA0007 and TA0008, then hunt for unusual resource changes across namespaces. | ||
| NIST CSF 2.0 | DE.CM-01 — Network and System Monitoring | The article is about monitoring API server activity as a security control. |
| Recommendation — Use DE.CM-01 to monitor Kubernetes audit events continuously and route them into detection workflows. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The article shows how audit collection, centralisation, and alerting support security oversight. |
| Recommendation — Apply CIS-8 to centralise Kubernetes audit logs, retain them, and alert on destructive actions. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Kubernetes audit policy defines which security-relevant events are recorded. |
| AU-6 — Audit Record Review, Analysis, and Reporting | The Wazuh pipeline turns audit events into alerts and analysis. | |
| Recommendation — Define AU-2 event selection so Kubernetes logs capture control-plane actions with enough fidelity for investigation. Use AU-6 to review Kubernetes audit records for privileged changes, deletions, and other high-impact actions. | ||
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.
- Control Plane: The control plane is the set of actions that create, configure, or manage a service. For AI workloads, it covers deployment and administration of the model platform, while data-plane permissions govern what the service and its identities can read or process.
- Audit Policy: An audit policy defines which Kubernetes requests are logged and how much detail is captured for each category. It is the key control for balancing visibility, noise, and sensitive-data exposure, and it shapes whether audit data is useful for security operations or too verbose to manage.
- Webhook: An automated HTTP callback that sends event data from one application to another when a trigger occurs. In security terms, a webhook is a machine-to-machine trust path that can carry sensitive data and authorization context without a human login step.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle control. It helps practitioners connect identity control to the operational systems their security programmes depend on.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org