Política de auditoría

Autopilot Estándar

En esta página, se describe la política de registro de auditoría de Google Kubernetes Engine (GKE). Si deseas obtener instrucciones para habilitar y ver los diferentes tipos de registros de auditoría, así como los permisos de IAM necesarios, consulta la Información del registro de auditoría de GKE.

Antes de comenzar

Antes de leer esta página, asegúrate de saber sobre los siguientes temas:

Descripción general

En un clúster de GKE, el servidor de la API de Kubernetes escribe entradas de registro de auditoría en un backend administrado por GKE. A medida que GKE recibe entradas de registro del servidor de la API de Kubernetes, las escribe en el registro de actividad del administrador y el registro de acceso a los datos de tu proyecto.

Hay dos políticas que influyen en lo que ves en los registros de auditoría de tu proyecto:

La política de auditoría de Kubernetes define reglas para los eventos que se registren como entradas de registro. También especifica qué datos deben incluir las entradas del registro.
La política de auditoría de Kubernetes Engine determina qué entradas se escriben en tu registro de actividad de administrador y cuáles se escriben en tu registro de acceso a datos.

Los registros de auditoría que se escriben en el registro de acceso a los datos dependen de la configuración del registro de auditoría. Los registros de acceso a los datos usan los precios de Google Cloud Observability. Los registros de actividad del administrador se ofrecen sin cargo. GKE admite los siguientes tipos de registros de acceso a datos.

ADMIN_READ: operaciones que leen metadatos sobre los recursos de Kubernetes, como enumerar Pods.
DATA_READ: operaciones que leen datos en recursos de Kubernetes, como leer los registros de un Pod.
DATA_WRITE: operaciones que escriben datos en recursos de Kubernetes, como la actualización del estado del Pod.

Para obtener más información, consulta Configura registros de auditoría de acceso a los datos.

Política de auditoría de Kubernetes

El servidor de la API de Kubernetes sigue una política que se especifica en la marca --audit-policy-file del comando kube-apiserver.

Cuando GKE inicia el servidor de la API de Kubernetes, configura el valor de la marca --audit-policy-file para proporcionar un archivo de política de auditoría. En el repositorio de Kubernetes de código abierto, puedes ver la secuencia de comandos de configure-helper.sh que genera el archivo de la política de auditoría. Puedes ver la mayor parte del archivo de políticas de auditoría consultando directamente la secuencia de comandos.

Eventos y etapas

Cuando una persona o componente realiza una solicitud al servidor de API de Kubernetes, la solicitud pasa por una o más etapas:

Etapa	Descripción
RequestReceived	El controlador de auditoría recibió la solicitud.
ResponseStarted	Se enviaron los encabezados de respuesta, pero el cuerpo de respuesta no se ha enviado.
ResponseComplete	El cuerpo de respuesta se completó y no se enviarán más bytes.
Panic	Se produjo un error interno del servidor y la solicitud no se completó.

Cada etapa de una solicitud genera un evento, el cual se procesa de acuerdo con una política. La política especifica si el evento se debe registrar como una entrada de registro y, de ser así, qué datos deben incluirse en la entrada de registro.

Niveles de auditoría

El archivo de política de auditoría de Kubernetes contiene una lista de reglas. En el archivo de políticas, la primera regla que coincide con un evento establece el nivel de auditoría para el evento.

Una regla puede especificar uno de estos niveles de auditoría:

Nivel	Descripción
Ninguno	No crea una entrada de registro para el evento.
Metadatos	Crea una entrada de registro. Incluye metadatos, pero no incluir el cuerpo de solicitud o el cuerpo de respuesta.
Solicitud	Crea una entrada de registro. Incluye los metadatos y el cuerpo de la solicitud, pero no incluye el cuerpo de respuesta.
RequestResponse	Crea una entrada de registro. Incluye los metadatos, el cuerpo de la solicitud y el cuerpo de respuesta.

Este un ejemplo de una regla. Si un evento coincide con la regla, el servidor de la API de Kubernetes crea una entrada de registro en el nivel de Request.

- level: Request
  userGroups: ["system:nodes"]
  verbs: ["update","patch"]
  resources:
    - group: "" # core
      resources: ["nodes/status", "pods/status"]
  omitStages:
    - "RequestReceived"

Un evento coincide con la regla si todos los siguientes enunciados son verdaderos:

El evento no coincide con ninguna regla anterior del archivo de políticas.
La identidad que realiza la llamada está en el grupo de usuarios system:nodes.
La llamada es una solicitud update o una solicitud patch.
La solicitud está en un recurso nodes/status o pods/status.
El evento no es para la etapa RequestReceived de la llamada.

Resumen de la política de auditoría de Kubernetes para clústeres de GKE

En general, las solicitudes de escritura como create, update y delete se registran en el nivel RequestResponse.
En general, los eventos get, list y watch se registran en el nivel Metadata.
Algunos eventos se tratan como casos especiales. Para obtener una lista definitiva de solicitudes que se tratan como casos especiales, consulta la política de secuencia de comandos. En el momento en el que se redacta este documento, estos son los casos especiales:
- Las solicitudes de actualización y aplicación de parches de kubelet, system:node-problem-detector o system:serviceaccount:kube-system:node-problem-detector en un recurso nodes/status o pods/status se registran en el nivel de solicitud.
- Las solicitudes de actualizaciones y parches por cualquier identidad en el grupo system:nodes en un recurso nodes/status o pods/status se registran en el nivel de la solicitud.
- Las solicitudes deletecollection de system:serviceaccount:kube-system:namespace-controller se registran en el nivel de la solicitud.
- Las solicitudes en un recurso secrets, configmaps o tokenreviews se registran en el nivel de metadatos.
Ciertas solicitudes no se registran en absoluto. Para obtener una lista definitiva de las solicitudes que no se registran, consulta las reglas level: None en la secuencia de comandos de la política. En el momento en el que se redacta este documento, estas son las solicitudes que no se registran:
- Solicitudes de system:kube-proxy para ver un recurso endpoints, services o services/status.
- Obtén solicitudes de system:unsecured en un recurso configmaps en el espacio de nombres kube-system.
- Obtén solicitudes de kubelet en un recurso nodes o nodes/status.
- Obtén solicitudes de cualquier identidad en el grupo system:nodes en un recurso nodes o nodes/status.
- Obtén y actualiza solicitudes de system:kube-controller-manager, system:kube-scheduler o system:serviceaccount:endpoint-controller en un recurso endpoints en el espacio de nombres kube-system.
- Obtén solicitudes de system:apiserver en un recurso namespaces, namespaces/status o namespaces/finalize.
- Obtén y enumera las solicitudes de system:kube-controller-manager en cualquier recurso del grupo metrics.k8s.io.
- Solicitudes de URL que coinciden con /healthz*, /version o /swagger*.

Política de auditoría de GKE

A medida que GKE recibe entradas de registro del servidor de la API de Kubernetes, aplica su propia política para determinar qué entradas se escriben en el registro de actividad del administrador de tu proyecto y qué entradas se escriben en el registro de acceso a los datos de tu proyecto.

En su mayor parte, GKE aplica las siguientes reglas para registrar las entradas que provienen del servidor de API de Kubernetes:

Las entradas que representan solicitudes de create, delete y update van a tu registro de actividad de administrador.
Las entradas que representan solicitudes de get, list y updateStatus van a tu registro de acceso a datos.

Para obtener información sobre los precios y qué tipos de registros están habilitados de forma predeterminada, consulta los detalles del registro.

Comprender el archivo de política de auditoría de Kubernetes

Para los clústeres de GKE, el archivo de políticas de auditoría de Kubernetes comienza con reglas que especifican que ciertos eventos no deben registrarse en absoluto. Por ejemplo, esta regla indica que cualquier solicitud get de kubelet en un recurso nodes o nodes/status no debe registrarse. Recuerda que un nivel de None implica que no se debe registrar ningún evento coincidente:

- level: None
  users: ["kubelet"] # legacy kubelet identity
  verbs: ["get"]
  resources:
    - group: "" # core
    resources: ["nodes", "nodes/status"]

Después de la lista de reglas level: None, el archivo de políticas tiene una lista de reglas que son casos especiales. Por ejemplo, esta es una regla de casos especiales que indica que se deben registrar ciertas solicitudes en el nivel de Metadata:

- level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
    omitStages:
      - "RequestReceived"

Un evento coincide con la regla si todos los siguientes enunciados son verdaderos:

El evento no coincide con ninguna regla anterior del archivo de políticas.
La solicitud está en un recurso de tipo secrets, configmaps o tokenreviews.
El evento no es para la etapa RequestReceived de la llamada.

Después de la lista de reglas de casos especiales, el archivo de políticas tiene algunas reglas generales. Para ver las reglas generales en la secuencia de comandos, debes sustituir el valor de known_apis por ${known_apis}. Después de la sustitución, obtendrás una regla como esta:

- level: Request
  verbs: ["get", "list", "watch"]
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

La regla se aplica a eventos que no coinciden con ninguna regla anterior del archivo de política y no están en la etapa RequestReceived. La regla indica que las solicitudes get, list y watch en cualquier recurso que pertenezca a uno de los grupos enumerados se deben registrar en el nivel de Request.

La regla siguiente en el archivo de política se ve así:

- level: RequestResponse
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

La regla se aplica a eventos que no coinciden con ninguna regla anterior del archivo de política y no están en la etapa RequestReceived. En particular, la regla no se aplica a las solicitudes de lectura: get, list y watch. En cambio, la regla se aplica a las solicitudes de escritura como create, update y delete. La regla establece que las solicitudes de escritura deben registrarse en el nivel RequestResponse.