Cette page explique comment déployer une image de conteneur sur un cluster GKE (sur Google Cloud ou Google Distributed Cloud) sur lequel l'autorisation binaire est activée.
Les commandes kubectl
que vous utilisez pour déployer l'image sont identiques à celles que vous utilisez pour déployer des images sur des clusters qui n'utilisent pas l'autorisation binaire.
Avant de commencer
Assurez-vous que l'API d'autorisation binaire est activée dans votre projet et qu'un cluster GKE avec autorisation binaire activée est disponible. Consultez la section Configurer sur Google Kubernetes Engine ou Configurer sur Distributed Cloud.
Installez kubectl
pour interagir avec GKE.
Configurer kubectl
Vous devez mettre à jour le fichier kubeconfig
local pour votre installation kubectl
.
Cela fournit les identifiants et les informations de point de terminaison requis pour accéder au cluster dans GKE ou Distributed Cloud.
Pour configurer kubectl
, exécutez la commande gcloud
suivante :
GKE
gcloud container clusters get-credentials \ --zone ZONE \ CLUSTER_NAME
Remplacez les éléments suivants :
- ZONE : nom de la zone GKE dans laquelle s'exécute le cluster, par exemple,
us-central1-a
- CLUSTER_NAME : nom du cluster
Cloud distribué
gcloud container fleet memberships get-credentials \ --location LOCATION \ MEMBERSHIP_NAME
Remplacez les éléments suivants :
- LOCATION: emplacement de l'appartenance au parc du cluster GKE (par exemple,
global
) - MEMBERSHIP_NAME : nom de l'appartenance au parc du cluster GKE
Déployer l'image de conteneur
Déployez votre image de conteneur comme suit :
Configurer les variables d'environnement :
POD_NAME=POD_NAME IMAGE_PATH=IMAGE_PATH IMAGE_DIGEST=IMAGE_DIGEST
Remplacez les éléments suivants :
- POD_NAME : nom que vous souhaitez utiliser pour la charge de travail GKE.
- IMAGE_PATH : chemin d'accès à l'image dans Artifact Registry, Container Registry ou un autre registre.
IMAGE_DIGEST : condensé du fichier manifeste de l'image. Les exemples sont les suivants :
- Artifact Registry :
- Chemin d'accès :
us-docker.pkg.dev/google-samples/containers/gke/hello-app
- Condensé :
sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567
- Chemin d'accès :
- Container Registry :
- Chemin d'accès :
gcr.io/google-samples/hello-app
- Condensé :
sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4
- Chemin d'accès :
Pour savoir comment obtenir le condensé d'une image dans Artifact Registry, consultez la section Gérer les images. Pour obtenir une image dans Container Registry, consultez la section Répertorier les versions d'une image
- Artifact Registry :
Déployez votre image à l'aide de la commande
kubectl run
.Vous devez déployer l'image à l'aide du condensé au lieu d'un tag tel que
1.0
oulatest
, car l'autorisation binaire utilise le condensé pour rechercher les attestations.Pour déployer l'image, exécutez la commande
kubectl
suivante :kubectl run ${POD_NAME} \ --image ${IMAGE_PATH}@${IMAGE_DIGEST}
Maintenant, vérifiez que le déploiement a été bloqué par l'autorisation binaire.
kubectl get pods
Votre pod s'affiche.
Configuration ouverte ("fail open")
Si GKE ne parvient pas à atteindre le serveur d'autorisation binaire pour une raison quelconque ou si le serveur renvoie une erreur, GKE ne peut pas déterminer si l'autorisation binaire autorise ou refuse l'image. Dans ce cas, GKE échoue à l'ouverture. Par défaut, le déploiement de l'image est autorisé, mais une entrée de journal est créée dans Cloud Audit Logs pour enregistrer la raison pour laquelle l'image a été autorisée.
L'application de GKE échoue en mode "fail open" en raison d'un compromis entre fiabilité et sécurité. GKE envoie une requête à l'autorisation binaire chaque fois qu'un pod est créé ou mis à jour. Cela inclut les scénarios où des pods sont automatiquement créés ou mis à jour par des contrôleurs de charge de travail Kubernetes de niveau supérieur, tels que des ReplicaSets et des StatefulSets. Si GKE a échoué en mode fermé au lieu d'être ouvert, toute panne de l'autorisation binaire empêcherait l'exécution de ces pods. De plus, lorsque des pods sont refusés, le basculement peut entraîner des défaillances en cascade, car le trafic redirigé surcharge les pods qui sont toujours en cours d'exécution. Toute panne de l'autorisation binaire peut déclencher une interruption complète de votre cluster, même si vous ne déployez pas de nouvelles images.
Déployer des images qui ne respectent pas le règlement
L'autorisation binaire accepte une fonctionnalité appelée bris de glace, qui permet de déployer une image, même si elle enfreint la stratégie.
Pour en savoir plus, consultez la page Utiliser le mode "bris de glace".
Effectuer un nettoyage
Pour le nettoyage, supprimez le pod en exécutant la commande suivante :
kubectl delete pod ${POD_NAME}
Étape suivante
- En savoir plus sur le mode de simulation.
- Découvrez comment utiliser la CV.
- Découvrez comment utiliser l'ancienne validation continue (obsolète).
- Learn how to use image digests in Kubernetes manifests.