Configurer une stratégie à l'aide de la CLI gcloud

Cette page explique comment configurer une stratégie d'autorisation binaire à l'aide de Google Cloud CLI. Vous pouvez également effectuer ces tâches à l'aide de la consoleGoogle Cloud ou de l'API REST. Cette étape fait partie de la configuration de l'autorisation binaire.

Pour configurer une stratégie à l'aide de l'outil de ligne de commande, exportez la stratégie existante sous forme de fichier YAML. Une fois le fichier modifié, vous pouvez l'importer pour mettre à jour la stratégie, comme décrit plus loin dans ce guide. Pour plus d'informations sur le format YAML de stratégie, consultez la documentation de référence sur les fichiers YAML de stratégie.

Avant de commencer

  1. Activer l'autorisation binaire.
  2. Créez un cluster.
  3. Si vous avez l'intention d'utiliser des attestations, nous vous recommandons de créer des certificateurs avant de configurer la stratégie. Vous pouvez créer des certificateurs à l'aide d'un outil de ligne de commande ou de la consoleGoogle Cloud .

  4. Définissez l'ID du projet dans lequel vous avez activé l'autorisation binaire :

    PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}

Exporter le fichier YAML de stratégie

Cette section s'applique à GKE, Distributed Cloud, Cloud Run et Cloud Service Mesh.

Pour mettre à jour la stratégie, commencez par l'exporter vers un fichier YAML local, comme suit :

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

Par défaut, le contenu du fichier ressemble à ceci :

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_ALLOW
globalPolicyEvaluationMode: ENABLE
name: projects/PROJECT_ID/policy

Pour modifier la stratégie, modifiez le fichier et ajoutez ou mettez à jour des sections, comme décrit plus loin dans ce guide. Après avoir enregistré le fichier, vous pouvez importer la règle.

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 que vous souhaitez exclure. Pour exclure d'autres images, ajoutez d'autres entrées - namePattern. En savoir plus sur admissionWhitelistPatterns.

Définir la règle par défaut

Cette section s'applique à GKE, Distributed Cloud, Cloud Run et Cloud Service Mesh.

Une règle est la partie d'une stratégie qui définit les contraintes que les images de conteneur doivent respecter pour pouvoir être déployées. La règle par défaut définit les contraintes qui s'appliquent à toutes les images de conteneur non exclues qui ne possèdent pas leurs propres règles spécifiques au cluster. Chaque stratégie doit inclure une règle par défaut.

La règle par défaut est définie dans le nœud defaultAdmissionRule du fichier YAML de la stratégie. Pour en savoir plus sur les éléments de cette règle, consultez la section ADMISSION_RULE dans la documentation de référence sur les fichiers YAML de stratégie. Pour obtenir des exemples de règles par défaut, consultez la page Exemples de stratégies.

Pour définir la règle par défaut, modifiez le nœud defaultAdmissionRule dans le fichier policy.yaml selon vos besoins :

defaultAdmissionRule:
  evaluationMode: EVALUATION_MODE
  enforcementMode: ENFORCEMENT_MODE
  requireAttestationsBy:
  - ATTESTOR
  - ...

Remplacez les éléments suivants :

  • EVALUATION_MODE : le mode d'évaluation spécifie le type de contrainte appliqué par l'outil d'application de l'autorisation binaire au moment du déploiement. Remplacez EVALUATION_MODE par l'un des éléments suivants :

    • ALWAYS_ALLOW : permet de déployer toutes les images.
    • ALWAYS_DENY : empêche le déploiement de toutes les images.
    • REQUIRE_ATTESTATION : permet de déployer une image si elle contient une ou plusieurs attestations pouvant être validées par tous les certificateurs que vous ajoutez à cette règle. Au moment du déploiement, l'outil d'application vérifie l'attestation à l'aide des certificateurs que vous ajoutez à la liste ATTESTOR de cette règle. Pour en savoir plus sur la création de certificateurs, consultez la page Créer des certificateurs. Si vous spécifiez REQUIRE_ATTESTATION, vous devez également ajouter un bloc requireAttestationsBy contenant au moins un certificateur. Pour en savoir plus sur la création de certificateurs, consultez la page Créer des certificateurs.

  • ENFORCEMENT_MODE : le mode d'application spécifie la manière dont l'outil d'application répond lorsqu'une image enfreint une règle. Remplacez ENFORCEMENT_MODE par l'un des éléments suivants :

    • ENFORCED_BLOCK_AND_AUDIT_LOG : bloque les images qui ne respectent pas la règle et consignent des informations sur les violations dans Cloud Audit Logging (par défaut).
    • DRYRUN_AUDIT_LOG_ONLY : permet de déployer toutes les images mais consigne les informations d'application, y compris les informations sur les violations, dans les journaux d'audit Cloud.

  • ATTESTOR : si vous définissez EVALUATION_MODE sur REQUIRE_ATTESTATION, vous devez également ajouter un bloc requireAttesationsBy. Dans le bloc, répertoriez un ou plusieurs certificateurs, par ID de ressource. L'ID de ressource est au format suivant :

    projects/PROJECT_ID/attestors/ATTESTOR_NAME.

    Pour en savoir plus sur la création de certificateurs, consultez la page Créer des certificateurs.

Gérer les images exclues

Cette section s'applique à GKE, Distributed Cloud, Cloud Run et Cloud Service Mesh.

Une image exclue est une image exclue des règles définies dans la stratégie. L'autorisation binaire permet toujours que les images exclues soient déployées.

Pour spécifier des images exclues, répertoriez leurs chemins de registre dans admissionWhitelistPatterns. Le chemin fait référence à Container Registry ou à un autre registre d'images. Au moment du déploiement, l'autorisation binaire exclut la liste des images spécifiées par admissionWhitelistPatterns après les images spécifiées par la stratégie système.

Pour ajouter une image exclue, ajoutez un nœud namePattern sous une liste admissionWhitelistPatterns dans le fichier policy.yaml :

admissionWhitelistPatterns:
- namePattern: MATCHING_PATTERN

Où MATCHING_PATTERN est le chemin d'accès à une image unique de votre registre en cas de correspondance exacte, ou à toute image correspondant à un modèle utilisant le caractère générique (*, **).

Cloud Run

Cette section s'applique à Cloud Run.

Vous ne pouvez pas directement spécifier des noms d'images contenant un tag. Par exemple, vous ne pouvez pas spécifier IMAGE_PATH:latest.

Si vous souhaitez spécifier des noms d'image contenant des tags, vous devez spécifier le nom de l'image à l'aide d'un caractère générique comme suit :

  • * pour toutes les versions d'une même image (par exemple, us-docker.pkg.dev/myproject/container/hello@*)
  • ** pour toutes les images d'un projet (par exemple, us-docker.pkg.dev/myproject/**)

Vous pouvez utiliser des chemins d'accès pour spécifier un condensé au format IMAGE_PATH@DIGEST.

Mode d'évaluation de la stratégie système

Cette section s'applique à GKE et Distributed Cloud.

Le mode d'évaluation de la stratégie système est un paramètre de stratégie qui permet à l'autorisation binaire d'évaluer une stratégie système avant d'évaluer la stratégie que vous configurez. Google gère la stratégie système, qui exclut une liste d'images système gérées par Google utilisées par GKE. Les images répertoriées dans la stratégie système ne sont pas bloquées par l'application de la stratégie. Si vous n'activez pas ce paramètre, vous devez gérer vous-même la liste des images exclues. Découvrez comment gérer les images exclues.

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

Pour activer le mode d'évaluation de la stratégie système, ajoutez la ligne suivante au fichier policy.yaml :

globalPolicyEvaluationMode: ENABLE

Pour désactiver le mode d'évaluation de la stratégie système, ajoutez la ligne suivante :

globalPolicyEvaluationMode: DISABLE

Vous pouvez exporter la règle système associée à une région spécifique comme suit :

gcloud alpha container binauthz policy export-system-policy \
  --location=REGION > /tmp/policy.yaml

Remplacez REGION par la région associée à la règle système que vous souhaitez exporter (ou "globale"). Voici quelques exemples : asia-east1, europe-west1, us-central1.

Si vous omettez --location ou spécifiez --location=global, la commande génère une règle système à partir d'une région du dernier groupe de régions pour recevoir des mises à jour. Comme la plupart des modifications apportées à la stratégie système sont des ajouts, la sortie affiche l'ensemble des images système actuellement autorisées dans toutes les régions.

Définir des règles spécifiques à un cluster (facultatif)

Cette section s'applique à GKE et Distributed Cloud.

Une ou plusieurs règles spécifiques à un cluster peuvent également être définies pour un cluster. Ce type de règle s'applique aux images qui ne doivent être déployées que sur des clusters GKE spécifiques. Les règles spécifiques à un cluster constituent une partie facultative d'une stratégie.

Les règles spécifiques à un cluster sont définies dans des nœuds clusterAdmissionRules du fichier YAML de stratégie. Pour en savoir plus sur les éléments de cette règle, consultez la section ADMISSION_RULE dans la documentation de référence sur les fichiers YAML de stratégie. Pour obtenir un exemple, consultez la section Utiliser une règle spécifique à un cluster dans la section Exemples de stratégies.

Pour ajouter une règle spécifique à un cluster :

Dans le fichier policy.yaml, ajoutez un nœud clusterAdmissionRules :

clusterAdmissionRules:
  CLUSTER_SPECIFIER:
    evaluationMode: EVALUATION_MODE
    enforcementMode: ENFORCEMENT_MODE
    requireAttestationsBy:
    - ATTESTOR
    - ...

Remplacez les éléments suivants :

  • CLUSTER_SPECIFIER : ID de ressource du cluster auquel la règle s'applique. Formatez la règle comme suit :

    • Pour GKE, les clusters GKE associés et GKE sur AWS, le format est CLUSTER_LOCATION.CLUSTER_NAME (par exemple, us-central1-a.test-cluster).

    • Pour le logiciel Google Distributed Cloud (clusters GKE sur Bare Metal ou VMware), le format est FLEET_MEMBERSHIP_LOCATION.FLEET_MEMBERSHIP_ID (par exemple, global.test-membership).