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 :
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 à exclure. Pour exclure des images supplémentaires, ajoutez d'autres entrées - namePattern
. En savoir plus sur admissionWhitelistPatterns
.
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écifiezREQUIRE_ATTESTATION
, vous devez également ajouter un blocrequireAttestationsBy
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
surREQUIRE_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.
- Pour GKE, les clusters GKE associés et GKE sur AWS, le format est
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écifiezREQUIRE_ATTESTATION
, vous devez également ajouter un blocrequireAttestationsBy
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
surREQUIRE_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écifiezREQUIRE_ATTESTATION
, vous devez également ajouter un blocrequireAttestationsBy
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
surREQUIRE_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écifiezREQUIRE_ATTESTATION
, vous devez également ajouter un blocrequireAttestationsBy
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
surREQUIRE_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écifiezREQUIRE_ATTESTATION
, vous devez également ajouter un blocrequireAttestationsBy
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
surREQUIRE_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.