Inizia a utilizzare la console Google Cloud (GKE)

Nota: questo tutorial presuppone che tu abbia letto la panoramica di Autorizzazione binaria.

Questo tutorial mostra come configurare e testare un criterio di autorizzazione binaria che richiede attestazioni. Questo tipo di policy protegge la catena di fornitura del software basata su container definendo chi può eseguire il deployment di immagini container su Google Kubernetes Engine (GKE) e quali immagini container GKE può eseguire il deployment.

Al momento del deployment, Autorizzazione binaria utilizza gli attestatori per verificare le firme digitali nelle attestazioni. Le attestazioni sono state create dai firmatari nell'ambito del processo di compilazione.

In questo tutorial, il cluster GKE, le attestazioni e gli attestatori si trovano tutti in un unico progetto. Una configurazione a progetto singolo è utile soprattutto per testare o sperimentare il servizio. Per un esempio più realistico, consulta la configurazione multi-progetto.

I passaggi riportati di seguito descrivono le attività che esegui dalla console Google Cloud , nonché alcune attività che esegui utilizzando i comandi gcloud. Per eseguire questi passaggi utilizzando gcloud, consulta Inizia a utilizzare Google Cloud CLI.

Obiettivi

In questo tutorial imparerai a:

• Crea un cluster (GKE) con Autorizzazione binaria abilitata
• Crea un attestatore che l'enforcer di Autorizzazione binaria utilizza per verificare la firma di un'attestazione.
• Configura 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
• Creare un'attestazione utilizzando la firma
• Testa la policy eseguendo il deployment di un'immagine container su GKE

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

• Artifact Registry
• Binary Authorization
• GKE
• Optional: 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 potrebbero avere diritto a una prova senza costi.

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 senza costi per l'esecuzione, il test e il deployment dei carichi di lavoro.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Container Registry, Artifact Analysis and Binary Authorization APIs, if any are not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

Install the Google Cloud CLI.

If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

To initialize the gcloud CLI, run the following command:

gcloud init

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Container Registry, Artifact Analysis and Binary Authorization APIs, if any are not already enabled.

Roles required to enable APIs

To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

Enable the APIs

Install the Google Cloud CLI.

If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

To initialize the gcloud CLI, run the following command:

gcloud init

1. Installa kubectl.

Impostare il progetto predefinito

Per facilitare i comandi successivi, archivia l'ID progetto Google Cloud in una variabile di ambiente come segue:

PROJECT_ID=PROJECT_ID

dove PROJECT_ID è il nome del tuo progetto.

Se il progetto predefinito non è selezionato, impostalo ora:

gcloud config set project ${PROJECT_ID}

Crea un cluster con Autorizzazione binaria abilitata

Crea il cluster

Ora puoi creare un cluster GKE con Autorizzazione binaria abilitata. Qui crei un cluster denominato test-cluster nella zona GKE us-central1-a.

Per creare il cluster:

1. Visita il menu GKE nella console Google Cloud .

   Vai a GKE

2. Fai clic su Crea cluster.

3. Inserisci test-cluster nel campo Nome.

4. Seleziona A livello di zona nelle opzioni Tipo di località.

5. Seleziona us-central1-a dall'elenco a discesa Zona.

6. Nel riquadro di navigazione, nella sezione Cluster, fai clic su Impostazioni avanzate.

7. Nella riga Autorizzazione binaria, fai clic su Modifica configurazione.

8. Seleziona Attiva Autorizzazione binaria.

9. Seleziona Solo applicazione e poi fai clic su Salva.

10. Fai clic su Crea.

Configura kubectl

Devi anche aggiornare il file kubeconfig locale per l'installazione di kubectl. Vengono fornite 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

Visualizzare la policy predefinita

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

Per visualizzare la policy predefinita:

1. Vai alla pagina Autorizzazione binaria nella console Google Cloud .

   Vai ad Autorizzazione binaria

2. Fai clic su Modifica policy.

3. In Regola predefinita del progetto, viene visualizzata l'opzione Consenti tutte le immagini.

4. Fai clic su Save Policy (Salva criterio).

Crea un attestatore

Un attestatore è l'autorità di verifica che lo strumento di applicazione di Autorizzazione binaria utilizza al momento del deployment per decidere se consentire a GKE di eseguire il deployment dell'immagine container firmata corrispondente. L'attestatore contiene la chiave pubblica ed è in genere gestito da persone responsabili della sicurezza della catena di fornitura del software.

Per creare un attestatore, devi:

• Crea l'attestatore in Autorizzazione binaria
• Genera automaticamente una nota dell'attestatore associato in Analisi artefatti per archiviare i metadati di attestazione attendibili utilizzati nel processo di autorizzazione

Per questo tutorial, hai un attestatore di nome test-attestor. In uno scenario reale, puoi avere un numero qualsiasi di attestatori, ognuno dei quali rappresenta una parte che partecipa al processo di autorizzazione per l'immagine.

Genera una coppia di chiavi

L'autorizzazione binaria utilizza chiavi di crittografia per verificare in modo sicuro l'identità dei firmatari. In questo modo, solo le immagini container autorizzate possono essere sottoposte a deployment. La coppia di chiavi è costituita da una chiave privata e una chiave pubblica. Il firmatario utilizza la chiave privata per firmare il digest dell'immagine container, producendo una firma che viene poi archiviata in un'attestazione. La chiave pubblica è archiviata nell'attestatore. Al momento del deployment, l'enforcer di Autorizzazione binaria utilizza la chiave pubblica dell'attestatore per verificare la firma nell'attestazione 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 Elliptic Curve Digital Signature Algorithm (ECDSA) consigliato per generare una coppia di chiavi PKIX. Puoi anche utilizzare chiavi RSA o PGP per la firma. Per ulteriori informazioni sugli algoritmi di firma, consulta la sezione Scopi e algoritmi delle chiavi.

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 di Cloud KMS, consulta Creazione di attestatori mediante l'interfaccia a riga di comando.

Avviso:sconsigliamo vivamente l'utilizzo di coppie di chiavi generate localmente negli ambienti di produzione, in quanto rappresentano un rischio per la sicurezza. Ti consigliamo invece di utilizzare Cloud Key Management Service. Questo esempio è fornito solo a scopo illustrativo.

Per generare una coppia di chiavi PKIX:

1. Crea la chiave privata:

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

2. 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}
   

Crea l'attestatore

Ora puoi creare l'attestatore stesso in Autorizzazione binaria e associare la chiave pubblica che hai creato.

Per creare l'attestatore:

1. Torna alla pagina Autorizzazione binaria nella console Google Cloud .

   Torna all'autorizzazione binaria

2. Nella scheda Attestatori, fai clic su Crea.

   

3. Compila i campi come segue:

   1. Inserisci test-attestor nel campo Nome attestatore.

   2. Verifica che l'opzione Crea automaticamente un Artifact Analysis artefatti sia selezionata.

   3. Fai clic su Aggiungi una chiave pubblica PKIX.

   4. Apri /tmp/ec_public.pem in un editor di testo. Questo è il file della chiave pubblica che hai creato nel passaggio precedente. Copia i contenuti del file nella casella di testo Materiale della chiave pubblica.

   5. Fai clic su Elliptic Curve P-256 - SHA256 Digest nel menu a discesa Algoritmo di firma.

   6. Fai clic su Fine.

4. Fai clic su Crea per creare l'attestatore.

5. Memorizza l'ID chiave pubblica.

   Per visualizzare l'ID della chiave pubblica dell'attestatore dopo averlo aggiunto, utilizza gcloud container binauthz attestors describe ${ATTESTOR_NAME}. Per creare una variabile di ambiente per archiviare l'ID della chiave pubblica, esegui questo comando:

   ATTESTOR_NAME=test-attestor
   PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME}\
     --format='value(userOwnedGrafeasNote.publicKeys[0].id)')
   

Configura la policy

Ora puoi configurare la tua policy:

1. Torna alla pagina Autorizzazione binaria nella console Google Cloud .

2. Nella scheda Policy, fai clic su Modifica policy.

3. Seleziona Consenti solo le immagini approvate dai seguenti attestatori.

4. Fai clic su Aggiungi attestatori.

5. Fai clic su Aggiungi per progetto e nome del dichiarante.

6. Inserisci PROJECT_ID nel campo Nome progetto.

7. Inserisci test-attestor nel campo Nome attestatore.

8. Fai clic su Aggiungi 1 attestatore.

9. Fai clic su Save Policy (Salva criterio).

Nota: l'applicazione del criterio può richiedere alcuni minuti.

Per saperne di più, consulta Configurazione di una policy utilizzando la console.

Testa la policy

Puoi testare la policy che hai configurato sopra provando a eseguire il deployment di un'immagine container di esempio nel cluster. La policy bloccherà il deployment perché non è stata eseguita l'attestazione richiesta.

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

Per provare a eseguire il deployment dell'immagine, esegui questo comando:

kubectl run hello-server --image us-docker.pkg.dev/google-samples/containers/gke/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, che indica che l'immagine non è stata di cui è stato eseguito il deployment:

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_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 continuare con il passaggio successivo:

kubectl delete deployment hello-server

Creare un'attestazione

Un'attestazione è un documento digitale creato da un firmatario che certifica che GKE è autorizzato a eseguire il deployment dell'immagine container associata. Il processo di creazione di un'attestazione è talvolta chiamato "firma di un'immagine".

In questo tutorial, creerai un'attestazione per le immagini di esempio di Artifact Registry.

Per creare un'attestazione:

1. Imposta le variabili che memorizzano il percorso del registro e il digest dell'immagine, nonché il nome del firmatario:

   Artifact Registry

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

2. Genera il payload di attestazione:

   Nota: nel comando seguente, mentre è necessario un ${IMAGE_PATH} per creare il payload della firma per l'attestazione, solo ${IMAGE_DIGEST} viene utilizzato al momento del deployment. Ciò significa che puoi eseguire il deployment di un'immagine container identica da più posizioni con la stessa attestazione.

   Artifact Registry

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

   Il file JSON del payload ha i seguenti contenuti:

   {
   "critical": {
     "identity": {
       "docker-reference": "us-docker.pkg.dev/google-samples/containers/gke/hello-app"
     },
     "image": {
       "docker-manifest-digest": "sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
     },
     "type": "Google cloud binauthz container signature"
   }
   }
   

3. Firma il payload con la tua chiave privata PKIX e genera un file di 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 sopra.

4. 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 chiave pubblica che hai trovato in Genera una coppia di chiavi PKIX sopra.

   Il flag validate verifica che l'attestazione possa essere verificata dall'attestatore configurato nelle norme.

5. Verifica che l'attestazione sia stata creata:

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

Per saperne di più sulla creazione di attestazioni, consulta Creare attestazioni.

Riapprova la policy

Ancora una volta, testa 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à il digest per cercare le attestazioni. In questo caso, Autorizzazione binaria consente il deployment dell'immagine perché è stata eseguita l'attestazione richiesta.

Per eseguire il deployment dell'immagine, esegui questo comando:

kubectl run hello-server --image ${IMAGE_PATH}@${IMAGE_DIGEST} --port 8080

Per verificare che l'immagine sia stata eseguita il deployment, esegui questo comando:

kubectl get pods

Il comando stampa un messaggio simile al seguente, che indica che il deployment è andato a buon fine:

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

Per eliminare il pod, esegui questo comando:

kubectl delete pod hello-server

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 il programma di attestazione built-by-cloud-build per eseguire il deployment solo delle immagini create da Cloud Build.
• Scopri come utilizzare i digest delle immagini nei manifest Kubernetes
• Attiva la modalità dry run per disattivare l'applicazione