Utiliser la vérification SLSA

Cette page explique comment utiliser la vérification SLSA de la validation continue (CV) d'autorisation binaire, qui vérifie la provenance des images de conteneurs associées aux pods exécutés sur GKE (Google Kubernetes Engine) sur lesquels la CV est activée.

Pour utiliser cette vérification, vous devez compiler les images avec Cloud Build, qui produit une provenance conforme à la norme SLSA.

L'exemple de ce guide utilise Cloud Source Repositories pour le dépôt de code source, Artifact Registry pour le registre d'images et Cloud Build pour créer l'image et produire la provenance.

Le seul compilateur approuvé compatible avec la vérification SLSA est Cloud Build.

Coûts

Ce guide utilise les produits Google Cloud suivants :

  • Artifact Registry
  • Autorisation binaire, mais la CV est disponible gratuitement pendant la phase bêta
  • Cloud Build
  • Cloud Source Repositories
  • GKE

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.

Avant de commencer

  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. 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. Make sure that billing is enabled for your Google Cloud project.

  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. Make sure that billing is enabled for your Google Cloud project.

  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. Assurez-vous que gcloud CLI est mis à jour à la dernière version.
  13. Installez l'outil de ligne de commande kubectl.
  14. Si vos stratégies d'autorisation binaire et vos clusters GKE se trouvent dans des projets différents, assurez-vous que l'autorisation binaire est activée dans les deux projets.

Rôles requis

Cette section vous explique comment définir des rôles pour cette vérification.

Présentation

Si vous exécutez tous les produits mentionnés dans ce guide dans le même projet, vous n'avez pas besoin de définir des autorisations. L'autorisation binaire configure correctement les rôles lorsque vous l'activez. Si vous exécutez les produits dans différents projets, vous devez définir des rôles comme décrit dans cette section.

Pour vous assurer que l'agent de service d'autorisation binaire de chaque projet dispose des autorisations nécessaires pour évaluer la vérification du SLSA de la CV, demandez à votre administrateur d'accorder à l'agent de service d'autorisation binaire de chaque projet l'IAM suivante rôles :

  • Lecteur Artifact Registry (roles/artifactregistry.reader) sur le compte de service Compute Engine du projet de cluster.
  • Si votre projet de cluster est différent du projet de règles : Évaluateur de règles d'autorisation binaire (roles/binaryauthorization.policyEvaluator) sur l'agent de service d'autorisation binaire du projet de cluster, pour qu'il puisse accéder au projet de règles.
  • Si votre projet d'attestation est différent de votre projet de règles : Lecteur d'occurrences Container Analysis (roles/containeranalysis.occurrences.viewer) sur l'agent de service d'autorisation binaire du projet de règles pour, pour qu'il puisse accéder au projet d'attestation.

Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

Votre administrateur peut également attribuer à l'agent de service d'autorisation binaire de chaque projet les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

Attribuer des rôles à l'aide de gcloud CLI

Pour vous assurer que les comptes de service de chaque projet disposent des autorisations nécessaires pour évaluer cette vérification, accordez aux comptes de service de chaque projet les rôles IAM suivants :

  1. Si le projet dans lequel vous exécutez votre cluster est différent du projet où réside la règle, vous devez autoriser l'agent de service d'autorisation binaire du projet de cluster à accéder à la règle dans le projet de règles.

    1. Obtenez l'agent de service d'autorisation binaire du projet de cluster :

      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"

      Remplacez CLUSTER_PROJECT_ID par l'ID de projet du cluster.

    2. Autorisez la CV à évaluer la règle sur le cluster :

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

      Remplacez POLICY_PROJECT_ID par l'ID du projet contenant votre stratégie.

  2. Autorisez l'agent de service du projet de règle à accéder aux attestations :

    1. Obtenez l'agent de service d'autorisation binaire associé au projet de règles :

      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"

      Remplacez POLICY_PROJECT_ID par l'ID du projet contenant votre stratégie.

    2. Attribuez le rôle :

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

      Remplacez ATTESTATION_PROJECT_ID par l'ID du projet contenant vos attestations.

  3. Autorisez le compte de service Compute Engine par défaut à extraire l'image du dépôt :

    1. Obtenez le compte de service Compute Engine associé au projet de cluster :

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

      Remplacez CLUSTER_PROJECT_ID par l'ID du projet de cluster contenant votre stratégie.

    2. Attribuez le rôle :

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

      Remplacez ARTIFACT_PROJECT_ID par l'ID du projet Artifact Registry qui héberge les images à déployer.

Facultatif : Compiler et importer un exemple d'image

Cette section est fournie à titre indicatif pour vous montrer comment créer un exemple d'image simple avec une provenance conforme à la norme SLSA. La provenance est utilisée ultérieurement dans le guide pour illustrer la vérification. Apprenez-en davantage sur la provenance Cloud Build.

Créer l'exemple de dépôt

Pour créer un dépôt dans Cloud Source Repositories, procédez comme suit :

  1. Créez le dépôt et clonez-le localement :

    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

    Remplacez les éléments suivants :

    • SOURCE_REPO_NAME : nom du dépôt de votre code source (par exemple, slsa-check-test-repo)
    • SOURCE_REPO_PROJECT_ID : ID du projet de dépôt

  2. Pour créer les fichiers source, de configuration et de compilation, procédez comme suit :

    1. Créez la source de l'image :

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

    2. Rendez le fichier exécutable :

      chmod +x quickstart.sh

    3. Créez le fichier de configuration Dockerfile :

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

    4. Créez le fichier Cloud Build cloudbuild.yaml, qui transfère l'image vers 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

      Remplacez les éléments suivants :

      • LOCATION : emplacement Artifact Registry (par exemple : us-west2, europe-central2 ou asia-east1)
      • ARTIFACT_PROJECT_ID : ID du projet qui stocke les artefacts Artifact Registry
      • ARTIFACT_REPO_NAME : nom du dépôt Artifact Registry (par exemple, slsa-check-test-repo)
      • DIRECTORY : le répertoire (par exemple, slsa-check)
      • IMAGE : chemin d'accès à l'image (par exemple, slsa-check-image)

    5. Effectuez un commit des fichiers dans Cloud Source Repositories :

      git add .
git commit -a

Créer et importer l'exemple d'image

Pour simplifier l'utilisation du présent guide, nous vous recommandons d'utiliser le même projet pour SOURCE_REPO_PROJECT_ID et ARTIFACT_PROJECT_ID. Si vous utilisez différents projets, vous devrez peut-être configurer des autorisations IAM supplémentaires. En savoir plus sur le contrôle des accès dans Artifact Registry. Pour en savoir plus sur Cloud Build, consultez la page Présentation de Cloud Build.

Pour créer le dépôt, procédez comme suit :

  1. Créez le dépôt Artifact Registry :

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

    Remplacez les éléments suivants :

    • ARTIFACT_REPO_NAME : le nom de votre dépôt
    • ARTIFACT_PROJECT_ID : ID du projet d'artefact
    • LOCATION : emplacement Artifact Registry (par exemple : us-west2, europe-central2 ou asia-east1)

  2. Créez le déclencheur de compilation 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

    Remplacez les éléments suivants :

    • SOURCE_REPO_NAME : nom du dépôt de code source
    • SOURCE_REPO_PROJECT_ID : ID du projet Cloud Build
    • LOCATION : emplacement

  3. Déclenchez une compilation en transférant les fichiers que vous avez créés précédemment dans ce guide.

    git push

    Lorsque l'image se compile correctement, Cloud Build génère une provenance et l'importe dans votre dépôt Artifact Registry.

  4. Pour rechercher la dernière image et obtenir son condensé, procédez comme suit :

    1. Assurez-vous que Cloud Build a créé votre image :

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

      Remplacez les éléments suivants :

      • LOCATION : emplacement Artifact Registry
      • ARTIFACT_PROJECT_ID : ID du projet pour les artefacts
      • ARTIFACT_REPO_NAME : nom du dépôt
      • DIRECTORY : répertoire

    2. Copiez le condensé de l'image la plus récente. Le condensé ressemble à ceci : sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59

  5. Facultatif : Affichez la provenance de votre image :

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

    Remplacez les éléments suivants :

    • ARTIFACT_PROJECT_ID : ID du projet pour les artefacts
    • LOCATION : emplacement Artifact Registry
    • ARTIFACT_REPO_NAME : nom du dépôt d'artefacts
    • DIRECTORY : répertoire
    • IMAGE : chemin d'accès à l'image
    • DIGEST : condensé associé à l'image

    Le résultat de la commande ressemble à ceci :

    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=

    Le résultat doit contenir le bloc provenance_summary pour que la vérification SLSA fonctionne. Si le résultat ne contient pas le bloc, vérifiez que Cloud Build a été invoqué par un déclencheur de compilation. Cloud Build ne génère pas d'informations de provenance lorsqu'il est déclenché manuellement.

Créer une règle de plate-forme

Pour générer la provenance, vous devez utiliser un déclencheur Cloud Build pour créer votre image, comme décrit dans la section Créer et importer l'exemple d'image.

Pour créer une règle de plate-forme avec une vérification SLSA, procédez comme suit :

  1. Créez le fichier YAML de règle de plate-forme :

    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

    Remplacez les éléments suivants :

    • POLICY_PATH : chemin d'accès au fichier de règle
    • ARTIFACT_LOCATION : emplacement de votre dépôt dans Artifact Registry
    • ARTIFACT_PROJECT_ID : ID du projet contenant vos artefacts
    • ARTIFACT_REPO_NAME : dépôt contenant l'image
    • EXEMPT_IMAGE_PATH : chemin d'accès facultatif à une ou plusieurs images exclues, par exemple : not-built-by-cloud-build. Le bloc imageAllowlist est inclus dans cette règle de plate-forme afin que vous puissiez exclure les images sans provenance afin qu'elles n'enfreignent pas la règle de plate-forme. Pour plutôt consigner les violations de ces images, omettez ce bloc.
    • ATTESTATION_PROJECT_ID : ID du projet qui stocke les attestations créées par Cloud Build
    • SOURCE_REPO_PROJECT_ID : ID du projet contenant votre code source.
    • SOURCE_REPO_NAME : dépôt contenant l'image. À des fins d'illustration, pour forcer une violation de cette vérification, définissez SOURCE_REPO_NAME sur un dépôt de code source autre que l'emplacement de votre image.
    • POLICY_PROJECT_ID : ID du projet contenant la règle de CV
    • POLICY_ID : ID de cette règle

  2. Créez la règle de plate-forme :

    Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

    • POLICY_ID : ID de règle de plate-forme de votre choix. Si la règle se trouve dans un autre projet, vous pouvez utiliser le nom complet de la ressource : projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID.
    • POLICY_PATH : chemin d'accès au fichier de règle.
    • POLICY_PROJECT_ID : ID du projet de règle.

    Exécutez la commande suivante :

    Linux, macOS ou 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

Activer la CV

Vous pouvez créer un cluster ou mettre à jour un cluster existant pour utiliser la surveillance CV avec des règles de plate-forme basées sur des vérifications.

Créer un cluster utilisant la surveillance CV

Dans cette section, vous allez créer un cluster qui n'utilise que la surveillance CV avec des règles de plate-forme basées sur des vérifications.

Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

  • CLUSTER_NAME : nom du cluster.
  • LOCATION : emplacement (par exemple : us-central1 ou asia-south1).
  • POLICY_PROJECT_ID : l'ID du projet dans lequel la règle est stockée.
  • POLICY_ID : ID de la règle.
  • CLUSTER_PROJECT_ID : ID de projet du cluster.

Exécutez la commande suivante :

Linux, macOS ou 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

Créer un cluster utilisant l'application forcée et la surveillance CV

Dans cette section, vous allez créer un cluster qui utilise à la fois l'application des règles Singleton de projet et la surveillance CV avec des règles de plate-forme basées sur les vérifications :

Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

  • CLUSTER_NAME : nom du cluster.
  • LOCATION : emplacement (par exemple : us-central1 ou asia-south1).
  • POLICY_PROJECT_ID : l'ID du projet dans lequel la règle est stockée.
  • POLICY_ID : ID de la règle.
  • CLUSTER_PROJECT_ID : ID de projet du cluster.

Exécutez la commande suivante :

Linux, macOS ou 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

Mettre à jour un cluster pour utiliser la surveillance CV

Dans cette section, vous allez mettre à jour un cluster pour utiliser la surveillance CV avec uniquement des règles de plate-forme basées sur la vérification. Si l'application de la règle Singleton de projet est déjà activée sur le cluster, l'exécution de cette commande la désactive. Envisagez plutôt de mettre à jour le cluster avec l'application forcée et la surveillance CV activées.

Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

  • CLUSTER_NAME : nom du cluster
  • LOCATION : emplacement (par exemple : us-central1 ou asia-south1)
  • POLICY_PROJECT_ID : ID du projet dans lequel la règle est stockée
  • POLICY_ID : ID de la règle
  • CLUSTER_PROJECT_ID : ID de projet du cluster

Exécutez la commande suivante :

Linux, macOS ou 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

Mettre à jour un cluster pour utiliser l'application forcée et la surveillance CV

Dans cette section, vous allez mettre à jour un cluster pour utiliser à la fois l'application forcée de la règle Singleton de projet et la surveillance CV avec des règles de plate-forme basées sur des vérifications.

Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

  • CLUSTER_NAME : nom du cluster
  • LOCATION : emplacement (par exemple : us-central1 ou asia-south1)
  • POLICY_PROJECT_ID : ID du projet dans lequel la règle est stockée
  • POLICY_ID : ID de la règle
  • CLUSTER_PROJECT_ID : ID de projet du cluster

Exécutez la commande suivante :

Linux, macOS ou 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

Déployer l'image

  1. Configurez kubectl :

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

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • LOCATION : emplacement du cluster
    • CLUSTER_PROJECT_ID : ID de projet du cluster

  2. Déployez le pod :

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

    Le pod est déployé. Étant donné que l'image a été créée avec provenance et à partir d'un dépôt de code source fiable, elle n'enfreindra pas la vérification CV SLSA et aucune entrée de journal ne sera générée.

    Pour forcer une violation de la vérification SLSA, vous pouvez définir SOURCE_REPO_NAME sur un dépôt de code source autre que l'emplacement de votre image. Vous pouvez également déclencher manuellement la compilation, ce qui ignore la génération de provenance. Vérifiez ensuite les entrées de journal.

Afficher les journaux pour les entrées de CV

La CV consigne les cas de non-respect des règles de plate-forme dans Cloud Logging sous 24 heures. Les entrées sont généralement visibles en quelques heures.

Si aucune image n'enfreint les règles de plate-forme que vous avez activées, aucune entrée n'apparaît dans les journaux.

Pour afficher les entrées de journal de la CV des sept derniers jours, exécutez la commande suivante :

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

Remplacez CLUSTER_PROJECT_ID par l'ID du projet de cluster.

Types de test

Les journaux de CV vérifient les informations de violation dans checkResults. Dans l'entrée, la valeur checkType indique la vérification. Les valeurs pour chaque vérification sont les suivantes :

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

Exemple de journal

L'exemple d'entrée de journal CV suivant décrit une image non conforme qui enfreint une vérification de répertoire de confiance :

{
  "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"
}

Effectuer un nettoyage

Cette section explique comment nettoyer la surveillance CV que vous avez configurée précédemment dans ce guide.

Vous pouvez désactiver la surveillance CV ou l'autorisation binaire et la CV dans votre cluster.

Désactiver l'autorisation binaire dans un cluster

Pour désactiver la CV et l'application forcée de l'autorisation binaire dans votre cluster, exécutez la commande suivante :

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

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster
  • LOCATION : emplacement du cluster
  • CLUSTER_PROJECT_ID : ID de projet du cluster

Désactiver la surveillance des règles basées sur des vérifications dans un cluster

Pour désactiver la CV avec des règles basées sur la vérification dans le cluster et réactiver l'application forcée à l'aide de la règle d'application de l'autorisation binaire, exécutez la commande suivante :

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

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster
  • LOCATION : emplacement du cluster
  • CLUSTER_PROJECT_ID : ID de projet du cluster

Notez que --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE équivaut à l'ancienne option --enable-binauthz.

Supprimer la stratégie

Pour supprimer la règle, exécutez la commande suivante. Il n'est pas nécessaire de supprimer la règle de plate-forme basée sur des vérifications pour désactiver son audit.

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

Remplacez les éléments suivants :

  • POLICY_ID : ID de la règle
  • POLICY_PROJECT_ID : ID du projet de règles

Étapes suivantes