Implementazione di Autorizzazione binaria mediante Cloud Build e GKE

Questo tutorial illustra come impostare, configurare e utilizzare l'autorizzazione binaria per Google Kubernetes Engine (GKE). Autorizzazione binaria è il processo di creazione di attestati sulle immagini container allo scopo di verificare che vengano soddisfatti determinati criteri prima di eseguire il deployment delle immagini in GKE.

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

Questo tutorial è rivolto 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 conosca i seguenti argomenti e tecnologie:

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

Obiettivi

• Eseguire il deployment dei cluster GKE per l'esecuzione temporanea e la produzione.
• Crea più attestatori e attestazioni.
• Esegui il deployment di una pipeline CI/CD utilizzando Cloud Build.
• Testare la pipeline di deployment.
• Sviluppa un processo in vetro di emergenza.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

• GKE
• Cloud Build
• Cloud Source Repositories
• Container Registry
• Cloud KMS

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.

   Nota: se non hai intenzione di mantenere le risorse che crei in questa procedura, crea un progetto invece di selezionarne uno esistente. Dopo aver completato questi passaggi, puoi eliminare il progetto e rimuovere tutte le risorse associate.

   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, Container Registry, Container Analysis, Resource Manager, and Cloud Source Repositories.

   Abilita le API

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

   Nota: se non hai intenzione di mantenere le risorse che crei in questa procedura, crea un progetto invece di selezionarne uno esistente. Dopo aver completato questi passaggi, puoi eliminare il progetto e rimuovere tutte le risorse associate.

   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, Container Registry, Container Analysis, Resource Manager, and Cloud Source Repositories.

   Abilita le API

8. Nella console, attiva Cloud Shell.

   Attiva Cloud Shell

   Nella parte inferiore della 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.

Tutti i comandi di questo tutorial sono eseguiti in Cloud Shell.

Architettura della pipeline CI/CD

Un aspetto importante del ciclo di vita di sviluppo del software (SDLC) è garantire e implementare i deployment delle app in modo che seguano i processi approvati dell'organizzazione. Un metodo per stabilire questi controlli e i saldi è l'autorizzazione binaria su GKE. Innanzitutto, Autorizzazione binaria allega le note alle immagini container. In seguito, GKE verifica che le note necessarie siano presenti prima di poter eseguire il deployment dell'app.

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

• L'app ha superato i test delle unità.
• L'app è stata verificata dal team addetto al controllo qualità.
• L'app è stata analizzata alla ricerca di vulnerabilità e non è stata trovata nessuna.

Il seguente diagramma raffigura un SDLC in cui viene applicata una singola attestazione al termine della scansione delle vulnerabilità senza vulnerabilità note.

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

Questa pipeline CI/CD prevede i seguenti passaggi:

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

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

3. Container Analysis: esegue la scansione dell'immagine container per individuare vulnerabilità di sicurezza note o CVE.

Se l'immagine non contiene CVE con un punteggio di gravità maggiore di cinque, l'immagine viene attestata come priva di CVE e il deployment viene eseguito automaticamente in gestione temporanea. Un punteggio superiore a cinque indica una vulnerabilità media nella fascia media e, di conseguenza, non è attestata o implementata.

Un team addetto al QA controlla l'app nel cluster temporaneo. Se soddisfano i requisiti, applicano un'attestazione manuale che l'immagine del container sia di qualità sufficiente per il deployment in produzione. I manifest di produzione vengono aggiornati e viene eseguito il deployment dell'app nel cluster GKE di produzione.

I cluster GKE sono configurati in modo da esaminare le immagini container per verificare le attestazioni e rifiutare i deployment che non presentano le attestazioni richieste. Il cluster GKE temporaneo richiede solo l'attestazione di scansione delle vulnerabilità, ma il cluster GKE di produzione richiede sia un'analisi delle vulnerabilità che un'attestazione di QA.

In questo tutorial presenterai gli errori nella pipeline CI/CD per testare e verificare questa applicazione. Infine, implementi una procedura di deployment 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}"
   

2. Imposta l'area geografica in cui esegui il deployment di queste risorse:

   export REGION="us-central1"
   

   Il cluster GKE e le chiavi Cloud KMS si trovano in questa area geografica. In questo tutorial, l'area geografica è us-central1. Per saperne di più sulle aree geografiche, consulta 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

Crea due cluster GKE e concedi le autorizzazioni di Identity and Access Management (IAM) per Cloud Build al deployment di app su 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 di chiavi di firma

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 dell'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 del 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 collegare 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'
   

Creare l'attestazione di 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 collegare 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 team addetto al QA l'autorizzazione a firmare le attestazioni:

   Nota: si tratta di un esempio che utilizza un gruppo o un alias del team per concedere l'autorizzazione. Puoi anche aggiungere singoli utenti. Se non disponi di un alias del team da sottoporre a test, sostituisci il membro con il tuo indirizzo email, ad esempio user:[e-mail].

   gcloud kms keys add-iam-policy-binding "qa-signer" \
     --project "${PROJECT_ID}" \
     --location "${REGION}" \
     --keyring "binauthz" \
     --member "group:[e-mail]" \
     --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 scrivere un criterio che indichi a GKE quali attestazioni dei programmi binari richiedono l'esecuzione nel cluster. I criteri di autorizzazione binaria esistono a livello di progetto, ma contengono la configurazione a livello di cluster.

Le seguenti norme alterano le norme predefinite nei seguenti modi:

• Modifica il valore predefinito di evaluationMode in ALWAYS_DENY. Solo le immagini esenti o le immagini con le attestazioni richieste sono ammesse 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 del 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 sezione 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

Crea un'immagine container che verrà utilizzata 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, 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
   

2. Crea ed esegui il push del container attestatore di analisi delle vulnerabilità cloudbuild-attestor in Container Registry:

   gcloud builds submit \
     --project "${PROJECT_ID}" \
     --tag "gcr.io/${PROJECT_ID}/cloudbuild-attestor" \
     ~/binauthz-tools
   

3. Abilita l'API dello scanner di vulnerabilità:

   gcloud services enable containerscanning.googleapis.com
   

Configurazione della pipeline di Cloud Build

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

Creare hello-app Cloud Source Repositories

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 localmente:

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

3. Copia il codice di esempio nel repository:

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

Creare il trigger di Cloud Build di hello-app

1. Nella console, vai alla pagina Trigger.

   Vai a Attivatori

2. Fai clic su Crea trigger.

3. Nella finestra Impostazioni trigger, inserisci i seguenti dettagli:

   • Nel campo Nome, inserisci build-vulnz-deploy.
   • Per Evento, scegli Push al 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 Location, seleziona Repository e inserisci il valore predefinito /cloudbuild.yaml.

4. Aggiungi le seguenti coppie Variabile di sostituzione:

   • _COMPUTE_REGION con il valore us-central1 (o l'area geografica che hai scelto all'inizio).
   • _KMS_KEYRING con il valore binauthz.
   • _KMS_LOCATION con il valore us-central1 (o l'area geografica che hai scelto 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.

5. 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 al 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 QA. Dopo che il deployment è stato verificato dal team QA, il processo continua e i manifest di Kubernetes di produzione 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 di Cloud Source Repositories per attivare una build:

   cd ~/hello-app
   
   git add .
   git commit -m "Initial commit"
   git push origin master
   

2. Nella console, vai alla pagina Cronologia.

   Vai alla pagina Cronologia

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

   

4. Al termine del deployment, vai alla paginaServizi di staging-cluster.

   Vai alla pagina Servizi

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

6. Vai alla pagina Immagini.

   Vai alla pagina Immagini

7. Fai clic su hello-app.

8. Fai clic sull'immagine convalidata nel deployment temporaneo.

   

9. Nella pagina Dettagli digest, copia il valore Sintesi dai dettagli dell'immagine. Queste informazioni sono necessarie nel passaggio successivo

   

10. Per applicare l'attestazione manuale del QA, sostituisci ... con il valore copiato dai dettagli dell'immagine. Il valore della variabile DIGEST deve essere sha256:hash-value.

    Nel passaggio di build di Await QA attestation verrà generato anche un comando copia-incollabile, mostrato di seguito.

    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. Per verificare se è stato eseguito il deployment dell'app, vai alla pagina Servizi.

    Vai alla pagina Servizi

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

Deployment di un'immagine non testata

Finora l'app di esempio non aveva vulnerabilità. Aggiorna l'app per visualizzare un messaggio diverso e cambiare l'immagine di base.

1. In Cloud Shell, modifica l'output da Hello World a Binary Authorization e cambia 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/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 vai alla pagina Cronologia.

   Vai alla pagina Cronologia

   Questa build non riesce a causa dei CVE rilevati nell'immagine.

4. Per esaminare i CVE identificati, vai alla pagina Immagini.

   Vai alla pagina Immagini

5. Fai clic su hello-app.

6. Per esaminare i CVE identificati, fai clic sul riepilogo delle vulnerabilità per l'immagine più recente.

   

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

   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. Nella console, vai alla pagina Carichi di lavoro.

   Vai alla pagina Carichi di lavoro

   

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

Procedura in vetro di emergenza

Occasionalmente, è necessario consentire modifiche che esulano dal normale flusso di lavoro. Per consentire i deployment delle immagini senza le attestazioni richieste, la definizione del pod è contrassegnata da un flag dei criteri di emergenza. L'abilitazione di questo flag fa comunque sì che GKE verifichi le attestazioni richieste, ma consente il deployment dell'immagine container e la registrazione delle violazioni.

Per ulteriori informazioni sull'elusione dei controlli di attestazione, vedi Ignorare un criterio.

1. In Cloud Shell, rimuovi il commento dall'annotazione per il deployment di emergenza nel file manifest 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.

   Vai alla pagina Carichi di lavoro

   Il messaggio di errore del deployment è stato eliminato.

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

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:
• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per questo tutorial, quando lo elimini elimini anche qualsiasi altro lavoro svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.
1. Nella console, vai alla pagina Gestisci risorse.

   Vai a Gestisci risorse

2. Nell'elenco dei progetti, seleziona il progetto da 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

• Best practice per la creazione di container.
• Deployment di un'applicazione web containerizzata.
• Distribuzione continua in stile GitOps con Cloud Build.
• Automatizzare l'analisi canary con Spinnaker.
• Immagini di base gestite.
• Esplora architetture di riferimento, diagrammi, tutorial e best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.