Mettre en œuvre l'autorisation binaire à l'aide de Cloud Build et GKE

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 et voir des cas d'utilisation, consultez la page Aider à sécuriser les chaînes d'approvisionnement logicielles sur Google Kubernetes Engine.

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
  • Container 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

Ce tutoriel utilise 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. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous avez terminé ce tutoriel, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Consultez la page Effectuer un nettoyage pour en savoir plus.

Avant de commencer

  1. 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.
  2. Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

    Accéder au sélecteur de projet

  3. Assurez-vous que la facturation est activée pour votre projet Cloud. Découvrez comment vérifier que la facturation est activée pour votre projet.

  4. Activer les API Binary Authorization, Cloud Build, Cloud KMS, GKE, Container Registry, Container Analysis, Resource Manager, and Cloud Source Repositories.

    Activer les API

  5. Dans Cloud Console, activez Cloud Shell.

    Activer Cloud Shell

    En bas de la fenêtre de Cloud Console, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel le SDK Cloud est déjà installé (y compris l'outil de ligne de commande gcloud), et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

  6. 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.

Architecture de SDLC avec application d'une seule attestation

Dans ce tutoriel, vous allez créer un pipeline CI/CD à l'aide de Cloud Source Repositories, Cloud Build, Container Registry et GKE. Le schéma suivant illustre le pipeline CI/CD.

Architecture du pipeline CI/CD avec trois produits Google Cloud

Ce pipeline CI/CD comprend les étapes suivantes :

  1. Créer une image de conteneur avec le code source de l'application

  2. Transférer l'image du conteneur dans Container Registry

  3. Analyser l'image du conteneur avec Container 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.

  1. Dans Cloud Shell, définissez le projet Cloud dans lequel vous déployez et gérez toutes les ressources utilisées dans ce tutoriel :

    export PROJECT_ID="${DEVSHELL_PROJECT_ID}"
    
  2. 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.

  3. Définissez le numéro du projet Cloud Build :

    export PROJECT_NUMBER="$(gcloud projects describe "${PROJECT_ID}" \
      --format='value(projectNumber)')"
    
  4. 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.

  1. 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" \
      --enable-binauthz
    
  2. 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" \
      --enable-binauthz
    
  3. 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.

  1. Dans Cloud Shell, créez un trousseau de clés Cloud KMS nommé binauthz :

    gcloud kms keyrings create "binauthz" \
      --project "${PROJECT_ID}" \
      --location "${REGION}"
    
  2. 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"
    
  3. 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

  1. Dans Cloud Shell, créez une note Container 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
    
  2. 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
    
  3. 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"
    
  4. 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}"
    
  5. Accordez au compte de service Cloud Build l'autorisation de valider 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"
    
  6. 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é

  1. Dans Cloud Shell, créez une note Container 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
    
  2. 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
    
  3. 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"
    
  4. 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}"
    
  5. Accordez au compte de service Cloud Build l'autorisation de vérifier 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"
    
  6. 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 --enable-binauthz, 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 par ALWAYS_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 de vulnz-attestor.

    • prod-cluster requiert des attestations de vulnz-attestor et qa-attestor.

Pour plus d'informations sur les stratégies d'autorisation binaire, consultez la Documentation de référence sur les règles YAML.

  1. Dans Cloud Shell, créez un fichier YAML qui décrit la règle d'autorisation binaire du projet 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
    
  2. Importez la nouvelle règle dans le projet 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.

  1. Dans Cloud Shell, 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
    
  2. Créez et transférez le conteneur du certificateur d'analyse des failles nommé cloudbuild-attestor dans Container Registry :

    gcloud builds submit \
      --project "${PROJECT_ID}" \
      --tag "gcr.io/${PROJECT_ID}/cloudbuild-attestor" \
      ~/binauthz-tools
    
  3. Activez l'API d'analyse des failles :

    gcloud services enable containerscanning.googleapis.com
    

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 pour hello-app

  1. 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}"
    
  2. Clonez le dépôt localement :

    gcloud source repos clone hello-app ~/hello-app \
      --project "${PROJECT_ID}"
    
  3. Copiez l'exemple de code dans le dépôt :

    cp -R ~/binauthz-tools/examples/hello-app/* ~/hello-app
    

Créer le déclencheur Cloud Build pour hello-app

  1. Dans Cloud Console, accédez à la page Déclencheurs.

    Accéder à la page "Déclencheurs"

  2. Cliquez sur Créer un déclencheur.

  3. Dans la fenêtre Paramètres du déclencheur, saisissez les détails suivants :

    • Dans le champ Dépôt, sélectionnez hello-app dans le menu.
    • Dans le champ Nom, saisissez build-vulnz-deploy.
    • Pour Type de déclencheur, sélectionnez Branche.
    • Dans le champ Branche (expression régulière), saisissez main.
    • Pour le champ Configuration, sélectionnez Fichier de configuration Cloud Build (yaml ou json).
    • Dans la section Emplacement du fichier de configuration Cloud Build, saisissez la valeur par défaut /cloudbuild.yaml.
  4. Ajoutez les paires de variables de substitution suivantes :

    • _COMPUTE_REGION avec la valeur us-central1 (ou la région que vous avez choisie au début)
    • _KMS_KEYRING avec la valeur binauthz
    • _KMS_LOCATION avec la valeur us-central1 (ou la région que vous avez choisie au début)
    • _PROD_CLUSTER avec la valeur prod-cluster
    • _QA_ATTESTOR avec la valeur qa-attestor
    • _QA_KMS_KEY avec la valeur qa-signer
    • _QA_KMS_KEY_VERSION avec la valeur 1
    • _STAGING_CLUSTER avec la valeur staging-cluster
    • _VULNZ_ATTESTOR avec la valeur vulnz-attestor
    • _VULNZ_KMS_KEY avec la valeur vulnz-signer
    • _VULNZ_KMS_KEY_VERSION avec la valeur 1
  5. Cliquez sur Créer un déclencheur.

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.

  1. 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 main
    
  2. Dans Cloud Console, accédez à la page Historique.

    Accéder à la page "Historique"

  3. Pour suivre la progression de la compilation, cliquez sur la dernière exécution de Cloud Build.

    Informations sur la compilation

  4. Une fois le déploiement sur staging-cluster terminé, accédez à la page Services.

    Accéder à la page "Services"

  5. Pour vérifier que l'application fonctionne, cliquez sur le lien Points de terminaison qui lui correspond.

  6. Accédez à la page Images.

    Accéder à la page "Images"

  7. Cliquez sur hello-app.

  8. Cliquez sur l'image que vous avez validée dans le déploiement en préproduction.

    Nom de l&#39;image validée

  9. Sur la page Informations relatives au condensé, copiez la valeur du Condensé figurant dans les détails de l'image. Vous aurez besoin de cette information à l'étape suivante.

    Valeur du condensé de l&#39;image

  10. 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 variable DIGEST doit être au format sha256: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 "gcr.io/${PROJECT_ID}/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}"
    
  11. Pour vérifier que l'application a été déployée, accédez à la page Services.

    Accéder à la page "Services"

  12. 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.

  1. Dans Cloud Shell, remplacez la sortie Hello World par Binary Authorization et l'image de base distroless par debian :

    cd ~/hello-app
    sed -i "s/Hello World/Binary Authorization/g" main.go
    sed -i "s/FROM gcr\.io\/distroless\/static/FROM debian/g" Dockerfile
    
  2. Validez et appliquez les modifications :

    git add .
    git commit -m "Change message and base image"
    git push origin main
    
  3. Pour surveiller l'état du pipeline CI/CD, accédez à la page Historique dans Cloud Console.

    Accéder à la page "Historique"

    La compilation échoue à cause de CVE détectées dans l'image.

  4. Pour examiner les CVE identifiées, accédez à la page Images.

    Accéder à la page "Images"

  5. Cliquez sur hello-app.

  6. Pour examiner les CVE identifiées, cliquez sur le récapitulatif des failles pour l'image la plus récente.

    Lien du récapitulatif des failles pour une image récente.

  7. 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/GOOGLE_CLOUD_PROJECT/${DEVSHELL_PROJECT_ID}/g" \
        kubernetes/deployment.yaml.tpl | sed -e  \
        "s/DIGEST/${SHA_DIGEST}/g" > kubernetes/deployment.yaml
    
    gcloud container clusters get-credentials \
        --project=${DEVSHELL_PROJECT_ID} \
        --region="${REGION}" prod-cluster
    
    kubectl apply -f kubernetes
    
  8. Dans Cloud Console, accédez à la page Charges de travail.

    Accéder à la page "Charges de travail"

    État d&#39;échec de l&#39;image.

    L'image n'a pas pu être déployée, car elle n'a pas été signée par les certificateurs vulnz-attestor et qa-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.

  1. 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
    
  2. Utilisez kubectl pour appliquer les modifications :

    kubectl apply -f kubernetes
    
  3. Pour vérifier si la modification a été déployée sur prod-cluster, accédez à la page Charges de travail dans Cloud Console.

    Accéder à la page "Charges de travail"

    Le message signalant l'erreur de déploiement n'apparaît plus.

  4. Pour vérifier que l'application a été déployée, accédez à la page Services.

    Accéder à la page "Services"

  5. 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 les ressources individuelles.

Supprimer le projet

  1. Dans Cloud Console, accédez à la page Gérer les ressources.

    Accéder à la page Gérer les ressources

  2. Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
  3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Étape suivante