Política de auditorías

Esta página 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 siguientes temas:

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 API de Kubernetes sigue una política que se especifica en el marcador --audit-policy-file del comando de kube-apiserver.

Cuando Kubernetes Engine inicia el servidor de API de Kubernetes, proporciona un archivo de política de auditoría cuando establece el valor del marcador --audit-policy-file. 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 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 son verdaderos:

  • El evento no coincide con ninguna regla anterior en el archivo de políticas.
  • La identidad que realiza la llamada está en el grupo de usuario system:nodes.
  • La llamada es una solicitud de update o de patch.
  • La solicitud se encuentra en un recurso de nodes/status o en uno de 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.

  • In 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, los siguientes son los casos especiales:

    • Las solicitudes de actualizaciones y parches realizadas por kubelet, system:node-problem-detector, o system:serviceaccount:kube-system:node-problem-detector en un recurso nodes/status o en un recurso pods/status, se registran en el nivel de solicitud.

    • Las solicitudes de actualizaciones y parches realizadas por cualquier identidad en el grupo system:nodes, en el recurso nodes/status o en el recurso pods/status, se registran en el nivel de solicitud.

    • Las solicitudes deletecollection de system:serviceaccount:kube-system:namespace-controller se registran en el nivel de solicitud.

    • Las solicitudes en un recurso secrets, en un recurso configmaps, o en un recurso tokenreviews se registran en el nivel de metadatos.

  • Ciertas solicitudes no se registran en absoluto. Para obtener una lista definitiva de solicitudes que no están registradas, consulta las reglas level: None en la política de secuencia de comandos. En el momento en el que se redacta este documento, las siguientes son las solicitudes que no se registran:

    • Solicitudes de system:kube-proxy para mirar un recurso de endpoints, recurso de services, o recurso de services/status.

    • Obtén solicitudes de system:unsecured en un recurso configmaps en el espacio de nombres del kube-system.

    • Obtén solicitudes de kubelet en un recurso de nodes, o en un recurso de nodes/status.

    • Obtén solicitudes de cualquier identidad en el grupo de system:nodes, en un recurso de nodes, o en un recurso de nodes/status.

    • Obtén y actualiza solicitudes de system:kube-controller-manager, system:kube-scheduler, o system:serviceaccount:endpoint-controller en un recurso de endpoints en el espacio de nombres de kube-system.

    • Obtén solicitudes de system:apiserver en un recurso de namespaces, en un recurso de namespaces/status, o en un recurso de namespaces/finalize.

    • Obtén y enumera las solicitudes de system:kube-controller-manager en cualquier recurso del grupo metrics.k8s.io.

    • Solicitudes a 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 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 las solicitudes get, list y updateStatus van a tu registro de acceso a datos.

Según la configuración predeterminada, el registro de actividad de administrador está habilitado y no tiene costo adicional.

Según la configuración predeterminada, el registro de acceso a los datos está inhabilitado y habilitarlo puede causar una facturación adicional. Para obtener más información sobre cómo habilitar el registro de acceso a los datos y los costos asociados, consulta Configurar registros de acceso a los datos.

Comprender 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 dice que cualquier solicitud get de kubelet en un recurso de nodes o en un recurso de nodes/status no debe registrarse. Recuerda que un nivel de None significa que no se debe registrar ningún evento que coincida:

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

Después de la lista de reglas de level: None, el archivo de políticas tiene una lista de reglas que son casos especiales. Por ejemplo, aquí hay una regla de casos especiales que dice 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 son verdaderos:

  • El evento no coincide con ninguna regla anterior en el archivo de políticas.
  • La solicitud se encuentra 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, obtienes 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 los eventos que no coinciden con ninguna regla anterior en el archivo de políticas y no se encuentran en la etapa RequestReceived. La regla dice que las solicitudes get, list y watch en cualquier recurso que pertenezca a uno de los grupos listados deben registrarse en el nivel de Request.

La siguiente regla 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 los eventos que no coinciden con ninguna regla anterior en el archivo de políticas y no se encuentran 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 dice que las solicitudes de escritura deben registrarse en el nivel RequestResponse.

¿Qué sigue?

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...