Build sicura e Esegui il deployment con Cloud Build, Artifact Registry e GKE

1. Introduzione

Container Analysis fornisce l'analisi delle vulnerabilità e l'archiviazione dei metadati per i container. Il servizio di analisi esegue scansioni delle vulnerabilità sulle immagini in Artifact Registry e Container Registry, quindi archivia i metadati risultanti e li rende disponibili per l'utilizzo tramite un'API. L'archiviazione dei metadati consente di archiviare informazioni provenienti da diverse fonti, tra cui analisi delle vulnerabilità, servizi Google Cloud e fornitori di terze parti.

L'analisi delle vulnerabilità può essere eseguita automaticamente o on demand:

• Quando l'analisi automatica è abilitata, l'analisi viene attivata automaticamente ogni volta che esegui il push di una nuova immagine su Artifact Registry o Container Registry. Le informazioni sulle vulnerabilità vengono aggiornate continuamente quando vengono scoperte nuove vulnerabilità.
• Quando è abilitata l'analisi on demand, devi eseguire un comando per analizzare un'immagine locale o un'immagine in Artifact Registry o Container Registry. On-Demand Scanning ti offre flessibilità per quanto riguarda il momento in cui esegui la scansione dei container. Ad esempio, puoi analizzare un'immagine creata localmente e correggere le vulnerabilità prima di archiviarla in un registro. I risultati della scansione sono disponibili fino a 48 ore dopo il completamento della scansione e le informazioni sulle vulnerabilità non vengono aggiornate dopo la scansione.

Con Container Analysis integrato nella pipeline CI/CD, puoi prendere decisioni in base a questi metadati. Ad esempio, puoi utilizzare Autorizzazione binaria per creare criteri di deployment che consentano solo i deployment per immagini conformi provenienti da registri attendibili.

Cosa imparerai a fare

• Come attivare la scansione automatica
• Come eseguire la scansione on demand
• Come integrare la scansione in una pipeline di build
• Come firmare le immagini approvate
• Come utilizzare i controller di ammissione GKE per bloccare le immagini
• Come configurare GKE per consentire solo immagini approvate firmate

2. Configurazione e requisiti

Configurazione dell'ambiente autonomo

1. Accedi alla console Google Cloud e crea un nuovo progetto o riutilizzane uno esistente. Se non hai ancora un account Gmail o Google Workspace, devi crearne uno.

• Il nome del progetto è il nome visualizzato per i partecipanti a questo progetto. È una stringa di caratteri non utilizzata dalle API di Google. Puoi aggiornarlo in qualsiasi momento.
• L'ID progetto è univoco in tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo l'impostazione). La console Cloud genera automaticamente una stringa univoca, di solito non ti interessa di cosa si tratta. Nella maggior parte dei codelab, devi fare riferimento all'ID progetto (in genere è identificato come PROJECT_ID). Se non ti piace l'ID generato, puoi generarne un altro casuale. In alternativa, puoi provare a crearne uno e vedere se è disponibile. Non può essere modificato dopo questo passaggio e rimarrà per tutta la durata del progetto.
• Per tua informazione, esiste un terzo valore, un numero di progetto, utilizzato da alcune API. Scopri di più su tutti e tre questi valori nella documentazione.

Attenzione:un ID progetto è univoco a livello globale e non può essere utilizzato da altri dopo che lo hai selezionato. Sei l'unico utente di questo ID. Anche se un progetto viene eliminato, l'ID non potrà mai più essere utilizzato

Nota:se utilizzi un account Gmail, puoi lasciare la località predefinita impostata su Nessuna organizzazione. Se utilizzi un account Google Workspace, scegli una posizione adatta alla tua organizzazione.

2. Successivamente, devi abilitare la fatturazione in Cloud Console per utilizzare le risorse/API Cloud. L'esecuzione di questo codelab non dovrebbe costare molto, se non nulla. Per arrestare le risorse in modo da non incorrere in costi di fatturazione al termine di questo tutorial, puoi eliminare le risorse che hai creato o l'intero progetto. I nuovi utenti di Google Cloud possono beneficiare del programma prova senza costi di 300$.

Avvia l'editor di Cloud Shell

Questo lab è stato progettato e testato per l'utilizzo con l'editor di Google Cloud Shell. Per accedere all'editor:

1. accedi al tuo progetto Google all'indirizzo https://console.cloud.google.com.
2. Nell'angolo in alto a destra, fai clic sull'icona dell'editor Cloud Shell.

3. Si aprirà un nuovo riquadro nella parte inferiore della finestra.

Configurazione dell'ambiente

In Cloud Shell, imposta l'ID progetto e il numero del tuo progetto. Salvali come variabili PROJECT_ID e PROJECT_ID.

export PROJECT_ID=$(gcloud config get-value project)
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \
    --format='value(projectNumber)')

Abilitazione dei servizi

Attiva tutti i servizi necessari:

gcloud services enable \
  cloudkms.googleapis.com \
  cloudbuild.googleapis.com \
  container.googleapis.com \
  containerregistry.googleapis.com \
  artifactregistry.googleapis.com \
  containerscanning.googleapis.com \
  ondemandscanning.googleapis.com \
  binaryauthorization.googleapis.com 

Crea il repository Artifact Registry

In questo lab utilizzerai Artifact Registry per archiviare e scansionare le immagini. Crea il repository con il seguente comando.

gcloud artifacts repositories create artifact-scanning-repo \
  --repository-format=docker \
  --location=us-central1 \
  --description="Docker repository"

Configura Docker per utilizzare le tue credenziali gcloud quando accedi ad Artifact Registry.

gcloud auth configure-docker us-central1-docker.pkg.dev

3. Scansione automatizzata

La scansione degli artefatti viene attivata automaticamente ogni volta che esegui il push di una nuova immagine su Artifact Registry o Container Registry. Le informazioni sulle vulnerabilità vengono aggiornate continuamente quando vengono scoperte nuove vulnerabilità. In questa sezione eseguirai il push di un'immagine in Artifact Registry ed esplorerai i risultati.

Crea una directory di lavoro e passa a questa directory

mkdir vuln-scan && cd vuln-scan

Definisci un'immagine di esempio

Crea un file denominato Dockerfile con i seguenti contenuti.

cat > ./Dockerfile << EOF
FROM gcr.io/google-appengine/debian9@sha256:ebffcf0df9aa33f342c4e1d4c8428b784fc571cdf6fbab0b31330347ca8af97a

# System
RUN apt update && apt install python3-pip -y

# App
WORKDIR /app
COPY . ./

RUN pip3 install Flask==1.1.4
RUN pip3 install gunicorn==20.1.0

CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app

EOF

Crea un file denominato main.py con i seguenti contenuti

cat > ./main.py << EOF
import os
from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello_world():
    name = os.environ.get("NAME", "Worlds")
    return "Hello {}!".format(name)

if __name__ == "__main__":
    app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))
EOF

Crea ed esegui il push dell'immagine in AR

Utilizza Cloud Build per creare ed eseguire automaticamente il push del container su Artifact Registry. Prendi nota del tag bad sull'immagine. In questo modo potrai identificarlo per i passaggi successivi.

gcloud builds submit . -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad

Rivedere i dettagli dell'immagine

Una volta completato il processo di compilazione, esamina l'immagine e i risultati delle vulnerabilità nella dashboard di Artifact Registry.

1. Apri Artifact Registry in Cloud Console.
2. Fai clic su artifact-scanning-repo per visualizzare i contenuti.
3. Fai clic sui dettagli dell'immagine.
4. Fai clic sull'ultimo riepilogo della tua immagine
5. Al termine della scansione, fai clic sulla scheda delle vulnerabilità per l'immagine.

Nella scheda Vulnerabilità vedrai i risultati della scansione automatica dell'immagine appena creata.

L'automazione della scansione è abilitata per impostazione predefinita. Esplora le impostazioni di Artifact Registry per scoprire come attivare/disattivare la scansione automatica.

4. Scansione on demand

Esistono vari scenari in cui potrebbe essere necessario eseguire una scansione prima di eseguire il push dell'immagine in un repository. Ad esempio, uno sviluppatore di container può analizzare un'immagine e risolvere i problemi prima di eseguire il push del codice nel controllo del codice sorgente. Nell'esempio riportato di seguito, creerai e analizzerai l'immagine localmente prima di agire in base ai risultati.

Creare un'immagine

In questo passaggio utilizzerai Docker locale per creare l'immagine nella cache locale.

docker build -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image .

Scansionare l'immagine

Una volta creata l'immagine, richiedi una scansione. I risultati della scansione vengono archiviati in un server dei metadati. Il job viene completato con una posizione dei risultati nel server dei metadati.

gcloud artifacts docker images scan \
    us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
    --format="value(response.scan)" > scan_id.txt

Esamina il file di output

Esamina l'output del passaggio precedente, memorizzato nel file scan_id.txt. Nota la posizione del report dei risultati dell'analisi nel server di metadati.

cat scan_id.txt

Esaminare i risultati dettagliati della scansione

Per visualizzare i risultati effettivi della scansione, utilizza il comando list-vulnerabilities nella posizione del report indicata nel file di output.

gcloud artifacts docker images list-vulnerabilities $(cat scan_id.txt) 

L'output contiene una quantità significativa di dati su tutte le vulnerabilità nell'immagine.

Segnalare problemi critici

Gli utenti raramente utilizzano direttamente i dati archiviati nel report. In genere, i risultati vengono utilizzati da un processo automatizzato. Utilizza i comandi riportati di seguito per leggere i dettagli del report e registrare se sono state trovate vulnerabilità CRITICHE

export SEVERITY=CRITICAL

gcloud artifacts docker images list-vulnerabilities $(cat scan_id.txt) --format="value(vulnerability.effectiveSeverity)" | if grep -Fxq ${SEVERITY}; then echo "Failed vulnerability check for ${SEVERITY} level"; else echo "No ${SEVERITY} Vulnerabilities found"; fi

L'output di questo comando sarà

Failed vulnerability check for CRITICAL level

5. Scansione della pipeline di build

In questa sezione creerai una pipeline di build automatizzata che creerà l'immagine container, la analizzerà e valuterà i risultati. Se non vengono trovate vulnerabilità CRITICHE, l'immagine viene inviata al repository. Se vengono rilevate vulnerabilità CRITICHE, la build non verrà creata e verrà interrotta.

Fornisci l'accesso per l'account di servizio Cloud Build

Cloud Build avrà bisogno dei diritti di accesso all'API di scansione on demand. Fornisci l'accesso con i seguenti comandi.

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/iam.serviceAccountUser"
        
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/ondemandscanning.admin"

Crea la pipeline di Cloud Build

Il comando seguente creerà un file cloudbuild.yaml nella directory che verrà utilizzato per il processo automatizzato. Per questo esempio, i passaggi sono limitati al processo di compilazione del container. In pratica, tuttavia, includerai istruzioni e test specifici dell'applicazione oltre ai passaggi del container.

Crea il file con il seguente comando.

cat > ./cloudbuild.yaml << EOF
steps:

# build
- id: "build"
  name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.']
  waitFor: ['-']

#Run a vulnerability scan at _SECURITY level
- id: scan
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    (gcloud artifacts docker images scan \
    us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
    --location us \
    --format="value(response.scan)") > /workspace/scan_id.txt

#Analyze the result of the scan
- id: severity check
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
      gcloud artifacts docker images list-vulnerabilities \$(cat /workspace/scan_id.txt) \
      --format="value(vulnerability.effectiveSeverity)" | if grep -Fxq CRITICAL; \
      then echo "Failed vulnerability check for CRITICAL level" && exit 1; else echo "No CRITICAL vulnerability found, congrats !" && exit 0; fi

#Retag
- id: "retag"
  name: 'gcr.io/cloud-builders/docker'
  args: ['tag',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']


#pushing to artifact registry
- id: "push"
  name: 'gcr.io/cloud-builders/docker'
  args: ['push',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']

images:
  - us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image
EOF

Esegui la pipeline CI

Invia la build per l'elaborazione per verificare che la build si interrompa quando viene rilevata una vulnerabilità di gravità CRITICA.

gcloud builds submit

Esamina l'errore di build

La build che hai appena inviato non andrà a buon fine perché l'immagine contiene vulnerabilità CRITICHE.

Esamina l'errore di build nella pagina Cronologia di Cloud Build.

Correggere la vulnerabilità

Aggiorna il Dockerfile in modo che utilizzi un'immagine di base che non contenga vulnerabilità CRITICAL.

Sovrascrivi il Dockerfile per utilizzare l'immagine Debian 10 con questo comando

cat > ./Dockerfile << EOF
from python:3.8-slim  

# App
WORKDIR /app
COPY . ./

RUN pip3 install Flask==2.1.0
RUN pip3 install gunicorn==20.1.0

CMD exec gunicorn --bind :\$PORT --workers 1 --threads 8 main:app

EOF

Esegui il processo CI con l'immagine corretta

Invia la build per l'elaborazione per verificare che la build venga completata correttamente quando non vengono trovate vulnerabilità di gravità CRITICA.

gcloud builds submit

Esaminare la creazione riuscita

La build che hai appena inviato verrà completata perché l'immagine aggiornata non contiene vulnerabilità CRITICHE.

Controlla l'esito positivo della build nella pagina Cronologia di Cloud Build.

Esaminare i risultati della scansione

Esamina l'immagine corretta in Artifact Registry

1. Apri Artifact Registry in Cloud Console.
2. Fai clic su artifact-scanning-repo per visualizzare i contenuti.
3. Fai clic sui dettagli dell'immagine.
4. Fai clic sull'ultimo riepilogo della tua immagine
5. Fai clic sulla scheda delle vulnerabilità dell'immagine.

6. Immagini con firme

Creare una nota dell'attestatore

Una nota dell'attestatore è semplicemente un piccolo bit di dati che funge da etichetta per il tipo di firma applicata. Ad esempio, una nota potrebbe indicare la scansione delle vulnerabilità, mentre un'altra potrebbe essere utilizzata per l'approvazione del controllo qualità. La nota verrà consultata durante la procedura di firma.

Creare una nota

cat > ./vulnz_note.json << EOM
{
  "attestation": {
    "hint": {
      "human_readable_name": "Container Vulnerabilities attestation authority"
    }
  }
}
EOM

Memorizzare la nota

NOTE_ID=vulnz_note

curl -vvv -X POST \
    -H "Content-Type: application/json"  \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    --data-binary @./vulnz_note.json  \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"

Verificare la nota

curl -vvv  \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

Creazione di un attestatore

Gli attestatori vengono utilizzati per eseguire il processo di firma dell'immagine e allegare un'occorrenza della nota all'immagine per la verifica successiva. Crea l'attestatore per un utilizzo successivo.

Crea attestatore

ATTESTOR_ID=vulnz-attestor

gcloud container binauthz attestors create $ATTESTOR_ID \
    --attestation-authority-note=$NOTE_ID \
    --attestation-authority-note-project=${PROJECT_ID}

Verifica attestatore

gcloud container binauthz attestors list

Tieni presente che l'ultima riga indica NUM_PUBLIC_KEYS: 0 che fornirai le chiavi in un passaggio successivo

Tieni presente inoltre che Cloud Build crea automaticamente l'attestatore built-by-cloud-build nel tuo progetto quando esegui una build che genera immagini. Pertanto, il comando precedente restituisce due attestatori, vulnz-attestor e built-by-cloud-build. Una volta create correttamente, Cloud Build firma automaticamente le immagini e crea attestazioni per loro.

Aggiunta del ruolo IAM

Il service account Autorizzazione binaria dovrà disporre dei diritti per visualizzare le note di attestazione. Fornisci l'accesso con la seguente chiamata API

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

BINAUTHZ_SA_EMAIL="service-${PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"


cat > ./iam_request.json << EOM
{
  'resource': 'projects/${PROJECT_ID}/notes/${NOTE_ID}',
  'policy': {
    'bindings': [
      {
        'role': 'roles/containeranalysis.notes.occurrences.viewer',
        'members': [
          'serviceAccount:${BINAUTHZ_SA_EMAIL}'
        ]
      }
    ]
  }
}
EOM

Utilizza il file per creare il criterio IAM

curl -X POST  \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    --data-binary @./iam_request.json \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"

Aggiunta di una chiave KMS

L'attestatore ha bisogno di chiavi crittografiche per allegare la nota e fornire firme verificabili. In questo passaggio creerai e archivierai le chiavi in KMS a cui Cloud Build potrà accedere in un secondo momento.

Per prima cosa, aggiungi alcune variabili di ambiente per descrivere la nuova chiave

KEY_LOCATION=global
KEYRING=binauthz-keys
KEY_NAME=codelab-key
KEY_VERSION=1

Crea un portachiavi per contenere un insieme di chiavi

gcloud kms keyrings create "${KEYRING}" --location="${KEY_LOCATION}"

Crea una nuova coppia di chiavi di firma asimmetrica per l'attestatore

gcloud kms keys create "${KEY_NAME}" \
    --keyring="${KEYRING}" --location="${KEY_LOCATION}" \
    --purpose asymmetric-signing   \
    --default-algorithm="ec-sign-p256-sha256"

Dovresti visualizzare la chiave nella pagina KMS della console Google Cloud.

Ora associa la chiave al tuo attestatore tramite il comando gcloud binauthz:

gcloud beta container binauthz attestors public-keys add  \
    --attestor="${ATTESTOR_ID}"  \
    --keyversion-project="${PROJECT_ID}"  \
    --keyversion-location="${KEY_LOCATION}" \
    --keyversion-keyring="${KEYRING}" \
    --keyversion-key="${KEY_NAME}" \
    --keyversion="${KEY_VERSION}"

Se stampi di nuovo l'elenco delle autorità, ora dovresti vedere una chiave registrata:

gcloud container binauthz attestors list

Creazione di un'attestazione firmata

A questo punto, hai configurato le funzionalità che ti consentono di firmare le immagini. Utilizza l'attestatore che hai creato in precedenza per firmare l'immagine container con cui hai lavorato

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:latest \
    --format='get(image_summary.digest)')

Ora puoi utilizzare gcloud per creare l'attestazione. Il comando accetta semplicemente i dettagli della chiave che vuoi utilizzare per la firma e l'immagine container specifica che vuoi approvare.

gcloud beta container binauthz attestations sign-and-create  \
    --artifact-url="${CONTAINER_PATH}@${DIGEST}" \
    --attestor="${ATTESTOR_ID}" \
    --attestor-project="${PROJECT_ID}" \
    --keyversion-project="${PROJECT_ID}" \
    --keyversion-location="${KEY_LOCATION}" \
    --keyversion-keyring="${KEYRING}" \
    --keyversion-key="${KEY_NAME}" \
    --keyversion="${KEY_VERSION}"

In termini di Container Analysis, verrà creata una nuova occorrenza e verrà allegata alla nota dell'attestatore. Per assicurarti che tutto abbia funzionato come previsto, puoi elencare le tue attestazioni

gcloud container binauthz attestations list \
   --attestor=$ATTESTOR_ID --attestor-project=${PROJECT_ID}

7. Firma con Cloud Build

Hai attivato la firma delle immagini e utilizzato manualmente l'attestatore per firmare l'immagine di esempio. In pratica, ti consigliamo di applicare le attestazioni durante i processi automatizzati, come le pipeline CI/CD.

In questa sezione configurerai Cloud Build per attestare automaticamente le immagini.

Ruoli

Aggiungi il ruolo Visualizzatore attestatore di autorizzazione binaria al service account Cloud Build:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/binaryauthorization.attestorsViewer

Aggiungi il ruolo Firmatario/Responsabile verifica Cloud KMS CryptoKey al service account Cloud Build (firma basata su KMS):

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/cloudkms.signerVerifier

Aggiungi il ruolo Container Analysis Notes Attacher al service account Cloud Build:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
  --role roles/containeranalysis.notes.attacher

Prepara il passaggio di build personalizzato di Cloud Build

Utilizzerai un passaggio di build personalizzato in Cloud Build per semplificare la procedura di attestazione. Google fornisce questo passaggio di compilazione personalizzata che contiene funzioni di assistenza per semplificare il processo. Prima dell'uso, il codice del passaggio di build personalizzato deve essere integrato in un container e inviato a Cloud Build. Per farlo, esegui questi comandi:

git clone https://github.com/GoogleCloudPlatform/cloud-builders-community.git
cd cloud-builders-community/binauthz-attestation
gcloud builds submit . --config cloudbuild.yaml
cd ../..
rm -rf cloud-builders-community

Aggiungi un passaggio di firma al file cloudbuild.yaml

In questo passaggio aggiungerai il passaggio di attestazione alla pipeline Cloud Build che hai creato in precedenza.

1. Rivedi il nuovo passaggio che stai per aggiungere.

Solo revisione. Non copiare

#Sign the image only if the previous severity check passes
- id: 'create-attestation'
  name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
  args:
    - '--artifact-url'
    - 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image'
    - '--attestor'
    - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID'
    - '--keyversion'
    - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'

2. Sovrascrivi il file cloudbuild.yaml con la pipeline completa aggiornata.

cat > ./cloudbuild.yaml << EOF
steps:

# build
- id: "build"
  name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.']
  waitFor: ['-']

#Run a vulnerability scan at _SECURITY level
- id: scan
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    (gcloud artifacts docker images scan \
    us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
    --location us \
    --format="value(response.scan)") > /workspace/scan_id.txt

#Analyze the result of the scan
- id: severity check
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
      gcloud artifacts docker images list-vulnerabilities \$(cat /workspace/scan_id.txt) \
      --format="value(vulnerability.effectiveSeverity)" | if grep -Fxq CRITICAL; \
      then echo "Failed vulnerability check for CRITICAL level" && exit 1; else echo "No CRITICAL vulnerability found, congrats !" && exit 0; fi

#Retag
- id: "retag"
  name: 'gcr.io/cloud-builders/docker'
  args: ['tag',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']


#pushing to artifact registry
- id: "push"
  name: 'gcr.io/cloud-builders/docker'
  args: ['push',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']


#Sign the image only if the previous severity check passes
- id: 'create-attestation'
  name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
  args:
    - '--artifact-url'
    - 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'
    - '--attestor'
    - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID'
    - '--keyversion'
    - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'



images:
  - us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good
EOF

Esegui la build

gcloud builds submit

Esamina la build nella cronologia di Cloud Build

Apri Cloud Console alla pagina Cronologia di Cloud Build e controlla l'ultima build e l'esecuzione corretta dei passaggi della build.

8. Policy di controllo di ammissione

Autorizzazione binaria è una funzionalità di GKE e Cloud Run che consente di convalidare le regole prima che un'immagine container possa essere eseguita. La convalida viene eseguita su qualsiasi richiesta di esecuzione di un'immagine, che provenga da una pipeline CI/CD attendibile o da un utente che tenta manualmente di eseguire il deployment di un'immagine. Questa funzionalità ti consente di proteggere gli ambienti di runtime in modo più efficace rispetto ai soli controlli della pipeline CI/CD.

Per comprendere questa funzionalità, modificherai il criterio GKE predefinito per applicare una regola di autorizzazione rigorosa.

Crea il cluster GKE

Crea il cluster GKE:

gcloud beta container clusters create binauthz \
    --zone us-central1-a  \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

Consenti a Cloud Build di eseguire il deployment in questo cluster:

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
        --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
        --role="roles/container.developer"

Policy di autorizzazione di tutti

Innanzitutto, verifica lo stato del criterio predefinito e la tua capacità di eseguire il deployment di qualsiasi immagine

1. Esaminare la policy esistente

gcloud container binauthz policy export

2. Tieni presente che i criteri di applicazione sono impostati su ALWAYS_ALLOW

evaluationMode: ALWAYS_ALLOW

3. Esegui il deployment di Sample per verificare di poter eseguire il deployment di qualsiasi cosa

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

4. Verifica che il deployment abbia funzionato

kubectl get pods

Verrà visualizzato l'output seguente

5. Elimina deployment

kubectl delete pod hello-server

Policy di negazione di tutto

Ora aggiorna la policy per non consentire tutte le immagini.

1. Esportare il criterio attuale in un file modificabile

gcloud container binauthz policy export  > policy.yaml

2. Modifica la norma

In un editor di testo, modifica evaluationMode da ALWAYS_ALLOW a ALWAYS_DENY.

edit policy.yaml

Il file YAML della policy dovrebbe avere il seguente aspetto:

globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: ALWAYS_DENY
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
name: projects/PROJECT_ID/policy

3. Apri Terminale, applica il nuovo criterio e attendi qualche secondo affinché la modifica venga propagata.

gcloud container binauthz policy import policy.yaml

4. Tentativo di deployment del carico di lavoro di esempio

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

5. Il deployment non riesce e viene visualizzato il seguente messaggio

Error from server (VIOLATES_POLICY): admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image gcr.io/google-samples/hello-app:1.0 denied by Binary Authorization default admission rule. Denied by always_deny admission rule

Ripristina il criterio per consentire tutto

Prima di passare alla sezione successiva, assicurati di ripristinare le modifiche alle norme.

1. Modifica la norma

In un editor di testo, modifica evaluationMode da ALWAYS_DENY a ALWAYS_ALLOW.

edit policy.yaml

Il file YAML della policy dovrebbe avere il seguente aspetto:

globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: ALWAYS_ALLOW
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
name: projects/PROJECT_ID/policy

2. Applica la policy ripristinata

gcloud container binauthz policy import policy.yaml

9. Bloccare le vulnerabilità in GKE

In questa sezione combinerai ciò che hai imparato finora implementando una pipeline CI/CD con Cloud Build che esegue la scansione delle immagini, quindi verifica la presenza di vulnerabilità prima di firmare l'immagine e tentare il deployment. GKE utilizzerà Autorizzazione binaria per verificare che l'immagine abbia una firma dall'analisi delle vulnerabilità prima di consentirne l'esecuzione.

Aggiorna il criterio GKE per richiedere l'attestazione

Richiedi che le immagini siano firmate dal tuo attestatore aggiungendo clusterAdmissionRules alla tua policy BinAuth di GKE

Sovrascrivi la policy con la configurazione aggiornata utilizzando il comando riportato di seguito.

COMPUTE_ZONE=us-central1-a

cat > binauth_policy.yaml << EOM
defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
clusterAdmissionRules:
  ${COMPUTE_ZONE}.binauthz:
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    requireAttestationsBy:
    - projects/${PROJECT_ID}/attestors/vulnz-attestor
EOM

Applica la policy

gcloud beta container binauthz policy import binauth_policy.yaml

Tentativo di deployment dell'immagine non firmata

Crea un descrittore di deployment per l'applicazione che hai creato in precedenza utilizzando il seguente comando. L'immagine utilizzata qui è quella che hai creato in precedenza, che contiene vulnerabilità critiche e NON contiene l'attestazione firmata.

I controller di ammissione di GKE devono conoscere l'immagine esatta da implementare per convalidare in modo coerente la firma. Per farlo, devi utilizzare il digest delle immagini anziché un semplice tag.

Recupera il digest dell'immagine non conforme

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image


DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:bad \
    --format='get(image_summary.digest)')

Utilizza il digest nella configurazione di Kubernetes

cat > deploy.yaml << EOM
apiVersion: v1
kind: Service
metadata:
  name: deb-httpd
spec:
  selector:
    app: deb-httpd
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deb-httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: deb-httpd
  template:
    metadata:
      labels:
        app: deb-httpd
    spec:
      containers:
      - name: deb-httpd
        image: ${CONTAINER_PATH}@${DIGEST}
        ports:
        - containerPort: 8080
        env:
          - name: PORT
            value: "8080"

EOM

Tenta di eseguire il deployment dell'app in GKE

kubectl apply -f deploy.yaml

Esamina il workload nella console e prendi nota dell'errore che indica che il deployment è stato negato:

No attestations found that were valid and signed by a key trusted by the attestor

Esegui il deployment di un'immagine firmata

Recupera il digest dell'immagine non conforme

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image


DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:good \
    --format='get(image_summary.digest)')

Utilizza il digest nella configurazione di Kubernetes

cat > deploy.yaml << EOM
apiVersion: v1
kind: Service
metadata:
  name: deb-httpd
spec:
  selector:
    app: deb-httpd
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deb-httpd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: deb-httpd
  template:
    metadata:
      labels:
        app: deb-httpd
    spec:
      containers:
      - name: deb-httpd
        image: ${CONTAINER_PATH}@${DIGEST}
        ports:
        - containerPort: 8080
        env:
          - name: PORT
            value: "8080"

EOM

Esegui il deployment dell'app in GKE

kubectl apply -f deploy.yaml

Esamina il workload nella console e prendi nota del deployment riuscito dell'immagine.

10. Complimenti!

Congratulazioni, hai completato il codelab.

Argomenti trattati:

• Come attivare la scansione automatica
• Come eseguire la scansione on demand
• Come integrare la scansione in una pipeline di build
• Come firmare le immagini approvate
• Come utilizzare i controller di ammissione GKE per bloccare le immagini
• Come configurare GKE per consentire solo immagini approvate firmate

Qual è il passaggio successivo?

• Protezione dei deployment di immagini in Cloud Run e Google Kubernetes Engine | Documentazione di Cloud Build
• Guida rapida: configura un criterio di autorizzazione binaria con GKE | Google Cloud

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

Il modo più semplice per eliminare la fatturazione è eliminare il progetto creato per il tutorial.