Implementazione di Autorizzazione binaria con Cloud Build e GKE

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questo tutorial mostra come impostare, configurare e utilizzare Autorizzazione binaria per Google Kubernetes Engine (GKE). Autorizzazione binaria è il processo di creazione di attestazioni sulle immagini container allo scopo di verificare che determinati criteri siano soddisfatti prima di poter eseguire il deployment delle immagini in GKE.

Ad esempio, Autorizzazione binaria può verificare che un'app abbia superato i test delle unità o che sia stata creata utilizzando un insieme specifico di sistemi. Per ulteriori informazioni e casi d'uso, consulta Contribuisci a proteggere le catene di fornitura software su Google Kubernetes Engine.

Questo tutorial è destinato ai professionisti che vogliono comprendere meglio l'analisi delle vulnerabilità dei container e l'autorizzazione binaria, nonché l'implementazione e l'applicazione in una pipeline CI/CD.

Questo tutorial presuppone che tu abbia dimestichezza con i seguenti argomenti e tecnologie:

  • Integrazione e deployment continui
  • Analisi delle vulnerabilità comuni ed esposizioni comuni (CVE)
  • GKE
  • Artifact Registry
  • Cloud Build
  • Cloud Key Management Service (Cloud KMS)

Obiettivi

  • Eseguire il deployment del cluster GKE per la gestione temporanea e la produzione.
  • Creare più attestatori e attestazioni.
  • Eseguire il deployment di una pipeline CI/CD utilizzando Cloud Build.
  • Test della pipeline di deployment.
  • Sviluppa un processo di emergenza.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono beneficiare di una prova gratuita.

Al termine di questo tutorial, puoi evitare una fatturazione continua eliminando le risorse che hai creato. Per scoprire di più, vedi Pulizia.

Prima di iniziare

  1. Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

  2. Nella pagina del selettore dei progetti in Google Cloud Console, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

  3. Assicurati che la fatturazione sia attivata per il tuo progetto Cloud. Scopri come verificare se la fatturazione è abilitata su un progetto.

  4. Abilita le API Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Container Analysis, Resource Manager, and Cloud Source Repositories.

    Abilita le API

    5.

  5. Nella pagina del selettore dei progetti in Google Cloud Console, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

  6. Assicurati che la fatturazione sia attivata per il tuo progetto Cloud. Scopri come verificare se la fatturazione è abilitata su un progetto.

  7. Abilita le API Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Container Analysis, Resource Manager, and Cloud Source Repositories.

    Abilita le API

    8.

  8. In Google Cloud Console, attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore di Google Cloud Console, viene avviata una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installato e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

    9. Tutti i comandi di questo tutorial vengono eseguiti in Cloud Shell.

Architettura della pipeline CI/CD

Un aspetto importante del ciclo di vita di sviluppo del software (SDLC) è garantire e applicare i deployment delle app seguendo i processi approvati della tua organizzazione. Un metodo per determinare questi controlli e saldi è l'Autorizzazione binaria su GKE. Innanzitutto, Autorizzazione binaria allega le note alle immagini container. Quindi, GKE verifica che le note richieste siano presenti prima di poter eseguire il deployment dell'app.

Queste note, o attestazioni, fanno affermazioni sull'immagine. Le attestazioni sono completamente configurabili, ma ecco alcuni esempi comuni:

  • L'app ha superato i test delle unità.
  • L'app è stata verificata dal team per il controllo qualità (QA).
  • L'app è stata analizzata per rilevare le vulnerabilità e non è stata trovata nessuna.

Il seguente diagramma mostra un SDLC a cui viene applicato un singolo attestato al termine dell'analisi delle vulnerabilità senza vulnerabilità note.

Architettura di SDLC con una singola attestazione applicata

In questo tutorial, creerai una pipeline CI/CD utilizzando Cloud Source Repositories, Cloud Build, Artifact Registry e GKE. Il seguente diagramma illustra la pipeline CI/CD.

Architettura della pipeline CI/CD con tre prodotti Google Cloud

Questa pipeline CI/CD comprende i seguenti passaggi:

  1. Crea un'immagine container con il codice sorgente dell'app.

  2. Esegue il push dell'immagine container in Artifact Registry.

  3. Container Analysis, analizza l'immagine container per individuare vulnerabilità di sicurezza note o CVE.

Se l'immagine non contiene CVE con un punteggio di gravità superiore a cinque, viene attestata l'assenza di CVE critiche e viene eseguito automaticamente il deployment in gestione temporanea. Un punteggio superiore a cinque indica una vulnerabilità di fascia media-media, quindi non è attestata o sottoposta a deployment.

Un team di QA controlla l'app nel cluster gestione temporanea. Se supera i requisiti, applica un'attestazione manuale che dimostri che l'immagine container è di qualità sufficiente per il deployment in produzione. I manifest di produzione vengono aggiornati e il deployment dell'app viene eseguito nel cluster GKE di produzione.

I cluster GKE sono configurati per esaminare le immagini container alla ricerca di attestazioni e rifiutare qualsiasi deployment che non disponga delle attestazioni richieste. Il cluster GKE di gestione temporanea richiede solo l'attestazione di analisi delle vulnerabilità, ma il cluster di produzione GKE richiede sia un'analisi delle vulnerabilità sia un'attestazione di QA.

In questo tutorial, scoprirai gli errori nella pipeline CI/CD per testare e verificare questa applicazione. Infine, implementa una procedura di emergenza per aggirare questi controlli di deployment in GKE in caso di emergenza.

Configurazione dell'ambiente

Questo tutorial utilizza le seguenti variabili di ambiente. Puoi modificare questi valori in base ai tuoi requisiti, ma tutti i passaggi nel tutorial presuppongono che queste variabili di ambiente esistano e contengano un valore valido.

  1. In Cloud Shell, imposta il progetto Cloud in cui esegui il deployment e gestisci tutte le risorse utilizzate in questo tutorial:

    export PROJECT_ID="${DEVSHELL_PROJECT_ID}"
gcloud config set project ${PROJECT_ID}

  2. Imposta la regione in cui esegui il deployment di queste risorse:

    export REGION="us-central1"

    Il cluster GKE e le chiavi Cloud KMS risiedono in questa regione. In questo tutorial, l'area geografica è us-central1. Per saperne di più sulle regioni, consulta la sezione Area geografica e regioni.

  3. Imposta il numero del progetto Cloud Build:

    export PROJECT_NUMBER="$(gcloud projects describe "${PROJECT_ID}" \
  --format='value(projectNumber)')"

  4. Imposta l'indirizzo email dell'account di servizio Cloud Build:

    export CLOUD_BUILD_SA_EMAIL="${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com"

Creazione di cluster GKE

Creare due cluster GKE e concedere le autorizzazioni Identity and Access Management (IAM) per Cloud Build per il deployment di app in GKE. La creazione di cluster GKE può richiedere alcuni minuti.

  1. In Cloud Shell, crea un cluster GKE per la gestione temporanea:

    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

  2. Crea un cluster GKE per la produzione:

    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

  3. Concedi all'account di servizio Cloud Build l'autorizzazione per eseguire il deployment in GKE:

    gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
  --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
  --role "roles/container.developer"

Creazione delle chiavi di firma in corso...

Crea due chiavi asimmetriche di Cloud KMS per la firma delle attestazioni.

  1. In Cloud Shell, crea un keyring Cloud KMS denominato binauthz:

    gcloud kms keyrings create "binauthz" \
  --project "${PROJECT_ID}" \
  --location "${REGION}"

  2. Crea una chiave Cloud KMS asimmetrica denominata vulnz-signer, che verrà utilizzata per firmare e verificare le attestazioni di analisi delle vulnerabilità:

    gcloud kms keys create "vulnz-signer" \
  --project "${PROJECT_ID}" \
  --location "${REGION}" \
  --keyring "binauthz" \
  --purpose "asymmetric-signing" \
  --default-algorithm "rsa-sign-pkcs1-4096-sha512"

  3. Crea una chiave Cloud KMS asimmetrica denominata qa-signer per firmare e verificare le attestazioni di QA:

    gcloud kms keys create "qa-signer" \
  --project "${PROJECT_ID}" \
  --location "${REGION}" \
  --keyring "binauthz" \
  --purpose "asymmetric-signing" \
  --default-algorithm "rsa-sign-pkcs1-4096-sha512"

Configurazione delle attestazioni

Puoi creare le note collegate alle immagini container, concedere le autorizzazioni all'account di servizio Cloud Build per visualizzare le note, allegare le note e creare gli attestatori utilizzando le chiavi dei passaggi precedenti.

Crea l'attestazione dello scanner di vulnerabilità

  1. In Cloud Shell, crea una nota Container Analysis denominata 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. Concedi all'account di servizio Cloud Build l'autorizzazione per visualizzare e allegare la nota vulnz-note alle immagini container:

    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. Crea l'attestatore di analisi delle vulnerabilità:

    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. Aggiungi la chiave pubblica per la chiave di firma dell'attestatore:

    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. Concedi all'account di servizio Cloud Build l'autorizzazione per visualizzare le attestazioni effettuate da 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. Concedi all'account di servizio Cloud Build l'autorizzazione per firmare gli oggetti utilizzando la chiave 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'

Crea l'attestazione QA

  1. In Cloud Shell, crea una nota Container Analysis denominata 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. Concedi all'account di servizio Cloud Build l'autorizzazione per visualizzare e allegare la nota qa-note alle immagini container:

    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. Crea l'attestatore QA:

    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. Aggiungi la chiave pubblica per la chiave di firma dell'attestatore:

    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. Concedi all'account di servizio Cloud Build l'autorizzazione per visualizzare le attestazioni effettuate da 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. Concedi al tuo team addetto al QA l'autorizzazione a firmare le attestazioni:

    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'

Impostazione del criterio di Autorizzazione binaria

Anche se hai creato i cluster GKE con --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE, devi creare un criterio che indichi a GKE su quali attestazioni i programmi binari richiedono l'esecuzione nel cluster. I criteri di Autorizzazione binaria esistono a livello di progetto, ma contengono la configurazione per il livello di cluster.

Il seguente criterio modifica il criterio predefinito nei seguenti modi:

  • Cambia il valore predefinito da evaluationMode a ALWAYS_DENY. Solo le immagini esenti o le immagini con le attestazioni richieste possono essere eseguite nel cluster.

  • Attiva globalPolicyEvaluationMode, che modifica la lista consentita predefinita in modo che includa solo le immagini di sistema fornite da Google.

  • Definisce le seguenti regole di ammissione ai cluster:

    • staging-cluster richiede attestazioni di vulnz-attestor.

    • prod-cluster richiede attestazioni di vulnz-attestor e qa-attestor.

Per ulteriori informazioni sui criteri di Autorizzazione binaria, consulta la pagina Riferimento YAML per i criteri.

  1. In Cloud Shell, crea un file YAML che descrive il criterio di autorizzazione binaria per il progetto 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. Carica il nuovo criterio nel progetto Cloud:

    gcloud container binauthz policy import ./binauthz-policy.yaml \
  --project "${PROJECT_ID}"

Creazione del controllo di scansione delle vulnerabilità e abilitazione dell'API

Creare un'immagine container da utilizzare come passaggio di build in Cloud Build. Questo container confronta i punteggi di gravità di eventuali vulnerabilità rilevate con la soglia configurata. Se il punteggio rientra nella soglia, Cloud Build crea un'attestazione sul container. Se il punteggio non rientra nella soglia, la build non riesce e non viene creata alcuna attestazione.

  1. In Cloud Shell, crea un nuovo repository Artifact Registry per archiviare l'immagine dell'attestatore:

    gcloud artifacts repositories create cloudbuild-helpers \
  --repository-format=DOCKER --location=${REGION}

  2. Clona gli strumenti di Autorizzazione binaria e l'origine dell'applicazione di esempio:

    git clone https://github.com/GoogleCloudPlatform/gke-binary-auth-tools ~/binauthz-tools

  3. Crea ed esegui il push del container attestatore dell'analisi delle vulnerabilità denominato attestor in cloudbuild-helpers Artifact Registry:

    gcloud builds submit \
  --project "${PROJECT_ID}" \
  --tag "us-central1-docker.pkg.dev/${PROJECT_ID}/cloudbuild-helpers/attestor" \
  ~/binauthz-tools

Configurazione della pipeline Cloud Build

Creare un repository Cloud Source Repositories e un trigger Cloud Build per l'app di esempio e i manifest Kubernetes.

Crea il repository Cloud Source Repositories e Artifact Registry di hello-app

  1. In Cloud Shell, crea un repository Cloud Source Repositories per l'app di esempio:

    gcloud source repos create hello-app \
  --project "${PROJECT_ID}"

  2. Clona il repository in locale:

    gcloud source repos clone hello-app ~/hello-app \
  --project "${PROJECT_ID}"

  3. Copia il codice campione nel repository:

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

  4. Crea un nuovo repository Artifact Registry per archiviare le immagini dell'applicazione:

    gcloud artifacts repositories create applications \
  --repository-format=DOCKER --location=${REGION}

Crea il trigger di Cloud Build di hello-app

  1. Nella console Google Cloud, vai alla pagina Trigger.

    Vai a Trigger

  2. Fai clic su Gestisci repository.

  3. Per il repository hello-app, fai clic su ... e seleziona Aggiungi trigger.

  4. Nella finestra Impostazioni di attivazione, inserisci i seguenti dettagli:

    • Nel campo Nome, inserisci build-vulnz-deploy.
    • Per Evento, scegli Esegui il push in un ramo.
    • Nel campo Repository, scegli hello-app dal menu.
    • Nel campo Ramo, inserisci master.
    • In Configurazione, seleziona File di configurazione di Cloud Build (yaml o json).
    • In Località, seleziona Repository e inserisci il valore predefinito /cloudbuild.yaml.

  5. Aggiungi le seguenti coppie di variabili di sostituzione:

    • _COMPUTE_REGION con il valore us-central1 (o la regione scelta all'inizio).
    • _KMS_KEYRING con il valore binauthz.
    • _KMS_LOCATION con il valore us-central1 (o la regione scelta all'inizio).
    • _PROD_CLUSTER con il valore prod-cluster.
    • _QA_ATTESTOR con il valore qa-attestor.
    • _QA_KMS_KEY con il valore qa-signer.
    • _QA_KMS_KEY_VERSION con il valore 1.
    • _STAGING_CLUSTER con il valore staging-cluster.
    • _VULNZ_ATTESTOR con il valore vulnz-attestor.
    • _VULNZ_KMS_KEY con il valore vulnz-signer.
    • _VULNZ_KMS_KEY_VERSION con il valore 1.

  6. Fai clic su Crea.

Testa la pipeline di Cloud Build

Testare la pipeline CI/CD eseguendo il push e il push dell'app di esempio nel repository Cloud Source Repositories. Cloud Build rileva la modifica, crea ed esegue il deployment dell'app in staging-cluster. La pipeline attende fino a 10 minuti per la verifica del QA. Dopo aver verificato il deployment dal team del QA, il processo continua e i manifest di produzione Kubernetes vengono aggiornati e Cloud Build esegue il deployment dell'app in prod-cluster.

  1. In Cloud Shell, esegui il commit e il push dei file hello-app nel repository Cloud Source Repositories per attivare una build:

    cd ~/hello-app

git add .
git commit -m "Initial commit"
git push origin master

  2. Nella console Google Cloud, vai alla pagina Cronologia.

    Vai alla pagina Cronologia

  3. Per controllare l'avanzamento della build, fai clic sull'esecuzione più recente di Cloud Build.

    Informazioni build

  4. Al termine del deployment in staging-cluster, vai alla pagina Servizi.

    Vai alla pagina Servizi

  5. Per verificare che l'app funzioni, fai clic sul link Endpoint dell'app.

  6. Vai alla pagina Repository.

    Vai alla pagina Immagini

  7. Fai clic su applications.

  8. Fai clic su hello-app.

  9. Fai clic sull'immagine convalidata nel deployment gestione temporanea.

    Nome dell'immagine convalidata

  10. Copia il valore di Digest dai dettagli dell'immagine. Queste informazioni sono necessarie nel passaggio successivo

    Valore digest dell'immagine

  11. Per applicare l'attestazione QA manuale, sostituisci ... con il valore copiato dai dettagli dell'immagine. La variabile DIGEST deve essere nel formato sha256:hash-value`.

    Nel passaggio di build Await QA attestation verrà prodotto anche un comando copiabile e incollabile, mostrato di seguito.

    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}"

  12. Per verificare se è stato eseguito il deployment dell'app, vai alla pagina Servizi.

    Vai alla pagina Servizi

  13. Per visualizzare l'app, fai clic sul link dell'endpoint.

Deployment di un'immagine non testata

Finora, l'app di esempio non presentava vulnerabilità. Aggiorna l'app in modo che venga restituito un messaggio diverso e modifica l'immagine di base.

  1. In Cloud Shell, modifica l'output da Hello World a Binary Authorization e modifica l'immagine di base da distroless a debian:

    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

  2. Esegui il commit e il push delle modifiche:

    git add .
git commit -m "Change message and base image"
git push origin master

  3. Per monitorare lo stato della pipeline CI/CD, nella console Google Cloud, vai alla pagina Cronologia.

    Vai alla pagina Cronologia

    Questa build non riesce a causa dell'individuazione di CVE nell'immagine.

  4. Per esaminare le CVE identificate, vai alla pagina Immagini.

    Vai alla pagina Immagini

  5. Fai clic su hello-app.

  6. Per esaminare le CVE identificate, fai clic sul riepilogo delle vulnerabilità relativo all'immagine più recente.

    Link di riepilogo delle vulnerabilità per un'immagine recente.

  7. In Cloud Shell, prova a eseguire il deployment della nuova immagine in produzione senza l'attestazione dall'analisi delle vulnerabilità:

    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

  8. Nella console Google Cloud, vai alla pagina Carichi di lavoro.

    Vai alla pagina Carichi di lavoro

    Stato di errore dell'immagine.

    Impossibile eseguire il deployment dell'immagine perché non è stata firmata da vulnz-attestor e da qa-attestor.

Procedura di emergenza

A volte è necessario consentire modifiche che non rientrano nel normale flusso di lavoro. Per consentire i deployment delle immagini senza le attestazioni richieste, la definizione del pod è annotata con un flag dei criteri di emergenza. L'attivazione di questo flag consente comunque a GKE di verificare le attestazioni richieste, ma consente il deployment dell'immagine container e di registrare le violazioni.

Per ulteriori informazioni su come ignorare i controlli di attestazione, consulta Eseguire l'override di un criterio.

  1. In Cloud Shell, rimuovi il commento dell'annotazione di emergenza nel manifest di Kubernetes:

    sed -i "31s/^#//" kubernetes/deployment.yaml

  2. Utilizza kubectl per applicare le modifiche:

    kubectl apply -f kubernetes

  3. Per verificare che il deployment della modifica sia stato eseguito in prod-cluster, vai alla pagina Carichi di lavoro nella console Google Cloud.

    Vai alla pagina Carichi di lavoro

    Il messaggio di errore del deployment non è più visibile.

  4. Per verificare se è stato eseguito il deployment dell'app, vai alla pagina Servizi.

    Vai alla pagina Servizi

  5. Per visualizzare l'app, fai clic sul link dell'endpoint.

Esegui la pulizia

Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Elimina il progetto

  1. In Google Cloud Console, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
  3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Passaggi successivi