Usa la verificación de SLSA

En esta página, se muestra cómo usar la verificación con SLSA de validación continua de autorización binaria (CV), que verifica la procedencia de las imágenes de contenedor compatibles con SLSA asociadas con Pods que se ejecutan en clústeres de Google Kubernetes Engine (GKE) en los que está habilitado el CV.

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

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

El único compilador confiable 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
  • La autorización binaria, pero el CV está disponible sin costo 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. Instala Google Cloud CLI.

  3. Para inicializar la CLI de gcloud, ejecuta el siguiente comando: 

    gcloud init

  4. Crea o selecciona un proyecto de Google Cloud.

    • Crea un proyecto de Google Cloud:

      gcloud projects create PROJECT_ID

    • Selecciona el proyecto de Google Cloud que creaste:

      gcloud config set project PROJECT_ID

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

  6. Habilita las APIs de Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories: 

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

  8. Para inicializar la CLI de gcloud, ejecuta el siguiente comando: 

    gcloud init

  9. Crea o selecciona un proyecto de Google Cloud.

    • Crea un proyecto de Google Cloud:

      gcloud projects create PROJECT_ID

    • Selecciona el proyecto de Google Cloud que creaste:

      gcloud config set project PROJECT_ID

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

  11. Habilita las APIs de Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories: 

    gcloud services enable artifactregistry.googleapis.com binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com
    12.
  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 roles para esta verificación.

Descripción general

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

A fin de asegurarte de que el agente de servicio de autorización binaria de cada proyecto tenga los permisos necesarios para evaluar la verificación SLSA de CV, pídele al administrador que le otorgue las siguientes funciones de IAM al agente de servicio de autorización binaria en cada proyecto:

  • Lector de Artifact Registry (roles/artifactregistry.reader) en la cuenta de servicio del proyecto de clúster de Compute Engine
  • Si tu proyecto de clúster es diferente del proyecto de política, usa el Evaluador de políticas de autorización binaria (roles/binaryauthorization.policyEvaluator) en el agente de servicio de autorización binaria del proyecto para que acceda al proyecto de política.
  • Si el proyecto de certificación es diferente del 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.

El administrador también puede otorgar al agente de servicio de autorización binaria en cada proyecto los permisos necesarios mediante funciones personalizadas o funciones predefinidas.

Otorga roles con gcloud CLI

A fin de asegurarte de que las cuentas de servicio en cada proyecto tengan los permisos necesarios para evaluar esta verificación, otorga a las cuentas de servicio de cada proyecto las siguientes funciones de IAM:

  1. Si el proyecto en el que ejecutas el clúster es diferente del proyecto en el que reside la política, debes otorgar permiso para que el agente de servicio de autorización binaria del proyecto del clúster acceda a la política en el proyecto de 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"

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

    2. Permita que el 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 asociado 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 la función:

      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 la función:

      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 aloja las imágenes que se implementarán.

Cómo crear y subir una imagen de muestra (opcional)

Esta sección se incluye con fines ilustrativos, para mostrarte cómo compilar una imagen de ejemplo simple con procedencia que cumpla 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 origen 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 repositorio 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: Es el nombre de tu repositorio de código fuente, por ejemplo: slsa-check-test-repo.
    • SOURCE_REPO_PROJECT_ID: Es el ID del proyecto del repositorio.

  2. Para crear los archivos fuente, de configuración y 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: Es la ubicación de Artifact Registry, por ejemplo: us-west2, europe-central2 o asia-east1.
      • ARTIFACT_PROJECT_ID: Es el ID del proyecto que almacena los artefactos de Artifact Registry.
      • ARTIFACT_REPO_NAME: Es el nombre del repositorio de Artifact Registry, por ejemplo: slsa-check-test-repo.
      • DIRECTORY: Es el directorio, por ejemplo: slsa-check.
      • IMAGE: Es la ruta a la imagen, por ejemplo: slsa-check-image.

    5. Confirme 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. Obtén más información sobre el control de acceso de Artifact Registry. Para obtener más información sobre Cloud Build, consulta 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: Es el ID del proyecto del artefacto.
    • LOCATION: Es 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 del código fuente.
    • SOURCE_REPO_PROJECT_ID: Es el ID del proyecto de Cloud Build.
    • LOCATION: Es la ubicación.

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

    git push

    Cuando la imagen se compila correctamente, Cloud Build genera un origen 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: Es la ubicación de Artifact Registry.
      • ARTIFACT_PROJECT_ID: Es el ID del proyecto de los artefactos.
      • ARTIFACT_REPO_NAME: Es el nombre del repositorio.
      • DIRECTORY: Es el directorio.

    2. Copia el resumen de la imagen más reciente. El resumen 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: Es el ID del proyecto de los artefactos.
    • LOCATION: Es la ubicación de Artifact Registry.
    • ARTIFACT_REPO_NAME: Es el nombre del repositorio de artefactos.
    • DIRECTORY: Es el directorio.
    • IMAGE: La ruta de acceso a la imagen
    • DIGEST: el resumen asociado a 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 un activador de compilación invocó Cloud Build. Cloud Build no produce información de origen cuando se activa de forma manual.

Crea la política de la plataforma

A fin de generar la fuente, debes usar un activador de Cloud Build para compilar la imagen, como se describe en Cómo compilar y subir la imagen de muestra.

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

  1. Crea el archivo de políticas en formato YAML:

    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
    displayName: My check set
EOF

    Reemplaza lo siguiente:

    • POLICY_PATH: Es una ruta para el archivo de políticas.
    • ARTIFACT_LOCATION: Es la ubicación de tu repositorio en Artifact Registry.
    • ARTIFACT_PROJECT_ID: Es el ID del proyecto que contiene tus artefactos.
    • ARTIFACT_REPO_NAME: Es el repositorio que contiene la imagen.
    • EXEMPT_IMAGE_PATH: Es una ruta 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 plataforma para que puedas eximir las imágenes que carecen de origen, de modo que no infrinjan la política de la plataforma. Para registrar los incumplimientos de estas imágenes, omite este bloque.
    • ATTESTATION_PROJECT_ID: Es el ID del proyecto que almacena las certificaciones que creó Cloud Build.
    • SOURCE_REPO_PROJECT_ID: Es el ID del proyecto que contiene tu código fuente.
    • SOURCE_REPO_NAME: Es 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 la ubicación de tu imagen.
    • POLICY_PROJECT_ID: El ID del proyecto que contiene la política de CV.
    • POLICY_ID: Es el ID de esta política.

  2. Crea la política de la plataforma:

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

    • POLICY_ID: Un ID de política de plataforma que elijas. Si la política está en otro proyecto, puedes usar el nombre completo del recurso: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID.
    • POLICY_PATH: Es una ruta de acceso al archivo de políticas.
    • POLICY_PROJECT_ID: El ID del proyecto de 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

Habilita la CV

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

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

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

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

  • CLUSTER_NAME: Es un nombre de clúster.
  • LOCATION: Es la ubicación, por ejemplo: us-central1 o asia-south1.
  • POLICY_PROJECT_ID: Es el ID del proyecto en el que se almacena la política.
  • POLICY_ID: Es 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 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 aplicación forzosa y la supervisión de CV

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

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

  • CLUSTER_NAME: Es un nombre de clúster.
  • LOCATION: Es la ubicación, por ejemplo: us-central1 o asia-south1.
  • POLICY_PROJECT_ID: Es el ID del proyecto en el que se almacena la política.
  • POLICY_ID: Es 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 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 CV

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

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

  • CLUSTER_NAME: Es el nombre del clúster.
  • LOCATION: Es la ubicación, por ejemplo: us-central1 o asia-south1.
  • POLICY_PROJECT_ID: Es el ID del proyecto en el que se almacena la política.
  • POLICY_ID: Es 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

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

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

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

  • CLUSTER_NAME: Es un nombre de clúster.
  • LOCATION: Es la ubicación, por ejemplo: us-central1 o asia-south1.
  • POLICY_PROJECT_ID: Es el ID del proyecto en el que se almacena la política.
  • POLICY_ID: Es 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'

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

    Para forzar un incumplimiento de la verificación de SLSA, puedes configurar SOURCE_REPO_NAME en un repositorio de código fuente que no sea la ubicación de tu imagen. También puedes activar la compilación de forma manual, lo que omite la generación de procedencia. Luego, busque entradas de registro.

Ver registros de las entradas de CV

El CV registra los incumplimientos de políticas de la plataforma en Cloud Logging en un plazo de 24 horas. Por lo general, es posible que veas entradas en un par de horas.

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

Para ver las entradas del registro de CV de los últimos siete días, ejecute 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.

Comprobar tipos

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

  • ImageFreshnessCheck
  • SimpleSigningAttestationCheck
  • SlsaCheck
  • TrustedDirectoryCheck
  • VulnerabilityCheck

Registro de ejemplo

En el siguiente ejemplo, la entrada de CV Logging describe una imagen que no cumple con las condiciones para infringir 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 CV que configuraste antes en esta guía.

Puedes inhabilitar la supervisión de CV o la autorización binaria y el CV en el clúster.

Inhabilita la autorización binaria en un clúster

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

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 la plataforma basada en verificaciones para inhabilitar la auditoría de la política 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: Es el ID del proyecto de política.

¿Qué sigue?