Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Ce guide explique comment créer et utiliser des attestations d'autorisation binaire. Une fois l'image de conteneur créée, une attestation peut être créée pour confirmer qu'une activité requise a été effectuée sur l'image telle qu'un test de régression, une analyse des failles ou un autre test. L'attestation est créée en signant le condensé unique de l'image.
Au cours du déploiement, au lieu de répéter les activités, l'autorisation binaire vérifie les attestations à l'aide d'un certificateur. Si toutes les attestations d'une image sont validées, l'autorisation binaire permet le déploiement de l'image.
Les utilisateurs de Cloud Service Mesh doivent simplement configurer la stratégie d'autorisation binaire. Pour ce faire, consultez la section Configurer une stratégie plus loin dans ce guide.
Créer un certificateur
Pour utiliser des attestations, vous devez d'abord créer des certificateurs.
Au moment du déploiement, l'autorisation binaire utilise des certificateurs pour valider l'attestation associée à l'image de conteneur.
Vous pouvez créer des certificateurs à l'aide des méthodes suivantes :
Les utilisateurs de Cloud Service Mesh peuvent créer des règles (y compris des règles nécessitant des attestations) s'appliquant à une identité de service de réseau maillé, à un compte de service Kubernetes ou à un espace de noms Kubernetes.
Pour configurer une règle spécifique, utilisez les méthodes suivantes :
Les attestations sont créées par un signataire.
Le processus de création d'une attestation est également appelé signature d'une image.
Un signataire peut être une personne qui crée manuellement une attestation. Un signataire peut également être un service automatisé. Pour obtenir des instructions décrivant différentes approches de la création d'attestations, consultez les pages suivantes :
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/04/21 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/04/21 (UTC)."],[[["\u003cp\u003eThis guide explains the process of creating and using attestations in Binary Authorization to verify container images before deployment.\u003c/p\u003e\n"],["\u003cp\u003eAttestations, which are created by signing an image's digest, affirm that certain activities, like regression tests or vulnerability scans, have been performed.\u003c/p\u003e\n"],["\u003cp\u003eBinary Authorization uses attestors to verify attestations at deploy time, and only allows deployment if all attestations are confirmed.\u003c/p\u003e\n"],["\u003cp\u003eAttestors can be created using the Google Cloud CLI or the Google Cloud console, and policies can be configured to require attestations for GKE, Cloud Run, Google Distributed Cloud, and Cloud Service Mesh.\u003c/p\u003e\n"],["\u003cp\u003eAfter creating an attestation, the associated image is ready for deployment, and there are different ways to deploy based on the product.\u003c/p\u003e\n"]]],[],null,["# Attestations overview\n\nThis guide describes how to create and use Binary Authorization\n[attestations](/binary-authorization/docs/key-concepts#attestations). After a container image is\nbuilt, an attestation can be created to affirm that a required activity was\nperformed on the image such as a regression test, vulnerability scan, or\nother test. The attestation is created by signing the image's unique digest.\n\nDuring deployment, instead of repeating the activities, Binary Authorization\nverifies the attestations using an attestor. If all of the attestations for\nan image are verified, Binary Authorization allows the image to be deployed.\n\nBefore you begin\n----------------\n\n1. [Enable Binary Authorization](/binary-authorization/docs/enabling).\n\n2. Set up Binary Authorization with one of the following products:\n\n - [Binary Authorization for Google Kubernetes Engine (GKE)](/binary-authorization/docs/setting-up)\n - [Binary Authorization for Cloud Run](/binary-authorization/docs/run/enabling-binauthz-cloud-run)\n - [Binary Authorization for Google Distributed Cloud](/binary-authorization/docs/setting-up-on-prem)\n\nCloud Service Mesh users need to only\nset up the Binary Authorization policy. To do so, see\n[Configure a policy](#config_policy), later in this guide.\n\nCreate an attestor\n------------------\n\nTo use attestations, you first create [attestors](/binary-authorization/docs/key-concepts#attestors).\nAt deploy time, Binary Authorization uses attestors to verify the\nattestation associated with the container image.\n| **Note:** Cloud Build users, you can use the `built-by-cloud-build` attestor to [deploy only images built by Cloud Build](/binary-authorization/docs/deploy-cloud-build).\n\nYou can create attestors using the following methods:\n\n- The [Google Cloud CLI](/binary-authorization/docs/creating-attestors-cli)\n- The [Google Cloud console](/binary-authorization/docs/creating-attestors-console)\n\nConfigure a policy rule to require attestations\n-----------------------------------------------\n\nThis section describes how to configure the policy to require attestations. \n\n### GKE\n\n- Configure the default rule to require attestations using the following\n methods:\n\n - The [Google Cloud console](/binary-authorization/docs/configuring-policy-console#default-rule)\n - The [command-line tool](/binary-authorization/docs/configuring-policy-cli#default-rule)\n- Configure a cluster-specific rule to require attestations using the following\n methods:\n\n - The [Google Cloud console](/binary-authorization/docs/configuring-policy-console#add-cluster-name-gke)\n - The [command-line tool](/binary-authorization/docs/configuring-policy-cli#set_cluster_specific_rules)\n\n### Cloud Run\n\nConfigure the default rule to require attestations using one of the\nfollowing methods:\n\n- [The Google Cloud console](/binary-authorization/docs/configuring-policy-console)\n- [The command-line tool](/binary-authorization/docs/configuring-policy-cli)\n\n### Distributed Cloud\n\n- Configure the default rule to require attestations using the following methods:\n - The [Google Cloud console](/binary-authorization/docs/configuring-policy-console#default-rule)\n - The [command-line tool](/binary-authorization/docs/configuring-policy-cli#default-rule)\n- Configure a cluster-specific rule to require attestations using the following methods:\n - The [Google Cloud console](/binary-authorization/docs/configuring-policy-console#add-cluster-name-anthos)\n - The [command-line tool](/binary-authorization/docs/configuring-policy-cli#set_cluster_specific_rules)\n\n### Cloud Service Mesh\n\nCloud Service Mesh users can create\nrules---including rules that require attestations---that are scoped to either a\nmesh service identity, a Kubernetes service account, or a Kubernetes\nnamespace.\n\nTo configure a specific rule, use the following methods:\n\n- The [Google Cloud console](/binary-authorization/docs/configuring-policy-console#add-specific-rules-asm)\n- The [command-line tool](/binary-authorization/docs/configuring-policy-cli#set_specific_rules)\n\nCreate attestations\n-------------------\n\nAttestations are created by a [signer](/binary-authorization/docs/key-concepts#signers).\nThe process of creating an attestation is also known as *signing an image*.\nA signer can be a person who manually creates an attestation. Alternatively, a\nsigner can be an automated service. For instructions that describe different\napproaches to creating attestations, see the following pages:\n\n- [Create attestations manually](/binary-authorization/docs/making-attestations) by signing a container image.\n- [Create attestations in a Cloud Build pipeline](/binary-authorization/docs/cloud-build).\n\nDeploy an image\n---------------\n\nAfter you create an attestation, you are ready to deploy the associated image. \n\n### GKE\n\n[Deploy images using GKE](/binary-authorization/docs/deploying-containers).\n\n### Cloud Run\n\n[Deploy images using Cloud Run](/binary-authorization/docs/run/enabling-binauthz-cloud-run).\n\n### Distributed Cloud\n\n[Deploy images using Distributed Cloud](/binary-authorization/docs/deploying-containers).\n\n### Cloud Service Mesh\n\nCloud Service Mesh workloads are enforced as soon as the policy is saved.\n\nWhat's next\n-----------\n\n- [View audit logs](/binary-authorization/docs/viewing-audit-logs)\n- [View Cloud Run breakglass audit logs](/binary-authorization/docs/run/viewing-audit-logs-cloud-run)\n- [Use breakglass (GKE)](/binary-authorization/docs/using-breakglass)\n- [Use breakglass (Cloud Run)](/binary-authorization/docs/run/using-breakglass-cloud-run)\n- [Use image digests in Kubernetes manifests](/architecture/using-container-image-digests-in-kubernetes-manifests)"]]
