Contrôler le déploiement d'images à l'aide de l'autorisation binaire

Preview

Ce produit ou cette fonctionnalité est soumis aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent bénéficier d'une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Cette page explique comment utiliser l'autorisation binaire pour autoriser uniquement le déploiement d'images compilées par Cloud Build.

Avant de commencer

1. Enable the Cloud Build, Binary Authorization, and Artifact Registry APIs.

   Enable the APIs

2. Pour utiliser les exemples de ligne de commande de ce guide, installez et configurez le SDK Google Cloud.

   Remarque : Si vous avez déjà installé le SDK Google Cloud, assurez-vous d'utiliser la dernière version disponible en exécutant gcloud components update.

3. Configurez l'autorisation binaire pour votre plate-forme.

Contrôler les déploiements avec l'autorisation binaire

Dans l'autorisation binaire, une stratégie est un ensemble de règles régissant le déploiement d'une ou plusieurs images de conteneurs. Vous pouvez configurer une règle pour exiger des attestations signées numériquement.

Cloud Build génère et signe des attestations au moment de la compilation. Avec l'autorisation binaire, vous pouvez utiliser le certificateur built-by-cloud-build pour valider les attestations et ne déployer que des images compilées par Cloud Build.

Pour créer le certificateur built-by-cloud-build dans votre projet, exécutez un build dans ce projet.

Pour n'autoriser que le déploiement des images créées par Cloud Build, procédez comme suit :

Console

1. Accédez à la page Autorisation binaire dans Google Cloud Console.

   Accéder à la page "Autorisation binaire"

2. Dans l'onglet Règles, cliquez sur Modifier la règle.

3. Dans la boîte de dialogue Modifier la stratégie, sélectionnez Autoriser uniquement les images qui ont été approuvées par tous les certificateurs suivants.

4. Cliquez sur Ajouter des certificateurs.

5. Dans la boîte de dialogue Ajouter des certificateurs, procédez comme suit :

   1. Sélectionnez Ajouter par projet et nom de certificateur, puis procédez comme suit :
      1. Dans le champ Nom du projet, saisissez le projet dans lequel vous exécutez Cloud Build.
      2. Cliquez sur le champ Nom du certificateur et notez que le certificateur built-by-cloud-build est disponible.
      3. Cliquez sur built-by-cloud-build.

   2. Vous pouvez également sélectionner Ajouter par ID de ressource de certificateur. Dans le champ ID de ressource du certificateur, saisissez

      projects/PROJECT_ID/attestors/built-by-cloud-build
      

      Remplacez PROJECT_ID par le projet dans lequel vous exécutez Cloud Build.

6. Cliquez sur Ajouter un certificateur.

7. Cliquez sur Save Policy (Enregistrer la stratégie).

gcloud

1. Exportez votre stratégie existante dans un fichier à l'aide de la commande suivante :

   gcloud container binauthz policy export > /tmp/policy.yaml
   

2. Modifiez votre fichier de stratégie.

3. Modifiez l'une des règles suivantes :

   • defaultAdmissionRule
   • clusterAdmissionRules
   • istioServiceIdentityAdmissionRules
   • kubernetesServiceAccountAdmissionRules

4. Ajoutez un bloc requireAttestationsBy à la règle s'il n'en existe pas déjà un.

5. Dans le bloc requireAttestationsBy, ajoutez :

   projects/PROJECT_ID/attestors/built-by-cloud-build
   

   Remplacez PROJECT_ID par le projet dans lequel vous exécutez Cloud Build.

6. Enregistrez le fichier de stratégie.

7. Importez le fichier de stratégie.

   gcloud container binauthz policy import /tmp/policy.yaml
   

   Voici un exemple de fichier de stratégie contenant la référence au fichier built-by-cloud-build-attestor :

   defaultAdmissionRule:
     evaluationMode: REQUIRE_ATTESTATION
     enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
     requireAttestationsBy:
       - projects/PROJECT_ID/attestors/built-by-cloud-build
   name: projects/PROJECT_ID/policy
   

   Remplacez PROJECT_ID par l'ID du projet dans lequel vous exécutez Cloud Build.

Vous pouvez afficher les erreurs de stratégie dans les messages de journal d'autorisation binaire pour GKE ou Cloud Run

Remarque : Cloud Build ne génère pas d'attestations pour les compilations dans un pool privé. Vous pouvez activer les attestations pour les builds dans des pools privés en ajoutant une option à votre fichier de compilation.

Utiliser le mode de simulation

En mode de simulation, l'autorisation binaire vérifie la conformité avec la stratégie sans bloquer réellement le déploiement. Au lieu de cela, les messages d'état concernant la conformité avec la stratégie sont enregistrés dans Cloud Logging. Ces journaux vous permettent de déterminer si votre règle de blocage fonctionne correctement et d'identifier les faux positifs.

Pour activer le mode de simulation, procédez comme suit :

Console

1. Accédez à la page d'autorisation binaire dans Google Cloud Console.

   Accéder à la page "Autorisation binaire"

2. Cliquez sur Modifier la règle.

3. Dans Règle par défaut ou une règle spécifique, sélectionnez Mode de simulation.

   Remarque : Pour illustrer le mode simulation, vous pouvez également définir la règle sur Interdire toutes les images. Avec ce paramètre, toutes les images qui enfreignent la stratégie ne peuvent pas être déployées et les violations sont consignées.

4. Cliquez sur Save Policy (Enregistrer la stratégie).

gcloud

1. Exportez la stratégie d'autorisation binaire dans un fichier YAML :

   gcloud container binauthz policy export  > /tmp/policy.yaml
   

2. Dans un éditeur de texte, définissez enforcementMode sur DRYRUN_AUDIT_LOG_ONLY et enregistrez le fichier.

   Remarque : Pour illustrer le mode simulation, vous pouvez définir evaluationMode sur ALWAYS_DENY. Avec ce paramètre, toutes les images qui enfreignent la stratégie ne peuvent pas être déployées et les violations sont consignées.

3. Pour mettre à jour la stratégie, importez le fichier en exécutant la commande suivante :

   gcloud container binauthz policy import /tmp/policy.yaml
   

Remarque : La règle peut nécessiter quelques minutes pour prendre effet.

Vous pouvez afficher les erreurs de stratégie dans les messages de journal d'autorisation binaire pour GKE ou Cloud Run

Limites

Pour suivre les instructions de cette page, Cloud Build et l'autorisation binaire doivent se trouver dans le même projet. Si vous exécutez votre plate-forme de déploiement dans un autre projet, reportez-vous au projet Cloud Build lors de l'ajout du certificateur built-by-cloud-build dans l'autorisation binaire.

Activer les attestations dans les pools privés

Par défaut, Cloud Build ne génère pas d'attestations d'autorisation binaire pour les builds dans des pools privés. Pour générer des attestations, ajoutez l'option requestedVerifyOption: VERIFIED à votre fichier de configuration de compilation :

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'us-central1-docker.pkg.dev/$PROJECT_ID/quickstart-docker-repo/quickstart-image:tag1', '.' ]
images:
- 'us-central1-docker.pkg.dev/$PROJECT_ID/quickstart-docker-repo/quickstart-image:tag1'
options:
  requestedVerifyOption: VERIFIED

Après avoir ajouté la propriété requestedVerifyOption, Cloud Build active la génération d'attestations et les métadonnées de provenance pour votre image.

Afficher les métadonnées du certificateur

Un certificateur est créé la première fois que vous exécutez une compilation dans un projet. L'ID du certificateur est au format projects/PROJECT_ID/attestors/built-by-cloud-build, où PROJECT_ID est l'ID de votre projet.

Vous pouvez vérifier les métadonnées du certificateur de compilation à l'aide de la commande suivante :

curl -X GET -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://binaryauthorization.googleapis.com/v1beta1/projects/PROJECT_ID/attestors/built-by-cloud-build

Remplacez PROJECT_ID par le projet dans lequel vous exécutez Cloud Build.

La sortie contient des informations sur le certificateur et les clés publiques correspondantes. Exemple :

name": "projects/PROJECT_ID/attestors/built-by-cloud-build",
  "userOwnedDrydockNote": {
    "noteReference": "projects/PROJECT_ID/notes/built-by-cloud-build",
    "publicKeys": [
      {
        "id": "//cloudkms.googleapis.com/v1/projects/verified-builder/locations/asia/keyRings/attestor/cryptoKeys/builtByGCB/cryptoKeyVersions/1",
        "pkixPublicKey": {
          "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEMMvFxZLgIiWOLIXsaTkjTmOKcaK7\neIZrgpWHpHziTFGg8qyEI4S8O2/2wh1Eru7+sj0Sh1QxytN/KE5j3mTvYA==\n-----END PUBLIC KEY-----\n",
          "signatureAlgorithm": "ECDSA_P256_SHA256"
        }
      },
...
      }
    ],
    "delegationServiceAccountEmail": "[e-mail]"
  },
  "updateTime": "2021-09-24T15:26:44.808914Z",
  "description": "Attestor autogenerated by build ID fab07092-30f4-4f70-caf7-4545cbc404d6"

Étapes suivantes

• Mettez en œuvre l'autorisation binaire à l'aide de Cloud Build et de Google Kubernetes Engine.