Kubernetes Audit Logs: Threat Detection Guide
Turn Kubernetes audit logs into detections for privilege abuse, secret access, persistence, risky exec, and control-plane compromise.

The Kubernetes API server is the control plane’s front door. Every deployment, secret read, role binding and interactive exec passes through it. Kubernetes audit logs preserve the sequence needed to answer who did what, where and when.
Raw audit volume is not a detection program. Teams need a deliberate policy, safe handling of sensitive fields and analytics tied to cluster identity and workload risk.
What Kubernetes Auditing Provides
The official Kubernetes auditing documentation defines a chronological record of actions by users, applications and the control plane. Events can be recorded at:
- Metadata: actor, verb, resource and timing without bodies;
- Request: metadata and request body;
- RequestResponse: request and response bodies;
- None: excluded events.
Request bodies can contain secrets or personal data. Use the minimum level required and protect the backend accordingly.
Design an Audit Policy
Start with broad Metadata coverage and suppress only well-understood high-volume noise. Increase detail selectively for high-risk changes such as role bindings, admission configuration or critical namespaces.
Ensure coverage for:
- authentication and authorization failures;
- secrets access and changes;
- role and cluster-role bindings;
- service accounts and token-related resources;
- exec, attach and port-forward;
- webhook and admission changes;
- workload creation with privileged settings;
- changes to audit or security controls.
Send logs to a remote, access-controlled backend so a cluster compromise cannot easily erase them.
High-Signal Detection Patterns
Privilege escalation
Alert on new cluster-admin bindings, wildcard permissions, privileged pods, hostPath mounts, host namespaces and unexpected service-account use.
Secret access
Detect list or get operations across many secrets, access from a new identity and reads outside the workload’s normal namespace.
Interactive access
Monitor exec or attach into production containers, especially from unusual users, IPs or times. Join with the command and runtime telemetry when available.
Persistence
Watch new admission webhooks, daemon sets, cron jobs, service accounts, tokens and workloads in system namespaces.
Defense evasion
Alert on deletion of security agents, logging changes, webhook removal and attempts to access audit configuration.
Enrich the Audit Event
Map user and service-account identity to team, privilege and normal namespaces. Add source IP reputation, device or VPN context and workload criticality. Resolve image digests and attach signature, provenance, SBOM and vulnerability status.
An admin creating a role during an approved change window differs from a dormant service account granting cluster-admin from a low-reputation IP.
Correlate Control Plane and Runtime
Audit logs show requested control-plane actions. Runtime tools show what processes, files and sockets did afterward. Link:
- pod creation to image execution;
- exec request to spawned shell;
- secret read to outbound connection;
- role binding to later privileged changes;
- deployment update to a new image digest.
This correlation with eBPF runtime security turns configuration anomalies into incident narratives.
Incident Response
Preserve audit events in original order and identify the first malicious request. Revoke affected credentials, remove unauthorized resources and isolate workloads while retaining evidence. Review all actions by the identity and source IP, not only the alerting verb.
Compare live state with infrastructure-as-code and verify image digests. Search other clusters for the same identity, IP, user agent and resource pattern.
Metrics
Track clusters with auditing enabled, policy coverage, ingestion delay, dropped events, sensitive-body exposure, detections by tactic, false positives and time to reconstruct a control-plane incident. Test alerts with controlled exercises.
Conclusion
Kubernetes audit logs are the authoritative story of API activity. Collect the right detail, enrich identity and correlate with runtime evidence. Combine them with cloud control-plane attack guidance so a dangerous API request becomes an early containment opportunity.
Frequently asked questions
- What do Kubernetes audit logs record?
- They record security-relevant requests handled by the API server, including who performed an action, from where, on which resource, with which verb, and at what stage.
- Which Kubernetes audit level should a production cluster use?
- There is no universal level. Metadata is a safe baseline for broad coverage, while Request or RequestResponse should be limited to selected resources because bodies can contain sensitive data and increase cost.
- Can audit logs detect activity inside a container?
- Only when that activity uses the Kubernetes API, such as exec or resource changes. Process, file, and network behavior inside the workload requires runtime or endpoint telemetry.
Related articles
eBPF Runtime Security for KubernetesUse eBPF runtime security to observe processes, files, privileges, and network activity in Kubernetes while controlling noise and enforcement risk.
- isMalicious vs OpenCTI: Why This Is the Wrong Comparison (and How They Work Together)
OpenCTI is a threat intelligence platform and knowledge graph. isMalicious is a data provider that feeds it. Teams searching for an OpenCTI alternative usually need a feed, not a replacement TIP.
- isMalicious vs MISP: Why This Is the Wrong Comparison (and What to Compare Instead)
MISP is where you store and share indicators. isMalicious is where indicators come from. Teams searching for a MISP alternative are usually looking for a feed, not a replacement platform.
Protect Your Infrastructure
Check any IP or domain against our threat intelligence database with indexed records.
Try the IP / Domain Checker