Notifications
Clear all
Topic starter
19/08/2026 3:41 pm
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.
NHIMG editorial — based on content published by Wazuh: auditing Kubernetes events with forwarded logs
By the numbers:
- The webhook listener in the guide receives audit logs on port 8080 and forwards them into the Wazuh analysis engine.
Questions worth separating out
Q: How should security teams use Kubernetes audit logs to detect risky change activity?
A: Focus first on API server actions that change state, especially create, patch, update, and delete events on workloads and configuration objects.
Q: Why does PQC planning matter to IAM and PAM teams?
A: Because authentication, privileged access, and workload trust all depend on cryptographic primitives that may need post-quantum replacement.
Q: What breaks when Kubernetes control-plane activity is not centrally logged?
A: Teams lose the ability to reconstruct administrative actions after the fact, especially resource deletion, configuration changes, and privileged API calls.
Practitioner guidance
- Log API server actions at policy-driven detail levels Separate low-risk endpoints from workload changes, token review activity, and sensitive authorisation events so audit volume stays useful.
- Centralise Kubernetes audit events outside the cluster Forward audit logs to an external analysis pipeline so delete, patch, and update events cannot be lost to local compromise or node failure.
- Alert on resource mutation before broadening to all audit noise Start with create, patch, update, and delete operations on deployments and ConfigMaps, then expand to other object types once the highest-risk paths are covered.
What's in the full article
Wazuh's full blog post covers the operational implementation details this analysis intentionally leaves for the source:
- Exact Minikube and host setup steps for building the test cluster on AlmaLinux 9
- TLS certificate generation, webhook listener code, and systemd service configuration for the Wazuh endpoint
- Full Kubernetes audit policy YAML and API server configuration changes needed to forward events
- Sample alert output and rule mapping for delete, patch, create, and update events
👉 Read Wazuh's guide to auditing Kubernetes events with forwarded audit logs →
Kubernetes audit logging: what it means for control-plane monitoring?
Explore further
19/08/2026 4:20 pm
Control-plane visibility is the real security gain here. Kubernetes audit logging is not just operational instrumentation, it is a governance layer for understanding who exercised power over cluster resources. When API server activity is centralised, security teams can correlate access, change, and identity context instead of treating Kubernetes as a black box. That directly supports NIST CSF monitoring expectations and helps identity teams distinguish legitimate privilege from unsafe standing access. The practitioner takeaway is simple: if the control plane is not observable, it is not governable.
A question worth separating out:
Q: How should organisations decide which Kubernetes audit events deserve alerts?
A: Prioritise events that change cluster state or reveal administrative intent, then tune depth by object criticality. Deletions, patches, and updates on deployments or ConfigMaps usually deserve higher priority than read-only events, because they are more likely to indicate a security-relevant change in the environment.
👉 Read our full editorial: Kubernetes audit logging strengthens visibility into cluster control-plane activity
