VK Cloud logo

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.

Audit policy structure

Following is the full file with audit policy settings for second-generation Kubernetes clusters.

Here:

  • The omitStages block specifies the stages of processing requests to the Kubernetes API that do not need to be logged:

    • RequestReceived — receiving a request
    • ResponseStarted — 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 rules block 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.

Which events get logged into the audit log

  • All change requests (create, update, patch, delete) at the RequestResponse level:

    • 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.
  • All requests to sensitive resources (secrets, configmaps, serviceaccounts/token, tokenreviews) at the Metadata level.

  • Read requests (get, list, watch) at the Metadata level for most of the resources that are not covered by other rules.

  • All other change requests (create, update, patch, delete) at the Request level for the resources that are not covered by other rules.

Which events are excluded from the audit log

  • watch requests for the endpoints, services, and services/status resources from the kube-proxy system user.

  • get requests for the nodes, nodes/status resources 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 the system:apiserver user.

  • Any events of the specialized events and leases resources, as well as the tiers resources for the Calico service accounts.

  • Updates of the configmaps and endpoints resources in the kube-system namespace for the cluster-autoscaler user.