Auditing [page]deterministic
Kubernetes _auditing_ provides a security-relevant, chronological set of records documenting the sequence of actions in a cluster. The cluster audits the activities generated by users, by applications that use the Kubernetes API, and by the control plane itself.
Auditing allows cluster administrators to answer the following questions:
- what happened? - when did it happen? - who initiated it? - on what did it happen? - where was it observed? - from where was it initiated? - to where was it going?
Audit records begin their lifecycle inside the [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) component. Each request on each stage of its execution generates an audit event, which is then pre-processed according to a certain policy and written to a backend. The policy determines what's recorded and the backends persist the records. The current backend implementations include logs files and webhooks.
Each request can be recorded with an associated _stage_. The defined stages are:
- `RequestReceived` - The stage for events generated as soon as the audit handler receives the request, and before it is delegated down the handler chain.
- `ResponseStarted` - Once the response headers are sent, but before the response body is sent. This stage is only generated for long-running requests (e.g. watch).
- `ResponseComplete` - The response body has been completed and no more bytes will be sent.
- `Panic` - Events generated when a panic occurred.
> Note: The configuration of an [Audit Event configuration](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) is different from the [Event](/docs/reference/generated/kubernetes-api//#event-v1-core) API object.
The audit logging feature increases the memory consumption of the API server because some context required for auditing is stored for each request. Memory consumption depends on the audit logging configuration.
## Audit policy
Audit policy defines rules about what events should be recorded and what data they should include. The audit policy object structure is defined in the [`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy). When an event is processed, it's compared against the list of rules in order. The first matching rule sets the _audit level_ of the event. The defined audit levels are:
- `None` - don't log events that match this rule.
- `Metadata` - log events with metadata (requesting user, timestamp, resource, verb, etc.) but not request or response body.
- `Request` - log events with request metadata and body but not response body. This does not apply for non-resource requests.
- `RequestResponse` - log events with request metadata, request body and response body. This does not apply for non-resource requests.
You can pass a file with the policy to `kube-apiserver` using the `--audit-policy-file` flag. If the flag is omitted, no events are logged. Note that the `rules` field __must__ be provided in the audit policy file. A policy with no (0) rules is treated as illegal.
Below is an example audit policy file:
You can use a minimal audit policy file to log all requests at the `Metadata` level:
```yaml # Log all requests at the Metadata level. apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: Metadata ```
If you're crafting your own audit profile, you can use the audit profile for Google Container-Optimized OS as a starting point. You can check the [configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh) script, which generates an audit policy file. You can see most of the audit policy file by looking directly at the script.
You can also refer to the [`Policy` configuration reference](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) for details about the fields defined.
## Audit backends
Audit backends persist audit events to an external storage. Out of the box …(trimmed)