Questo tutorial mostra come configurare e testare un criterio di Autorizzazione binaria che richiede attestazioni. Questo tipo di criterio protegge la catena di fornitura del software basato su container definendo chi può eseguire il deployment delle immagini container su Google Kubernetes Engine (GKE) e quali immagini container GKE è autorizzato a 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 Google Cloud console, nonché
alcune attività che esegui utilizzando i comandi gcloud. Per eseguire questi passaggi
utilizzando gcloud, consulta la pagina Inizia a utilizzare Google Cloud CLI.
Obiettivi
In questo tutorial imparerai a:
- Creare un cluster (GKE) con Autorizzazione binaria abilitata
- Creare un attestatore che l'applicazione di Autorizzazione binaria utilizza per verificare la firma su un'attestazione
- Configurare un criterio che richiede un'attestazione
- Creare una coppia di chiavi di crittografia per firmare le attestazioni e verificarle in un secondo momento
- Firmare il digest di un'immagine container, creando una firma
- Creare un'attestazione utilizzando la firma
- Testare il criterio eseguendo il deployment di un'immagine container in GKE
Costi
In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi in base all'utilizzo previsto,
utilizza il calcolatore prezzi.
Prima di iniziare
- Accedi al tuo Google Cloud account. 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 workload.
-
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 theresourcemanager.projects.createpermission. Learn how to grant roles.
-
Verify that billing is enabled for your Google Cloud project.
Enable the Container Registry, Artifact Analysis and Binary Authorization APIs.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (
roles/serviceusage.serviceUsageAdmin), which contains theserviceusage.services.enablepermission. Learn how to grant roles.-
Installa Google Cloud CLI.
-
Se utilizzi un provider di identità (IdP) esterno, devi prima accedere a gcloud CLI con la tua identità federata.
-
Per inizializzare gcloud CLI, esegui questo comando:
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 theresourcemanager.projects.createpermission. Learn how to grant roles.
-
Verify that billing is enabled for your Google Cloud project.
Enable the Container Registry, Artifact Analysis and Binary Authorization APIs.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (
roles/serviceusage.serviceUsageAdmin), which contains theserviceusage.services.enablepermission. Learn how to grant roles.-
Installa Google Cloud CLI.
-
Se utilizzi un provider di identità (IdP) esterno, devi prima accedere a gcloud CLI con la tua identità federata.
-
Per inizializzare gcloud CLI, esegui questo comando:
gcloud init - Installa
kubectl.
Imposta il progetto predefinito
Per facilitare i comandi successivi, archivia l'ID progetto in una variabile di ambiente come segue: Google Cloud
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:
Visita il menu GKE nella Google Cloud console.
Fai clic su Crea cluster.
Inserisci
test-clusternel campo Nome.Seleziona A livello di zona nelle opzioni Tipo di località.
Seleziona
us-central1-adall'elenco a discesa Zona.Fai clic su Disponibilità, networking, sicurezza e funzionalità aggiuntive.
Nella sezione Sicurezza, seleziona Attiva Autorizzazione binaria.
Seleziona Solo applicazione.
Fai clic su Crea.
Configura kubectl
Devi anche aggiornare il file kubeconfig locale per l'installazione di 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 per consentire il deployment di tutte le immagini container.
Per visualizzare il criterio predefinito:
Vai alla pagina Autorizzazione binaria nella Google Cloud console.
Fai clic su Modifica criterio.
In Regola predefinita del progetto, viene visualizzata l'opzione Consenti tutte le immagini.
Fai clic su Salva criterio.
Crea un attestatore
Un attestatore è l'autorità di verifica che l' 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 e in genere viene gestito dalle persone responsabili della sicurezza della catena di fornitura del software.
Per creare un attestatore:
- Crea l'attestatore stesso in Autorizzazione binaria
- Genera automaticamente una nota dell'attestatore associata in Artifact Analysis per archiviare i metadati di attestazione attendibili utilizzati nel processo di autorizzazione
Per questo tutorial, hai un attestatore denominato 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
Autorizzazione binaria utilizza chiavi crittografiche per verificare in modo sicuro l'identità dei firmatari. In questo modo, è possibile eseguire il deployment solo delle immagini container autorizzate. La coppia di chiavi è composta 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 è memorizzata nell'attestatore. Al momento del deployment, l'applicazione 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 PKIX (Public-Key Infrastructure X.509) per le chiavi crittografiche. Questo tutorial utilizza l'algoritmo di firma digitale con curva ellittica (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 Finalità e algoritmi delle chiavi.
Le chiavi generate e archiviate da Cloud Key Management Service (Cloud KMS) sono conformi a PKIX. Per ulteriori informazioni sull'utilizzo delle chiavi PKIX e di Cloud KMS, consulta Creare attestatori utilizzando la CLI.
Per generare una coppia di chiavi PKIX:
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}
Crea l'attestatore
Ora puoi creare l'attestatore stesso in Autorizzazione binaria e associare la chiave pubblica che hai creato.
Per creare l'attestatore:
Torna alla pagina Autorizzazione binaria nella Google Cloud console.
Nella scheda Attestatori, fai clic su Crea.
Compila i campi come segue:
Inserisci
test-attestornel campo Nome attestatore.Verifica che l'opzione Crea automaticamente una nota di Artifact Analysis sia selezionata.
Fai clic su Aggiungi una chiave pubblica PKIX.
Apri
/tmp/ec_public.pemin 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.Fai clic su
Elliptic Curve P-256 - SHA256 Digestnel menu a discesa Algoritmo di firma.Fai clic su Fine.
Fai clic su Crea per creare l'attestatore.
Memorizza l'ID della 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 il criterio
Ora puoi configurare il criterio:
Torna alla pagina Autorizzazione binaria nella Google Cloud console.
Nella scheda Criterio, fai clic su Modifica criterio.
Seleziona Consenti solo le immagini approvate dai seguenti attestatori.
Fai clic su Aggiungi attestatori.
Fai clic su Aggiungi in base a nome progetto e attestatore.
Inserisci PROJECT_ID nel campo Nome progetto.
Inserisci
test-attestornel campo Nome attestatore.Fai clic su Aggiungi 1 attestatore.
Fai clic su Salva criterio.
Per ulteriori informazioni, consulta Configurare un criterio utilizzando la console.
Testa il criterio
Puoi testare il criterio configurato sopra provando a eseguire il deployment di un'immagine container di esempio nel cluster. Il criterio bloccherà il deployment perché non è stata eseguita l'attestazione richiesta.
Per questo tutorial, puoi utilizzare le immagini di esempio di 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 sottoposta a 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
Crea 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, crei un'attestazione per le immagini di esempio di Artifact Registry.
Per creare un'attestazione:
Imposta le variabili che memorizzano il percorso del registro e il digest dell'immagine, nonché il nome dell'attestatore:
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}Genera il payload dell'attestazione:
Artifact Registry
gcloud container binauthz create-signature-payload \ --artifact-url=${IMAGE_PATH}@${IMAGE_DIGEST} > /tmp/generated_payload.jsonIl 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" } }Firma il payload con la chiave privata PKIX e genera un file di firma:
openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signatureIl file di firma è una versione firmata digitalmente del file JSON del payload creato sopra.
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}" \ --validatedove
PUBLIC_KEY_IDè l'ID della chiave pubblica che hai trovato in Genera una coppia di chiavi PKIX sopra.Il flag
validateverifica 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 ulteriori informazioni sulla creazione di attestazioni, consulta Creare attestazioni.
Riapprova il criterio
Ripeti il test del 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 sottoposta a 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
Libera spazio
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-buildper eseguire il deployment solo delle immagini create da Cloud Build. - Scopri come utilizzare i digest delle immagini nei manifest di Kubernetes
- Attiva la modalità dry run per disattivare l'applicazione