Blocco dei deployment con Autorizzazione binaria

1. Introduzione

Autorizzazione binaria è un controllo di sicurezza della fase di deployment che garantisce che venga eseguito il deployment su Google Kubernetes Engine (GKE) o Cloud Run solo delle immagini container attendibili. Con Autorizzazione binaria, puoi richiedere che le immagini vengano firmate da autorità attendibili durante il processo di sviluppo e quindi applicare la convalida della firma durante il deployment. Se applichi la convalida, puoi controllare più strettamente l'ambiente dei container assicurando che solo le immagini verificate siano integrate nel processo di build e rilascio.

Il seguente diagramma mostra i componenti in una configurazione di Autorizzazione binaria/Cloud Build:

**Figura 1.**Pipeline Cloud Build che crea un'attestazione di Autorizzazione binaria.

In questa pipeline:

1. Il codice per creare l'immagine container viene inviato a un repository di origine, ad esempio Cloud Source Repositories.
2. Uno strumento di integrazione continua (CI), Cloud Build, crea e testa il container.
3. La build esegue il push dell'immagine container in Container Registry o in un altro registro che archivia le immagini create.
4. Cloud Key Management Service, che fornisce la gestione delle chiavi per la coppia di chiavi di crittografia, firma l'immagine container. La firma risultante viene quindi archiviata in un'attestazione appena creata.
5. Al momento del deployment, l'attestatore verifica l'attestazione utilizzando la chiave pubblica della coppia di chiavi. Autorizzazione binaria applica i criteri richiedendo attestazioni firmate per eseguire il deployment dell'immagine container.

In questo lab ti concentrerai sugli strumenti e sulle tecniche per proteggere gli artefatti di cui è stato eseguito il deployment. Questo lab si concentra sugli artefatti (container) dopo la loro creazione, ma prima che vengano implementati in un ambiente specifico.

Cosa imparerai a fare

• Firma delle immagini
• Policy di controllo di ammissione
• Firma di immagini scansionate
• Autorizzazione delle immagini firmate
• Immagini non firmate bloccate

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

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

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

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.

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

3. Firma delle immagini

Che cos'è un attestatore

Attestatore

• Questa persona/questo processo è responsabile di un collegamento nella catena di attendibilità del sistema.
• Possiedono una chiave di crittografia e firmano un'immagine se supera la procedura di approvazione.
• Mentre il creatore delle norme determina le norme in modo astratto e di alto livello, l'attestatore è responsabile dell'applicazione concreta di un aspetto delle norme.
• Può essere una persona reale, come un tester QA o un manager, oppure un bot in un sistema di integrazione continua.
• La sicurezza del sistema dipende dalla loro affidabilità, quindi è importante che le loro chiavi private siano protette.

Ciascuno di questi ruoli può rappresentare una singola persona o un team di persone della tua organizzazione. In un ambiente di produzione, questi ruoli verrebbero probabilmente gestiti da progetti Google Cloud Platform (GCP) separati e l'accesso alle risorse verrebbe condiviso tra loro in modo limitato utilizzando Cloud IAM.

Gli attestatori in Autorizzazione binaria vengono implementati sopra l'API Container Analysis, quindi è importante descrivere il funzionamento prima di procedere. L'API Container Analysis è stata progettata per consentirti di associare metadati a immagini container specifiche.

Ad esempio, è possibile creare una nota per monitorare la vulnerabilità Heartbleed. I fornitori di sicurezza creerebbero quindi scanner per testare le immagini container alla ricerca della vulnerabilità e creare un'occorrenza associata a ogni container compromesso.

Oltre a monitorare le vulnerabilità, Container Analysis è stato progettato per essere un'API di metadati generica. Autorizzazione binaria utilizza Container Analysis per associare le firme alle immagini container che sta verificando. Una nota di Container Analysis viene utilizzata per rappresentare un singolo attestatore e le occorrenze vengono create e associate a ogni container approvato dall'attestatore.

L'API Autorizzazione binaria utilizza i concetti di "attestatori" e "attestazioni", ma questi vengono implementati utilizzando note e occorrenze corrispondenti nell'API Container Analysis.

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

La nota è ora salvata nell'API Container Analysis.

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. Per utilizzare l'attestatore, devi anche registrare la nota con Autorizzazione binaria:

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

Prima di poter utilizzare questo attestatore, l'autorità deve creare una coppia di chiavi di crittografia che possono essere utilizzate per firmare le immagini container. Questa operazione può essere eseguita tramite Google Cloud Key Management Service (KMS).

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.

Un'attestazione deve includere una firma crittografica per dichiarare che l'attestatore ha verificato una particolare immagine container ed è sicura da eseguire sul cluster. Per specificare quale immagine container attestare, devi determinarne il digest.

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}

4. 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 con Autorizzazione binaria abilitata:

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

Questa policy è relativamente semplice. La riga globalPolicyEvaluationMode dichiara che questa policy estende la policy globale definita da Google. In questo modo, per impostazione predefinita possono essere eseguiti tutti i container GKE ufficiali. Inoltre, il criterio dichiara una defaultAdmissionRule che indica che tutti gli altri pod verranno rifiutati. La regola di ammissione include una riga enforcementMode, che indica che l'esecuzione di tutti i pod non conformi a questa regola deve essere bloccata sul cluster.

Per istruzioni su come creare policy più complesse, consulta la documentazione di Autorizzazione binaria.

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

5. Firma di immagini scansionate

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

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"

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.

1. Esamina il passaggio di firma riportato di seguito.

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. Scrivi un file cloudbuild.yaml con la pipeline completa riportata di seguito.

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.

6. Autorizzazione delle immagini firmate

In questa sezione aggiornerai GKE in modo che utilizzi l'autorizzazione binaria per convalidare 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

Al momento, il cluster esegue una policy con una regola: consentire i container dai repository ufficiali e rifiutare tutti gli altri.

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

Ora dovresti avere un nuovo file sul disco, chiamato updated_policy.yaml. Ora, anziché rifiutare tutte le immagini, la regola predefinita controlla prima le verifiche del tuo attestatore.

Carica il nuovo criterio in Autorizzazione binaria:

gcloud beta container binauthz policy import binauth_policy.yaml

Esegui il deployment di un'immagine firmata

Ottieni il digest dell'immagine per l'immagine buona

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.

7. Immagini non firmate bloccate

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:bad .

Esegui il push dell'immagine non firmata nel repository

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

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

8. Complimenti!

Congratulazioni, hai completato il codelab.

Argomenti trattati:

• Firma delle immagini
• Policy di controllo di ammissione
• Firma di immagini scansionate
• Autorizzazione delle immagini firmate
• Immagini non firmate bloccate

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.

—

Ultimo aggiornamento: 21/03/23