Description
File-based auditing requires an output path through --audit-log-path. Audit events can also be sent through a webhook, so an absent file path alone does not mean there are no records. Without a working output destination, tracing who made an API request becomes difficult.
Audit logs support incident response and operational reviews. Configure the destination and verify that records are actually collected and retained.
Potential impact
- API request history may be insufficient during incident investigations.
- Misuse of privileges or configuration changes may be harder to trace.
- Audit and operational record requirements may not be met.
Remediation
- For file output, configure
--audit-log-pathand a writable, persistent location. For webhook output, verify delivery and retention. - Include the logs in collection, retention and monitoring procedures.
- Review the audit policy with the output configuration and confirm that test requests produce records.
Examples
These existing examples compare the log-path argument. Match the old image to the actual cluster version, and separately provide the audit policy and log volume required by that version.
Before
yaml
apiVersion: v1
kind: Pod
metadata:
name: command-demo
spec:
containers:
- name: command-demo-container
image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
command: ["kube-apiserver"]
args: [""]
After
yaml
apiVersion: v1
kind: Pod
metadata:
name: command-demo
spec:
containers:
- name: command-demo-container
image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
command: ["kube-apiserver"]
args: ["--audit-log-path=path/to/log"]
Explanation:
- Before: There is no file output path. Check other audit outputs, such as a webhook.
- After: A file output path is specified. Recording still requires a valid audit policy, write permissions and retention settings.