Cette page a été traduite par l'API Cloud Translation.

Utiliser la vérification SLSA

Cette page vous explique comment utiliser la vérification SLSA de l'autorisation binaire, qui vérifie la provenance SLSA des images de conteneurs associées aux pods s'exécutant sur des clusters Google Kubernetes Engine (GKE) sur lesquels le CV est activé.

Pour utiliser cette vérification, vous devez créer des images avec Cloud Build, qui génère une provenance SLSA.

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

Le seul constructeur de confiance compatible avec la vérification SLSA est Cloud Build.

Coûts

Ce guide utilise les produits Google Cloud suivants :

Artifact Registry
L'autorisation binaire, mais le CV est disponible sans frais pendant l'étape Aperçu
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

Connectez-vous à votre compte Google Cloud. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

Installez Google Cloud CLI.

Pour initialiser gcloudCLI, exécutez la commande suivante :

gcloud init

Remarque : Si vous avez déjà installé gcloud CLI, assurez-vous que vous disposez de la dernière version en exécutant

gcloud components
      update

Créer ou sélectionner un projet Google Cloud

Créez un projet Google Cloud :
```
gcloud projects create PROJECT_ID
```
Sélectionnez le projet Google Cloud que vous avez créé :
```
gcloud config set project PROJECT_ID
```

Vérifiez que la facturation est activée pour votre projet Google Cloud.

Activer les API 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

Installez Google Cloud CLI.

Pour initialiser gcloudCLI, exécutez la commande suivante :

gcloud init

Remarque : Si vous avez déjà installé gcloud CLI, assurez-vous que vous disposez de la dernière version en exécutant

gcloud components
      update

Créer ou sélectionner un projet Google Cloud

Créez un projet Google Cloud :
```
gcloud projects create PROJECT_ID
```
Sélectionnez le projet Google Cloud que vous avez créé :
```
gcloud config set project PROJECT_ID
```

Vérifiez que la facturation est activée pour votre projet Google Cloud.

Activer les API 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

Assurez-vous que gcloud CLI est mise à jour vers la dernière version.
Installez l'outil de ligne de commande kubectl.
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 d'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 SLSA du CV, demandez à votre administrateur d'accorder à l'agent de service de l'autorisation binaire de chaque projet les rôles IAM suivants:

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 stratégie : évaluateur de règles d'autorisation binaire (roles/binaryauthorization.policyEvaluator) sur l'agent de service d'autorisation binaire du projet de cluster pour lui permettre d'accéder au projet de stratégie
Si votre projet d'attestation est différent de votre projet de stratégie : Lecteur d'occurrences Container Analysis (roles/containeranalysis.occurrences.viewer) sur l'agent de service d'autorisation binaire du projet de règles (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:

Si le projet dans lequel vous exécutez votre cluster est différent du projet où se trouve la stratégie, vous devez autoriser l'agent de service d'autorisation binaire du projet de cluster à accéder à la stratégie dans le projet de stratégie.
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 le CV à évaluer la stratégie 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 qui contient votre stratégie.

Autorisez l'agent de service du projet Policy à accéder aux attestations:

Obtenez l'agent de service d'autorisation binaire associé au projet de stratégie:

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 qui contient votre stratégie.

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.

Autorisez l'autorisation par défaut du compte de service Compute Engine à 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: créer et importer un exemple d'image

Cette section est incluse à titre d'illustration pour vous montrer comment créer un exemple d'image simple avec une provenance SLSA. La provenance sera utilisée ultérieurement dans le guide pour illustrer la vérification. Apprenez-en plus 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:

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 de votre dépôt de code source, par exemple: slsa-check-test-repo
- SOURCE_REPO_PROJECT_ID: ID du projet du dépôt
Pour créer les fichiers source, config et build, 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 d'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 : répertoire (par exemple, slsa-check)
  - IMAGE: chemin d'accès à l'image, par exemple: slsa-check-image
5. Validez les fichiers dans Cloud Source Repositories:
```
git add .
git commit -a
```

Créer et importer l'exemple d'image

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

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

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 d'Artifact Registry (par exemple, us-west2, europe-central2 ou asia-east1).

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 du code source
SOURCE_REPO_PROJECT_ID: ID de projet Cloud Build
LOCATION: emplacement

Déclenchez une compilation en transférant les fichiers que vous avez créés précédemment dans ce guide.
```
git push
```
Une fois l'image compilée, Cloud Build génère une provenance et l'importe dans votre dépôt Artifact Registry.
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 d'Artifact Registry
  - ARTIFACT_PROJECT_ID: ID de 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

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 de projet pour les artefacts.
LOCATION: emplacement d'Artifact Registry
ARTIFACT_REPO_NAME: nom du dépôt d'artefacts.
DIRECTORY: répertoire
IMAGE: chemin d'accès à l'image
DIGEST: condensé de l'image.

Le résultat de la commande ressemble à ce qui suit:

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=

La sortie 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é appelé 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 la règle de plate-forme

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

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

Créez le fichier YAML de stratégie:
```
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ègles.
- 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 pour que vous puissiez exempter les images dont la provenance n'est pas conforme afin qu'elles n'enfreignent pas la règle. Pour enregistrer les cas de non-respect des règles à partir 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 le non-respect de cette vérification, définissez SOURCE_REPO_NAME sur un dépôt de code source autre que celui où se trouve votre image.
- POLICY_PROJECT_ID: ID du projet contenant la règle de CV.
- POLICY_ID: ID de cette règle.
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 stratégie.
- POLICY_PROJECT_ID: ID du projet de stratégie
Exécutez la commande suivante:
Linux, macOS ou Cloud Shell

Remarque : Assurez-vous d'avoir initialisé Google Cloud CLI avec l'authentification et un projet en exécutant la commande gcloud init ou gcloud auth login et gcloud config set project.
```
gcloud beta container binauthz policy create POLICY_ID \
    --platform=gke \
    --policy-file=POLICY_PATH \
    --project=POLICY_PROJECT_ID
```
Windows (PowerShell)

Remarque : Assurez-vous d'avoir initialisé Google Cloud CLI avec l'authentification et un projet en exécutant la commande gcloud init ou gcloud auth login et gcloud config set project.
```
gcloud beta container binauthz policy create POLICY_ID `
    --platform=gke `
    --policy-file=POLICY_PATH `
    --project=POLICY_PROJECT_ID
```
Windows (cmd.exe)

Remarque : Assurez-vous d'avoir initialisé Google Cloud CLI avec l'authentification et un projet en exécutant la commande gcloud init ou gcloud auth login et gcloud config set project.
```
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 du CV avec des règles de plate-forme basées sur des vérifications.

Créer un cluster utilisant la surveillance du CV

Dans cette section, vous allez créer un cluster qui n'utilise que la surveillance de 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 stratégie est stockée
POLICY_ID: ID de la règle
CLUSTER_PROJECT_ID: ID du projet de 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 du CV

Dans cette section, vous allez créer un cluster qui utilise à la fois l'application des règles de projet-singleton et la surveillance du 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 stratégie est stockée
POLICY_ID: ID de la règle
CLUSTER_PROJECT_ID: ID du projet de 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 du CV

Dans cette section, vous allez mettre à jour un cluster pour qu'il n'utilise la surveillance du CV qu'avec des règles de plate-forme basées sur des vérifications. Si l'application de la règle de projet unique 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 en activant l'application forcée et la surveillance du CV.

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 stratégie est stockée
POLICY_ID: ID de la règle
CLUSTER_PROJECT_ID: ID du projet de 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 des CV

Dans cette section, vous allez mettre à jour un cluster pour utiliser à la fois l'application des règles de projet unique et la surveillance du 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: ID du projet dans lequel la stratégie est stockée
POLICY_ID: ID de la règle
CLUSTER_PROJECT_ID: ID du projet de 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

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 du projet de cluster
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é. Comme l'image a été créée à partir d'une provenance et provient d'un dépôt de code source fiable, elle n'enfreint pas la vérification SLSA de la CV et aucune entrée de journal n'est générée.

Pour forcer le non-respect de la vérification SLSA, vous pouvez définir SOURCE_REPO_NAME sur un dépôt de code source autre que celui où se trouve votre image. Vous pouvez également déclencher manuellement la compilation, ce qui ignore la génération de la provenance. Vérifiez ensuite les entrées de journal.

Afficher les journaux des entrées CV

CV consigne les cas de non-respect des règles de plate-forme dans Cloud Logging sous 24 heures. Les entrées apparaissent généralement au bout de 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 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 du cluster.

Vérifier les types

Les journaux CV vérifient les cas de non-conformité dans checkResults. Dans l'entrée, la valeur checkType indique la vérification. Les valeurs de chaque vérification sont les suivantes:

ImageFreshnessCheck
SimpleSigningAttestationCheck
SlsaCheck
TrustedDirectoryCheck
VulnerabilityCheck

Exemple de journal

L'exemple d'entrée de journalisation CV ci-dessous décrit une image non conforme qui ne respecte pas une vérification de l'annuaire 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 du CV que vous avez configurée précédemment dans ce guide.

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

Désactiver l'autorisation binaire dans un cluster

Pour désactiver l'application forcée du CV et 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 du projet de cluster

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

Pour désactiver la CV avec des règles basées sur les vérifications dans le cluster et réactiver l'application à 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 du projet de cluster

Notez que --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE est équivalent à l'ancien indicateur --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 les 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 stratégie

Utiliser la vérification SLSA

Coûts

Avant de commencer

Rôles requis

Présentation

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

Facultatif: créer et importer un exemple d'image

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

Créer et importer l'exemple d'image

Créer la règle de plate-forme

Linux, macOS ou Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Activer la CV

Créer un cluster utilisant la surveillance du CV

Linux, macOS ou Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

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

Linux, macOS ou Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Mettre à jour un cluster pour utiliser la surveillance du CV

Linux, macOS ou Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

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

Linux, macOS ou Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Déployer l'image

Afficher les journaux des entrées CV

Vérifier les types

Exemple de journal

Effectuer un nettoyage

Désactiver l'autorisation binaire dans un cluster

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

Supprimer la stratégie

Étapes suivantes