Questo tutorial mostra come configurare e testare un criterio di Autorizzazione binaria che richiede attestazioni. Questo tipo di criterio protegge la tua catena di fornitura del software basata su container verificando che un'immagine container ha un'attestazione firmata prima di consentire il deployment dell'immagine.
Durante la fase di deployment, Autorizzazione binaria utilizza gli attacchi per Verificare le firme digitali negli attestazioni. La le attestazioni vengono create dai firmati, di solito nell'ambito di un una pipeline di integrazione continua (CI).
In questo tutorial vengono illustrati il cluster GKE, le attestazioni gli attestatori si trovano tutti in un unico progetto. La configurazione per un singolo progetto utile soprattutto per eseguire test o sperimentare con il servizio. Per un altri esempi reali, vedi configurazione multiprogetto.
I passaggi riportati di seguito descrivono le attività eseguite dalla riga di comando. Da seguire utilizzando la console Google Cloud, vedi Inizia a utilizzare la console Google Cloud.
Obiettivi
In questo tutorial imparerai a:
- Creare un cluster Google Kubernetes Engine Cluster (GKE) con Autorizzazione binaria abilitata
- Crea un attestatore utilizzato dall'applicazione forzata dell'Autorizzazione binaria per la verifica la firma su 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
- Crea un'attestazione utilizzando la firma
- Testa il criterio eseguendo il deployment di un'immagine container in GKE
Costi
In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:
- Artifact Registry or Container Registry
- Binary Authorization
- GKE
- Optional: Cloud Key Management Service
Per generare una stima dei costi basata sull'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.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
- Installa Google Cloud CLI.
-
Per initialize gcloud CLI, esegui questo comando:
gcloud init
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
- Installa Google Cloud CLI.
-
Per initialize gcloud CLI, esegui questo comando:
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
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
Crea un cluster GKE con Autorizzazione binaria
in un bucket con il controllo
delle versioni attivo. Questo è il cluster in cui vuoi che venga eseguito il deployment delle immagini container
vengono eseguiti tutti i test delle unità. Quando crei il cluster, passi il flag --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE
alla
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
nel
Zona GKE us-central1-a
.
Configura kubectl
Devi anche aggiornare il file kubeconfig
locale per il tuo kubectl
dell'installazione. In questo modo avrai a disposizione le credenziali e le informazioni sugli endpoint
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 il deployment delle immagini container. Puoi avere un solo criterio per progetto. Per impostazione predefinita, il criterio è configurato in modo da consentire la visualizzazione di tutte le immagini container di cui è stato eseguito il deployment.
Autorizzazione binaria consente di esportare e importare un file di criteri in
YAML. Questo formato riflette la struttura di un criterio così come viene archiviato
il servizio. Se configuri un criterio utilizzando i comandi gcloud
, puoi modificarlo
.
Per visualizzare il criterio predefinito, esporta il file YAML del criterio:
gcloud container binauthz policy export
Per impostazione predefinita, il file ha i seguenti contenuti:
defaultAdmissionRule: enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG evaluationMode: ALWAYS_ALLOW globalPolicyEvaluationMode: ENABLE name: projects/PROJECT_ID/policy
La regola predefinita è definita in defaultAdmissionRule
nodo. evaluationMode
specifica che
il criterio consente tutti i tentativi di deployment dell'immagine. In questo tutorial, aggiorni
per richiedere le attestazioni.
globalPolicyEvaluationMode
esclude le immagini di sistema gestite da Google dall'applicazione di Autorizzazione binaria.
Per aggiungere un'immagine esente alla lista consentita, aggiungi l'elemento al file dei criteri:
admissionWhitelistPatterns: - namePattern: EXEMPT_IMAGE_PATH
Sostituisci EXEMPT_IMAGE_PATH
con il percorso dell'immagine da escludere. Per escludere altre immagini, aggiungi altre voci - namePattern
. Scopri di più su admissionWhitelistPatterns
.
Per ulteriori informazioni sulla struttura di un criterio, consulta Riferimento YAML per i criteri.
Crea un attestatore
Un attestatore è l'autorità di verifica che L'applicazione forzata 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 è gestito dal personale responsabili della fornitura del software nella tua organizzazione. della catena di sicurezza.
Per creare un attestatore devi:
- Crea una nota in Artifact Analysis da archiviare metadati attendibili utilizzati nel processo di autorizzazione
- Crea l'attestatore stesso in Autorizzazione binaria e associa la nota che creato
Per questo tutorial, hai un attestatore denominato test-attestor
e un container
Nota di analisi denominata test-attestor-note
. In uno scenario reale, è possibile avere
un qualsiasi numero di attestatori, ognuno dei quali rappresenta un partito che partecipa al
per un'immagine container.
Crea la nota Artifact Analysis
Imposta le variabili in cui memorizzare il nome dell'attestatore e Artifact Analysis Nota:
ATTESTOR_NAME=test-attestor NOTE_ID=test-attestor-note
Sostituisci:
- test-attestor: nome dell'attestatore scelto da te.
- attestor-note: nome della nota attestatore scelto da te.
Crea un file JSON in
/tmp/note_payload.json
che descriva il container Nota sull'analisi: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 al REST di Artifact Analysis API:
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 creato non può ancora essere utilizzato senza una coppia di chiavi PKIX associata. che crei di seguito.
Genera una coppia di chiavi
Autorizzazione binaria utilizza chiavi crittografiche per verificare in modo sicuro l'identità dei sottoscrittori. Ciò garantisce consente di eseguire il deployment solo delle immagini container autorizzate. La chiave è composta da una chiave privata e una chiave pubblica. La signer utilizza la chiave privata per firmare l'immagine container digest, producendo una firma che viene poi archiviata in attestazione. La chiave pubblica viene archiviata attestatore. Al momento del deployment, l'autorizzazione binaria il responsabile dell'applicazione delle norme utilizza la chiave pubblica dell'attestatore per verificare la firma nel prima di consentire il deployment del container.
In questo tutorial utilizzi Infrastruttura a chiave pubblica (X.509) (PKIX) per le chiavi di crittografia. Questo tutorial utilizza lo strumento Algoritmo di firma digitale con curva ellittica (ECDSA) per generare una coppia di chiavi PKIX. Puoi anche usare chiavi RSA o PGP per firma.
Scopi e algoritmi chiave per ulteriori informazioni su di firma digitale.
Le chiavi generate e archiviate Cloud Key Management Service (Cloud KMS) è conforme a PKIX. Per ulteriori informazioni, consulta Creazione di attestatori utilizzando gcloud CLI informazioni sull'uso delle chiavi PKIX e di Cloud KMS.
PKIX (Cloud KMS)
Per creare la coppia di chiavi in Cloud KMS, segui questi passaggi:
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 questo comando:
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 questo comando:
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 l'ID della chiave pubblica in qualsiasi momento utilizzando il comando:
gcloud container binauthz attestors describe <var>ATTESTOR_NAME</var>
.Per salvare l'ID della chiave pubblica in una variabile di ambiente, inserisci questo :
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 esportata nell'attestatore in modo che possa essere utilizzata 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 della chiave pubblica, puoi copiarlo dall'output della
public-keys add
sopra. Per visualizzare l'ID della chiave pubblica dell'attestatore dopo l'aggiunta all'attestatore, usagcloud 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 esporterai il file YAML del criterio file al sistema locale e modificare la regola predefinita in modo che richieda una dell'attestatore che hai definito sopra.
Per configurare il criterio:
Crea un nuovo file dei criteri che consenta il sistema gestito da Google immagini, imposta Da
evaluationMode
aREQUIRE_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 ulteriori informazioni sulla configurazione di un criterio, consulta Configura un criterio utilizzando gcloud CLI.
Testa il criterio
Puoi testare il criterio configurato in precedenza provando a eseguire il deployment di un esempio l'immagine container al cluster. Il criterio bloccherà il deployment perché l'attestazione richiesta non è stata effettuata.
Per questo tutorial, puoi usare immagini di esempio di Container Registry
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 messaggio "Hello,
Mondo!" campione.
un'applicazione.
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 visualizza il seguente messaggio, che indica che l'immagine non è 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}}'
Verrà 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'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 a volte è chiamata "firma di un'immagine". Il firmatario può essere una persona o, più spesso, è un processo automatizzato che viene eseguito quando viene creata un'immagine container. La firma è creata utilizzando la chiave privata di una coppia di chiavi. Al momento del deployment nel tempo, l'applicazione forzata di Autorizzazione binaria utilizza il campo pubblico dell'attestatore chiave per verificare la firma nell'attestazione.
In questo tutorial, la tua attestazione dichiara semplicemente che autorizzi l'immagine per il deployment.
Per creare un'attestazione, segui questi passaggi:
Imposta le variabili in cui è archiviato il percorso del Registro di sistema e il digest 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:
Cloud KMS PKIX
Per creare l'attestazione utilizzando la chiave Cloud KMS, esegui il comando seguente 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 include 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 tua chiave privata PKIX e generare un esegui questo comando:
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 che hai 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 che hai trovato in Genera una coppia di chiavi PKIX sopra.Il flag
validate
controlla che l'attestazione possa essere verificata dal 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, 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. Qui, Autorizzazione binaria consente di eseguire il deployment dell'immagine
è 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 sia stato eseguito il deployment dell'immagine:
kubectl get pods
Il comando visualizza un messaggio simile al seguente, che indica che 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). - Attiva la modalità dry run per disabilitare l'applicazione
- Utilizzare il deployment di emergenza per bypassare l'applicazione forzata