Ce tutoriel explique comment configurer et utiliser l'autorisation binaire pour Google Kubernetes Engine (GKE). L'autorisation binaire consiste à créer des attestations sur des images de conteneurs afin de vérifier que certains critères sont remplis avant de pouvoir déployer ces images sur GKE.
Par exemple, l'autorisation binaire peut vérifier si une application a réussi ses tests unitaires ou si elle a été créée à l'aide d'un ensemble spécifique de systèmes. Pour en savoir plus, consultez la page Présentation de Software Delivery Shield.
Ce tutoriel s'adresse aux professionnels qui souhaitent mieux comprendre l'analyse des failles de conteneurs et l'autorisation binaire, ainsi que leur mise en œuvre et leur application dans un pipeline CI/CD.
Dans ce tutoriel, nous partons du principe que vous connaissez les sujets et technologies suivants :
- Intégration et déploiement continus
- Analyse des failles CVE (Common Vulnerabilities and Exposures, ou failles et expositions courantes)
- GKE
- Artifact Registry
- Cloud Build
- Cloud Key Management Service (Cloud KMS)
Objectifs
- Déployer des clusters GKE pour la préproduction et la production
- Créer plusieurs certificateurs et attestations
- Déployer un pipeline CI/CD à l'aide de Cloud Build
- Tester le pipeline de déploiement
- Développer une procédure de création de comptes d'accès d'urgence ("break-glass")
Coûts
Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :
Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.
Une fois que vous avez terminé les tâches décrites dans ce document, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.
Avant de commencer
- Connectez-vous à votre compte Google Cloud. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Vérifiez que la facturation est activée pour votre projet Google Cloud.
-
Activer les API Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Vérifiez que la facturation est activée pour votre projet Google Cloud.
-
Activer les API Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Artifact Analysis, Resource Manager, and Cloud Source Repositories.
-
Dans la console Google Cloud, activez Cloud Shell.
En bas de la fenêtre de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.
Toutes les commandes de ce tutoriel sont exécutées dans Cloud Shell.
Architecture du pipeline CI/CD
Un aspect important du cycle de vie du développement logiciel (SDLC, software development lifecycle) consiste à s'assurer que les déploiements d'applications respectent les procédures approuvées par votre organisation. L'une des méthodes permettant d'établir ces vérifications consiste à utiliser l'autorisation binaire sur GKE. Tout d'abord, l'autorisation binaire joint des notes aux images de conteneurs. Ensuite, avant de pouvoir déployer l'application, GKE vérifie que les notes requises sont présentes.
Ces notes, ou attestations, font des déclarations au sujet de l'image. Les attestations sont entièrement configurables, mais en voici quelques exemples courants :
- L'application a réussi les tests unitaires.
- L'application a été validée par l'équipe chargée du contrôle qualité.
- L'application a été analysée, et aucune faille n'a été trouvée.
Le schéma suivant illustre un SDLC dans lequel une seule attestation est appliquée, une fois que l'analyse s'est achevée, et qu'aucune faille n'a été trouvée.
Dans ce tutoriel, vous allez créer un pipeline CI/CD à l'aide de Cloud Source Repositories, Cloud Build, Artifact Registry et GKE. Le schéma suivant illustre le pipeline CI/CD.
Ce pipeline CI/CD comprend les étapes suivantes :
Créer une image de conteneur avec le code source de l'application
Transférer l'image du conteneur dans Artifact Registry
Analyser l'image du conteneur avec Artifact Analysis à la recherche de CVE ou de failles de sécurité connues
Si l'image ne contient pas de CVE dont le score de gravité est supérieur à cinq, elle est certifiée comme étant dépourvue de CVE critiques et elle est automatiquement déployée en préproduction. Un score supérieur à cinq indique une faille moyenne à critique, et l'image n'est donc ni certifiée, ni déployée.
Une équipe de contrôle qualité inspecte l'application dans le cluster de préproduction. Si elle répond aux exigences du contrôle qualité, l'image du conteneur est certifiée manuellement indiquant qu'elle est de qualité suffisante pour le déploiement en production. Les fichiers manifestes de production sont mis à jour et l'application est déployée dans le cluster de production GKE.
Les clusters GKE sont configurés pour examiner les images de conteneur à la recherche d'attestations et refuser les déploiements qui ne possèdent pas les attestations requises. Le cluster GKE de préproduction requiert uniquement l'attestation d'analyse des failles, mais le cluster GKE de production requiert une analyse des failles et une attestation de contrôle qualité.
Dans ce tutoriel, vous allez introduire des échecs dans le pipeline CI/CD pour tester et valider cette mesure d'application. Enfin, vous mettez en œuvre une procédure "break-glass" pour contourner ces vérifications de déploiement dans GKE en cas d'urgence.
Configurer votre environnement
Ce tutoriel utilise les variables d'environnement ci-après. Vous pouvez modifier ces valeurs en fonction de vos besoins, mais toutes les étapes du tutoriel supposent que ces variables d'environnement existent et contiennent une valeur valide.
Dans Cloud Shell, définissez le projet Google Cloud dans lequel vous déployez et gérez toutes les ressources utilisées dans ce tutoriel :
export PROJECT_ID="${DEVSHELL_PROJECT_ID}" gcloud config set project ${PROJECT_ID}
Définissez la région dans laquelle vous déployez les ressources suivantes :
export REGION="us-central1"
Le cluster GKE et les clés Cloud KMS résident dans cette région. Dans ce tutoriel, la région est
us-central1
. Pour en savoir plus sur les régions, consultez la page Zones géographiques et régions.Définissez le numéro du projet Cloud Build :
export PROJECT_NUMBER="$(gcloud projects describe "${PROJECT_ID}" \ --format='value(projectNumber)')"
Définissez l'adresse e-mail du compte de service Cloud Build :
export CLOUD_BUILD_SA_EMAIL="${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com"
Créer des clusters GKE
Créez deux clusters GKE et accordez des autorisations de gestion de l'authentification et des accès (IAM) pour que Cloud Build puisse déployer des applications sur GKE La création de clusters GKE peut prendre quelques minutes.
Dans Cloud Shell, créez un cluster GKE pour la préproduction :
gcloud container clusters create "staging-cluster" \ --project "${PROJECT_ID}" \ --machine-type "n1-standard-1" \ --region "${REGION}" \ --num-nodes "1" \ --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
Créez un cluster GKE pour la production :
gcloud container clusters create "prod-cluster" \ --project "${PROJECT_ID}" \ --machine-type "n1-standard-1" \ --region "${REGION}" \ --num-nodes "1" \ --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
Accordez au compte de service Cloud Build l'autorisation d'effectuer un déploiement sur GKE :
gcloud projects add-iam-policy-binding "${PROJECT_ID}" \ --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \ --role "roles/container.developer"
Créer des clés de signature
Créez deux clés asymétriques Cloud KMS pour signer les attestations.
Dans Cloud Shell, créez un trousseau de clés Cloud KMS nommé
binauthz
:gcloud kms keyrings create "binauthz" \ --project "${PROJECT_ID}" \ --location "${REGION}"
Créez une clé Cloud KMS asymétrique nommée
vulnz-signer
, qui servira à signer et à vérifier les attestations d'analyse des failles :gcloud kms keys create "vulnz-signer" \ --project "${PROJECT_ID}" \ --location "${REGION}" \ --keyring "binauthz" \ --purpose "asymmetric-signing" \ --default-algorithm "rsa-sign-pkcs1-4096-sha512"
Créez une clé Cloud KMS asymétrique nommée
qa-signer
pour signer et vérifier les attestations de contrôle qualité :gcloud kms keys create "qa-signer" \ --project "${PROJECT_ID}" \ --location "${REGION}" \ --keyring "binauthz" \ --purpose "asymmetric-signing" \ --default-algorithm "rsa-sign-pkcs1-4096-sha512"
Configurer les attestations
Vous créez les notes associées aux images de conteneur, accordez des autorisations au compte de service Cloud Build afin d'afficher les notes, joignez des notes et créez les certificateurs à l'aide des clés des étapes précédentes.
Créer l'attestation de l'analyse des failles
Dans Cloud Shell, créez une note Artifact Analysis nommée
vulnz-note
:curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=vulnz-note" \ --request "POST" \ --header "Content-Type: application/json" \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --header "X-Goog-User-Project: ${PROJECT_ID}" \ --data-binary @- <<EOF { "name": "projects/${PROJECT_ID}/notes/vulnz-note", "attestation": { "hint": { "human_readable_name": "Vulnerability scan note" } } } EOF
Accordez au compte de service Cloud Build l'autorisation d'afficher et de joindre la note
vulnz-note
aux images de conteneur :curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/vulnz-note:setIamPolicy" \ --request POST \ --header "Content-Type: application/json" \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --header "X-Goog-User-Project: ${PROJECT_ID}" \ --data-binary @- <<EOF { "resource": "projects/${PROJECT_ID}/notes/vulnz-note", "policy": { "bindings": [ { "role": "roles/containeranalysis.notes.occurrences.viewer", "members": [ "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" ] }, { "role": "roles/containeranalysis.notes.attacher", "members": [ "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" ] } ] } } EOF
Créez le certificateur en charge de l'analyse des failles :
gcloud container binauthz attestors create "vulnz-attestor" \ --project "${PROJECT_ID}" \ --attestation-authority-note-project "${PROJECT_ID}" \ --attestation-authority-note "vulnz-note" \ --description "Vulnerability scan attestor"
Ajoutez la clé publique de la clé de signature du certificateur :
gcloud beta container binauthz attestors public-keys add \ --project "${PROJECT_ID}" \ --attestor "vulnz-attestor" \ --keyversion "1" \ --keyversion-key "vulnz-signer" \ --keyversion-keyring "binauthz" \ --keyversion-location "${REGION}" \ --keyversion-project "${PROJECT_ID}"
Accordez au compte de service Cloud Build l'autorisation de visualiser les attestations effectuées par
vulnz-attestor
:gcloud container binauthz attestors add-iam-policy-binding "vulnz-attestor" \ --project "${PROJECT_ID}" \ --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \ --role "roles/binaryauthorization.attestorsViewer"
Accordez au compte de service Cloud Build l'autorisation de signer des objets à l'aide de la clé
vulnz-signer
:gcloud kms keys add-iam-policy-binding "vulnz-signer" \ --project "${PROJECT_ID}" \ --location "${REGION}" \ --keyring "binauthz" \ --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \ --role 'roles/cloudkms.signerVerifier'
Créer l'attestation de contrôle qualité
Dans Cloud Shell, créez une note Artifact Analysis nommée
qa-note
:curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=qa-note" \ --request "POST" \ --header "Content-Type: application/json" \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --header "X-Goog-User-Project: ${PROJECT_ID}" \ --data-binary @- <<EOF { "name": "projects/${PROJECT_ID}/notes/qa-note", "attestation": { "hint": { "human_readable_name": "QA note" } } } EOF
Accordez au compte de service Cloud Build l'autorisation d'afficher et de joindre la note
qa-note
aux images de conteneur :curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/qa-note:setIamPolicy" \ --request POST \ --header "Content-Type: application/json" \ --header "Authorization: Bearer $(gcloud auth print-access-token)" \ --header "X-Goog-User-Project: ${PROJECT_ID}" \ --data-binary @- <<EOF { "resource": "projects/${PROJECT_ID}/notes/qa-note", "policy": { "bindings": [ { "role": "roles/containeranalysis.notes.occurrences.viewer", "members": [ "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" ] }, { "role": "roles/containeranalysis.notes.attacher", "members": [ "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" ] } ] } } EOF
Créez le certificateur en charge du contrôle qualité :
gcloud container binauthz attestors create "qa-attestor" \ --project "${PROJECT_ID}" \ --attestation-authority-note-project "${PROJECT_ID}" \ --attestation-authority-note "qa-note" \ --description "QA attestor"
Ajoutez la clé publique de la clé de signature du certificateur :
gcloud beta container binauthz attestors public-keys add \ --project "${PROJECT_ID}" \ --attestor "qa-attestor" \ --keyversion "1" \ --keyversion-key "qa-signer" \ --keyversion-keyring "binauthz" \ --keyversion-location "${REGION}" \ --keyversion-project "${PROJECT_ID}"
Accordez au compte de service Cloud Build l'autorisation de visualiser les attestations effectuées par
qa-attestor
:gcloud container binauthz attestors add-iam-policy-binding "qa-attestor" \ --project "${PROJECT_ID}" \ --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \ --role "roles/binaryauthorization.attestorsViewer"
Autorisez votre équipe de contrôle qualité à signer les attestations :
gcloud kms keys add-iam-policy-binding "qa-signer" \ --project "${PROJECT_ID}" \ --location "${REGION}" \ --keyring "binauthz" \ --member "group:qa-team@example.com" \ --role 'roles/cloudkms.signerVerifier'
Définir la stratégie d'autorisation binaire
Même si vous avez créé les clusters GKE avec --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
, vous devez créer une règle indiquant à GKE les attestations que les binaires doivent exécuter dans le cluster. Les stratégies d'autorisation binaire existent au niveau du projet, mais contiennent une configuration au niveau du cluster.
La stratégie suivante modifie la stratégie par défaut comme suit :
Elle remplace la valeur par défaut
evaluationMode
parALWAYS_DENY
. Seules les images exemptées ou présentant les attestations requises peuvent être exécutées dans le cluster.Elle active
globalPolicyEvaluationMode
, ce qui modifie la liste d'autorisation par défaut pour n'inclure que les images système fournies par Google.Elle définit les règles d'admission de cluster suivantes :
staging-cluster
requiert des attestations devulnz-attestor
.prod-cluster
requiert des attestations devulnz-attestor
etqa-attestor
.
Pour plus d'informations sur les stratégies d'autorisation binaire, consultez la Documentation de référence sur les règles YAML.
Dans Cloud Shell, créez un fichier YAML qui décrit la règle d'autorisation binaire du projet Google Cloud :
cat > ./binauthz-policy.yaml <<EOF admissionWhitelistPatterns: - namePattern: docker.io/istio/* defaultAdmissionRule: enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG evaluationMode: ALWAYS_DENY globalPolicyEvaluationMode: ENABLE clusterAdmissionRules: # Staging cluster ${REGION}.staging-cluster: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor # Production cluster ${REGION}.prod-cluster: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor - projects/${PROJECT_ID}/attestors/qa-attestor EOF
Importez la nouvelle règle dans le projet Google Cloud :
gcloud container binauthz policy import ./binauthz-policy.yaml \ --project "${PROJECT_ID}"
Créer l'outil d'analyse des failles et activer l'API
Créez une image de conteneur à utiliser comme étape de compilation dans Cloud Build. Ce conteneur compare les scores de gravité des failles détectées au seuil configuré. Si le score est inférieur au seuil, Cloud Build crée une attestation sur le conteneur. Si le score se situe en dehors du seuil, la compilation échoue et aucune attestation n'est créée.
Dans Cloud Shell, créez un nouveau dépôt Artifact Registry pour stocker l'image du certificateur :
gcloud artifacts repositories create cloudbuild-helpers \ --repository-format=DOCKER --location=${REGION}
Clonez les outils d'autorisation binaire et l'exemple de source d'application :
git clone https://github.com/GoogleCloudPlatform/gke-binary-auth-tools ~/binauthz-tools
Créez et transférez le conteneur du certificateur d'analyse des failles nommé
attestor
verscloudbuild-helpers
dans Artifact Registry :gcloud builds submit \ --project "${PROJECT_ID}" \ --tag "us-central1-docker.pkg.dev/${PROJECT_ID}/cloudbuild-helpers/attestor" \ ~/binauthz-tools
Configurer le pipeline Cloud Build
Créez un dépôt Cloud Source Repositories et un déclencheur Cloud Build pour l'exemple d'application et les fichiers manifestes Kubernetes.
Créer les dépôts Cloud Source Repositories et Artifact Registry pour hello-app
Dans Cloud Shell, créez un dépôt Cloud Source Repositories pour l'exemple d'application :
gcloud source repos create hello-app \ --project "${PROJECT_ID}"
Clonez le dépôt localement :
gcloud source repos clone hello-app ~/hello-app \ --project "${PROJECT_ID}"
Copiez l'exemple de code dans le dépôt :
cp -R ~/binauthz-tools/examples/hello-app/* ~/hello-app
Créez un nouveau dépôt Artifact Registry pour stocker les images d'application :
gcloud artifacts repositories create applications \ --repository-format=DOCKER --location=${REGION}
Créer le déclencheur Cloud Build pour hello-app
Dans la console Google Cloud, accédez à la page Déclencheurs.
Cliquez sur Gérer les dépôts.
Pour le dépôt
hello-app
, cliquez sur ... et sélectionnez Ajouter un déclencheur.Dans la fenêtre Paramètres du déclencheur, saisissez les détails suivants :
- Dans le champ Nom, saisissez
build-vulnz-deploy
. - Dans le champ Événement, sélectionnez Déployer sur une branche.
- Dans le champ Dépôt, sélectionnez
hello-app
dans le menu. - Dans le champ Branche, saisissez
master
. - Pour le champ Configuration, sélectionnez Fichier de configuration Cloud Build (yaml ou json).
- Dans le champ Emplacement, sélectionnez Dépôt et saisissez la valeur par défaut
/cloudbuild.yaml
.
- Dans le champ Nom, saisissez
Ajoutez les paires de variables de substitution suivantes :
_COMPUTE_REGION
avec la valeurus-central1
(ou la région que vous avez choisie au début)_KMS_KEYRING
avec la valeurbinauthz
_KMS_LOCATION
avec la valeurus-central1
(ou la région que vous avez choisie au début)_PROD_CLUSTER
avec la valeurprod-cluster
_QA_ATTESTOR
avec la valeurqa-attestor
_QA_KMS_KEY
avec la valeurqa-signer
_QA_KMS_KEY_VERSION
avec la valeur1
_STAGING_CLUSTER
avec la valeurstaging-cluster
_VULNZ_ATTESTOR
avec la valeurvulnz-attestor
_VULNZ_KMS_KEY
avec la valeurvulnz-signer
_VULNZ_KMS_KEY_VERSION
avec la valeur1
Cliquez sur Create (Créer).
Tester le pipeline Cloud Build
Testez le pipeline CI/CD en validant et en transférant l'exemple d'application vers le dépôt Cloud Source Repositories. Cloud Build détecte la modification, compile et déploie l'application sur staging-cluster
. Le pipeline attend jusqu'à 10 minutes que la validation du contrôle qualité ait lieu. Une fois le déploiement validé par l'équipe de contrôle qualité, le processus se poursuit : les fichiers manifestes de production Kubernetes sont mis à jour et Cloud Build déploie l'application sur prod-cluster
.
Dans Cloud Shell, validez et transférez les fichiers
hello-app
vers le dépôt Cloud Source Repositories pour déclencher une compilation :cd ~/hello-app git add . git commit -m "Initial commit" git push origin master
Dans la console Google Cloud, accédez à la page Historique.
Pour suivre la progression de la compilation, cliquez sur la dernière exécution de Cloud Build.
Une fois le déploiement sur
staging-cluster
terminé, accédez à la page Services.Pour vérifier que l'application fonctionne, cliquez sur le lien Points de terminaison qui lui correspond.
Accédez à la page Dépôts.
Cliquez sur
applications
.Cliquez sur
hello-app
.Cliquez sur l'image que vous avez validée dans le déploiement en préproduction.
Copiez la valeur du Condensé figurant dans les détails de l'image. Vous aurez besoin de cette information à l'étape suivante.
Pour appliquer l'attestation de contrôle qualité manuelle, remplacez
...
par la valeur que vous avez copiée à partir des détails de l'image. La variableDIGEST
doit être au formatsha256:hash-value
.L'étape de compilation
Await QA attestation
génère également une commande de type "copier-coller", illustrée ci-dessous.DIGEST="sha256:..." # Replace with your value gcloud beta container binauthz attestations sign-and-create \ --project "${PROJECT_ID}" \ --artifact-url "${REGION}-docker.pkg.dev/${PROJECT_ID}/applications/hello-app@${DIGEST}" \ --attestor "qa-attestor" \ --attestor-project "${PROJECT_ID}" \ --keyversion "1" \ --keyversion-key "qa-signer" \ --keyversion-location "${REGION}" \ --keyversion-keyring "binauthz" \ --keyversion-project "${PROJECT_ID}"
Pour vérifier que l'application a été déployée, accédez à la page Services.
Pour consulter l'application, cliquez sur le lien du point de terminaison.
Déployer une image non certifiée
Jusqu'à présent, l'exemple d'application ne présentait aucune faille. Mettez à jour l'application pour générer un autre message et modifier l'image de base.
Dans Cloud Shell, remplacez la sortie
Hello World
parBinary Authorization
et l'image de basedistroless
pardebian
:cd ~/hello-app sed -i "s/Hello World/Binary Authorization/g" main.go sed -i "s/FROM gcr\.io\/distroless\/static-debian11/FROM debian/g" Dockerfile
Validez et appliquez les modifications :
git add . git commit -m "Change message and base image" git push origin master
Pour surveiller l'état du pipeline CI/CD, accédez à la page Historique dans la console Google Cloud.
Accéder à la page "Historique"
La compilation échoue à cause de CVE détectées dans l'image.
Pour examiner les CVE identifiées, accédez à la page Images.
Cliquez sur
hello-app
.Pour examiner les CVE identifiées, cliquez sur le récapitulatif des failles pour l'image la plus récente.
Dans Cloud Shell, essayez de déployer la nouvelle image en production sans l'attestation de l'analyse des failles :
export SHA_DIGEST="[SHA_DIGEST_VALUE]" cd ~/hello-app sed "s/REGION/${REGION}/g" kubernetes/deployment.yaml.tpl | \ sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_ID}/g" | \ sed -e "s/DIGEST/${SHA_DIGEST}/g" > kubernetes/deployment.yaml gcloud container clusters get-credentials \ --project=${PROJECT_ID} \ --region="${REGION}" prod-cluster kubectl apply -f kubernetes
Dans la console Google Cloud, accédez à la page Charges de travail.
Accéder à la page "Charges de travail"
L'image n'a pas pu être déployée, car elle n'a pas été signée par les certificateurs
vulnz-attestor
etqa-attestor
.
Procédure "break-glass"
De manière ponctuelle, vous pouvez être amené à autoriser des modifications exceptionnelles contournant le flux de travail normal. Pour autoriser le déploiement d'images sans les attestations requises, la définition de pod est annotée avec une option de stratégie "break-glass". En activant cette option, GKE vérifie les attestations requises, mais autorise le déploiement de l'image de conteneur et enregistre les violations dans ses journaux.
Pour en savoir plus sur le contournement des vérifications d'attestation, consultez la section Ignorer une règle.
Dans Cloud Shell, annulez la mise en commentaire de l'annotation "break-glass" figurant dans le fichier manifeste de Kubernetes :
sed -i "31s/^#//" kubernetes/deployment.yaml
Utilisez
kubectl
pour appliquer les modifications :kubectl apply -f kubernetes
Pour vérifier si la modification a été déployée sur
prod-cluster
, accédez à la page Charges de travail dans la console Google Cloud.Accéder à la page "Charges de travail"
Le message signalant l'erreur de déploiement n'apparaît plus.
Pour vérifier que l'application a été déployée, accédez à la page Services.
Pour consulter l'application, cliquez sur le lien du point de terminaison.
Nettoyer
Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.
Supprimer le projet
- Dans la console Google Cloud, accédez à la page Gérer les ressources.
- Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
- Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.
Étape suivante
- Bonnes pratiques en matière de création de conteneurs.
- Déployer une application Web en conteneur.
- Livraison continue de type GitOps avec Cloud Build
- Images de base gérées
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.