Cluster audit policy
In Cloud Containers, an audit policy is configured for second-generation Kubernetes clusters you create. This policy determines which Kubernetes API events in the cluster and to what extent are logged into the Cloud Audit service on the VK Cloud platform. This audit policy is configured for all clusters you create in the Cloud Containers service, and you cannot change it.
The audit policy helps to:
- Ensure that clusters meet the configured security requirements.
- Monitor cluster activities, errors, and attempts to gain unauthorized access.
- Prevent and investigate security incidents in clusters.
The audit policy defines the rules that all events in the cluster go through one by one. If an event fits a rule, it is applied. Whether the event gets logged depends on the configured audit level and additional settings.
Following is the full file with audit policy settings for second-generation Kubernetes clusters.
Here:
-
The
omitStagesblock specifies the stages of processing requests to the Kubernetes API that do not need to be logged:RequestReceived— receiving a requestResponseStarted— starting to form the response
This helps to reduce the amount of logs, as these stages do not contain critical information for audit purposes.
-
The
rulesblock contains specific rules of the audit policy. For each rule, the following is configured:-
level— The audit level. This is the level of detail with which Kubernetes must log events:None— The specified resources and events are excluded from the audit and are not logged.Metadata— Only the request metadata is logged (for example, username, time, resource type, method), but not the contents of the resource (for example, the contents of the secret, token, configuration).Request— The entire request is logged, but not the response.RequestResponse— Both the request and the response are logged, meaning a full audit of the events is performed.
-
users,userGroups— The user or group of users the rule is defined for. -
verbs— Operations (watch,create,update,patch,delete) on a user or group of users that, depending on the level, need or do not need to be logged. For more details on these operations, refer to the official Kubernetes documentation. -
resources— Cluster resources the rule is applied to.
-
-
All change requests (
create,update,patch,delete) at theRequestResponselevel:- For all requests from anonymous users
system:anonymous. - For all requests to change the resources listed in the rule that are not covered by other rules.
- For all requests from anonymous users
-
All requests to sensitive resources (
secrets,configmaps,serviceaccounts/token,tokenreviews) at theMetadatalevel. -
Read requests (
get,list,watch) at theMetadatalevel for most of the resources that are not covered by other rules. -
All other change requests (
create,update,patch,delete) at theRequestlevel for the resources that are not covered by other rules.
-
watchrequests for theendpoints,services, andservices/statusresources from thekube-proxysystem user. -
getrequests for thenodes,nodes/statusresources from the kubelet services. -
Bulk read requests (
get,list,watch) for the following system components and service accounts:system:nodes;system:serviceaccounts;calico-node;calico-kube-controllers;system:kube-controller-manager;system:kube-scheduler;cluster-autoscaler;system:serviceaccounts:monitoring;csi-cinder-controller-sa.
This approach helps to significantly reduce the amount of logs.
-
Read requests (
get,list,watch) for special Kubernetes API endpoints:healthz,livez,version,swagger. These endpoints are designed to check the status of the API server itself, not to work with cluster resources. -
Read requests (
get,list,watch) for the API server events from thesystem:apiserveruser. -
Any events of the specialized
eventsandleasesresources, as well as thetiersresources for the Calico service accounts. -
Updates of the
configmapsandendpointsresources in thekube-systemnamespace for thecluster-autoscaleruser.