Enable and Analyze Kubernetes Audit Logs - Container Service for Kubernetes

Logging and auditing capabilities

Capability	What it records	Use it to
Cluster auditing	Every request made to the API server, including the requesting user, verb, and outcome	Track who changed what in the cluster; investigate unauthorized access
exec container auditing	Commands run inside a container after an operator or attacker connects via `exec`	Reconstruct attacker activity that the API server audit log cannot capture
Kubernetes Event Center	All cluster events generated by Pods, nodes, and controllers (evictions, image pull failures, etc.)	Detect instability patterns and abnormal user behavior (e.g., regular users running `exec` on production Pods)
Ingress access logs	All HTTP requests handled by the Ingress controller, streamed to standard output	Monitor service traffic; detect malicious requests and DDoS attacks
CoreDNS logs	All DNS queries resolved by CoreDNS	Diagnose slow DNS resolution; identify queries to high-risk domain names

Use cluster auditing

The API server audit log records every request made to the cluster — which user or service account sent it, which resource it targeted, and whether it was allowed. This makes cluster auditing the primary tool for security investigations and compliance reviews.

To collect and analyze audit logs with Simple Log Service, set custom alert rules, or disable cluster auditing, see Work with cluster auditing.

Audit policy

ACK applies the following audit policy to control which events are recorded and at what level of detail.

Audit levels

Level	What is recorded	Applied to
None	Nothing — events matching this rule are not logged	High-volume, low-risk system operations: `kube-proxy` watching endpoints/services, `kubelet` reading nodes, `system:nodes` reading nodes, control plane components updating endpoints, `system:apiserver` reading namespaces, health and version endpoints (`/healthz`, `/version`, `/swagger`), and `events` resources
Metadata	Request metadata only (user, timestamp, resource, verb) — no request or response body	Secrets, ConfigMaps, and token reviews (contain sensitive or binary data); all other requests not matched by a more specific rule
Request	Metadata and request body	Read operations (`get`, `list`, `watch`) on all core API groups
RequestResponse	Metadata, request body, and response body	Write operations on all core API groups, including `autoscaling.alibabacloud.com`

The RequestReceived stage is omitted from all rules. Audit events are generated only after the API server processes a request.

For audit log field descriptions, see audit-k8s-io-v1-Event.

Full audit policy

apiVersion: audit.k8s.io/v1beta1 # This is required.
kind: Policy
# Do not generate audit events for requests in the RequestReceived stage.
omitStages:
- "RequestReceived"
rules:
# Ignore the following requests because the requests are manually identified as high-volume and low-risk.
- level: None
  users: ["system:kube-proxy"]
  verbs: ["watch"]
  resources:
    - group: "" # core
      resources: ["endpoints", "services"]
- level: None
  users: ["system:unsecured"]
  namespaces: ["kube-system"]
  verbs: ["get"]
  resources:
    - group: "" # core
      resources: ["configmaps"]
- level: None
  users: ["kubelet"] # legacy kubelet identity
  verbs: ["get"]
  resources:
    - group: "" # core
      resources: ["nodes"]
- level: None
  userGroups: ["system:nodes"]
  verbs: ["get"]
  resources:
    - group: "" # core
      resources: ["nodes"]
- level: None
  users:
    - system:kube-controller-manager
    - system:kube-scheduler
    - system:serviceaccount:kube-system:endpoint-controller
  verbs: ["get", "update"]
  namespaces: ["kube-system"]
  resources:
    - group: "" # core
      resources: ["endpoints"]
- level: None
  users: ["system:apiserver"]
  verbs: ["get"]
  resources:
    - group: "" # core
      resources: ["namespaces"]
# Do not audit requests that are sent to the following read-only URLs.
- level: None
  nonResourceURLs:
    - /healthz*
    - /version
    - /swagger*
# Do not audit requests generated upon audit events.
- level: None
  resources:
    - group: "" # core
      resources: ["events"]
# Secrets, ConfigMaps, and token reviews can contain sensitive and binary data.
# Therefore, only the metadata of these resources is audited.
- level: Metadata
  resources:
    - group: "" # core
      resources: ["secrets", "configmaps"]
    - group: authentication.k8s.io
      resources: ["tokenreviews"]

- level: Request
  verbs: ["get", "list", "watch"]
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
# The default audit level for known API requests and responses.
- level: RequestResponse
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
    - group: "autoscaling.alibabacloud.com"
# The default audit level for other requests.
- level: Metadata

Audit log annotations

The Kubernetes audit log includes two authorization annotations on each event:

Annotation	What it records
`authorization.k8s.io/decision`	Whether the request was allowed or denied
`authorization.k8s.io/reason`	Why specific API operations were permitted

Enable exec container auditing

When an attacker gains access to a container via kubectl exec, the default API server audit log records only the exec request itself — not the commands the attacker runs inside the container. This gap makes post-incident forensics difficult.

Container internal activity auditing fills this gap by recording the commands executed inside the container after a session starts. With this data, operations engineers can reconstruct attacker activity, identify the scope of lateral movement, and stop further business impact.

Use the Kubernetes Event Center to detect abnormal events

node-problem-detector is a daemon maintained by ACK that monitors each node for hardware and OS-level problems. It generates node events when it detects:

Docker engine hangs
Linux kernel hangs
Outbound traffic exceptions
File descriptor exceptions

node-problem-detector works with kube-eventer to trigger alerts on these events and close the alerting loop.

Beyond node problems, the cluster itself generates events whenever its state changes — for example, when a Pod is evicted or when an image pull fails. The Kubernetes Event Center of Simple Log Service collects all events from across the cluster and provides storage, query, analytics, visualization, and alerting capabilities.

Use the Event Center to identify patterns that affect cluster stability and to surface anomalous user behavior — for example, detecting when regular users run exec to connect to production containers.

For setup and configuration, see Event monitoring.

Enable the Ingress dashboard

ACK Ingress controllers stream all HTTP request log data to standard output, and ACK integrates with Simple Log Service to visualize this data. The Ingress dashboard shows:

Page views (PVs) and unique visitors (UVs)
Inbound and outbound traffic volume
Average request latency
Top URLs by request count

Use the dashboard to understand service traffic patterns and to detect malicious requests or DDoS attacks as early as possible.

For setup instructions, see Ingress Dashboard.

Enable CoreDNS logging

CoreDNS is deployed in ACK clusters and serves as the cluster DNS server. Its log records every DNS query, making it useful for two scenarios:

Slow DNS resolution: identify which queries are taking too long and why
High-risk domain detection: spot queries to known malicious domain names

Simple Log Service provides a pre-built analytical dashboard for CoreDNS logs. For configuration steps, see Collect and analyze CoreDNS logs.