Verificar la integridad de las VMs del plano de control de GKE


Puedes verificar la integridad de la imagen de máquina virtual (VM) de Compute Engine que usa Google Kubernetes Engine (GKE) para las VMs del plano de control. En esta página se proporcionan instrucciones para un equipo de seguridad que monitoriza los registros del plano de control para verificar lo siguiente:

  • La VM del plano de control se ha iniciado con firmware auténtico y otro software de arranque que se ha verificado criptográficamente mediante el arranque seguro y la monitorización de integridad.
  • La VM del plano de control se ha iniciado desde una imagen auténtica del SO de GKE.

También puedes realizar esta verificación en las imágenes del SO y la integridad del arranque de tus nodos.

En esta página se describe una parte de un conjunto de funciones opcionales del plano de control de GKE que te permiten realizar tareas como verificar el estado de seguridad del plano de control o configurar el cifrado y la firma de credenciales en el plano de control mediante claves que tú gestionas. Para obtener más información, consulta el artículo Acerca de la autoridad del plano de control de GKE.

De forma predeterminada, Google Cloud aplica varias medidas de seguridad al plano de control gestionado. En esta página se describen las funciones opcionales que le ofrecen más visibilidad o control sobre el plano de control de GKE.

Acerca de la verificación de la integridad de las VMs

De forma predeterminada, todas las instancias del plano de control de GKE son VMs blindadas, que son VMs reforzadas que usan funciones de seguridad como el arranque seguro y medido, un módulo de plataforma segura virtual (vTPM) y firmware UEFI. Todos los nodos de GKE también habilitan la monitorización de integridad, que valida la secuencia de arranque de cada VM blindada con una secuencia de arranque "correcta" de referencia. Esta validación devuelve resultados de éxito o de error para cada fase de la secuencia de arranque y añade esos resultados a Cloud Logging. La monitorización de la integridad está habilitada de forma predeterminada en todos los clústeres de GKE y valida las siguientes fases:

  • Secuencia de arranque temprana: desde que se inicia el firmware de UEFI hasta que el bootloader toma el control. Se añade a los registros de la VM como earlyBootReportEvent.
  • Secuencia de arranque tardío: desde que el bootloader toma el control hasta que lo toma el kernel del sistema operativo. Se ha añadido a los registros de la VM como lateBootReportEvent.

GKE también añade registros de creación de VMs del plano de control a Logging. Estos registros contienen metadatos que identifican la máquina e incluyen detalles sobre la imagen de la VM y la secuencia de arranque. Google Cloud publica una atestación de resumen de verificación (VSA) para cada imagen de VM del plano de control de GKE en el repositorio gke-vsa de GitHub. La VSA usa el framework in-toto para las atestaciones. Puede validar los registros de la VM del plano de control de sus clústeres comparándolos con las VSAs correspondientes para verificar que los nodos del plano de control se han iniciado correctamente.

Realizar estas validaciones puede ayudarte a conseguir los siguientes objetivos:

  • Asegúrate de que el software del plano de control esté protegido por el arranque seguro y la monitorización de la integridad, coincida con el código fuente previsto y sea exactamente igual que la imagen que usan otros clientes de Google Cloud .
  • Aumentar tu confianza en cómo protege GKE el plano de control.

Precios

Esta función se ofrece sin coste adicional en GKE.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
  • Habilitar la API de Google Kubernetes Engine
  • Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.
  • Enable the Cloud Logging API.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

  • Asegúrate de que ya tienes un clúster en modo Autopilot o Estándar de GKE que ejecute la versión 1.29 o posterior.

Roles obligatorios

Para obtener los permisos que necesitas para verificar la integridad de la VM del plano de control, pide a tu administrador que te conceda las siguientes funciones de gestión de identidades y accesos en tu proyecto:

Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.

También puedes conseguir los permisos necesarios a través de roles personalizados u otros roles predefinidos.

Comprobar si se han producido errores en las fases de la secuencia de arranque

La supervisión de integridad añade un registro a Logging si una VM del plano de control falla o completa correctamente una fase de la secuencia de arranque. Para ver los eventos de arranque fallidos, ejecuta los siguientes comandos:

  1. En la Google Cloud consola, ve a la página Explorador de registros:

    Ir a Explorador de registros

  2. En el campo Consulta, especifica la siguiente consulta:

    jsonPayload.@type="type.googleapis.com/cloud_integrity.IntegrityEvent"
    jsonPayload.earlyBootReportEvent.policyEvaluationPassed="false" OR jsonPayload.lateBootReportEvent.policyEvaluationPassed="false"
    jsonPayload.metadata.isKubernetesControlPlaneVM="true"
    

    También puedes comprobar si se han producido eventos de arranque correctamente sustituyendo false por true en esta consulta.

  3. Haz clic en Realizar una consulta. Si no ves ningún resultado, significa que las VMs del plano de control han superado todas las comprobaciones de monitorización de la integridad. Si ves un resultado, ve al siguiente paso para identificar el clúster correspondiente.

  4. En el registro de integridad de arranque fallido, copie el valor del campo resource.labels.instance_id.

  5. En el campo Consulta, especifica la siguiente consulta:

    protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog"
    protoPayload.metadata.isKubernetesControlPlaneVM="true"
    resource.labels.instance_id="INSTANCE_ID"
    protoPayload.methodName="v1.compute.instances.insert"
    

    Sustituye INSTANCE_ID por el valor del campo instance_id del paso anterior.

  6. Haz clic en Realizar una consulta. El valor del campo protoPayload.metadata.parentResource.parentResourceId es el ID del clúster de GKE.

  7. Busca el nombre del clúster de GKE:

    gcloud asset query \
        --organization=ORGANIZATION_ID \
        --statement="SELECT name FROM container_googleapis_com_Cluster WHERE resource.data.id='CLUSTER_ID';"
    

    Haz los cambios siguientes:

    • ORGANIZATION_ID: el ID numérico de tu Google Cloud organización.
    • CLUSTER_ID: el valor del campo protoPayload.metadata.parentResource.parentResourceId del paso anterior.

    El resultado debería ser similar al siguiente:

    # lines omitted for clarity
    //container.googleapis.com/projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME
    

    Este resultado tiene los siguientes campos:

    • PROJECT_ID: tu ID de proyecto Google Cloud .
    • LOCATION: la ubicación del clúster.
    • CLUSTER_NAME: el nombre del clúster.

Buscar e inspeccionar los registros de la VM del plano de control

Los registros de creación de VMs de Compute Engine que corresponden a los clústeres de GKE se almacenan en el _Defaultsegmento de registro. Para encontrar los registros de creación de las VMs del plano de control de tu clúster y recuperar estos metadatos, haz lo siguiente:

  1. En la Google Cloud consola, ve a la página Explorador de registros:

    Ir a Explorador de registros

  2. En el campo Consulta, especifica la siguiente consulta:

    resource.type="gce_instance"
    protoPayload.methodName="v1.compute.instances.insert"
    protoPayload.metadata.isKubernetesControlPlaneVM="true"
    
  3. Haz clic en Realizar una consulta. Si no ves resultados, comprueba que cumples todos los requisitos de la sección Antes de empezar.

  4. En los resultados de la consulta, comprueba el campo metadata. La salida es similar a la siguiente:

    # fields omitted for clarity
    "metadata": {
      "usedResources": {
        "attachedDisks": [
          {
            "sourceImageId": "9046093115864736653",
            "sourceImage": "https://www.googleapis.com/compute/v1/projects/1234567890/global/images/gke-1302-gke1627000-cos-113-18244-85-49-c-pre",
            "isBootDisk": true
          }
    # fields omitted for clarity
    

    El campo metadata incluye la siguiente información:

    • usedResources: la lista de recursos utilizados para crear la máquina virtual.
    • attachedDisks: el disco de arranque de la VM.
    • sourceImageId: el ID único de la imagen de VM.
    • sourceImage: la URL de la imagen de VM de origen. La sintaxis del valor de este campo es https://www.googleapis.com/compute/v1/projects/PROJECT_NUMBER/global/images/IMAGE_NAME, donde PROJECT_NUMBER es el número del proyecto propiedad deGoogle Cloudque aloja las VMs del plano de control y IMAGE_NAME es el nombre de la imagen que se ha usado para arrancar la VM.
    • isBootDisk: identificador booleano que indica si este disco se ha usado como disco de arranque de la VM.

Buscar y verificar el VSA de las imágenes de VM del plano de control

En esta sección, encontrarás el VSA que corresponde a la imagen de VM de tu plano de control en el repositorio gke-vsa de GitHub. Después, usa una herramienta llamada slsa-verifier proporcionada por el framework Supply chain Levels for Software Artifacts (SLSA) para verificar la VSA. Necesitas los siguientes datos del registro de creación de la VM del plano de control:

  • ID de la imagen de VM
  • El número de proyecto del proyecto propiedad de Google Cloudque aloja las VMs
  • El nombre de la imagen del SO que se usó para arrancar la VM.

El archivo que corresponde a tu VM del plano de control tiene el siguiente formato de nombre de archivo:

IMAGE_NAME:IMAGE_ID.intoto.jsonl

Haz los cambios siguientes:

  • IMAGE_NAME: el nombre de la imagen de VM, que es la cadena después de /images/ en el campo attachedDisks.sourceImage del registro de auditoría de VM de la sección anterior. Por ejemplo, gke-1302-gke1627000-cos-113-18244-85-49-c-pre.
  • IMAGE_ID: el ID de la imagen de la VM, que es el valor del campo attachedDisks.sourceImageId del registro de auditoría de la VM de la sección anterior. Por ejemplo, 9046093115864736653.

Para encontrar y verificar el archivo de VSA cuando sepas su nombre, sigue estos pasos:

  1. Abre el gke-vsarepositorio de GitHub.
  2. En el directorio "gke-master-images", busca el archivo que corresponda a tu imagen de máquina virtual. Por ejemplo: https://github.com/GoogleCloudPlatform/gke-vsa/blob/main/gke-master-images:78064567238/IMAGE_NAME:IMAGE_ID.intoto.jsonl
  3. Descarga el archivo VSA.
  4. Instala la herramienta slsa-verifier.
  5. Guarda la clave pública para verificar el VSA en un archivo llamado vsa_signing_public_key:

    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEeGa6ZCZn0q6WpaUwJrSk+PPYEsca
    3Xkk3UrxvbQtoZzTmq0zIYq+4QQl0YBedSyy+XcwAMaUWTouTrB05WhYtg==
    -----END PUBLIC KEY-----
    

  6. Verifica la VSA:

    slsa-verifier verify-vsa \
        --attestation-path=PATH_TO_VSA_FILE \
        --resource-uri=gce_image://gke-master-images:IMAGE_NAME \
        --subject-digest=gce_image_id:IMAGE_ID\
        --verifier-id=https://bcid.corp.google.com/verifier/bcid_package_enforcer/v0.1 \
        --verified-level=BCID_L1 \
        --verified-level=SLSA_BUILD_LEVEL_2 \
        --public-key-path=PATH_TO_PUBLIC_KEY_FILE \
        --public-key-id=keystore://76574:prod:vsa_signing_public_key
    

    Haz los cambios siguientes:

    • PATH_TO_VSA_FILE: la ruta al archivo VSA que has descargado.
    • IMAGE_NAME: el nombre de la imagen de VM, como gke-1302-gke1627000-cos-113-18244-85-49-c-pre.
    • IMAGE_ID: el ID de la imagen de la VM, como 9046093115864736653.

    Si la VSA supera las comprobaciones de verificación, el resultado será el siguiente:

    Verifying VSA: PASSED
    PASSED: SLSA verification passed
    

Siguientes pasos