Audit Logging: KCSA practice questions

Kubernetes auditing produces a chronological, security-relevant record of actions in the cluster, covering activity by users, by applications that use the Kubernetes API, and by the control plane itself. It lets an administrator answer what happened, when, who initiated it, on which object, where it was observed and from where it came. Audit records start inside the kube-apiserver: every request generates audit events at each stage of its execution, the events are filtered by a policy, and the result is written to a backend.

The stages are RequestReceived (as soon as the audit handler gets the request), ResponseStarted (headers sent, only for long-running requests such as watch), ResponseComplete (body finished) and Panic. The policy file, written in the audit.k8s.io API group, is a list of rules evaluated in order, and the first rule that matches an event decides its audit level. There are four levels. None records nothing. Metadata records the requesting user, timestamp, resource and verb but no bodies. Request adds the request body. RequestResponse adds both request and response bodies. A rule can narrow its match by users, userGroups, verbs, resources, namespaces and nonResourceURLs, and omitStages drops events for chosen stages; an empty list in a field means every value. To cover everything in one namespace, a rule lists that namespace in its namespaces field.

Enabling auditing takes kube-apiserver flags. --audit-policy-file points to the policy; without it no events are logged, and a policy with zero rules is invalid. For the log backend, --audit-log-path sets the file the events are written to in JSON lines format (a dash means standard out), and --audit-log-maxage, --audit-log-maxbackup and --audit-log-maxsize control retention and rotation. When the API server runs as a static Pod, as it does in kubeadm clusters, the policy file and the log directory must also be mounted into the Pod with hostPath volumes, or the records will not persist. The alternative webhook backend sends events to a remote API configured with --audit-webhook-config-file.

Choosing levels is a trade-off. Auditing increases API server memory use because context is kept for each request, and logging full response bodies at RequestResponse level for every resource makes logs very large. There is also a confidentiality angle: logging Secret or ConfigMap changes at Request or RequestResponse level would copy their contents into the audit log, which is why the example policy in the documentation logs Secret and ConfigMap changes outside kube-system at Metadata level.