Es posible que parte de la información de esta página (o toda) no se aplique a Trusted Cloud de S3NS.

Esta página se ha traducido con Cloud Translation API.

Política de auditoría

Autopilot Standard

En esta página se ofrece una descripción general de la política de registro de auditoría de Google Kubernetes Engine (GKE). En esta página se explica cómo captura y registra GKE los eventos de tu clúster, los factores que influyen en la información que se registra, dónde se almacena esa información y las políticas que influyen en lo que ves en tus registros de auditoría.

Para obtener instrucciones sobre cómo habilitar y ver los distintos tipos de registros de auditoría, así como los permisos de gestión de identidades y accesos necesarios, consulta la información sobre el registro de auditoría de GKE.

Esta página está dirigida a especialistas en seguridad que quieran obtener información valiosa sobre las actividades que se producen en sus clústeres para monitorizar las amenazas de seguridad, hacer un seguimiento de los cambios y solucionar problemas. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Trusted Cloud by S3NS

Antes de leer esta página, asegúrate de que conoces estos temas:

Información general sobre las políticas de auditoría

En un clúster de GKE, el servidor de la API de Kubernetes escribe entradas de registro de auditoría en un backend gestionado por GKE. Cuando GKE recibe entradas de registro del servidor de la API de Kubernetes, las escribe en el registro de actividad de administración y en 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 las reglas de los eventos que se registran como entradas de registro. También especifica qué datos deben incluir las entradas de registro.
La política de auditoría de GKE determina qué entradas se escriben en el registro de actividad de administración y cuáles en el registro de acceso a los datos.

Los registros de auditoría que se escriben en tu registro de acceso a datos dependen de la configuración de los registros de auditoría. Los registros de acceso a datos usan los precios de Google Cloud Observability. Los registros de actividad de administración se ofrecen sin coste económico. GKE admite los siguientes tipos de registros de acceso a datos.

ADMIN_READ: operaciones que leen metadatos sobre recursos de Kubernetes, como listar 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 de los pods.

Para obtener más información, consulta el artículo sobre cómo configurar registros de auditoría de acceso a datos.

Política de auditoría de Kubernetes

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

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

Eventos y fases

Cuando una persona o un componente envía una solicitud al servidor de la API de Kubernetes, la solicitud pasa por una o varias fases:

Fase	Descripción
RequestReceived	El controlador de auditoría ha recibido la solicitud.
ResponseStarted	Se han enviado los encabezados de respuesta, pero no el cuerpo de la respuesta.
ResponseComplete	El cuerpo de la respuesta se ha completado y no se enviarán más bytes.
Panic	Se ha producido un error de servidor interno y no se ha completado la solicitud.

Cada fase 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, si es así, qué datos se deben incluir 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 coincida con un evento define el nivel de auditoría del 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 la solicitud ni el de la respuesta.
Solicitud	Crea una entrada de registro. Incluye los metadatos y el cuerpo de la solicitud, pero no el cuerpo de la respuesta.
RequestResponse	Crea una entrada de registro. Incluye metadatos, el cuerpo de la solicitud y el cuerpo de la respuesta.

Aquí tienes un ejemplo de regla. Si un evento coincide con la regla, el servidor de la API de Kubernetes crea una entrada de registro en el nivel 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 se cumplen todas las condiciones siguientes:

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 patch.
La solicitud se refiere a un recurso nodes/status o a un recurso pods/status.
El evento no es para la fase RequestReceived de la llamada.

Política de auditoría de GKE

Cuando 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 de administración de tu proyecto y cuáles se escriben en el registro de acceso a los datos de tu proyecto.

Por lo general, GKE aplica las siguientes reglas a las entradas de registro que proceden del servidor de la API de Kubernetes:

Las entradas que representan solicitudes create, delete y update se registran en el registro de actividad de administrador.
Las entradas que representan solicitudes get, list y updateStatus se registran en el registro de acceso a datos.

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

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

En los clústeres de GKE, el archivo de política de auditoría de Kubernetes empieza con reglas que especifican que no se deben registrar determinados eventos. Por ejemplo, esta regla indica que no se debe registrar ninguna solicitud get de kubelet en un recurso nodes o nodes/status. Recuerda que un nivel de None significa 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 de level: None, el archivo de política tiene una lista de reglas que son casos especiales. Por ejemplo, a continuación se muestra una regla de caso especial que indica que se deben registrar determinadas solicitudes en el nivel Metadata:

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

Un evento coincide con la regla si se cumplen todas las condiciones siguientes:

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

Después de la lista de reglas de casos especiales, el archivo de política 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 los eventos que no coinciden con ninguna regla anterior del archivo de política y que no están en la fase RequestReceived. La regla indica que las solicitudes get, list y watch en cualquier recurso que pertenezca a uno de los grupos indicados se deben registrar en el nivel Request.

La siguiente regla del archivo de política tiene este aspecto:

- 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 del archivo de política y que no están en la fase RequestReceived. En concreto, la regla no se aplica a las solicitudes de lectura: get, list y watch. En su lugar, la regla se aplica a las solicitudes de escritura, como create, update y delete. La regla indica que las solicitudes de escritura se deben registrar en el nivel RequestResponse.

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

En la siguiente lista se resumen las políticas de auditoría de Kubernetes para los clústeres de GKE:

En general, las solicitudes de escritura como create, update y delete se registran en el nivel RequestResponse.
Por lo general, los eventos get, list y watch se registran en el nivel Metadata.
Algunos eventos se tratan como casos especiales. Para ver una lista definitiva de las solicitudes que se tratan como casos especiales, consulta el script de la política. Entre los casos especiales se incluyen los siguientes:
- Las solicitudes de actualización y de 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 a nivel de solicitud.
- Las solicitudes de actualización y de aplicación de parches de cualquier identidad del grupo system:nodes en un recurso nodes/status o en un recurso pods/status se registran a nivel de solicitud.
- Las solicitudes deletecollection de system:serviceaccount:kube-system:namespace-controller se registran a nivel de solicitud.
- Las solicitudes de un recurso secrets, un recurso configmaps o un recurso tokenreviews se registran a nivel de metadatos.
Algunas solicitudes no se registran. Para ver una lista definitiva de las solicitudes que no se registran, consulta las reglas level: None en la secuencia de comandos de la política. No se registran las siguientes solicitudes:
- Solicitudes de system:kube-proxy para ver un recurso endpoints, un recurso services o un recurso services/status.
- Obtiene solicitudes por system:unsecured en un recurso configmaps del espacio de nombres kube-system.
- Obtiene solicitudes de kubelet en un recurso nodes o en un recurso nodes/status.
- Obtener solicitudes de cualquier identidad del grupo system:nodes en un recurso nodes o en un recurso nodes/status.
- Obtener y actualizar solicitudes por system:kube-controller-manager, system:kube-scheduler o system:serviceaccount:endpoint-controller en un recurso endpoints del espacio de nombres kube-system.
- Obtiene solicitudes por system:apiserver en un recurso namespaces, un recurso namespaces/status o un recurso namespaces/finalize.
- Obtener y enumerar solicitudes de system:kube-controller-manager en cualquier recurso del grupo metrics.k8s.io.
- Solicitudes a URLs que coincidan con /healthz*, /version o /swagger*.