In today’s cloud-native environments, Kubernetes is the default backbone for container orchestration.
Its power lies in automating and scaling large-scale applications, but that also makes it a major target.
As your workloads scale, so does your responsibility to keep track of what’s happening inside the cluster.
Enter audit logs: your first line of defense when things go sideways.
But here’s the problem, most teams either misconfigure audit logs or forget to set them up properly.
That’s not just a missed opportunity; it’s a serious risk.
This guide walks you through common gotchas in Kubernetes audit logging, and how to configure logs
to actually be useful when it counts.
What Are Kubernetes Audit Logs (and Why Should You Care)?
Kubernetes audit logs are chronological records of every request made to the Kubernetes API server.
These records show who did what, when, and how within your cluster - critical context for detecting
breaches, enforcing policy, and proving compliance.
Each log entry typically includes:
- Who made the request (user/service account)
- What was accessed (e.g. pods, secrets, deployments)
- How it was accessed (GET, POST, PATCH, etc.)
- When it happened (timestamp)
So far so good, but only if the logs are configured correctly. Let’s look at how it usually goes wrong.
Pitfall 1: Not Capturing the Right Events
Kubernetes supports four logging levels:
- None: No logs at all.
- Metadata: Captures requestor and timestamp but not request or response body.
- Request: Includes request body.
- RequestResponse: Full request/response log.
The trap? Logging everything (RequestResponse) causes massive overhead. Logging too little (Metadata)
gives you blind spots.
Fix: Fine-Tune Your Audit Policy
Your audit policy should be targeted:
- Log sensitive resources (e.g. secrets) at RequestResponse.
- Log routine actions (e.g. pod scheduling) at Metadata.
Step-by-step:
- Create/Edit Audit Policy File with YAML rules.
- Attach it to the API server using the --audit-policy-file flag.

Pitfall 2: Letting Logs Blow Up Your Cluster
Audit logs can grow fast and impact both performance and storage.
Fix: Rotate and Compress Logs
Step-by-step:
- Enable log rotation via API server flags.
- Enable compression on older logs to save space.
- Archive logs to external storage (e.g. S3, GCS).

Pitfall 3: Only Logging API Server Events
Imagine this: You’ve configured audit logging for the API server, but you’re missing logs from other critical
components like kubelets or controllers. This is a common pitfall, leading to gaps in visibility.
Fix: Enable Cluster-Wide Visibility
Step-by-step:
- Kubelet logs: Add --audit-log-* flags to kubelet startup config.
- Controller logs: Enable and route logs via logging agents.
- Aggregate everything using Fluentd/Filebeat → Elasticsearch/Splunk.

Pitfall 4: No Real-Time Alerts
What’s the use of logging something if no one notices in time?
Fix: Connect Logs to Alerting Systems
Step-by-step:
- Ingest logs into Prometheus/ELK/Grafana.
- Set alerts on high-risk events (e.g. failed logins, role changes).
- Build dashboards for visibility.


Pitfall 5: Forgetting to Watch Sensitive Data
If you’re not logging access to secrets or config maps, you’re blind to one of the biggest attack targets.
Fix: Log and Alert on Sensitive Access
Step-by-step:
- Update audit policy to log secrets and configMaps at high verbosity.
- Set alerts for unusual access patterns.
Pitfall 6: Ignoring RBAC Events
A modified role binding can turn a viewer into a cluster-admin, and if you’re not watching, that’s a breach
waiting to happen.
Fix: Monitor RBAC Policy Modifications
Step-by-step:
- Log all changes to RBAC bindings in your audit policy.
- Trigger alerts on RBAC modifications.

Final Thoughts
Audit logs aren’t just a box to tick. They’re critical for detection, incident response, and compliance.
But only if they’re configured properly.
TL;DR: Do This
✅ Capture the right events at the right verbosity.
✅ Rotate, compress, and archive logs.
✅ Monitor everything - not just the API server.
✅ Set real-time alerts for sensitive actions.
✅ Retain logs long enough to be useful.
Kubernetes gives you the tools. It’s up to you to use them right.
Related Resources
Find your Tribe
Membership is by approval only. We'll review your LinkedIn to make sure the Tribe stays community focused, relevant and genuinely useful.
To join, you’ll need to meet these criteria:
> You are not a vendor, consultant, recruiter or salesperson
> You’re a practitioner inside a business (no consultancies)
> You’re based in Australia or New Zealand