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 4 installation. The function is controlled by the spec.apiServer.audit section of the MKE 4 configuration file, and to enable it you set the spec.apiServer.audit.enabled parameter to true.

Example MKE 4 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 4 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
maxAge	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 4 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 level

  In MKE 4, 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 is None.

• Configurable audit levels

  MKE 4 users can configure the audit log level through the MKE 4 configuration file, under apiServer.audit.level. The values that are supported are None, Metadata, and Request.

  To match the audit policy tuning available in MKE 3x, MKE 4 uses a specific audit stage RequestReceived, for noise reduction in the audit logs.

• Support for Custom Audit Policies

  MKE 4 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 4 ignores the default audit policy and instead applies the configuration provided by the user.