Audit logging

Kubernetes auditing provides a security-relevant chronological set of records documenting the sequence of activities that have affected the system by individual users, administrators or other components of the system. This documentation covers the configuration and usage of these audit logs in the Charmed Distribution of Kubernetes®. For a more detailed description of the motives and methodology behind audit logging in Kubernetes, see the Kubernetes Auditing documentation.

Viewing the log

By default, CDK enables audit logging to files on the kubernetes-master units. The log file is located at /root/cdk/audit/audit.log and is owned by the nominal root user. You can view the log directly by using Juju’s credentials to make an SSH connection:

juju ssh kubernetes-master/0 sudo cat /root/cdk/audit/audit.log

Note that this log is replicated on all kubernetes-master units.

Audit policy configuration

Audit policy defines rules about what events should be recorded and what data they should include. For CDK this is configurable on the kubernetes-master charm using the audit-policy setting.

To view the current policy:

juju config kubernetes-master audit-policy

To set a new audit policy, it is easiest to write the policy to a file. Assuming you have a file named audit-policy.yaml with the following contents:

# Log all requests at the Metadata level.
apiVersion: audit.k8s.io/v1beta1
kind: Policy
rules:
- level: Metadata

You can set the new audit policy like so:

juju config kubernetes-master audit-policy="$(cat audit-policy.yaml)"

For more information about audit policy definitions, please refer to the upstream Kubernetes Audit Policy documentation.

Audit log backend configuration

The audit log backend writes audit events to a file in JSON format. It is configurable in CDK through the use of the api-extra-args config on kubernetes-master.

By default, the log backend is enabled in CDK with the following configuration:

kube-apiserver config value
audit-log-path /root/cdk/audit/audit.log
audit-log-maxsize 100
audit-log-maxbackup 9

You can override the defaults by using api-extra-args. For example:

juju config kubernetes-master api-extra-args="audit-log-path=/root/cdk/my-audit-location audit-log-maxage=30 audit-log-maxsize=200 audit-log-maxbackup=5"

Note: The audit-log-path must be a directory that is writeable by the kube-apiserver snap. Any non-hidden folders in /root, /var/snap/kube-apiserver/current, or /var/snap/kube-apiserver/common should work.

Please refer to the upstream Kubernetes Audit Log Backend documentation for more information about the available options.

Audit webhook backend configuration

The audit webhook backend sends audit events to a remote API, which is assumed to be the same API that the kube-apiserver exposes. This backend is disabled by default in CDK, and is configurable on the kubernetes-master charm via the audit-webhook-config option.

To view the current audit webhook configuration:

juju config kubernetes-master audit-webhook-config

To set a new audit webhook config, it is easiest to write the config to a file. Assuming you have a file named audit-webhook-config.yaml with the following contents:

apiVersion: v1
kind: Config
preferences: {}
clusters:
- name: example-cluster
  cluster:
    server: http://10.1.35.4
users:
- name: example-user
  user:
    username: some-user
    password: some-password
contexts:
- name: example-context
  context:
    cluster: example-cluster
    user: example-user
current-context: example-context

You can set the new audit webhook config with:

juju config kubernetes-master audit-webhook-config=$(cat audit-webhook-config.yaml)

Additional options for the webhook backend can be set by using api-extra-args. For example:

juju config kubernetes-master api-extra-args="audit-webhook-initial-backoff=20s"

Please refer to the upstream Kubernetes Audit Webhook Backend documentation for more information about the audit webhook config format and related options.