Audit logging
Kubernetes provides a powerful and extensible API that serves as the central control point for managing clusters. Every action flows through the Kubernetes API server, whether it is the creation of a Pod, the modification of a deployment, or secrets retrieval. This design makes the API server the authoritative source of truth; however, it also issues a critical challenge: visibility into who did what, when, and from where.
Audit logging addresses the visibility challenge. By enabling audit logs on the API server, administrators can gain a chronological record of all requests that are received by the cluster. The log entries capture such essential details as the requesting user or service account, the action performed, the target resource, and whether the action was permitted or denied. Thus, audit logging provides a comprehensive trail of activity that can be analyzed for operational insights, compliance, and security.
Enable Audit logging
You can enable Kubernetes API server audit logging through the MKE
configuration file, either during or after MKE 4k installation. The function is
controlled by the spec.apiServer.audit
section of the MKE 4k configuration
file, and to enable it you set the spec.apiServer.audit.enabled
parameter to true
.
Example MKE 4k configuration:
spec:
apiServer:
audit:
enabled: false
level: Metadata
logPath: /var/log/mke4/audit/audit.log
maxAge: 30
maxBackup: 10
maxSize: 10
policyFile: /etc/audit_policy.yaml
Configuration fields
Field | Description |
---|---|
enabled | Enables or disables API server audit logging. Default: false |
logPath | Filesystem path where audit logs are written. Default: /var/log/mke4/audit/audit.log MKE 4k strictly enforces the default value, and will reject any attempt to configure a custom log path. |
level | Specifies the audit logging level. Valid values: none , metadata , request .metadata |
ma`xAge | Maximum number of days to retain old audit log files. Default: 30 |
maxBackup | Maximum number of old audit log files to retain. Default: 10 |
maxSize | Maximum size (in MB) of the audit log file before rotation. Default: 10 |
customPolicyYaml | Inline YAML definition of a custom audit policy. If set, overrides the default policy. Default: “” |
policyFile | Filesystem path to the audit policy file used by the API server. Default: /etc/audit_policy.yaml The default file path cannot be changed. You can still provide a custom audit policy using spec.apiServer.audit.customPolicyYaml , however the policyFile path itself is immutable. |
webhookConfigPath | Path to the file containing the webhook configuration backend for sending audit events. Default: “” |
Comparison to MKE 3x Audit Logging
MKE 4k improves on MKE 3x Kubernetes API server audit logging, providing better visibility, flexibility, and control over cluster activity. Key enhancements include:
Metadata
as the default audit levelIn MKE 4k, the API server defaults to level
Metadata
, in alignment with the recommended minimal audit policy that is recommended by Kubernetes. In comparison, the default level for MKE 3x is from MKE-3 isNone
.Configurable audit levels
MKE 4k users can configure the audit log level through the MKE 4k configuration file, under
apiServer.audit.level
. The values that are supported areNone
,Metadata
, andRequest
.To match the audit policy tuning available in MKE 3x, MKE 4k uses a specific audit stage
RequestReceived
, for noise reduction in the audit logs.Support for Custom Audit Policies
MKE 4k adds support for fully customizable audit policies by way of the
customPolicyYaml
field in the API server configuration:apiServer: externalAddress: <load-balancer> audit: enabled: true level: metadata logPath: /var/log/mke4/audit/audit.log customPolicyYaml: | apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: Request
When a custom policy is defined, MKE 4k ignores the default audit policy and instead applies the configuration provided by the user.