Kubernetes Audit

Kubernetes Audit #

Continuing the Kubernetes article series in a new format.

Kubernetes is a powerful interaction interface via gRPC and REST API, but it requires significant effort to ensure security and protection against unauthorized access. One of the key tools for this is the audit system, which allows you to track all actions in the cluster. In this article, we will cover the basics of configuring audit in Kubernetes, its capabilities, and configuration examples that will help you build an effective audit policy for your cluster.

Table of Contents

• What is Audit
• Audit Policy
• Filtering Parameters
• Logging Levels
• omitStages Stages
• Suppressing System Noise
• Filtering by Users
• Protecting Sensitive Data
• Detailed Logging for Important APIs
• API Server Configuration
• Conclusion
• Bonus: Yandex Cloud Example

What is Audit

Audit in Kubernetes is a mechanism that records all requests to the API server, including access attempts before the authentication stage. This allows tracking both actions of authorized users and any unauthorized or anonymous requests. This approach is essential for timely detection of security incidents, analysis of cluster activity, and meeting regulatory requirements.

Audit events are generated according to a policy described in a configuration file. Each event contains:

• a timestamp.
• a user identifier (if available).
• the requested resource and action.
• the result (success/failure).
• a unique auditID that can be used to trace the chain of calls.

Events themselves can be directed to a file, a remote webhook, or a logging system.

Audit Policy

An audit policy is a YAML file describing a set of rules that determine which events should be logged and with what level of detail. Each rule consists of conditions (filters) and a logging level that defines the amount of information to be saved.

The API server processes the list of rules top-down and applies the first matching rule. If no rule matches, the default behavior or event skip is applied.

Filtering Parameters

Below are the attributes that can be used to configure event filtering:

Parameter	Description	Example Value
level	Detail level	None, Metadata, Request, RequestResponse
users, userGroups	Filtering by user or group	system:serviceaccount:default:my-app
verbs	Operations on resources	get, list, watch, create, update, patch, delete, deletecollection, proxy, redirect, head
resources	Target Kubernetes objects	pods, configmaps
namespaces	Namespace restriction	default, kube-system
nonResourceURLs	Requests to system paths outside API objects	/metrics, /healthz
omitStages	Excluding processing stages	RequestReceived, ResponseStarted, ResponseComplete, Panic

Logging Levels

Value	Description
None	Do not log the event at all
Metadata	Only request metadata is logged (user, resource, verb, etc.)
Request	Metadata and request body are logged. Response is not logged
RequestResponse	Metadata, request body, and response body are logged

omitStages Stages

Stage	Description
RequestReceived	Request received by the API server but not yet processed
ResponseStarted	Response has started being sent to the client
ResponseComplete	Request fully completed
Panic	Request processing ended with a fatal error

Audit Policy Examples

These examples will help you get started with configuring audit in Kubernetes. They cover the main scenarios and allow you to adapt the policy to your needs.

Suppressing System Noise

info

Suppressing system noise allows you to focus only on events that are important for cluster security. This is especially useful for reducing the number of log entries related to internal Kubernetes processes that are not of interest to most users.

Description	Example
Suppressing noise from kube-apiserver Not needed if you want to see all technical requests from the API server itself (e.g., for deep auditing of internal processes). Usually these events are not needed for analyzing user actions.
Suppressing noise from kube-controller-manager Not needed if full auditing of controller operations is required (e.g., for debugging their logic). In most cases, these events only clutter the audit log.
Suppressing noise from kube-scheduler Not needed if you are analyzing the scheduler's operation. For most users, these events are not of interest.
Suppressing noise from kubelet Not needed if auditing of all kubelet and node actions is required. Usually these events are only needed for diagnosing node problems.

Filtering by Users

info

Event filtering by users and groups allows you to focus on actions that matter for cluster security. For example, tracking the use of system groups such as system:masters, which have full access to the cluster.

Description	Example
Logging actions of the system:masters group

Protecting Sensitive Data

Important!

Protecting sensitive data is critical in Kubernetes, especially if you are not using external secrets management solutions such as HashiCorp Vault or Sealed Secrets.

Description	Example
Logging actions with secrets and tokens.

Detailed Logging for Important APIs

Important!

Kubernetes also has plenty of resources that can be used for privilege escalation — for example, role-based policies (RBAC), workload resources (Deployments, Pods), and Admission resources. Logging actions on these resources allows you to track changes and identify potential security threats.

Description	Example
Logging actions on role-based policies. Scenarios: auditing RBAC changes to investigate privilege escalation, detecting unauthorized role and access changes.
Logging actions on workloads. Scenarios: auditing deployment changes, investigating incidents with pod creation/deletion, tracking manual interventions in workloads.
Logging actions on Admission resources. Scenarios: debugging and auditing Admission Webhooks, investigating issues with validation/mutation policies, controlling changes to admission rules.

API Server Configuration

To enable audit, specify the path to the policy file:

--audit-policy-file=/etc/kubernetes/audit-policy.yaml
--audit-log-path=/var/log/kubernetes/audit/audit.log

Note!

Please note that policy configuration files are loaded into the API server only at startup. Therefore, if you change the policy, you will need to restart the API server for the changes to take effect.

Conclusion

Kubernetes audit is a powerful security tool. Proper policy configuration allows you to track actions of users and services, minimize data leaks, and focus on critically important events. The policy examples in this article are a starting point, but audit policies are always written to meet the requirements of your company and infrastructure.

Basic Recommendations

• Suppress system noise (e.g., from internal components)
• Filter by users and groups
• Log only metadata for sensitive data (secrets, tokens)
• Add detailed logging only for important APIs (CRD, Admission, Webhook)
• Decompose policies into modules for easier management
• Use omitStages to reduce log volume
• Regularly review and update the policy as the cluster evolves
• Test the policy on a staging cluster before applying to production
• Use tools for audit analysis and visualization (e.g., ELK Stack, Loki, Grafana)

Bonus: Yandex Cloud Example

The Yandex Cloud policy example is a good starting point for creating your own audit policy.

Description	Example
Logging actions on role-based policies.