Audit logging in Kubernetes captures detailed records of all API server requests, helping you detect suspicious or unauthorized activities within your cluster. By defining audit policies, you can control which events to log, reducing noise and focusing on critical operations.Documentation Index
Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
Use this file to discover all available pages before exploring further.
Audit logging is disabled by default in Kubernetes. Enabling it requires configuring the API server to use an audit policy and log backend.
Why Audit Logging Matters
- Security: Track changes and identify unauthorized access.
- Compliance: Maintain an immutable record of user actions.
- Troubleshooting: Correlate events with incidents for diagnostics.
Viewing Falco Alerts
Before diving into Kubernetes-native auditing, you might already be using Falco to detect suspicious container activities. For example:Kubernetes API Server Request Stages
Every API request flows through the server in four logical stages. You can choose to log specific stages via your audit policy:| Stage | Description |
|---|---|
| RequestReceived | Recorded immediately upon receipt, before authn/authz. |
| ResponseStarted | Emitted when the server begins processing long-running requests (e.g., watch). |
| ResponseComplete | Logged after the response is sent to the client. |
| Panic | Captures internal server errors or panics during request handling. |
Defining an Audit Policy
An audit policy is a YAML file that specifies which events to include or omit. Start with a minimal policy:omitStages: Skip logging for specified stages (optional).rules: A list of match conditions and thelevelof logging.
Audit Levels
| Level | Captured Data |
|---|---|
| None | Do not log the event. |
| Metadata | Timestamps, user, verb, resource, etc. |
| Request | Metadata + request body. |
| RequestResponse | Metadata + request body + response body. |
Example: Log Pod Deletions in Production
This policy logs only DELETE operations on the Podwebapp-pod in prod-namespace at the full request/response level:
Enabling Audit Logging
To activate auditing, point your API server to the audit policy and log file:kubeadm-based Clusters
Edit the static pod manifest/etc/kubernetes/manifests/kube-apiserver.yaml:
systemd-based API Server
Add the same flags to the service unit file under theExecStart section.
--audit-policy-file: Path to your YAML policy--audit-log-path: Destination for audit logs--audit-log-maxage: Retention days for old logs--audit-log-maxbackup: Number of rotated files to keep--audit-log-maxsize: Max size (MB) before rotation
Verifying Audit Logs
Delete the target Pod to generate an audit entry:delete event for webapp-pod in prod-namespace.
Use
kubectl apply -f audit-policy.yaml to update your policy dynamically and trigger events for testing.