Questo tutorial mostra come configurare e testare un criterio di Autorizzazione binaria che richiede attestation. 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 signers, in quanto parte di una pipeline di integrazione continua (CI).
In questo tutorial, il cluster GKE, gli attestatori e gli attestatori si trovano tutti in un unico progetto. La configurazione di un singolo progetto è utile soprattutto per testare o sperimentare il servizio. Per un esempio più 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 Iniziare a utilizzare la 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
- Firmare 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
In questo documento vengono utilizzati 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.
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 console di Google Cloud Console, nella pagina del selettore dei progetti, seleziona o crea un progetto Google Cloud.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
- Installa Google Cloud CLI.
-
Per inizializzare l'interfaccia a riga di comando gcloud, esegui il comando seguente:
gcloud init
-
Nella console di Google Cloud Console, nella pagina del selettore dei progetti, seleziona o crea un progetto Google Cloud.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
- 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 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 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 riflette la struttura di un criterio quando è archiviato dal servizio. Quando configuri un criterio utilizzando i comandi gcloud
, devi 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
L'elenco predefinito contiene il registro open source di proprietà della community k8s.gcr.io
, che viene sostituito da registry.k8s.io
e mantenuto nell'elenco per garantire la compatibilità con le versioni precedenti. Il Registro di sostituzione registry.k8s.io
non è incluso nell'elenco predefinito.
Quando esegui la migrazione da k8s.gcr.io
, passa al registro di cui hai il controllo o aggiungi il registro di sostituzione registry.k8s.io
a questo elenco.
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 scoprire di più 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 è generalmente gestito dal personale della tua organizzazione responsabile della sicurezza della catena di fornitura del software.
Per creare un attestatore devi:
- Crea una nota in Artifact 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 di analisi del container denominata test-attestor-note
. In uno scenario reale, puoi avere
numerosi attestatori, ciascuno dei quali rappresenta una parte che partecipa al
processo di autorizzazione di un'immagine container.
Crea la nota Artifact Analysis
Imposta le variabili che memorizzano il nome dell'attestatore e della nota di Artifact Analysis:
ATTESTOR_NAME=test-attestor NOTE_ID=test-attestor-note
Sostituisci:
- test-attestor: nome dell'attestatore che preferisci.
- attestor-note: nome della nota dell'attestatore che preferisci.
Crea un file JSON in
/tmp/note_payload.json
che descriva la nota di analisi del container: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 Artifact 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 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 creato non è ancora utilizzabile senza una coppia di chiavi PKIX associata, creata di seguito.
Genera una coppia di chiavi
Autorizzazione binaria utilizza le chiavi di crittografia per verificare in modo sicuro l'identità dei firmatori. In questo modo puoi garantire il deployment delle sole immagini container autorizzate. La coppia di chiavi è composta da una chiave privata e una chiave pubblica. signer utilizza la chiave privata per firmare il digest dell'immagine container, producendo una firma che viene quindi archiviata in un'attestato. La chiave pubblica è archiviata nell'attestatore. Al momento del deployment, l'applicazione 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 infrastruttura a chiave pubblica (X.509) (PKIX) per le chiavi di crittografia. Questo tutorial utilizza l'algoritmo di firma digitale (ELDSA) Curve Elliptic Curve per generare una coppia di chiavi PKIX. Puoi utilizzare anche le chiavi RSA o PGP per la firma.
Scopo e algoritmi chiave per scoprire di più sulla firma degli algoritmi.
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 Cloud KMS, consulta la pagina Creazione di attestatori mediante l'interfaccia a riga di comando gcloud.
PKIX (Cloud KMS)
Per creare la coppia di chiavi in Cloud KMS, procedi nel seguente modo:
Configura le variabili di ambiente necessarie per creare la coppia di chiavi.
KMS_KEY_PROJECT_ID=${PROJECT_ID} KMS_KEYRING_NAME=my-binauthz-keyring KMS_KEY_NAME=my-binauthz-kms-key-name KMS_KEY_LOCATION=global KMS_KEY_PURPOSE=asymmetric-signing KMS_KEY_ALGORITHM=ec-sign-p256-sha256 KMS_PROTECTION_LEVEL=software KMS_KEY_VERSION=1
Per creare il keyring, esegui il comando seguente:
gcloud kms keyrings create ${KMS_KEYRING_NAME} \ --location ${KMS_KEY_LOCATION}
Per creare la chiave, esegui questo comando:
gcloud kms keys create ${KMS_KEY_NAME} \ --location ${KMS_KEY_LOCATION} \ --keyring ${KMS_KEYRING_NAME} \ --purpose ${KMS_KEY_PURPOSE} \ --default-algorithm ${KMS_KEY_ALGORITHM} \ --protection-level ${KMS_PROTECTION_LEVEL}
Per aggiungere la chiave pubblica all'attestatore, esegui il comando seguente:
gcloud --project="${PROJECT_ID}" \ container binauthz attestors public-keys add \ --attestor="${ATTESTOR_NAME}" \ --keyversion-project="${KMS_KEY_PROJECT_ID}" \ --keyversion-location="${KMS_KEY_LOCATION}" \ --keyversion-keyring="${KMS_KEYRING_NAME}" \ --keyversion-key="${KMS_KEY_NAME}" \ --keyversion="${KMS_KEY_VERSION}"
Recupera l'ID della chiave pubblica dall'attestatore:
Puoi visualizzare il tuo ID chiave pubblica in qualsiasi momento usando il comando:
gcloud container binauthz attestors describe <var>ATTESTOR_NAME</var>
.Per salvare l'ID chiave pubblica in una variabile di ambiente, inserisci questo comando:
PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \ --format='value(userOwnedGrafeasNote.publicKeys[0].id)' --project ${PROJECT_ID})
PKIX (chiave locale)
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 all'attestatore.
Ora aggiungi la chiave pubblica che hai esportato nell'attestatore in modo che possa essere utilizzata da 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
Salva l'ID della chiave pubblica.
Per salvare l'ID 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, utilizzagcloud container binauthz attestors describe ${ATTESTOR_NAME}
:PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \ --format='value(userOwnedGrafeasNote.publicKeys[0].id)')
Configurare 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'attestatore 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
suREQUIRE_ATTESTATION
e aggiunge un nodo denominatorequireAttestationsBy
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 saperne di più sulla configurazione di un criterio, consulta la pagina Configurare un criterio utilizzando l'interfaccia a riga di comando gcloud.
Testa il criterio
Puoi testare il criterio che hai configurato sopra provando a 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 da Container Registry e Artifact Registry. L'immagine di Container Registry si trova sul percorso gcr.io/google-samples/hello-app:1.0
. L'immagine di Artifact Registry si trova lungo il 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, che indica 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 in modo da poter andare al passaggio successivo:
kubectl delete deployment hello-server
Crea un'attestazione
Una 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 a volte viene chiamato "firma di un'immagine". Un firmatario può essere una persona o, più spesso, un processo automatizzato che viene eseguito quando si crea un'immagine container. La firma viene creata utilizzando la chiave privata da una coppia di chiavi. Al momento del deployment, l'applicazione di Autorizzazione binaria utilizza la chiave pubblica dell'attestatore per verificare la firma nell'attestazione.
In questo tutorial, la tua attestazione ti autorizza semplicemente a eseguire il deployment dell'immagine.
Per creare un'attestazione, segui questi passaggi:
Imposta le variabili per archiviare il percorso del Registro di sistema e una 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}
Per creare l'attestazione:
PKIX di Cloud KMS
Per creare l'attestazione utilizzando la chiave Cloud KMS, esegui questo comando:
gcloud beta container binauthz attestations sign-and-create \ --project="${PROJECT_ID}" \ --artifact-url="${IMAGE_TO_ATTEST}" \ --attestor="${ATTESTOR_NAME}" \ --attestor-project="${PROJECT_ID}" \ --keyversion-project="${KMS_KEY_PROJECT_ID}" \ --keyversion-location="${KMS_KEY_LOCATION}" \ --keyversion-keyring="${KMS_KEYRING_NAME}" \ --keyversion-key="${KMS_KEY_NAME}" \ --keyversion="${KMS_KEY_VERSION}"
PKIX (chiave locale)
Per creare l'attestazione utilizzando la chiave locale:
Genera il payload di attestazione:
gcloud container binauthz create-signature-payload \ --artifact-url=${IMAGE_TO_ATTEST} > /tmp/generated_payload.json
Il file JSON del payload presenta 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" } }
Per firmare il payload con la chiave privata PKIX e generare un file per la firma, esegui il comando seguente:
openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
Il file della firma è la versione firmata del file JSON del payload creato in precedenza in questa guida.
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
Sostituisci
PUBLIC_KEY_ID
con l'ID della chiave pubblica trovato in Generare una coppia di chiavi PKIX riportata 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 ulteriori informazioni sulla creazione di attestazioni, consulta Creazione di attestazioni.
Ripeti il test del criterio
Anche in questo caso, verifica 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
, in quanto Autorizzazione binaria utilizzerà sia il percorso dell'immagine che il
digest per cercare attestazioni. Qui 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 di immagini create da Cloud Build (Anteprima). - Abilita la modalità di prova per disabilitare l'applicazione forzata
- Utilizzare il deployment di emergenza per bypassare l'applicazione