Usar la comprobación de firmas de Sigstore

En esta página se explica cómo usar la comprobación de firmas de Sigstore de la validación continua (VC) de la autorización binaria. La comprobación verifica las firmas generadas por Sigstore de las imágenes de contenedor asociadas a los pods que se ejecutan en un clúster de GKE en el que está habilitada la verificación de contenedores. La principal diferencia entre esta comprobación y la comprobación de atestación de firma simple es que el flujo de trabajo de firma de Sigstore no usa notas de análisis de artefactos para vincular firmas a imágenes. Todas las firmas se almacenan junto con la imagen que firman.

Esta comprobación solo admite repositorios de Artifact Registry.

Costes

En esta guía se utilizan los siguientes servicios de Google Cloud :

  • Autorización binaria, pero CV está disponible de forma gratuita durante la fase de vista previa
  • GKE
  • Cloud Key Management Service
  • Artifact Registry

Para generar una estimación de costes basada en el uso previsto, utiliza la calculadora de precios.

Antes de empezar

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
  2. Install the Google Cloud CLI.

  3. Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

  4. Para inicializar gcloud CLI, ejecuta el siguiente comando:

    gcloud init
  5. Create or select a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  6. Verify that billing is enabled for your Google Cloud project.

  7. Enable the Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine, Artifact Registry APIs:

    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.

    gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com artifactregistry.googleapis.com
  8. Install the Google Cloud CLI.

  9. Si utilizas un proveedor de identidades (IdP) externo, primero debes iniciar sesión en la CLI de gcloud con tu identidad federada.

  10. Para inicializar gcloud CLI, ejecuta el siguiente comando:

    gcloud init
  11. Create or select a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  12. Verify that billing is enabled for your Google Cloud project.

  13. Enable the Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine, Artifact Registry APIs:

    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.

    gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com artifactregistry.googleapis.com
  14. Asegúrate de que la CLI de gcloud esté actualizada a la última versión.
  15. Instala la herramienta de línea de comandos kubectl.
  16. Si tus políticas de autorización binaria y tus clústeres de GKE están en proyectos diferentes, asegúrate de que la autorización binaria esté habilitada en ambos proyectos.
  17. Instala la herramienta de línea de comandos cosign.
  18. Roles obligatorios

    En esta sección se explica cómo definir roles para esta comprobación.

    Información general

    Si ejecutas todos los productos que se mencionan en esta guía en el mismo proyecto, no tienes que definir ningún permiso. Autorización binaria configura los roles correctamente cuando la habilitas. Si ejecuta los productos en proyectos diferentes, debe asignar roles tal como se describe en esta sección.

    Para asegurarte de que el agente de servicio de Autorización binaria de cada proyecto tenga los permisos necesarios para evaluar la comprobación de la firma de Sigstore de CV, pide a tu administrador que conceda los siguientes roles de gestión de identidades y accesos al agente de servicio de Autorización binaria de cada proyecto:

    • Si el proyecto del clúster es diferente del proyecto de la política: Evaluador de políticas de autorización binaria (roles/binaryauthorization.policyEvaluator) en el agente de servicio de autorización binaria del proyecto del clúster
    • Si el proyecto del repositorio de imágenes es diferente del proyecto de la política: Lector de Artifact Registry (roles/artifactregistry.reader) en el agente de servicio de Autorización binaria del proyecto de la política

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

    Es posible que tu administrador también pueda conceder los permisos necesarios al agente de servicio de Autorización Binaria en cada proyecto mediante roles personalizados u otros roles predefinidos.

    Otorgar roles con la CLI de gcloud

    Para asegurarte de que el agente de servicio de autorización binaria de cada proyecto tenga los permisos necesarios para evaluar la comprobación de la firma de Sigstore de CV, concede al agente de servicio de autorización binaria de cada proyecto los siguientes roles de gestión de identidades y accesos:

    1. Concede permiso al agente de servicio de Autorización binaria del proyecto del clúster para acceder a la política del proyecto de la política.

      1. Obtén el agente de servicio de autorización binaria del proyecto del clúster:

        PROJECT_NUMBER=$(gcloud projects list --filter="projectId:CLUSTER_PROJECT_ID" \
          --format="value(PROJECT_NUMBER)")
        CLUSTER_SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
        

        Sustituye CLUSTER_PROJECT_ID por el ID del proyecto del clúster.

      2. Permite que CV evalúe la política en el clúster:

        gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \
            --member="serviceAccount:$CLUSTER_SERVICE_ACCOUNT" \
            --role='roles/binaryauthorization.policyEvaluator'
        

        Sustituye POLICY_PROJECT_ID por el ID del proyecto que contiene tu política.

    2. Permite que el agente de servicio de autorización binaria del proyecto de la política acceda a las firmas de tu repositorio:

      1. Obtén el agente de servicio de autorización binaria del proyecto de la política:

        PROJECT_NUMBER=$(gcloud projects list \
          --filter="projectId:POLICY_PROJECT_ID" \
          --format="value(PROJECT_NUMBER)")
        SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
        

        Sustituye POLICY_PROJECT_ID por el ID del proyecto que contiene tu política.

      2. Concede el rol:

        gcloud projects add-iam-policy-binding REPOSITORY_PROJECT_ID \
            --member="serviceAccount:$SERVICE_ACCOUNT" \
            --role='roles/artifactregistry.reader'
        

        Sustituye REPOSITORY_PROJECT_ID por el ID del proyecto que contiene tu repositorio.

    Crear un par de claves

    En esta sección, crearás un par de claves asimétricas con el algoritmo de firma digital de curva elíptica (ECDSA).

    Usas la clave privada para firmar la imagen, lo que crea la certificación. Incluye la clave pública en la política de la plataforma. Cuando CV comprueba la atestación, utiliza la clave pública para verificarla.

    Puedes usar Cloud Key Management Service (Cloud KMS) o claves locales, pero te recomendamos que uses claves de Cloud KMS en producción.

    Firmas conjuntas de PKIX Cloud KMS

    1. Configura las variables de entorno necesarias para crear el par de claves. Para ello, te recomendamos que rellenes los marcadores de posición del siguiente comando y, a continuación, lo ejecutes.

      KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
      KMS_KEYRING_NAME=KMS_KEYRING_NAME
      KMS_KEY_NAME=KMS_KEY_NAME
      KMS_KEY_LOCATION=global
      KMS_KEY_PURPOSE=asymmetric-signing
      KMS_KEY_ALGORITHM=ec-sign-p256-sha256
      KMS_PROTECTION_LEVEL=software
      KMS_KEY_VERSION=1
      

      Haz los cambios siguientes:

      • KMS_KEY_PROJECT_ID: tu ID de proyecto
      • KMS_KEYRING_NAME: nombre del conjunto de claves de Cloud KMS
      • KMS_KEY_NAME: nombre de la clave de Cloud KMS
    2. Genera la clave con la CLI de Cosign:

      cosign generate-key-pair \
        --kms gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}
      
    3. Anota la ubicación de la clave pública:

      Cosign guarda automáticamente la clave pública generada como cosign.pub en el directorio en el que se ejecutó el comando generate-key-pair. Guarda la ubicación de este archivo en una variable para usarla en comandos futuros.

      PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
      

    PKIX Cloud KMS gcloud

    Para crear el par de claves en Cloud KMS, sigue estos pasos:

    1. Configura las variables de entorno necesarias para crear el par de claves. Para ello, te recomendamos que rellenes los marcadores de posición del siguiente comando y, a continuación, lo ejecutes.

      KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
      KMS_KEYRING_NAME=KMS_KEYRING_NAME
      KMS_KEY_NAME=KMS_KEY_NAME
      KMS_KEY_LOCATION=global
      KMS_KEY_PURPOSE=asymmetric-signing
      KMS_KEY_ALGORITHM=ec-sign-p256-sha256
      KMS_PROTECTION_LEVEL=software
      KMS_KEY_VERSION=1
      

      Haz los cambios siguientes:

      • KMS_KEY_PROJECT_ID: tu ID de proyecto
      • KMS_KEYRING_NAME: nombre del conjunto de claves de Cloud KMS
      • KMS_KEY_NAME: nombre de la clave de Cloud KMS
    2. Crea el conjunto de claves:

      gcloud kms keyrings create ${KMS_KEYRING_NAME} \
          --location=${KMS_KEY_LOCATION} \
          --project=${KMS_KEY_PROJECT_ID}
      
    3. Crea la clave:

      gcloud kms keys create ${KMS_KEY_NAME} \
          --location=${KMS_KEY_LOCATION} \
          --keyring=${KMS_KEYRING_NAME}  \
          --purpose=${KMS_KEY_PURPOSE} \
          --default-algorithm=${KMS_KEY_ALGORITHM} \
          --protection-level=${KMS_PROTECTION_LEVEL} \
          --project=${KMS_KEY_PROJECT_ID}
      
    4. Exporta el material de clave pública a un archivo:

      PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
      gcloud kms keys versions get-public-key 1 \
          --key=${KMS_KEY_NAME} \
          --keyring=${KMS_KEYRING_NAME} \
          --location=${KMS_KEY_LOCATION} \
          --output-file=${PUBLIC_KEY_FILE} \
          --project=${KMS_KEY_PROJECT_ID}
      

    Clave local

    Para crear el par de claves de forma local, sigue estos pasos:

      cosign generate-key-pair
      PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
      PRIVATE_KEY_FILE="$(pwd)/cosign.key"
    

    Crear la política de la plataforma

    Para crear la política de la plataforma de CV con una comprobación de la firma de Sigstore, haga lo siguiente:

    1. Crea el archivo de política de plataforma de comprobación de firmas de Sigstore:

      cat > POLICY_PATH <<EOF
      gkePolicy:
        checkSets:
        - checks:
          - displayName: sigstore-signature-check
            sigstoreSignatureCheck:
              sigstoreAuthorities:
              - displayName: sigstore-authority
                publicKeySet:
                  publicKeys:
                    publicKeyPem: |
      $(awk '{printf "                %s\n", $0}' ${PUBLIC_KEY_FILE})
      EOF
      

      Sustituye POLICY_PATH por la ruta al archivo de políticas.

    2. Crea la política de la plataforma:

      Antes de usar los datos de los comandos que se indican a continuación, haz los siguientes cambios:

      • POLICY_ID: ID de política de plataforma que elijas. Si la política está en otro proyecto, puedes usar el nombre de recurso completo: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID.
      • POLICY_PATH: ruta al archivo de la política.
      • POLICY_PROJECT_ID: ID del proyecto de la política.

      Ejecuta el siguiente comando:

      Linux, macOS o Cloud Shell

      gcloud beta container binauthz policy create POLICY_ID \
          --platform=gke \
          --policy-file=POLICY_PATH \
          --project=POLICY_PROJECT_ID

      Windows (PowerShell)

      gcloud beta container binauthz policy create POLICY_ID `
          --platform=gke `
          --policy-file=POLICY_PATH `
          --project=POLICY_PROJECT_ID

      Windows (cmd.exe)

      gcloud beta container binauthz policy create POLICY_ID ^
          --platform=gke ^
          --policy-file=POLICY_PATH ^
          --project=POLICY_PROJECT_ID

    Habilitar CV

    Puedes crear un clúster o actualizar uno que ya tengas para usar la monitorización de CV con políticas de plataforma basadas en comprobaciones.

    Crear un clúster que use la monitorización de CV

    En esta sección, crearás un clúster que solo use la monitorización de CV con políticas de plataforma basadas en comprobaciones.

    Antes de usar los datos de los comandos que se indican a continuación, haz los siguientes cambios:

    • CLUSTER_NAME: nombre del clúster.
    • LOCATION: la ubicación (por ejemplo, us-central1 o asia-south1).
    • POLICY_PROJECT_ID: el ID del proyecto en el que se almacena la política.
    • POLICY_ID: el ID de la política.
    • CLUSTER_PROJECT_ID: el ID del proyecto del clúster.

    Ejecuta el siguiente comando:

    Linux, macOS o Cloud Shell

    gcloud beta container clusters create CLUSTER_NAME \
        --location=LOCATION \
        --binauthz-evaluation-mode=POLICY_BINDINGS \
        --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
        --project=CLUSTER_PROJECT_ID

    Windows (PowerShell)

    gcloud beta container clusters create CLUSTER_NAME `
        --location=LOCATION `
        --binauthz-evaluation-mode=POLICY_BINDINGS `
        --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
        --project=CLUSTER_PROJECT_ID

    Windows (cmd.exe)

    gcloud beta container clusters create CLUSTER_NAME ^
        --location=LOCATION ^
        --binauthz-evaluation-mode=POLICY_BINDINGS ^
        --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
        --project=CLUSTER_PROJECT_ID

    Crear un clúster que use la monitorización de cumplimiento y de CV

    En esta sección, crearás un clúster que utilice tanto la aplicación de la política project-singleton como la monitorización de CV con políticas de plataforma basadas en comprobaciones:

    Antes de usar los datos de los comandos que se indican a continuación, haz los siguientes cambios:

    • CLUSTER_NAME: nombre del clúster.
    • LOCATION: la ubicación (por ejemplo, us-central1 o asia-south1).
    • POLICY_PROJECT_ID: el ID del proyecto en el que se almacena la política.
    • POLICY_ID: el ID de la política.
    • CLUSTER_PROJECT_ID: el ID del proyecto del clúster.

    Ejecuta el siguiente comando:

    Linux, macOS o Cloud Shell

    gcloud beta container clusters create CLUSTER_NAME \
        --location=LOCATION \
        --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
        --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
        --project=CLUSTER_PROJECT_ID

    Windows (PowerShell)

    gcloud beta container clusters create CLUSTER_NAME `
        --location=LOCATION `
        --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
        --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
        --project=CLUSTER_PROJECT_ID

    Windows (cmd.exe)

    gcloud beta container clusters create CLUSTER_NAME ^
        --location=LOCATION ^
        --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
        --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
        --project=CLUSTER_PROJECT_ID

    Actualizar un clúster para usar la monitorización de CV

    En esta sección, actualizarás un clúster para que use la monitorización de CV solo con políticas de plataforma basadas en comprobaciones. Si el clúster ya tiene habilitada la aplicación de la política de proyecto único, al ejecutar este comando se inhabilitará. En su lugar, actualiza el clúster con la monitorización de CV y la aplicación habilitadas.

    Antes de usar los datos de los comandos que se indican a continuación, haz los siguientes cambios:

    • CLUSTER_NAME: el nombre del clúster
    • LOCATION: la ubicación (por ejemplo, us-central1 o asia-south1)
    • POLICY_PROJECT_ID: ID del proyecto en el que se almacena la política
    • POLICY_ID: el ID de la política
    • CLUSTER_PROJECT_ID: el ID del proyecto del clúster

    Ejecuta el siguiente comando:

    Linux, macOS o Cloud Shell

    gcloud beta container clusters update CLUSTER_NAME \
        --location=LOCATION \
        --binauthz-evaluation-mode=POLICY_BINDINGS \
        --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
        --project=CLUSTER_PROJECT_ID

    Windows (PowerShell)

    gcloud beta container clusters update CLUSTER_NAME `
        --location=LOCATION `
        --binauthz-evaluation-mode=POLICY_BINDINGS `
        --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
        --project=CLUSTER_PROJECT_ID

    Windows (cmd.exe)

    gcloud beta container clusters update CLUSTER_NAME ^
        --location=LOCATION ^
        --binauthz-evaluation-mode=POLICY_BINDINGS ^
        --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
        --project=CLUSTER_PROJECT_ID

    Actualizar un clúster para usar la monitorización de cumplimiento y de CV

    En esta sección, actualizarás un clúster para que use tanto la aplicación de la política de un solo proyecto como la monitorización de versiones con políticas de plataforma basadas en comprobaciones.

    Antes de usar los datos de los comandos que se indican a continuación, haz los siguientes cambios:

    • CLUSTER_NAME: nombre de un clúster
    • LOCATION: la ubicación (por ejemplo, us-central1 o asia-south1)
    • POLICY_PROJECT_ID: ID del proyecto en el que se almacena la política
    • POLICY_ID: el ID de la política
    • CLUSTER_PROJECT_ID: el ID del proyecto del clúster

    Ejecuta el siguiente comando:

    Linux, macOS o Cloud Shell

    gcloud beta container clusters update CLUSTER_NAME \
        --location=LOCATION \
        --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
        --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
        --project=CLUSTER_PROJECT_ID

    Windows (PowerShell)

    gcloud beta container clusters update CLUSTER_NAME `
        --location=LOCATION `
        --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
        --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
        --project=CLUSTER_PROJECT_ID

    Windows (cmd.exe)

    gcloud beta container clusters update CLUSTER_NAME ^
        --location=LOCATION ^
        --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
        --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
        --project=CLUSTER_PROJECT_ID

    Prueba de CV

    En esta sección, probarás CV implementando una imagen firmada. En este caso, la comprobación de la firma de CV Sigstore verifica la firma y no genera ninguna entrada de registro.

    Después, intentas implementar otra imagen sin firmar. En este caso, la comprobación de CV no encuentra una firma válida y registra la infracción en Cloud Logging.

    Firmar una imagen

    Para que se cumpla la comprobación, la imagen debe tener una firma válida. Para crear la firma, haz lo siguiente:

    1. Crea las variables que usas para firmar la imagen:

      IMAGE_PATH=IMAGE_PATH
      IMAGE_DIGEST=sha256:IMAGE_DIGEST_SHA
      IMAGE_TO_SIGN="${IMAGE_PATH}@${IMAGE_DIGEST}"
      

      Haz los cambios siguientes:

      • IMAGE_PATH: la ruta a tu imagen
      • IMAGE_DIGEST_SHA: el hash SHA del resumen de tu imagen
    2. Firma la imagen y envía la firma a Artifact Registry:

      PKIX Cloud KMS

      Firma la imagen con una clave alojada en Cloud KMS y envía la firma a Artifact Registry:

      cosign sign \
          --key gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME} \
          ${IMAGE_TO_SIGN}
      

      Clave local

      Firma la imagen con una clave privada local y envía la firma a Artifact Registry.

      cosign sign --key ${PRIVATE_KEY_FILE} ${IMAGE_TO_SIGN}
      
    3. Responde a la petición de Cosign:

      Después de ejecutar el comando cosign sign, Cosign te pregunta si quieres subir la firma al registro de transparencia Rekor. Responde y o n a las peticiones. Para obtener más información sobre Rekor, consulta la documentación de Rekor.

    Verificar manualmente la firma

    Para verificar manualmente la firma, haz lo siguiente:

    1. Asegúrate de que la firma esté en Artifact Registry:

      Google Cloud consola

      1. Ve a la página Artifact Registry en la Google Cloud consola.

        Ir a Artifact Registry

      2. En la lista de repositorios, haga clic en el nombre del repositorio que contiene su imagen.

      3. Haz clic en el nombre de la imagen que has firmado.

      4. Busca el elemento que contiene la firma. Este elemento tiene la etiqueta: sha256-[image digest].sig. Solo debe haber un elemento con la etiqueta.

      5. Haz clic en Manifiesto.

      6. Debería aparecer un archivo con formato JSON con varios campos. Cada firma se encuentra en un elemento de la lista layers, en el mapa annotations. Las firmas se encuentran en la clave dev.cosignproject.cosign/signature.

        Este es un ejemplo de manifiesto:

        {
              "schemaVersion": 2,
              "mediaType": "application/vnd.oci.image.manifest.v1+json",
              "config": {
                  "mediaType": "application/vnd.oci.image.config.v1+json",
                  "size": SIZE_OF_LAYERS,
                  "digest": "DIGEST_OF_LAYERS"
              },
              "layers": [
                  {
                      "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json",
                      "size": SIZE_OF_ANNOTATIONS,
                      "digest": "DIGEST_OF_ANNOTATIONS",
                      "annotations": {
                          "dev.cosignproject.cosign/signature": "BASE64_SIGNATURE",
                          "dev.sigstore.cosign/bundle": "BUNDLE"
                      }
                  }
              ]
        }

      El manifiesto de ejemplo incluye lo siguiente:

      • SIZE_OF_LAYERS: tamaño de la matriz layers en bytes
      • DIGEST_OF_LAYERS: el resumen de la matriz layers
      • SIZE_OF_ANNOTATIONS: tamaño del diccionario annotations en bytes
      • DIGEST_OF_ANNOTATIONS: resumen del diccionario annotations
      • BASE64_SIGNATURE: la firma sin procesar codificada en formato base64. Esta es la firma que se usará para la verificación.
      • BUNDLE: metadatos específicos de Sigstore

      Puedes consultar más detalles sobre el formato del manifiesto en la especificación de firma de cosign de Sigstore.

      Línea de comandos

      1. Busca el artefacto correcto:

        Lista los elementos almacenados con la imagen:

        gcloud artifacts docker tags list ${IMAGE_PATH}
        

        Un ejemplo de salida sería el siguiente:

        Listing items under project PROJECT_ID, location REPOSITORY_LOCATION, repository REPOSITORY_NAME.
        TAG                         IMAGE                                                         DIGEST
        latest                      us-east1-docker.pkg.dev/my-project/my-repo/my-image           sha256:abc123
        sha256-abc123.sig           us-east1-docker.pkg.dev/my-project/my-repo/my-image           sha256:def456
        

        En el resultado, el artefacto con la etiqueta sha256-abc123.sig contiene la firma en su manifiesto.

      2. Obtener el archivo de manifiesto

        Para obtener el manifiesto del artefacto con la etiqueta sha256-IMAGE_DIGEST_SHA.sig, ejecuta el siguiente comando:

        curl -X GET -H "Content-Type: application/json" \
                    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
                    -H "X-Goog-User-Project: REPOSITORY_PROJECT_ID" \
                    "https://REPOSITORY_LOCATION-docker.pkg.dev/v2/REPOSITORY_PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME/manifests/sha256-IMAGE_DIGEST_SHA.sig"
        

        Haz los cambios siguientes:

        • REPOSITORY_PROJECT_ID: ID del proyecto que contiene el repositorio
        • REPOSITORY_LOCATION: la ubicación del repositorio
        • REPOSITORY_NAME: el nombre del repositorio
        • IMAGE_NAME: el nombre de la imagen

        Debería aparecer un archivo con formato JSON con varios campos. Cada firma se encuentra en un elemento de la lista layers, en el mapa annotations. Las firmas se encuentran en la clave dev.cosignproject.cosign/signature.

        Aquí se muestra un ejemplo de manifiesto:

        {
            "schemaVersion": 2,
            "mediaType": "application/vnd.oci.image.manifest.v1+json",
            "config": {
                "mediaType": "application/vnd.oci.image.config.v1+json",
                "size": SIZE_OF_LAYERS,
                "digest": "DIGEST_OF_LAYERS"
            },
            "layers": [
                {
                    "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json",
                    "size": SIZE_OF_ANNOTATIONS,
                    "digest": "DIGEST_OF_ANNOTATIONS",
                    "annotations": {
                        "dev.cosignproject.cosign/signature": "BASE64_SIGNATURE",
                        "dev.sigstore.cosign/bundle": "BUNDLE"
                    }
                }
            ]
        }

      El manifiesto de ejemplo incluye lo siguiente:

      • SIZE_OF_LAYERS: tamaño de la matriz layers en bytes
      • DIGEST_OF_LAYERS: el resumen de la matriz layers
      • SIZE_OF_ANNOTATIONS: tamaño del diccionario annotations en bytes
      • DIGEST_OF_ANNOTATIONS: resumen del diccionario annotations
      • BASE64_SIGNATURE: la firma sin procesar codificada en formato base64. Esta es la firma que se usará para la verificación.
      • BUNDLE: metadatos específicos de Sigstore

      Puedes consultar más detalles sobre el formato del manifiesto en la especificación de firma de cosign de Sigstore.

    2. Verifica la firma manualmente:

      Usa cosign verify para verificar la firma subida:

      PKIX Cloud KMS

      cosign verify --key gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME} \
            ${IMAGE_PATH}@${IMAGE_DIGEST}
      

      Clave local

      cosign verify --key {PUBLIC_KEY_FILE} ${IMAGE_PATH}@${IMAGE_DIGEST}
      

      El resultado del comando indica The signatures were verified against the specified public key si la verificación se ha realizado correctamente.

    Implementar la imagen firmada

    Para implementar una imagen firmada, siga estos pasos:

    1. Configura kubectl:

      gcloud container clusters get-credentials CLUSTER_NAME \
          --location=LOCATION \
          --project=CLUSTER_PROJECT_ID
      

      Haz los cambios siguientes:

      • CLUSTER_NAME: el nombre de tu clúster
      • LOCATION: la ubicación del clúster
      • CLUSTER_PROJECT_ID: el ID del proyecto del clúster
    2. Despliega una imagen y comprueba el despliegue con la política de autorización binaria:

      kubectl run hello-app-signed --image=${IMAGE_PATH}@${IMAGE_DIGEST}
      

      Se ha desplegado el pod. Como la imagen está firmada, CV no genera entradas de registro relacionadas con este pod.

    Desplegar una imagen sin firmar

    En esta sección, desplegarás una imagen sin firmar.

    Como la política requiere firmas y esta imagen no tiene ninguna, el CV registra periódicamente la infracción mientras el contenedor está en ejecución.

    Para desplegar la imagen, ejecuta el siguiente comando:

      kubectl run hello-app-unsigned \
          --image=UNSIGNED_IMAGE_PATH@UNSIGNED_IMAGE_DIGEST
    

    Se ha desplegado el pod. Como la imagen no tiene una certificación, CV genera entradas de registro mientras se ejecuta el pod.

    Ver registros de entradas de CV

    Puedes buscar entradas de Cloud Logging para encontrar errores de configuración de CV y infracciones de validación de la política de la plataforma de CV.

    CV registra los errores y las infracciones en Cloud Logging en un plazo de 24 horas. Normalmente, las entradas se muestran al cabo de unas horas.

    Ver los registros de errores de configuración de la verificación

    Para ver los registros de errores de configuración de CV, ejecuta el siguiente comando:

    gcloud logging read \
         --order="desc" \
         --freshness=7d \
         --project=CLUSTER_PROJECT_ID \
        'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "configErrorEvent"'
    

    En el siguiente resultado se muestra un error de configuración en el que no se encuentra una política de plataforma de CV:

    {
      "insertId": "141d4f10-72ea-4a43-b3ec-a03da623de42",
      "jsonPayload": {
        "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent",
        "configErrorEvent": {
          "description": "Cannot monitor cluster 'us-central1-c.my-cluster': Resource projects/123456789/platforms/gke/policies/my-policy does not exist."
        }
      },
      "resource": {
        "type": "k8s_cluster",
        "labels": {
          "cluster_name": "my-cluster",
          "location": "us-central1-c",
          "project_id": "my-project"
        }
      },
      "timestamp": "2024-05-28T15:31:03.999566Z",
      "severity": "WARNING",
      "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
      "receiveTimestamp": "2024-05-28T16:30:56.304108670Z"
    }
    

    Ver las infracciones de validación de las políticas de la plataforma de CV

    Si ninguna imagen infringe las políticas de la plataforma que has habilitado, no aparecerá ninguna entrada en los registros.

    Para ver las entradas de registro de CV de los últimos siete días, ejecuta el siguiente comando:

    gcloud logging read \
         --order="desc" \
         --freshness=7d \
         --project=CLUSTER_PROJECT_ID \
        'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "policyName"'
    

    Sustituye CLUSTER_PROJECT_ID por el ID del proyecto del clúster.

    Tipos de comprobación

    Los registros de CV comprueban la información de las infracciones en checkResults. En la entrada, el valor checkType indica la comprobación. Los valores de cada comprobación son los siguientes:

    • ImageFreshnessCheck
    • SigstoreSignatureCheck
    • SimpleSigningAttestationCheck
    • SlsaCheck
    • TrustedDirectoryCheck
    • VulnerabilityCheck

    Registro de ejemplo

    La siguiente entrada de registro de CV describe una imagen no conforme que infringe una comprobación de directorio de confianza:

    {
      "insertId": "637c2de7-0000-2b64-b671-24058876bb74",
      "jsonPayload": {
        "podEvent": {
          "endTime": "2022-11-22T01:14:30.430151Z",
          "policyName": "projects/123456789/platforms/gke/policies/my-policy",
          "images": [
            {
              "result": "DENY",
              "checkResults": [
                {
                  "explanation": "TrustedDirectoryCheck at index 0 with display name \"My trusted directory check\" has verdict NOT_CONFORMANT. Image is not in a trusted directory",
                  "checkSetName": "My check set",
                  "checkSetIndex": "0",
                  "checkName": "My trusted directory check",
                  "verdict": "NON_CONFORMANT",
                  "checkType": "TrustedDirectoryCheck",
                  "checkIndex": "0"
                }
              ],
              "image": "gcr.io/my-project/hello-app:latest"
            }
          ],
          "verdict": "VIOLATES_POLICY",
          "podNamespace": "default",
          "deployTime": "2022-11-22T01:06:53Z",
          "pod": "hello-app"
        },
        "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent"
      },
      "resource": {
        "type": "k8s_cluster",
        "labels": {
          "project_id": "my-project",
          "location": "us-central1-a",
          "cluster_name": "my-test-cluster"
        }
      },
      "timestamp": "2022-11-22T01:44:28.729881832Z",
      "severity": "WARNING",
      "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
      "receiveTimestamp": "2022-11-22T03:35:47.171905337Z"
    }
    

    Limpieza

    En esta sección se describe cómo limpiar la monitorización de CV que has configurado anteriormente en esta guía.

    Puedes inhabilitar la monitorización de CV o tanto Binary Authorization como CV en tu clúster.

    Inhabilitar la autorización binaria en un clúster

    Para inhabilitar la aplicación de CV y de autorización binaria en tu clúster, ejecuta el siguiente comando:

    gcloud beta container clusters update CLUSTER_NAME \
        --binauthz-evaluation-mode=DISABLED \
        --location=LOCATION \
        --project=CLUSTER_PROJECT_ID
    

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster
    • LOCATION: la ubicación del clúster
    • CLUSTER_PROJECT_ID: el ID del proyecto del clúster

    Inhabilitar la monitorización de políticas basada en comprobaciones en un clúster

    Para inhabilitar la verificación de versiones con políticas basadas en comprobaciones en el clúster y volver a habilitar la aplicación mediante la política de aplicación de la autorización binaria, ejecuta el siguiente comando:

    gcloud beta container clusters update CLUSTER_NAME  \
        --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
        --location=LOCATION \
        --project="CLUSTER_PROJECT_ID"
    

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster
    • LOCATION: la ubicación del clúster
    • CLUSTER_PROJECT_ID: el ID del proyecto del clúster

    Ten en cuenta que --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE es equivalente a la marca anterior --enable-binauthz.

    Eliminar la política

    Para eliminar la política, ejecuta el siguiente comando. No es necesario eliminar la política de plataforma basada en comprobaciones para inhabilitar la auditoría de políticas basada en comprobaciones.

    gcloud beta container binauthz policy delete POLICY_ID \
        --platform=gke \
        --project="POLICY_PROJECT_ID"
    

    Haz los cambios siguientes:

    • POLICY_ID: el ID de la política
    • POLICY_PROJECT_ID: el ID del proyecto de la política

    Siguientes pasos