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 Google Cloud Console 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

Activer l'autorisation binaire.
Créez un cluster.
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 console Google Cloud.
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, aux clusters GKE, à Cloud Run et à Anthos 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 :

admissionWhitelistPatterns:
- namePattern: gcr.io/google_containers/*
- namePattern: gcr.io/google-containers/*
- namePattern: k8s.gcr.io/**
- namePattern: gke.gcr.io/**
- namePattern: gcr.io/stackdriver-agents/*
globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: EVALUATION_MODE
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
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.

Remarque : La liste admissionWhitelistPatterns peut contenir par défaut d'autres chemins recommandés pour les images.

Définir la règle par défaut

Cette section s'applique à GKE, aux clusters GKE, à Cloud Run et à Anthos 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, aux clusters GKE, à Cloud Run et à Anthos 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 aux clusters GKE.

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 aux clusters GKE.

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 GKE sur Bare Metal et GKE sur VMware, le format est FLEET_MEMBERSHIP_LOCATION.FLEET_MEMBERSHIP_ID (par exemple, global.test-membership).
  
  Les autres propriétés sont décrites dans la section Définir la règle par défaut plus haut dans ce guide. Consultez la section Exemples de stratégies pour obtenir un exemple de règle spécifique à un cluster.
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.

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

Vous pouvez créer des règles associées à une identité de service de réseau maillé, un compte de service Kubernetes ou un espace de noms Kubernetes.

Définir une règle pour une identité de service Anthos Service Mesh

Pour définir une règle pour une identité de service Anthos Service Mesh (Aperçu), modifiez votre fichier policy.yaml et ajoutez un bloc istioServiceIdentityAdmissionRules. Par exemple :

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
istioServiceIdentityAdmissionRules:
  SERVICE_IDENTITY_ID:
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    evaluationMode: ENFORCEMENT_MODE
    requireAttestationsBy:
    - <var>ATTESTOR</var>
    - ...

name: projects/PROJECT_ID/policy

Remplacez les éléments suivants :

SERVICE_IDENTITY_ID : identité du service Anthos Service Mesh à laquelle appliquer cette règle. L'identité du service est au format suivant : PROJECT_ID.svc.id.goog/ns/NAMESPACE/sa/SERVICE_ACCOUNT. Dans l'ID d'identité du service, remplacez les éléments suivants :
- PROJECT_ID : ID du projet dans lequel vous définissez vos ressources Kubernetes.
- NAMESPACE : espace de noms Kubernetes.
- SERVICE_ACCOUNT : compte de service.
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.

Définir une règle pour un compte de service Kubernete

Pour définir une règle pour un compte de service Kubernetes, modifiez votre fichier policy.yaml et ajoutez un bloc kubernetesServiceAccountAdmissionRules. Par exemple :

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
kubernetesServiceAccountAdmissionRules:
  KUBERNETES_SERVICE_ACCOUNT_ID:
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    evaluationMode: ENFORCEMENT_MODE
    requireAttestationsBy:
    - <var>ATTESTOR</var>
    - ...
name: projects/PROJECT_ID/policy

Remplacez les éléments suivants :

KUBERNETES_SERVICE_ACCOUNT_ID : compte de service Kubernetes sur lequel définir la règle. Cet ID de compte de service est au format suivant : NAMESPACE:SERVICE_ACCOUNT. Dans l'ID du compte de service, remplacez les éléments suivants :
- NAMESPACE : espace de noms Kubernetes.
- SERVICE_ACCOUNT : nom du compte de service.
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.

Définir une règle pour un espace de noms Kubernetes

Pour définir une règle pour un espace de noms Kubernetes, modifiez votre fichier policy.yaml et ajoutez un bloc kubernetesNamespaceAdmissionRules. Par exemple :

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
kubernetesNamespaceAdmissionRules:
  KUBERNETES_NAMESPACE:
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    evaluationMode: EVALUATION_MODE
    requireAttestationsBy:
    - <var>ATTESTOR</var>
    - ...
name: projects/PROJECT_ID/policy

Remplacez les éléments suivants :

KUBERNETES_NAMESPACE : espace de noms Kubernetes sur lequel définir cette règle.
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.

Importer le fichier YAML de stratégie

Cette section s'applique à GKE, aux clusters GKE, à Cloud Run et à Anthos Service Mesh.

Importez le fichier YAML de stratégie dans l’autorisation binaire en saisissant les éléments suivants :

gcloud container binauthz policy import /tmp/policy.yaml

Étape suivante

Utilisez le certificateur built-by-cloud-build pour déployer uniquement des images créées par Cloud Build (bêta).
Utilisez des attestations.
Déployez une image GKE.