Log pod and workload changes at Request or RequestResponse level, secrets and RBAC changes at Metadata, and everything else at Metadata. Without an audit policy file, the API server logs nothing, so deploy monitoring starts with writing one and shipping the output somewhere an attacker cannot edit.
What an audit policy is
Kubernetes documentation defines an audit policy as rules about what events should be recorded and what data they include. Events are compared against the rules in order, and the first matching rule sets the level. The levels are:
| Level | What is recorded |
|---|---|
| None | Nothing for matching events |
| Metadata | Who, when, resource and verb, but no request or response body |
| Request | Metadata plus the request body |
| RequestResponse | Metadata, request body and response body |
You pass the file to kube-apiserver with a flag. The documentation states plainly that if the flag is omitted, no events are logged, and that a policy with zero rules is illegal.
A starter rule set for deploy monitoring
Order matters, because the first match wins. Put specific rules first and a catch all last.
- Workload changes, meaning pods, deployments and similar, at Request level, so you can see which image was set.
- Secrets and ConfigMaps at Metadata only, so values never land in the log.
- RBAC objects such as roles and bindings at Metadata or Request, since changes here are how privileges quietly grow.
- Noisy, low value reads such as health checks at None.
- A final catch all at Metadata.
The documentation's own example uses the same shape: pod changes at RequestResponse, pod log and status at Metadata, a named leader election ConfigMap at None, and a catch all at Metadata. It also shows omitting the RequestReceived stage to cut volume.
Questions the log should answer
After a deploy, you should be able to answer these from the audit trail:
- Who created or changed this workload, and with which identity?
- Which image reference was requested?
- Was a policy warning or denial recorded for it? The admission policy documentation says Audit validation actions add the failure to the audit event.
- Did anyone change a policy, a binding or an exemption in the same window?
If an answer is missing, adjust the policy and test again.
Where the logs go
The API server has two backends out of the box, as the documentation describes: a log backend that writes JSON lines to a file, and a webhook backend that sends events to an external HTTP API. A file on the control plane node is a start, not a destination. Forward events to a store that people who deploy cannot alter, and set retention to match your obligations. The log backend has flags for maximum age and backup count.
Mind the cost
The documentation warns that audit logging increases API server memory use depending on configuration. Request and RequestResponse levels on busy resources create volume. Start narrow, measure, then widen.
Make it routine
Write three or four saved searches, such as new images in production, privilege changes and policy changes, and review them on a schedule. An audit log nobody queries is a record, not a control.
Where Safeguard fits
Safeguard's continuous monitoring tracks findings on your projects after release, and compliance and evidence automation helps you keep records of controls in one place. It does not replace cluster audit logging, which you configure on the API server itself.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what changes between one point in time and the next.
Quick check
Does Kubernetes log API requests by default?
Per the documentation, if no audit policy file is passed to kube-apiserver, no events are logged.
Should I log Secrets at RequestResponse level?
No. That would put secret values into the log. Use Metadata for secrets.
Sources
Last reviewed: 19 October 2026.
