Concepts de l'autorisation binaire

Cette page contient des informations sur les concepts liés à l'autorisation binaire.

Règles

Une stratégie d'autorisation binaire, également appelée stratégie Singleton de projet, est un ensemble de règles régissant le déploiement d'images de conteneurs.

La validation continue (CV) utilise un type de règle différent, appelé règle de plate-forme.

Une stratégie se compose des éléments suivants :

Vous pouvez configurer une stratégie à l'aide de l'une des méthodes suivantes :

  • Google Cloud Console
  • Commandes gcloud

Lorsque vous utilisez des commandes gcloud, vous exportez et modifiez une définition de la stratégie au format YAML avant de l'importer de nouveau dans votre projet. Le format YAML reflète la structure interne d'une stratégie dans l'espace de stockage de l'autorisation binaire. Pour en savoir plus sur ce format, consultez la documentation de référence sur les fichiers YAML de stratégie.

Chaque projet Google Cloud ne peut avoir qu'une seule stratégie. Vous devez configurer cette règle dans le projet dans lequel vous exécutez votre plate-forme de déploiement. Dans une configuration à projet unique, la stratégie et toutes les ressources subordonnées (certificateurs et attestations) résident dans. le même projet. Pour établir une séparation des tâches, vous pouvez utiliser une configuration multiprojets. Dans cette configuration, la plate-forme de déploiement peut s'exécuter dans un projet, les certificateurs peuvent résider dans un autre projet, et les attestations peuvent résider dans un autre projet.

Pour configurer et utiliser l'autorisation binaire sur les plates-formes compatibles, consultez la page Configurer par plate-forme.

Consultez un exemple de configuration multiprojet pour GKE.

Règles

Lorsque vous configurez une stratégie, vous définissez ses règles. Les règles définissent les contraintes que les images doivent respecter pour pouvoir être déployées. Une stratégie dispose d'une règle par défaut et peut comporter des règles spécifiques en fonction de la plate-forme. Pour en savoir plus, consultez la section Types de règles compatibles par plate-forme.

Chaque règle peut être configurée avec un mode d'évaluation et un mode d'application. Par exemple, une règle peut exiger qu'une image comporte une attestation avant de pouvoir être déployée.

Règle par défaut

Chaque stratégie comporte une règle par défaut. Cette règle s'applique à toute requête de déploiement qui ne correspond pas à une règle spécifique à un cluster. Dans un fichier YAML de stratégie, la règle par défaut est spécifiée dans le nœud defaultAdmissionRule.

Pour plus d'informations sur la configuration de la règle par défaut, consultez la page Configurer une stratégie.

Règles spécifiques

Vous pouvez ajouter une ou plusieurs règles spécifiques à une stratégie. Ce type de règle s'applique aux images qui doivent être déployées sur des clusters, un compte de service ou une identité spécifiques. La compatibilité de ces règles varie selon la plate-forme. Pour en savoir plus, consultez la section Types de règles compatibles par plate-forme.

Dans un fichier YAML de stratégie, chaque règle spécifique à un cluster est spécifiée dans un nœud clusterAdmissionRule.

Types de règles compatibles par plate-forme

Le tableau suivant indique les types de règles compatibles avec chaque plate-forme de déploiement.

Plate-forme Règle par défaut Règle spécifique
GKE Compatible Clusters
Espaces de noms Kubernetes
Comptes de service Kubernetes
Cloud Run Compatible Non compatible
Clusters associés à GKE Compatible Clusters
Espaces de noms Kubernetes
Comptes de service Kubernetes
GKE sur AWS Compatible Clusters
Espaces de noms Kubernetes
Comptes de service Kubernetes
GKE sur solution Bare Metal Compatible Clusters
Espaces de noms Kubernetes
Comptes de service Kubernetes
GKE sur VMware Compatible Clusters
Espaces de noms Kubernetes
Comptes de service Kubernetes
Anthos Service Mesh Compatible Identités pour le service Anthos Service Mesh

Modes d'évaluation

Chaque règle dispose d'un mode d'évaluation qui spécifie le type de contrainte appliqué par l'autorisation binaire pour la règle. Le mode d'évaluation d'une règle est spécifié à l'aide de la propriété evaluationMode du fichier YAML de stratégie.

Il existe trois modes d'évaluation :

  • Autoriser toutes les images : permet de déployer toutes les images.
  • Refuser toutes les images : empêche le déploiement de toutes les images.
  • Exiger des attestations : nécessite qu'un signataire signe le condensé numérique de l'image et crée une attestation avant le déploiement. Au moment du déploiement, l'outil d'application de l'autorisation binaire utilise un certificateur pour valider la signature de l'attestation avant de déployer l'image associée.

Les modes d'exécution

Chaque règle dispose également d'un mode d'application qui spécifie l'action entreprise par GKE lorsqu'une image ne respecte pas la règle. Une règle peut avoir les modes d'application suivants :

  • Block and Audit Log (Blocage et écriture dans le journal d'audit) : bloque le déploiement d'images non conformes à la règle et écrit un message dans le journal d'audit pour indiquer pourquoi l'image n'a pas été déployée.

  • Dry Run: Audit Log Only (Simulation : écriture dans le journal d'audit uniquement) : le mode simulation est un mode d'application d'une stratégie qui permet de déployer des images non conformes et qui écrit des informations sur le déploiement dans Cloud Audit Logs. Le mode de simulation vous permet de tester une stratégie, par exemple dans votre environnement de production, avant son application effective.

La plupart des règles de production utilisent le mode d'application Blocage et écriture dans le journal d'audit. Le mode Simulation : écriture dans le journal d'audit uniquement est principalement utilisé pour tester une stratégie dans votre environnement avant son entrée en vigueur.

Le mode d'application d'une règle est spécifié à l'aide de la propriété enforcementMode dans le fichier YAML de stratégie.

Consultez la page Afficher les journaux d'audit (GKE, clusters GKE, Anthos Service Mesh) ou Afficher les journaux d'audit (Cloud Run) pour en savoir plus sur les messages écrits dans Cloud Audit Logs.

Validation continue

La validation continue (CV, Continuous Validation) est une fonctionnalité de l'autorisation binaire qui vérifie régulièrement les images associées aux pods en cours d'exécution pour assurer la conformité avec les règles.

En savoir plus sur la CV

Images exclues

Une image exclue est une image exclue des règles définies dans la stratégie. L'autorisation binaire permet toujours le déploiement des images exclues. Chaque projet dispose d'une liste d'autorisation d'images exclues, lesquelles sont spécifiées par leur chemin d'accès au registre. Les images du chemin gcr.io/google_containers/*, k8s.gcr.io/** et les autres chemins d'accès sont exclues par défaut, car elles contiennent des ressources requises pour que GKE puisse démarrer un cluster avec la stratégie par défaut active.

Pour ajouter une image exclue à la liste d'autorisation, ajoutez ce qui suit au fichier de stratégie :

admissionWhitelistPatterns:
  - namePattern: EXEMPT_IMAGE_PATH

Remplacez EXEMPT_IMAGE_PATH par le chemin d'accès à l'image à exclure. Pour exclure des images supplémentaires, ajoutez d'autres entrées - namePattern. En savoir plus sur admissionWhitelistPatterns.

Modèles de listes d'autorisation

Pour ajouter à la liste d'autorisation toutes les images dont l'emplacement du registre correspond au chemin d'accès spécifié, exécutez la commande suivante :

gcr.io/example-project/*

Pour ajouter à la liste d'autorisation toutes les images dont l'emplacement du registre correspond à n'importe quel sous-répertoire du chemin spécifié (par exemple, gcr.io/example-project/my-directory/helloworld) :

gcr.io/example-project/**

Pour ajouter à la liste d'autorisation une image spécifique, procédez comme suit :

gcr.io/example-project/helloworld

Pour ajouter à la liste d'autorisation une version spécifique d'une image, identifiée par son tag, utilisez l'exemple de code ci-dessous :

gcr.io/example-project/helloworld:latest
gcr.io/example-project/helloworld:my-tag

Pour ajouter à la liste d'autorisation tous les versions/tags d'une image, procédez comme suit :

gcr.io/example-project/helloworld:*

Pour ajouter à la liste d'autorisation une version spécifique d'une image, identifiée par son condensé, utilisez l'exemple de code ci-dessous :

gcr.io/example-project/helloworld@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c

En savoir plus sur l'utilisation des condensés d'images de conteneur.

Découvrez comment gérer les images exclues dans la console Google Cloud, à l'aide de l'outil de ligne de commande ou de l'API REST.

Images système gérées par Google

Le paramètre Trust all Google-maintained system images (Faire confiance à toutes les images système gérées par Google) permet à l'autorisation binaire d'exempter une liste d'images système gérées par Google d'une évaluation plus approfondie par la stratégie. Lorsque ce paramètre est activé, les images requises par GKE ne sont pas bloquées par l'application de la stratégie. La stratégie système est évaluée avant et en plus de l'évaluation de la stratégie utilisateur.

Vous pouvez activer ou désactiver ce paramètre à l'aide de la propriété globalPolicyEvaluationMode dans le fichier YAML de stratégie. Vous pouvez afficher le contenu de la stratégie système à l'aide de la commande suivante :

gcloud alpha container binauthz policy export-system-policy

Attestations

Une attestation est un document numérique qui certifie une image. Pendant le déploiement, l'autorisation binaire vérifie l'attestation avant d'autoriser le déploiement de l'image.

Le processus de création d'une attestation est parfois appelé signature d'une image. Une attestation est créée après la création d'une image. Chacune de ces images possède un condensé globalement unique. Un signataire signe le condensé de l'image à l'aide d'une clé privée issue d'une paire de clés, et utilise la signature pour créer l'attestation. Au moment du déploiement, l'outil d'application de l'autorisation binaire utilise la clé publique du certificateur pour valider la signature dans l'attestation. Généralement, un certificateur correspond à un seul signataire.

Une attestation signifie que l'image associée a été créée en exécutant un processus spécifique et obligatoire. Par exemple, si le signataire est un représentant de votre fonction de contrôle qualité (QA), l'attestation peut indiquer que l'image a passé tous les tests fonctionnels de bout en bout dans un environnement de préproduction.

Pour activer les attestations dans l'autorisation binaire, le paramètre evaluationMode de votre stratégie est défini sur REQUIRE_ATTESTATION.

Découvrez comment créer et utiliser des certificateurs et des attestations.

Signataires

Un signataire est une personne ou un processus automatisé qui crée une attestation en signant un descripteur d'image unique avec une clé privée. L'attestation est validée au moment du déploiement par la clé publique correspondante stockée dans un certificateur avant le déploiement de l'image associée.

Découvrez comment créer et utiliser des certificateurs et des attestations.

Attestataires

Un certificateur est une ressource Google Cloud utilisée par l'autorisation binaire pour valider l'attestation au moment du déploiement de l'image. Les certificateurs contiennent la clé publique correspondant à la clé privée utilisée par un signataire pour signer le condensé de l'image et créer l'attestation. L'outil d'application de l'autorisation binaire utilise le certificateur au moment du déploiement pour limiter les images pouvant être déployées à celles accompagnées d'une attestation vérifiable créée avant le déploiement.

Les certificateurs peuvent être gérés par le personnel chargé des opérations de sécurité qui gère également les paires de clés publique et privée, tandis que les signataires sont généralement des ingénieurs logiciels, ou des équipes de contrôle qualité ou de conformité DevOps chargés de produire des images de conteneurs déployables, de les signer avec la clé privée et de créer les attestations avant de les déployer.

Les certificateurs disposent des éléments suivants :

Lorsque vous configurez une stratégie contenant une règle d'Require Attestations (Exiger des attestations), vous devez ajouter un certificateur pour chaque personne ou processus devant vérifier que l'image est prête à être déployée. Vous pouvez ajouter des certificateurs à l'aide de Google Cloud Console, de l'interface gcloud ou de l'API REST d'autorisation binaire.

Découvrez comment créer et utiliser des certificateurs et des attestations.

Clés de chiffrement

L'autorisation binaire utilise des signatures numériques pour vérifier les images au moment du déploiement, lorsque la stratégie contient une règle d'Require Attestations (Exiger des attestations).

Une paire de clés est générée. La clé privée est utilisée par le signataire pour signer un descripteur d'image. Cela crée une attestation.

Un certificateur est ensuite créé et stocké dans la stratégie. La clé publique correspondant à la clé privée utilisée pour la signature est importée et associée au certificateur.

Lorsqu'une tentative de déploiement d'une image est effectuée, l'autorisation binaire utilise des certificateurs dans la stratégie pour vérifier les attestations de l'image. Si l'attestation peut être validée, l'image est déployée.

L'autorisation binaire est compatible avec deux types de clés :

Les clés PKIX peuvent être stockées localement, en externe ou dans Cloud Key Management Service.

Créez une clé cryptographique et un certificateur.

Notes Artifact Analysis

L'autorisation binaire utilise Container Analysis pour stocker les métadonnées de confiance utilisées dans le processus d'autorisation. Pour chaque certificateur que vous créez, vous devez créer une note Artifact Analysis. Chaque attestation est stockée en tant qu'occurrence de cette note.

Lorsque l'autorisation binaire évalue une règle qui exige que des certificateurs aient validé une image, elle vérifie que les attestations requises sont présentent dans l'espace de stockage de Artifact Analysis.