Cette page explique comment sécuriser les déploiements d'images Cloud Run et Google Kubernetes Engine à l'aide de Cloud Build.
Découvrez comment configurer l'autorisation binaire pour vérifier la compilation. et de bloquer les déploiements d'images qui ne sont pas générées par Cloud Build. Ce processus peut réduire le risque de déploiement des logiciels non autorisés.
Avant de commencer
Activer les API Cloud Build, Binary Authorization, and Artifact Registry.
Pour utiliser les exemples de ligne de commande de ce guide, installez et configurez SDK Google Cloud :
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
vérifier les attestations et ne déployer que les images créées par Cloud Build.
Pour créer le certificateur built-by-cloud-build
dans votre projet, exécutez une compilation dans
ce projet.
Pour n'autoriser que le déploiement des images créées par Cloud Build, procédez comme suit :
Console
Accédez à la page Autorisation binaire dans Google Cloud Console.
Dans l'onglet Règles, cliquez sur Modifier la règle.
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.
Cliquez sur Ajouter des certificateurs.
Dans la boîte de dialogue Ajouter des certificateurs, procédez comme suit :
- Sélectionnez Ajouter par projet et nom de certificateur, puis procédez comme suit :
- Dans le champ Nom du projet, saisissez le projet dans lequel vous exécutez Cloud Build.
- Cliquez sur le champ Nom du certificateur et notez que le certificateur
built-by-cloud-build
est disponible. - Cliquez sur
built-by-cloud-build
.
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.
- Sélectionnez Ajouter par projet et nom de certificateur, puis procédez comme suit :
Cliquez sur Ajouter un certificateur.
Cliquez sur Save Policy (Enregistrer la stratégie).
gcloud
Exportez votre stratégie existante dans un fichier à l'aide de la commande suivante :
gcloud container binauthz policy export > /tmp/policy.yaml
Modifiez votre fichier de stratégie.
Modifiez l'une des règles suivantes :
defaultAdmissionRule
clusterAdmissionRules
istioServiceIdentityAdmissionRules
kubernetesServiceAccountAdmissionRules
Ajoutez un bloc
requireAttestationsBy
à la règle s'il n'en existe pas déjà un.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.Enregistrez le fichier de stratégie.
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
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
Accédez à la page "Autorisation binaire" dans Google Cloud Console.
Cliquez sur Modifier la règle.
Dans Règle par défaut ou une règle spécifique, sélectionnez Mode de simulation.
Cliquez sur Save Policy (Enregistrer la stratégie).
gcloud
Exportez la stratégie d'autorisation binaire dans un fichier YAML :
gcloud container binauthz policy export > /tmp/policy.yaml
Dans un éditeur de texte, définissez
enforcementMode
surDRYRUN_AUDIT_LOG_ONLY
et enregistrez le fichier.Pour mettre à jour la stratégie, importez le fichier en exécutant la commande suivante :
gcloud container binauthz policy import /tmp/policy.yaml
Vous pouvez afficher les erreurs de stratégie dans les messages de journal de l'autorisation binaire pour GKE ou Cloud Run
Limites
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 une autre les rôles IAM pour une configuration multiprojets, et de faire référence au projet Cloud Build lorsque vous ajoutez le Certificat
built-by-cloud-build
dans l'autorisation binaire.Cloud Build ne génère pas d'attestations lorsque vous transférez des images vers Artifact Registry à l'aide d'une étape de compilation
docker push
explicite. Veillez à transmettre vers Artifact Registry à l'aide du champimages
lors de l'étape de compilationdocker build
. Pour Pour en savoir plus surimages
, consultez Différentes manières de stocker des images dans Artifact Registry.Vous devez utiliser des fichiers de configuration de compilation distincts pour votre pipeline de compilation et le pipeline de déploiement. En effet, Cloud Build génère les attestations qu'une fois le pipeline de compilation terminé. L'autorisation binaire vérifie ensuite l'attestation avant de déployer l'image.
Activer les attestations dans les pools privés
Par défaut, Cloud Build ne génère pas d'autorisation binaire.
les attestations pour les compilations hébergées dans des pools privés. Pour générer
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é requestedVerifyOption
, Cloud Build active
de génération d'attestation et de métadonnées de provenance pour votre
l'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. La
l'ID du certificateur est au format suivant :
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": "service-942118413832@gcp-binaryauthorization.iam.gserviceaccount.com" }, "updateTime": "2021-09-24T15:26:44.808914Z", "description": "Attestor autogenerated by build ID fab07092-30f4-4f70-caf7-4545cbc404d6"
Étape suivante
- Découvrez l'autorisation binaire.