Usa la verificación de SLSA

En esta página, se muestra cómo usar la validación continua (CV) de Autorización Binaria, la verificación de SLSA, que verifica la procedencia de las imágenes de contenedor compatibles con SLSA con Pods que se ejecutan en clústeres de GKE en los que la CV está habilitada.

Para usar esta verificación, debes compilar imágenes con Cloud Build, que produce una procedencia compatible con SLSA.

En el ejemplo de esta guía, se usa Cloud Source Repositories para el repositorio de código fuente, Artifact Registry para el registro de imágenes y Cloud Build para compilar la imagen y producir la procedencia.

El único compilador de confianza que admite la verificación de SLSA es Cloud Build.

Costos

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

  • Artifact Registry
  • Autorización Binaria, pero la CV está disponible de forma gratuita durante la etapa de vista previa
  • Cloud Build
  • Cloud Source Repositories
  • GKE

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.

Antes de comenzar

  1. Accede a tu cuenta de Google Cloud. Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.
  2. Install the Google Cloud CLI.

  3. To initialize the gcloud CLI, run the following command: 

    gcloud init

  4. Create or select a Google Cloud project.

    • 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.

  5. Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

  6. Enable the Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories APIs: 

    gcloud services enable artifactregistry.googleapis.com binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com
  7. Install the Google Cloud CLI.

  8. To initialize the gcloud CLI, run the following command: 

    gcloud init

  9. Create or select a Google Cloud project.

    • 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.

  10. Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

  11. Enable the Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories APIs: 

    gcloud services enable artifactregistry.googleapis.com binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com
  12. Asegúrate de que gcloud CLI esté actualizada a la versión más reciente.
  13. Instala la herramienta de línea de comandos de kubectl.
  14. Si tus políticas de autorización binaria y clústeres de GKE están en proyectos diferentes, asegúrate de que la autorización binaria esté habilitada en ambos proyectos.

Roles obligatorios

En esta sección, se muestra cómo configurar las funciones para esta verificación.

Descripción general

Si ejecutas todos los productos mencionados en esta guía en el mismo proyecto, no necesitas establecer ningún permiso. La autorización binaria configura las funciones de forma correcta cuando la habilitas. Si ejecutas los productos en diferentes proyectos, debes establecer las funciones como se describe en esta sección.

Para garantizar que el agente de servicio de autorización binaria de cada proyecto tenga los permisos necesarios para evaluar la verificación de SLSA de al CV, pídele a tu administrador que le otorgue al agente de servicio de Autorización Binaria en cada proyecto los siguientes roles de IAM:

  • Lector de Artifact Registry (roles/artifactregistry.reader) en la cuenta de servicio de Compute Engine del proyecto del clúster
  • Si tu proyecto de clúster es diferente del proyecto de política: Evaluador de política de Autorización Binaria (roles/binaryauthorization.policyEvaluator) en el agente de servicio de Autorización Binaria del proyecto del clúster, para que acceda al proyecto de política
  • Si tu proyecto de certificación es diferente de tu proyecto de política: Visualizador de casos de Container Analysis (roles/containeranalysis.occurrences.viewer) en el agente de servicio de Autorización Binaria del proyecto de política, para que acceda al proyecto de certificación

Si quieres obtener más información para otorgar roles, consulta Administra el acceso.

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

Otorga roles mediante gcloud CLI

Para garantizar que las cuentas de servicio de cada proyecto tengan los permisos necesarios para evaluar esta verificación, otorga a las cuentas de servicio de cada proyecto los siguientes roles de IAM:

  1. Si el proyecto en el que ejecutas tu clúster es diferente del proyecto en el que reside la política, debes otorgar permiso al agente de servicio de Autorización Binaria del proyecto del clúster para acceder a la política en el proyecto de política.

    1. Obtén el agente de servicio de Autorización Binaria del proyecto de 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"

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

    2. Permite que la 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'

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

  2. Permite que el agente de servicio del proyecto de política acceda a las certificaciones:

    1. Obtén el agente de servicio de Autorización Binaria con el proyecto de política:

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

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

    2. Otorga el rol:

      gcloud projects add-iam-policy-binding ATTESTATION_PROJECT_ID \
    --member="serviceAccount:$POLICY_PROJECT_SERVICE_ACCOUNT" \
    --role='roles/containeranalysis.occurrences.viewer'

      Reemplaza ATTESTATION_PROJECT_ID por el ID del proyecto que contiene tus certificaciones.

  3. Permite que la cuenta de servicio predeterminada de Compute Engine extraiga la imagen del repositorio:

    1. Obtén la cuenta de servicio de Compute Engine asociada con el proyecto del clúster:

      PROJECT_NUMBER=$(gcloud projects list \
  --filter="projectId:CLUSTER_PROJECT_ID" \
  --format="value(PROJECT_NUMBER)")
COMPUTE_ENGINE_SERVICE_ACCOUNT="$PROJECT_NUMBER-compute@developer.gserviceaccount.com"

      Reemplaza CLUSTER_PROJECT_ID por el ID del proyecto del clúster que contiene tu política.

    2. Otorga el rol:

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

      Reemplaza ARTIFACT_PROJECT_ID por el ID del proyecto de Artifact Registry que almacena las imágenes que se implementarán.

Opcional: Compila y sube una imagen de muestra

Esta sección se incluye con fines ilustrativos, a fin de mostrarte cómo compilar una imagen de ejemplo con procedencia que cumple con SLSA. La procedencia se usa más adelante en la guía para demostrar la verificación. Obtén más información sobre la procedencia de Cloud Build.

Crea el repositorio de muestra

Para crear un repositorio en Cloud Source Repositories, haz lo siguiente:

  1. Crea el repositorio y clona el archivo de forma local:

    gcloud source repos create SOURCE_REPO_NAME \
    --project=SOURCE_REPO_PROJECT_ID && \
gcloud source repos clone SOURCE_REPO_NAME \
    --project=SOURCE_REPO_PROJECT_ID && \
cd SOURCE_REPO_NAME

    Reemplaza lo siguiente:

    • SOURCE_REPO_NAME: El nombre de tu repositorio de código fuente, por ejemplo: slsa-check-test-repo
    • SOURCE_REPO_PROJECT_ID: El ID del proyecto del repositorio

  2. Para crear la fuente, la configuración y los archivos de compilación, haz lo siguiente:

    1. Crea la fuente de la imagen:

      cat > quickstart.sh <<EOF
#!/bin/sh
echo "Hello, world! The time is $(date)."
sleep infinity
EOF

    2. Haz que el archivo sea ejecutable:

      chmod +x quickstart.sh

    3. Crea el archivo de configuración de Dockerfile:

      cat > Dockerfile <<EOF
FROM alpine
COPY quickstart.sh /
CMD ["/quickstart.sh"]
EOF

    4. Crea el archivo cloudbuild.yaml de Cloud Build, que envía la imagen a Artifact Registry:

      cat > cloudbuild.yaml <<EOF
steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE', '.' ]
options:
  requestedVerifyOption: VERIFIED
images:
- 'LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE'
EOF

      Reemplaza lo siguiente:

      • LOCATION: La ubicación de Artifact Registry, por ejemplo: us-west2, europe-central2 o asia-east1
      • ARTIFACT_PROJECT_ID: El ID del proyecto que almacena los artefactos de Artifact Registry
      • ARTIFACT_REPO_NAME: El nombre del repositorio de Artifact Registry, por ejemplo: slsa-check-test-repo
      • DIRECTORY: El directorio, por ejemplo: slsa-check
      • IMAGE: La ruta a la imagen, por ejemplo: slsa-check-image

    5. Confirma los archivos en Cloud Source Repositories:

      git add .
git commit -a

Compila y sube la imagen de muestra

A fin de simplificar el uso de esta guía, te recomendamos que uses el mismo proyecto para SOURCE_REPO_PROJECT_ID y ARTIFACT_PROJECT_ID. Si usas proyectos diferentes, es posible que debas configurar permisos de IAM adicionales. Más información sobre el control de acceso de Container Registry. Para obtener más información sobre Cloud Build, consulta la Descripción general de Cloud Build.

Para crear el repositorio, haz lo siguiente:

  1. Crea el repositorio de Artifact Registry:

    gcloud artifacts repositories create ARTIFACT_REPO_NAME \
    --project=ARTIFACT_PROJECT_ID \
    --repository-format=docker \
    --location=LOCATION \
    --description="Docker repository"

    Reemplaza lo siguiente:

    • ARTIFACT_REPO_NAME: El nombre de tu repositorio.
    • ARTIFACT_PROJECT_ID: el ID del proyecto del artefacto
    • LOCATION: La ubicación de Artifact Registry, por ejemplo: us-west2, europe-central2 o asia-east1

  2. Crea el activador de compilación de Cloud Build:

    gcloud beta builds triggers create cloud-source-repositories \
    --project=SOURCE_REPO_PROJECT_ID \
    --repo=SOURCE_REPO_NAME \
    --region=LOCATION \
    --branch-pattern=.* \
    --build-config=cloudbuild.yaml

    Reemplaza lo siguiente:

    • SOURCE_REPO_NAME: Es el nombre del repositorio de código fuente.
    • SOURCE_REPO_PROJECT_ID: El ID del proyecto de Cloud Build.
    • LOCATION: la ubicación

  3. Para activar una compilación, envía los archivos que creaste antes en esta guía.

    git push

    Cuando la imagen se compila correctamente, Cloud Build genera una procedencia y la sube a tu repositorio de Artifact Registry.

  4. Para verificar la imagen más reciente y obtener su resumen, haz lo siguiente:

    1. Asegúrate de que Cloud Build haya compilado tu imagen:

      gcloud artifacts docker images list LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/REPO_NAME/DIRECTORY \
    --project=ARTIFACT_PROJECT_ID \
    --sort-by=create_time

      Reemplaza lo siguiente:

      • LOCATION: la ubicación de Artifact Registry
      • ARTIFACT_PROJECT_ID: el ID del proyecto para los artefactos
      • ARTIFACT_REPO_NAME: el nombre del repositorio
      • DIRECTORY: el directorio

    2. Copia el resumen de la imagen más reciente. El resultado es similar al siguiente: sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59

  5. Opcional: Consulta la procedencia de tu imagen:

    gcloud artifacts docker images describe \
  LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE@DIGEST \
    --project=ARTIFACT_PROJECT_ID \
    --show-provenance

    Reemplaza lo siguiente:

    • ARTIFACT_PROJECT_ID: el ID del proyecto para los artefactos
    • LOCATION: la ubicación de Artifact Registry
    • ARTIFACT_REPO_NAME: el nombre del repositorio de artefactos
    • DIRECTORY: el directorio
    • IMAGE: la ruta de acceso a la imagen
    • DIGEST: el resumen asociado con la imagen

    El resultado del comando es similar al siguiente:

    image_summary:
  digest: sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59
  fully_qualified_digest: us-west2-docker.pkg.dev/my-project/slsa-check-repo/slsa-check-image@sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59
  registry: us-west2-docker.pkg.dev
  repository: slsa-check-repo
  slsa_build_level: 3
provenance_summary:
  provenance:
  - build:
      intotoStatement:
        _type: https://in-toto.io/Statement/v0.1
        predicateType: https://slsa.dev/provenance/v0.1
        slsaProvenance:
          builder:
            id: https://cloudbuild.googleapis.com/GoogleHostedWorker
          materials:
          - digest:
              sha1: de4e4227fff1d00d6f7785a827608627e4a369ea
            uri: git+https://source.cloud.google.com/my-project/slsa-check-source-repo
          metadata:
            ...
envelope:
  payload: eyJfdHlwZSI6I ... taW1hZ2U6dGFnMSJ9XX0=
  payloadType: application/vnd.in-toto+json
  signatures:
  - keyid: projects/verified-builder/locations/global/keyRings/attestor/cryptoKeys/provenanceSigner/cryptoKeyVersions/1
    sig: MEQCIBCCkho_re4EfAT-NBSSmAXOZlv4lU_vWzEru97tU8KmAiAKcAa99umWngzNQADmPixqYjbKjLOKQEUvrI5chSrf7g==
  - keyid: projects/verified-builder/locations/global/keyRings/attestor/cryptoKeys/builtByGCB/cryptoKeyVersions/1
    sig: MEUCIFOEq_7RpiZAB4vUlit3hkZ2yI0n37-5Y87l0JbU-EZSAiEA9TNZZcv_MnzKffTnswHWZR2DSLmYiklr5twWfIec-zo=

    El resultado debe contener el bloque provenance_summary para que funcione la verificación de SLSA. Si el resultado no contiene el bloque, verifica que Cloud Build haya invocado un activador de compilación. Cloud Build no produce información de procedencia cuando se activa de forma manual.

Crea una política de plataforma

Para generar la procedencia, debes usar un activador de Cloud Build a fin de compilar tu imagen, como se describe en Compila y sube la imagen de muestra.

Para crear una política de plataforma con una verificación de SLSA, haz lo siguiente:

  1. Crea el archivo YAML de la política de plataforma:

    cat > POLICY_PATH <<EOF
gkePolicy:
  checkSets:
  - checks:
    - displayName: My SLSA check
      imageAllowlist:
        # This policy exempts images that are in the following artifact registry
        allowPattern:
        - ARTIFACT_LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/EXEMPT_IMAGE_PATH/**
      slsaCheck:
        rules:
        - attestationSource:
            containerAnalysisAttestationProjects:
            - projects/ATTESTATION_PROJECT_ID
          configBasedBuildRequired: true
          trustedBuilder: GOOGLE_CLOUD_BUILD
          trustedSourceRepoPatterns:
          - source.cloud.google.com/SOURCE_REPO_PROJECT_ID/SOURCE_REPO_NAME
          customConstraints:
          - CEL_EXPRESSION
    displayName: My check set
EOF

    Reemplaza lo siguiente:

    • POLICY_PATH: una ruta de acceso al archivo de política.
    • ARTIFACT_LOCATION: la ubicación de tu repositorio en Artifact Registry.
    • ARTIFACT_PROJECT_ID: el ID del proyecto que contiene tus artefactos.
    • ARTIFACT_REPO_NAME: el repositorio que contiene la imagen.
    • EXEMPT_IMAGE_PATH: Es una ruta de acceso opcional a una o más imágenes exentas, por ejemplo, not-built-by-cloud-build. El bloque imageAllowlist se incluye en esta política de la plataforma para que puedas eximir las imágenes que carecen de procedencia para que no infrinjan la política de la plataforma. Para, en cambio, registrar incumplimientos de estas imágenes, omite este bloque.
    • ATTESTATION_PROJECT_ID: el ID del proyecto que almacena las certificaciones que creó Cloud Build.
    • SOURCE_REPO_PROJECT_ID: el ID del proyecto que contiene tu código fuente.
    • SOURCE_REPO_NAME: el repositorio que contiene la imagen. Con fines ilustrativos, para forzar una infracción de esta verificación, configura SOURCE_REPO_NAME en un repositorio de código fuente que no sea el lugar en el que reside la imagen.
    • POLICY_PROJECT_ID: el ID del proyecto que contiene la política de la CV.
    • POLICY_ID: el ID de esta política.

    • CEL_EXPRESSION: Es un CEL. expresión que proporciona restricciones adicionales en la política SLSA. Para ejemplo, para agregar una restricción personalizada que requiera que las imágenes se desde una ruta de acceso a un directorio específico, reemplaza CEL_EXPRESSION con la siguiente expresión:

      payload.predicate.externalParameters.buildConfigSource.path != "" && payload.predicate.externalParameters.buildConfigSource.repository.contains("github.com/my-repo/my-production-repo")

  2. Crea la política de plataforma:

    Antes de usar cualquiera de los datos de comando a continuación, haz los siguientes reemplazos:

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

    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

Habilita la CV

Puedes crear un clúster nuevo o actualizar uno existente para usar la supervisión de la CV con políticas de plataforma basadas en verificaciones.

Crea un clúster que use la supervisión de la CV

En esta sección, crearás un clúster que solo usará la supervisión de la CV con las políticas de plataforma basadas en verificaciones.

Antes de usar cualquiera de los datos de comando a continuación, haz los siguientes reemplazos:

  • CLUSTER_NAME: un nombre de 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

Crea un clúster que use la aplicación y la supervisión de la CV

En esta sección, crearás un clúster que use la aplicación de políticas singleton de proyecto con la supervisión de la CV con políticas de plataforma basadas en verificaciones:

Antes de usar cualquiera de los datos de comando a continuación, haz los siguientes reemplazos:

  • CLUSTER_NAME: un nombre de 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

Actualiza un clúster para usar la supervisión de la CV

En esta sección, actualizarás un clúster para usar la supervisión de la CV solo con las políticas de plataforma basadas en verificaciones. Si el clúster ya tiene la aplicación de la política de singleton de proyecto habilitada, la ejecución de este comando la inhabilita. En su lugar, considera actualizar el clúster con la aplicación y la supervisión de la CV habilitadas.

Antes de usar cualquiera de los datos de comando a continuación, haz los siguientes reemplazos:

  • CLUSTER_NAME: el 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: Es 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

Actualiza un clúster para usar la aplicación y la supervisión de la CV

En esta sección, actualizarás un clúster para usar la aplicación de políticas de singleton del proyecto y la supervisión de la CV con políticas de plataforma basadas en verificaciones.

Antes de usar cualquiera de los datos de comando a continuación, haz los siguientes reemplazos:

  • CLUSTER_NAME: un nombre de 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: Es 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

Implementa la imagen

  1. Configura kubectl:

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

    Reemplaza lo siguiente:

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

  2. Implementa el Pod:

    kubectl run hello-app \
    --image='LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE@DIGEST'

    El Pod se implementa. Debido a que la imagen se compiló con procedencia y a partir de un repositorio de código fuente confiable, no infringirá la verificación de SLSA de la CV y no se generarán entradas de registro.

    Para forzar una infracción de la verificación de SLSA, puedes configurar SOURCE_REPO_NAME como un repositorio de código fuente distinto de donde reside la imagen. También puedes activar de forma manual la compilación, lo que omite la generación de procedencia. Luego, busca entradas de registro.

Visualiza los registros de entradas de la CV

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

Errores y infracciones de los registros de CV en Cloud Logging en un plazo de 24 horas. Por lo general, las postulaciones tardan unas horas.

Ver registros de errores de configuración de CV

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"'

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

{
  "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 incumplimientos de la validación de la política de la plataforma de CV

Si ninguna imagen infringe las políticas de la plataforma que habilitaste, no aparecerán las entradas 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"'

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

Tipos de verificación

Los registros de la CV verifican la información de incumplimiento en checkResults. En la entrada, el valor checkType indica la verificación. Los valores para cada verificación son los siguientes:

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

Registro de ejemplo

En el siguiente ejemplo de entrada de Logging de la CV, se describe una imagen que no infringe una verificació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"
}

Limpia

En esta sección, se describe cómo limpiar la supervisión de la CV que configuraste antes en esta guía.

Puedes inhabilitar la supervisión de la CV o Autorización Binaria y la CV en tu clúster.

Inhabilita 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

Reemplaza lo siguiente:

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

Inhabilita la supervisión de políticas basada en verificaciones en un clúster

Para inhabilitar la CV con políticas basadas en verificaciones en el clúster y volver a habilitar la aplicación mediante la política de aplicación de 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"

Reemplaza lo siguiente:

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

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

Borrar la política

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

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

Reemplaza lo siguiente:

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

¿Qué sigue?