Implementazione di Autorizzazione binaria con Cloud Build e GKE

Questo tutorial mostra come impostare, configurare e utilizzare Autorizzazione binaria per Google Kubernetes Engine (GKE). L'autorizzazione binaria è il processo di creazione di attestations sulle immagini container al fine di verificare che determinati criteri siano soddisfatti prima di poter eseguire il deployment delle immagini su GKE.

Ad esempio, Autorizzazione binaria può verificare che un'app abbia superato i test delle unità o che sia stata creata utilizzando un set specifico di sistemi. Per ulteriori informazioni, consulta la panoramica di Software Delivery Shield.

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

Questo tutorial presuppone la conoscenza dei seguenti argomenti e tecnologie:

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

Obiettivi

  • Esegui il deployment di cluster GKE per la gestione temporanea e la produzione.
  • Crea più attestatori e attestazioni.
  • Esegui il deployment di una pipeline CI/CD utilizzando Cloud Build.
  • Testa la pipeline di deployment.
  • Sviluppare un processo di emergenza.

Costi

In questo documento vengono utilizzati 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 essere idonei a una prova senza costi aggiuntivi.

Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina 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 di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

  3. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

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

    Abilita le API

    5.

  5. Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

  6. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

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

    Abilita le API

    8.

  8. Nella console Google Cloud, attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell che mostra 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 attuale. 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 dello sviluppo del software (SDLC) è garantire e fare in modo che i deployment delle app seguano i processi approvati della tua organizzazione. Un metodo per stabilire questi controlli e saldi è mediante Autorizzazione binaria su GKE. Innanzitutto, Autorizzazione binaria aggiunge note alle immagini container. Quindi, GKE verifica che siano presenti le note richieste prima di eseguire il deployment dell'app.

Queste note, o attestations, contengono 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 del controllo qualità (QA).
  • L'app è stata analizzata per rilevare eventuali vulnerabilità. Non ne è stata trovata nessuna.

Il seguente diagramma mostra un SDLC in cui viene applicata una singola attestazione 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 è costituita dai seguenti passaggi:

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

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

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

Se l'immagine non contiene CVE con un punteggio di gravità superiore a cinque, viene attestato che non ha CVE critiche e viene eseguito automaticamente il deployment nella gestione temporanea. Un punteggio maggiore di cinque indica una vulnerabilità da media a critica di fascia media, quindi non ne è stata attestata la proprietà o non ne è stata eseguita il deployment.

Un team addetto al QA esamina l'app nel cluster di gestione temporanea. Se soddisfa i requisiti, viene applicata un'attestazione manuale secondo cui l'immagine container è 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 per esaminare le immagini container per ottenere le attestazioni e rifiutare eventuali deployment che non abbiano le attestazioni richieste. Il cluster GKE gestione temporanea richiede solo l'attestazione dell'analisi delle vulnerabilità, mentre il cluster GKE di produzione richiede sia un'analisi delle vulnerabilità sia l'attestazione di QA.

In questo tutorial, introduci gli errori nella pipeline CI/CD per testare e verificare l'applicazione. Infine, implementerai una procedura di emergenza per bypassare 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 del tutorial presuppongono che queste variabili di ambiente esistano e contengano un valore valido.

  1. In Cloud Shell, imposta il progetto Google 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 si trovano in questa regione. In questo tutorial, l'area geografica è us-central1. Per ulteriori informazioni sulle regioni, 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 a Cloud Build le autorizzazioni di Identity and Access Management (IAM) per eseguire il deployment delle 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 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

Crea due chiavi asimmetriche 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 allegate alle immagini container, concedere all'account di servizio Cloud Build le autorizzazioni per visualizzare le note, allegare le note e creare gli attestatori utilizzando le chiavi dei passaggi precedenti.

Crea l'attestazione dell'analisi delle vulnerabilità

  1. In Cloud Shell, crea una nota Artifact 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 a 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 dell'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 a 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 a firmare 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 Artifact 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 a 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 a 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:

    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'

Configurare il 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 le attestazioni necessarie per l'esecuzione dei programmi binari nel cluster. I criteri di Autorizzazione binaria esistono a livello di progetto, ma contengono la configurazione per il livello di cluster.

La seguente norma modifica la norma predefinita nei modi seguenti:

  • Modifica il valore predefinito di evaluationMode in ALWAYS_DENY. Solo le immagini esenti o con le attestazioni richieste possono essere eseguite nel cluster.

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

  • Definisce le seguenti regole di ammissione ai cluster:

    • staging-cluster richiede attestazioni da vulnz-attestor.

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

Per ulteriori informazioni sui criteri di Autorizzazione binaria, consulta il riferimento YAML per i criteri.

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

  2. Carica il nuovo criterio nel progetto Google Cloud:

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

Creazione del controllo dell'analisi 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 qualsiasi vulnerabilità rilevata con la soglia configurata. Se il punteggio è compreso nella soglia, Cloud Build crea un'attestazione sul container. Se il punteggio è al di fuori della soglia, la build ha esito negativo e non viene creata alcuna attestazione.

  1. In Cloud Shell, crea un nuovo repository Artifact Registry per archiviare l'immagine 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 dell'attestatore dell'analisi delle vulnerabilità denominato attestor in Artifact Registry di cloudbuild-helpers:

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

Configurazione della pipeline di Cloud Build

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

Crea il repository Cloud Source Repositories e Artifact Registry 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 delle applicazioni:

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

Crea il trigger di Cloud Build dell'app hello

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

    Vai ai trigger

  2. Fai clic su Gestisci repository.

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

  4. Nella finestra Impostazioni attivatore, inserisci i seguenti dettagli:

    • Nel campo Nome, inserisci build-vulnz-deploy.
    • In 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 Posizione, seleziona Repository e inserisci il valore predefinito /cloudbuild.yaml.

  5. Aggiungi le seguenti coppie di Variabile di sostituzione:

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

  6. Fai clic su Crea.

Testa la pipeline di Cloud Build

Testa la pipeline CI/CD eseguendo il commit dell'app di esempio ed eseguendone il push 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 che il team addetto al QA ha verificato il deployment, il processo continua, i manifest Kubernetes di produzione vengono aggiornati e Cloud Build esegue il deployment dell'app in prod-cluster.

  1. In Cloud Shell, esegui il commit dei file hello-app ed eseguine il push 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 Repositories.

    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 Digest dai dettagli dell'immagine. Queste informazioni sono necessarie nel passaggio successivo

    Il valore digest dell'immagine

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

    Il passaggio di creazione Await QA attestation restituirà anche un comando copiabile, 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 che il deployment dell'app sia stato eseguito, vai alla pagina Servizi.

    Vai alla pagina Servizi

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

Deployment di un'immagine non attestata

Finora l'app di esempio non presentava vulnerabilità. Aggiorna l'app per generare un altro messaggio e modificare 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-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 di CVE rilevate 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à per l'immagine più recente.

    Link al 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 qa-attestor.

Procedura di emergenza

Occasionalmente, devi consentire le modifiche che non rientrano nel normale flusso di lavoro. Per consentire il deployment delle immagini senza le attestazioni richieste, la definizione del pod viene annotata con un flag di criterio di emergenza. Se abiliti questo flag, GKE controlla comunque le attestazioni richieste, ma consente il deployment dell'immagine container e le violazioni dei log.

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

  1. In Cloud Shell, rimuovi il commento dall'annotazione di deployment 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 relativo al deployment non è più presente.

  4. Per verificare che il deployment dell'app sia stato eseguito, 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. Nella console Google Cloud, 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