Concepts clés

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

Stratégies

Une stratégie d'autorisation binaire est un ensemble de règles régissant le déploiement des images de conteneurs dans Google Kubernetes Engine (GKE). 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 Platform (GCP) ne peut avoir qu'une seule stratégie. Dans une configuration à projet unique, cette stratégie régit le déploiement vers GKE, où toutes les ressources du pipeline de déploiement font partie du même projet. Pour une configuration multiprojets, une seule stratégie peut régir le déploiement d'images de Container Registry d'un projet sur un cluster GKE s'exécutant dans un autre projet.

Pour en savoir plus, consultez les pages Configurer une stratégie à l'aide de la CLI et Configurer une stratégie à l'aide de la console.

Règles

Une règle est la partie d'une stratégie qui définit les contraintes que les images de conteneurs doivent respecter pour pouvoir être déployées. Le plus souvent, une règle nécessite une ou plusieurs attestations signées numériquement. Lorsque la signature de chaque attestation requise est validée (ce qui indique que tous les processus internes requis sont terminés), le conteneur peut être déployé. Une règle peut également autoriser ou refuser tous les déploiements depuis des chemins d'accès Container Registry spécifiques et/ou vers des clusters GKE spécifiques.

Vous définissez des règles lorsque vous configurez une stratégie. Une stratégie dispose d'une règle par défaut et d'un nombre illimité de règles spécifiques à un cluster.

Règles 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. Si la stratégie ne comporte pas de règle spécifique à un cluster, la règle par défaut s'applique toujours. Dans un fichier YAML de stratégie, la règle par défaut est spécifiée dans le nœud defaultAdmissionRule.

Règles spécifiques à un cluster

Une stratégie peut également comporter une ou plusieurs règles spécifiques à un cluster. Ce type de règle s'applique aux images de conteneurs qui ne doivent être déployées que sur des clusters GKE spécifiques. Dans un fichier YAML de stratégie, chaque règle spécifique à un cluster est spécifiée dans un nœud clusterAdmissionRule.

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
  • Deny All Images (Refuser toutes les images)
  • Require Attestations (Exiger des attestations)

Une règle Require Attestations nécessite qu'un signataire signe le condensé numérique de l'image de conteneur 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 de conteneur associée.

Modes d'application

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) : autorise le déploiement d'images non conformes, mais écrit des informations sur les violations dans le journal d'audit.

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 section Consulter les journaux d'audit pour plus d'informations sur les messages écrits dans Cloud Logging.

Images exclues

Une image exclue est une image de conteneur 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 exemptés 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.

La liste d'autorisation des images exclues est spécifiée à l'aide de la propriété admissionWhitelistPatterns du fichier YAML de stratégie.

Modèles de listes d'autorisation

Pour ajouter à la liste d'autorisation toutes les images de conteneurs 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 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 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

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 globale 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 globale à l'aide de la commande suivante :

gcloud container binauthz policy export --project=binauthz-global-policy

Attestations

Une attestation est un document numérique certifiant que GKE est autorisé à déployer l'image de conteneur.

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 de conteneur. Chacun de ces conteneurs possède un condensé globalement unique. Un signataire signe le condensé de l'image de conteneur à 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 de conteneur associée a été créée par un processus spécifique et obligatoire qui a bien été exécuté. Par exemple, si le signataire est un représentant de votre fonction de contrôle qualité (QA), l'attestation peut indiquer que l'image de conteneur 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 enforcementMode de votre stratégie est défini sur REQUIRE_ATTESTATION.

Consultez la présentation de l'autorisation binaire pour découvrir des cas d'utilisation types.

Pour savoir comment créer une attestation, consultez la page Créer des attestations.

Signataires

Un signataire est une personne ou un processus automatisé qui crée une attestation en signant un descripteur d'image de conteneur 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 du conteneur associé.

Certificateurs

Un certificateur est une ressource GCP utilisée par l'autorisation binaire pour valider l'attestation au moment du déploiement de l'image de conteneur. Les certificateurs contiennent la clé publique correspondant à la clé privée utilisée par un signataire pour signer le condensé de l'image de conteneur 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 de conteneurs pouvant être déployées à celles accompagnées d'une attestation vérifiable créée avant le déploiement.

En tant que tels, 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 de conteneur 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.

Pour en savoir plus, consultez la page Créer des certificateurs à l'aide de la CLI ou Créer des certificateurs à l'aide de la console.

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 de conteneur. 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.

Au moment du déploiement, GKE appelle l'outil d'application de l'autorisation binaire, qui utilise des certificateurs dans la stratégie pour vérifier la validité des attestations associées, garantissant ainsi que chaque image de conteneur signée numériquement est autorisée pour le déploiement.

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.

Notes Container 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 Container 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 Container Analysis.