Questa pagina è stata tradotta dall'API Cloud Translation.

Inizia a utilizzare Google Cloud CLI (GKE)

Questo tutorial mostra come configurare e testare un criterio di Autorizzazione binaria che richiede attestati. Questo tipo di criterio protegge la catena di fornitura del software basata su container verificando che un'immagine container abbia un'attestazione firmata prima di consentire il deployment dell'immagine.

Al momento del deployment, Autorizzazione binaria utilizza gli attestatori per verificare le firme digitali nelle attestazioni. Le attestazioni sono create da signori, di solito come parte di una pipeline di integrazione continua (CI).

In questo tutorial, il cluster GKE, le attestazioni e gli attestatori si trovano tutti in un unico progetto. La configurazione per un singolo progetto è utile soprattutto per testare o sperimentare il servizio. Per un esempio reale, consulta la pagina Configurazione multiprogetto.

I passaggi seguenti descrivono le attività eseguite dalla riga di comando. Per seguire questi passaggi utilizzando la console Google Cloud, consulta la Guida introduttiva all'utilizzo della console Google Cloud.

Obiettivi

In questo tutorial imparerai a:

Crea un cluster Google Kubernetes Engine (GKE) con Autorizzazione binaria abilitata
Crea un attestatore utilizzato dall'applicazione di Autorizzazione binaria per verificare la firma su un'attestazione
Configurare un criterio che richiede un'attestazione
Crea una coppia di chiavi di crittografia per firmare le attestazioni e verificarle in un secondo momento
Firma un digest dell'immagine container, creando una firma
Crea un'attestazione utilizzando la firma
Testa il criterio eseguendo il deployment di un'immagine container su GKE

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

Artifact Registry o Container Registry
Autorizzazione binaria
GKE
Facoltativo: Cloud Key Management Service

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.

Prima di iniziare

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.

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

Vai al selettore progetti

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

Installa Google Cloud CLI.

Per inizializzare l'interfaccia a riga di comando gcloud, esegui il comando seguente:

gcloud init

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

Vai al selettore progetti

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

Installa Google Cloud CLI.

Per inizializzare l'interfaccia a riga di comando gcloud, esegui il comando seguente:

gcloud init

Installa kubectl per interagire con GKE.

Attiva Autorizzazione binaria

Imposta il progetto predefinito

Il primo passaggio consiste nell'impostare il progetto Google Cloud predefinito utilizzato dal comando gcloud:

PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}

dove PROJECT_ID è il nome del tuo progetto.

Abilita le API richieste

Abilita le API per:

Container Registry

gcloud --project=${PROJECT_ID} \
    services enable\
    container.googleapis.com\
    containerregistry.googleapis.com\
    binaryauthorization.googleapis.com

Artifact Registry

gcloud --project=${PROJECT_ID} \
    services enable\
    container.googleapis.com\
    artifactregistry.googleapis.com\
    binaryauthorization.googleapis.com

Crea un cluster con Autorizzazione binaria abilitata

Crea il cluster

Creare un cluster GKE con Autorizzazione binaria abilitata. Questo è il cluster in cui vuoi eseguire le immagini container di cui hai eseguito il deployment. Quando crei il cluster, passi il flag --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE al comando gcloud container clusters create.

Per creare il cluster, segui questi passaggi:

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

Qui crei un cluster denominato test-cluster nella zona GKE us-central1-a.

Configura `kubectl`

Devi anche aggiornare il file kubeconfig locale per l'installazione kubectl. Questo fornisce le credenziali e le informazioni sull'endpoint necessarie per accedere al cluster in GKE.

Per aggiornare il file kubeconfig locale:

gcloud container clusters get-credentials \
    --zone us-central1-a \
    test-cluster

Visualizza il criterio predefinito

Un criterio in Autorizzazione binaria è un insieme di regole che regolano il deployment delle immagini container. Puoi avere un solo criterio per progetto. Per impostazione predefinita, il criterio è configurato in modo da consentire il deployment di tutte le immagini container.

Autorizzazione binaria consente di esportare e importare un file dei criteri in formato YAML. Questo formato rispecchia la struttura di un criterio quando viene archiviato dal servizio. Quando configuri un criterio utilizzando i comandi gcloud, puoi modificare questo file.

Per visualizzare il criterio predefinito, esporta il file YAML del criterio:

gcloud container binauthz policy export

Per impostazione predefinita, il file include i seguenti contenuti:

admissionWhitelistPatterns:
- namePattern: gcr.io/google_containers/*
- namePattern: gcr.io/google-containers/*
- namePattern: k8s.gcr.io/**
- namePattern: gke.gcr.io/**
- namePattern: gcr.io/stackdriver-agents/*
globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: ALWAYS_ALLOW
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
name: projects/${PROJECT_ID}/policy

In questo caso, la regola predefinita è definita nel nodo defaultAdmissionRule. evaluationMode specifica che il criterio consente tutti i tentativi di deployment delle immagini. In questo tutorial, aggiorni la regola predefinita per richiedere le attestazioni.

Per ulteriori informazioni sulla struttura di un criterio, consulta la pagina Riferimento YAML per i criteri.

Crea un attestatore

Un attestatore è l'autorità di verifica utilizzata dall'applicazione di Autorizzazione binaria al momento del deployment per decidere se consentire a GKE di eseguire il deployment dell'immagine del container firmato corrispondente. L'attestatore contiene la chiave pubblica ed è solitamente gestito dal personale della tua organizzazione che è responsabile della sicurezza della catena di fornitura del software.

Per creare un attestatore devi:

Crea una nota in Container Analysis per archiviare i metadati attendibili utilizzati nel processo di autorizzazione
Crea l'attestatore in Autorizzazione binaria e associa la nota che hai creato

Per questo tutorial, hai un attestatore denominato test-attestor e una nota Container Analysis test-attestor-note. In uno scenario reale, puoi avere un numero qualsiasi di attestatori, ognuno dei quali rappresenta una parte che partecipa al processo di autorizzazione per un'immagine container.

Crea la nota Container Analysis

Imposta le variabili in cui è memorizzato il nome dell'attestatore e della nota Container Analysis:
```
ATTESTOR_NAME=test-attestor
NOTE_ID=test-attestor-note
```
Sostituisci:
- test-attestor: nome dell'attestatore a tua scelta.
- attestor-note: nome della nota dell'attestatore di tua scelta.

Crea un file JSON in /tmp/note_payload.json che descriva la nota Container Analysis:

cat > /tmp/note_payload.json << EOM
{
  "name": "projects/${PROJECT_ID}/notes/${NOTE_ID}",
  "attestation": {
    "hint": {
      "human_readable_name": "Attestor Note"
    }
  }
}
EOM

Crea la nota inviando una richiesta HTTP all'API REST di Container Analysis:

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

Verifica che la nota sia stata creata:

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

Crea l'attestatore

Ora puoi creare l'attestatore:

Crea l'attestatore in Autorizzazione binaria:

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

Verifica che l'attestatore sia stato creato:
```
gcloud container binauthz attestors list
```

L'attestatore che hai creato non è ancora utilizzabile senza una coppia di chiavi PKIX associata, creata di seguito.

Per una configurazione multiprogetto, devi impostare le autorizzazioni nella nota Container Analysis come descritto nella sezione Configurazione multiprogetto. Questo non è obbligatorio in uno scenario con un singolo progetto, perché il progetto ha il roles/containeranalysis.notes.occurrences.viewer richiesto per impostazione predefinita.

Genera una coppia di chiavi

Autorizzazione binaria utilizza le chiavi crittografiche per verificare in modo sicuro l'identità dei firmatori. Questo garantisce che sia possibile eseguire il deployment solo delle immagini container autorizzate. La coppia di chiavi è composta da una chiave privata e da una chiave pubblica. Il firmatore utilizza la chiave privata per firmare il digest dell'immagine container, producendo una firma che viene quindi archiviata in un'attesta. La chiave pubblica è archiviata nell'attestatore. Al momento del deployment, lo strumento di Autorizzazione binaria utilizza la chiave pubblica dell'attestatore per verificare la firma nell'attestatore prima di consentire il deployment del container.

In questo tutorial, utilizzi il formato Public-Key Infrastructure (X.509) (PKIX) per le chiavi di crittografia. Questo tutorial utilizza l'algoritmo di firma digitale della curva ellittica (ECDSA) consigliato per generare una coppia di chiavi PKIX. Per la firma puoi anche utilizzare chiavi RSA o PGP.

Scopi e algoritmi chiave per ulteriori informazioni sugli algoritmi di firma.

Le chiavi generate e archiviate da Cloud Key Management Service (Cloud KMS) sono conformi a PKIX. Per saperne di più sull'utilizzo delle chiavi PKIX e Cloud KMS, consulta Creazione di attestatori mediante l'interfaccia a riga di comando gcloud.

Per generare una coppia di chiavi PKIX, segui questi passaggi:

Crea la chiave privata:

PRIVATE_KEY_FILE="/tmp/ec_private.pem"
openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}

Estrai la chiave pubblica dalla chiave privata:

PUBLIC_KEY_FILE="/tmp/ec_public.pem"
openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}

Aggiungi la chiave pubblica ECDSA nell'attestatore.

Ora, aggiungi la chiave pubblica esportata all'attestatore in modo che possa essere utilizzata dall'Autorizzazione binaria per la verifica dell'identità:
```
gcloud --project="${PROJECT_ID}" \
    beta container binauthz attestors public-keys add \
    --attestor="${ATTESTOR_NAME}" \
    --pkix-public-key-file=${PUBLIC_KEY_FILE} \
    --pkix-public-key-algorithm=ecdsa-p256-sha256
```
Nota: questo comando restituisce PUBLIC_KEY_ID che utilizzerai quando crei un'attestazione. Si trova nel campo id dell'output e ha un aspetto simile a ni:///sha-256;ybf_gINTzsBKLCaRIeQnExNhKFkGONXXXlr63QeZY-Q.
Salva l'ID della chiave pubblica.

Per salvare l'ID della chiave pubblica, puoi copiarlo dall'output di public-keys add sopra. Per visualizzare l'ID della chiave pubblica dell'attestatore dopo averlo aggiunto all'attestatore, utilizza gcloud container binauthz attestors describe ${ATTESTOR_NAME}:
```
PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \
  --format='value(userOwnedGrafeasNote.publicKeys[0].id)')
```

Configura il criterio

Ora puoi configurare il criterio. In questo passaggio, esporti il file YAML del criterio nel tuo sistema locale e modifichi la regola predefinita in modo che richieda un'attesta da parte dell'attestatore definito sopra.

Per configurare il criterio, segui questi passaggi:

Crea un nuovo file di criteri che consenta le immagini di sistema gestite da Google, imposti evaluationMode su REQUIRE_ATTESTATION e aggiunga un nodo denominato requireAttestationsBy che fa riferimento all'attestatore che hai creato:

cat > /tmp/policy.yaml << EOM
    globalPolicyEvaluationMode: ENABLE
    defaultAdmissionRule:
      evaluationMode: REQUIRE_ATTESTATION
      enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
      requireAttestationsBy:
        - projects/${PROJECT_ID}/attestors/${ATTESTOR_NAME}
    name: projects/${PROJECT_ID}/policy
EOM

Importa il file YAML del criterio in Autorizzazione binaria:
```
gcloud container binauthz policy import /tmp/policy.yaml
```

Per ulteriori informazioni sulla configurazione di un criterio, consulta Configurare un criterio utilizzando l'interfaccia a riga di comando gcloud.

Testa il criterio

Puoi testare il criterio configurato sopra cercando di eseguire il deployment di un'immagine container di esempio nel cluster. Il criterio bloccherà il deployment perché l'attestazione richiesta non è stata effettuata.

Per questo tutorial, puoi utilizzare immagini di esempio di Container Registry e Artifact Registry. L'immagine di Container Registry si trova nel percorso gcr.io/google-samples/hello-app:1.0. L'immagine di Artifact Registry si trova nel percorso us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0. Entrambi i percorsi contengono un'immagine pubblica creata da Google che contiene un'applicazione di esempio "Hello World".

Innanzitutto, prova a eseguire il deployment dell'immagine:

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

Ora verifica che il deployment sia stato bloccato da Autorizzazione binaria:

kubectl get pods

Il comando stampa il seguente messaggio, a indicare che il deployment dell'immagine non è stato eseguito:

No resources found.

Puoi ottenere ulteriori dettagli sul deployment:

kubectl get event --template \
'{{range.items}}{{"\033[0;36m"}}{{.reason}}:{{"\033[0m"}}\{{.message}}{{"\n"}}{{end}}'

Viene visualizzata una risposta simile alla seguente:

FailedCreate: Error creating: pods POD_NAME is forbidden: admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image IMAGE_NAME denied by Binary Authorization default admission rule. Image IMAGE_NAME denied by attestor ATTESTOR_NAME: No attestations found

In questo output:

POD_NAME: il nome del pod.
IMAGE_NAME: il nome dell'immagine.
ATTESTOR_NAME: il nome dell'attestatore.

Assicurati di eliminare il deployment per poter andare al passaggio successivo:

kubectl delete deployment hello-server

Crea un'attestazione

Un'attesta è un documento digitale creato da un firmatore che certifica che GKE è autorizzato a eseguire il deployment dell'immagine container associata. Il processo di creazione di un'attestazione viene talvolta chiamato "firma di un'immagine". Per firmatario si intende una persona o, più spesso, un processo automatizzato che viene eseguito alla creazione di un'immagine container. La firma viene creata utilizzando la chiave privata da una coppia di chiavi. Al momento del deployment, l'applicazione forzata di Autorizzazione binaria utilizza la chiave pubblica dell'attestatore per verificare la firma nell'attestazione.

In questo tutorial, la tua attestazione indica semplicemente che autorizzi l'immagine per il deployment.

Per creare un'attestazione:

Imposta le variabili in cui archiviare il percorso del Registro di sistema e la sintesi dell'immagine:

Container Registry

IMAGE_PATH="gcr.io/google-samples/hello-app"
IMAGE_DIGEST="sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4"
IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}

Artifact Registry

IMAGE_PATH="us-docker.pkg.dev/google-samples/containers/gke/hello-app"
IMAGE_DIGEST="sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}

Genera il payload dell'attestazione:

gcloud container binauthz create-signature-payload \
--artifact-url=${IMAGE_TO_ATTEST} > /tmp/generated_payload.json

Il file JSON del payload ha i seguenti contenuti:

{
  "critical": {
    "identity": {
      "docker-reference": "gcr.io/google-samples/hello-app"
    },
    "image": {
      "docker-manifest-digest": "sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea
882eb722c3be4"
    },
    "type": "Google cloud binauthz container signature"
  }
}

Firma il payload con la chiave privata PKIX e genera un file della firma:
```
openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
```
Il file della firma è una versione con firma digitale del file JSON del payload che hai creato in precedenza.

Crea e convalida l'attestazione:

gcloud container binauthz attestations create \
    --project="${PROJECT_ID}" \
    --artifact-url="${IMAGE_TO_ATTEST}" \
    --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
    --signature-file=/tmp/ec_signature \
    --public-key-id="${PUBLIC_KEY_ID}" \
    --validate

dove PUBLIC_KEY_ID è l'ID della chiave pubblica che hai trovato in Generare una coppia di chiavi PKIX sopra.

Il flag validate controlla che l'attestazione possa essere verificata dall'attestatore configurato nel criterio.

Verifica che l'attestazione sia stata creata:

gcloud container binauthz attestations list \
    --attestor=$ATTESTOR_NAME --attestor-project=$PROJECT_ID

Per scoprire di più sulla creazione di attestazioni, consulta la sezione Creazione di attestazioni.

Ripeti il test del criterio

Come già detto, prova il criterio eseguendo il deployment di un'immagine container di esempio nel cluster. Questa volta devi eseguire il deployment dell'immagine utilizzando il digest anziché un tag come 1.0 o latest, poiché Autorizzazione binaria utilizzerà sia il percorso dell'immagine sia il digest per cercare le attestazioni. Autorizzazione binaria consente il deployment dell'immagine perché è stata effettuata l'attestazione richiesta.

Per eseguire il deployment dell'immagine, segui questi passaggi:

kubectl run hello-server --image ${IMAGE_TO_ATTEST} --port 8080

Per verificare che il deployment dell'immagine sia stato eseguito:

kubectl get pods

Il comando stampa un messaggio simile al seguente, che indica che il deployment è riuscito:

NAME                            READY     STATUS    RESTARTS   AGE
hello-server-579859fb5b-h2k8s   1/1       Running   0          1m

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 cluster che hai creato in GKE:

gcloud container clusters delete \
    --zone=us-central1-a \
    test-cluster

Passaggi successivi

Scopri di più su Autorizzazione binaria
Scopri i concetti chiave utilizzati in Autorizzazione binaria
Utilizza l'attestatore built-by-cloud-build per eseguire il deployment solo delle immagini create da Cloud Build (Anteprima).
Abilita la modalità di prova per disabilitare l'applicazione
Utilizzare il deployment di emergenza per bypassare l'applicazione

Inizia a utilizzare Google Cloud CLI (GKE)

Obiettivi

Costi

Prima di iniziare

Attiva Autorizzazione binaria

Imposta il progetto predefinito

Abilita le API richieste

Container Registry

Artifact Registry

Crea un cluster con Autorizzazione binaria abilitata

Crea il cluster

Configura kubectl

Visualizza il criterio predefinito

Crea un attestatore

Crea la nota Container Analysis

Crea l'attestatore

Genera una coppia di chiavi

Configura il criterio

Testa il criterio

Crea un'attestazione

Container Registry

Artifact Registry

Ripeti il test del criterio

Esegui la pulizia

Passaggi successivi

Configura `kubectl`