Política de auditorías

En esta página, se describe la política de registro de auditoría para Google Kubernetes Engine.

Antes de comenzar

Antes de leer este tema, debes familiarizarte con el material de los temas siguientes:

Descripción general

En un clúster de Kubernetes Engine, el servidor de API de Kubernetes escribe las entradas del registro de auditoría en un backend administrado por Kubernetes Engine. A medida que Kubernetes Engine recibe las entradas de registro del servidor de API de Kubernetes, las escribe en el registro de actividad de administrador y el registro de acceso a 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.

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 Kubernetes Engine 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 la 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 no el cuerpo de respuesta.
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 que 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 se crea una entrada de registro para el evento.
Metadatos Crea una entrada de registro. Incluye metadatos, pero no el cuerpo de solicitud ni el de respuesta.
Solicitud Crea una entrada de registro. Incluye los metadatos y el cuerpo de la solicitud, pero no el de respuesta.
RequestResponse Crea una entrada de registro. Incluye los metadatos, el cuerpo de la solicitud y el de la 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 enunciados siguientes 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 Kubernetes Engine

  • 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 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 Kubernetes Engine

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

En su mayor parte, Kubernetes Engine aplica las reglas siguientes para registrar las entradas que provienen del servidor de la 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.

Información sobre el archivo de política de auditoría de Kubernetes

Para los clústeres de Kubernetes Engine, 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 enunciados siguientes 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.

Pasos siguientes