Concept
Audit logging answers key questions about activity in your cluster:- Who created, modified, or deleted a resource?
- When did the action occur?
- Which namespace was the resource in?
- Where was the request made from?
- What was the response?
- What happened?
Four stages of audit logging
Each request can be recorded at an associated stage:RequestReceived
RequestReceived
Logged when the API server receives the request, before any processing. Useful for tracking when a request was initiated and by whom.
ResponseStarted
ResponseStarted
Logged when the API server starts sending a response (headers only, no body). Indicates the server has begun processing and has enough information to generate a response.
ResponseComplete
ResponseComplete
Logged when the API server finishes sending the full response (including body). Includes the outcome — success or failure — and associated metadata.
Panic
Panic
Logged if the API server encounters an unexpected error or crash while processing a request. Used to capture critical failures that require investigation.
Usage
You can use a log backend or a webhook backend (such as Falco) to enable audit logging. The steps below use the log backend.Create an audit policy file
Only record the events that matter (for example, pod deletions in a specific namespace). Recording all events for every stage generates a large volume of data.
| Level | Description |
|---|---|
None | Do not log events that match this rule |
Metadata | Log request metadata (user, timestamp, resource, verb) but not the request or response body |
Request | Log metadata and request body, but not the response body. Does not apply to non-resource requests |
RequestResponse | Log metadata, request body, and response body. Does not apply to non-resource requests |
/etc/kubernetes/audit-policy.yaml
omitStages— optional; events from these stages are not recordedlevel— mandatoryverbs— optional; when omitted, applies to all verbs (get,list,watch,create,update,patch,delete)pods/log— subresource used bykubectl logs <pod-name>pods/status— subresource used bykubectl get pod <pod-name> -o jsonpath='{.status}'
Enable audit logging in kube-apiserver
Enable audit logging by passing
--audit-policy-file and --audit-log-path flags to kube-apiserver, and mount the required files with volumes and volumeMounts.Additional log backend flags:| Flag | Description |
|---|---|
--audit-policy-file | Path to the audit policy file |
--audit-log-path | File path where audit events are written |
--audit-log-maxage | Maximum number of days to retain old audit log files |
--audit-log-maxbackup | Maximum number of audit log files to retain |
--audit-log-maxsize | Maximum size in megabytes before the log file is rotated |
kube-apiserver.yaml