Questo tutorial descrive come utilizzare Autorizzazione binaria in più progetti configurazione. Per una configurazione più semplice per un singolo progetto, consulta Inizia a utilizzare Google Cloud CLI (GKE).
Per stabilire la separazione dei compiti, puoi: configurare Autorizzazione binaria in una configurazione con più progetti. Lo scopo di di ciascun progetto verrà discusso più avanti in questo tutorial.
Obiettivi
In questo tutorial imparerai a:Configura un progetto diverso per il deployment (GKE), attestatore e delle attestazioni, per supportare separazione dei compiti.
Configura la regola predefinita del tuo Criterio di Autorizzazione binaria per richiedere le attestazioni.
Crea una coppia di chiavi per firmare e verificare in un secondo momento l'attestazione.
Crea un attestatore utilizzato dall'applicazione di Autorizzazione binaria per verificare l'attestazione.
Firma un'immagine di esempio, creando un'attestazione.
Testa il criterio eseguendo il deployment dell'immagine di esempio.
Devi configurare il controllo dell'accesso appropriato per ciascun progetto tramite Identity and Access Management (IAM).
Per maggiore sicurezza, puoi usare i Controlli di servizio VPC per proteggere risorse create in questo tutorial. Per ulteriori informazioni, vedi Protezione con i Controlli di servizio VPC.
Costi
In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:
- Artifact Registry or Container Registry
- Binary Authorization
- GKE
- Container Registry
- 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.
configura il progetto deployer
Il progetto di deployment gestisce Google Kubernetes Engine. (GKE), in cui esegui il deployment delle immagini e Criterio di Autorizzazione binaria che Autorizzazione binaria viene applicata al momento del deployment. Puoi avere più di un progetto di deployment, a seconda in base a dimensioni, complessità e altri requisiti del tuo ambiente.
Per configurare il progetto del deployer:
Crea il progetto e abilita la fatturazione nella console Google Cloud, se non lo hai fatto già fatto.
Nota su Identity and Access Management: il progetto di deployment contiene le informazioni cluster GKE. La configurazione di Identity and Access Management per dovrebbe riflettere questo concetto.
Imposta le variabili di ambiente per archiviare il progetto Google Cloud e il numero:
DEPLOYER_PROJECT_ID=DEPLOYER_PROJECT_ID
Sostituisci DEPLOYER_PROJECT_ID con il progetto Google Cloud ID.
DEPLOYER_PROJECT_NUMBER=$(gcloud projects describe "${DEPLOYER_PROJECT_ID}" \ --format="value(projectNumber)")
Abilita le API:
Container Registry
gcloud --project=${DEPLOYER_PROJECT_ID} \ services enable\ container.googleapis.com\ containerregistry.googleapis.com\ binaryauthorization.googleapis.com
Artifact Registry
gcloud --project=${DEPLOYER_PROJECT_ID} \ services enable\ container.googleapis.com\ artifactregistry.googleapis.com\ binaryauthorization.googleapis.com
Ottieni il nome dell'account di servizio del progetto deployer:
DEPLOYER_SERVICE_ACCOUNT="service-${DEPLOYER_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
Potrai utilizzare il nome dell'account di servizio in un passaggio successivo, quando configuri autorizzazioni nella nota Artifact Analysis associata all'attestatore.
configura il progetto attestatore
Un progetto attestatore archivia gli attetori che possono per verificare che un'immagine sia pronta per il deployment. Spesso è presente un solo attestatore progetto che funge da archivio centralizzato di informazioni su parti affidabili nel processo di autorizzazione. In questo modo puoi gestire centralmente i token di sicurezza per verificare l'identità degli attestatori e limitare l'accesso i soggetti che li amministrano.
Per configurare il progetto attestatore:
Crea il progetto e abilita la fatturazione nella console Google Cloud, se non lo hai fatto già fatto.
Nota Identity and Access Management: poiché il progetto contiene gli attestatori, solo il personale addetto alla sicurezza deve avere accesso in scrittura.
Imposta le variabili di ambiente per archiviare l'ID e il numero del progetto:
ATTESTOR_PROJECT_ID=ATTESTOR_PROJECT_ID
Sostituisci ATTESTOR_PROJECT_ID con l'ID progetto attestatore.
ATTESTOR_PROJECT_NUMBER=$(gcloud projects describe "${ATTESTOR_PROJECT_ID}" \ --format="value(projectNumber)")
Abilita le API Artifact Analysis e Autorizzazione binaria:
gcloud services --project=${ATTESTOR_PROJECT_ID} \ enable containeranalysis.googleapis.com \ binaryauthorization.googleapis.com
Ottieni il nome dell'account di servizio del progetto attestatore:
ATTESTOR_SERVICE_ACCOUNT="service-${ATTESTOR_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
Potrai utilizzare il nome dell'account di servizio in un passaggio successivo, quando configuri autorizzazioni nella nota Artifact Analysis associata all'attestatore.
Configura il progetto di attestazioni
Un progetto di attestazione è un progetto in cui attestazioni rilasciate dagli attestatori durante la verifica un'immagine. Un progetto di attestazione separato ti consente di organizzare e ispezionare le dichiarazioni sull'idoneità del software.
Crea il progetto e abilita la fatturazione nella console Google Cloud, se non lo hai fatto già fatto.
Nota Identity and Access Management: tutti i ruoli coinvolti in Autorizzazione binaria devono avere accesso in lettura alle note e alle occorrenze di Artifact Analysis in questo progetto, Tuttavia, solo i gestori delle attestazioni devono disporre dell'accesso in scrittura.
Imposta una variabile di ambiente per archiviare il nome del progetto:
ATTESTATION_PROJECT_ID=ATTESTATION_PROJECT_ID
Sostituisci ATTESTATION_PROJECT_ID con l'ID progetto di attestazione.
Abilita le API Artifact Analysis e Autorizzazione binaria:
gcloud services --project=${ATTESTATION_PROJECT_ID} \ enable containeranalysis.googleapis.com \ binaryauthorization.googleapis.com
Crea un cluster
Ora puoi creare un cluster GKE nel progetto Deployer.
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
Comando gcloud container clusters create
.
Per creare il cluster:
gcloud --project=${DEPLOYER_PROJECT_ID} \ 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
.
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 --project=${DEPLOYER_PROJECT_ID} \ container clusters get-credentials \ --zone us-central1-a \ test-cluster
Crea un attestatore
Un attestatore è una parte responsabile attestare il completamento di un processo obbligatorio prima che un'immagine container di cui è stato eseguito il deployment. Può trattarsi di un utente umano o, più spesso, di un processo automatizzato come un sistema di build e di test o l'integrazione continua (CI) e il deployment pipeline di dati (CD). Puoi creare attestatori nel progetto attestatore.
Per creare un attestatore devi:
- Crea una nota in Artifact Analysis da archiviare metadati attendibili utilizzati nel processo di autorizzazione
- Crea l'attestatore nel relativo progetto e associa la nota creato da te
- Aggiungi un'associazione del ruolo IAM per l'account di servizio del progetto deployer alla attestatore
- Impostare le autorizzazioni nella nota Artifact Analysis
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
processo di autorizzazione dell'immagine.
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.
- test-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/${ATTESTOR_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/${ATTESTOR_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/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}"
Crea l'attestatore
Ora puoi creare l'attestatore:
Crea l'attestatore in Autorizzazione binaria:
gcloud --project=${ATTESTOR_PROJECT_ID} \ container binauthz attestors create ${ATTESTOR_NAME} \ --attestation-authority-note=${NOTE_ID} \ --attestation-authority-note-project=${ATTESTOR_PROJECT_ID}
Verifica che l'attestatore sia stato creato:
gcloud --project=${ATTESTOR_PROJECT_ID} \ container binauthz attestors list
L'attestatore creato non può ancora essere utilizzato senza una coppia di chiavi PKIX associata. che crei di seguito.
Aggiungi un'associazione del ruolo IAM per il progetto deployer
Devi aggiungere un'associazione del ruolo IAM per il progetto deployer all'attestatore. Viene utilizzato da Autorizzazione binaria quando valuta un criterio per determinare se il progetto dispone delle autorizzazioni per accedere a qualsiasi attestazione associata.
Per aggiungere l'associazione del ruolo IAM:
gcloud --project ${ATTESTOR_PROJECT_ID} \ container binauthz attestors add-iam-policy-binding \ "projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \ --member="serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}" \ --role=roles/binaryauthorization.attestorsVerifier
Impostare le autorizzazioni nella nota Artifact Analysis
Devi anche impostare le autorizzazioni nella nota Artifact Analysis che hai creato in modo che sia accessibile sia al progetto deployer che al progetto attestatore. Per farlo, aggiorna il criterio IAM per la nota che assegna l'accesso come Visualizzatore agli account di servizio del progetto.
Genera un file JSON contenente le informazioni necessarie per impostare IAM norme sulla tua nota.
cat > /tmp/iam_request.json << EOM { 'resource': 'projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}', 'policy': { 'bindings': [ { 'role': 'roles/containeranalysis.notes.occurrences.viewer', 'members': [ 'serviceAccount:${ATTESTOR_SERVICE_ACCOUNT}', 'serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}' ] } ] } } EOM
Aggiungi l'account di servizio e i ruoli di accesso richiesti al criterio IAM per nota che hai creato:
curl -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ --data-binary @/tmp/iam_request.json \ "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"
Configurazione delle chiavi PKIX
Autorizzazione binaria utilizza le chiavi di crittografia per verificare in modo sicuro l'identità dei attestatori. In questo modo ti assicuri che solo le parti verificate possano partecipare ai autorizzazione di un'immagine container. La coppia di chiavi è composta da una chiave privata, utilizzata dall'attestatore per firmare digitalmente le attestazioni e una chiave pubblica, che aggiungi all'attestatore come archiviato dal servizio Autorizzazione binaria.
In questo tutorial vengono usate le Algoritmo di firma digitale con curva ellittica (ECDSA) per creare la coppia di chiavi. Puoi anche usare chiavi RSA o PGP per firma. Per saperne di più, consulta Scopi e algoritmi principali informazioni sugli algoritmi di firma.
Le chiavi asimmetriche generate e archiviate dalla Cloud Key Management Service (Cloud KMS) è conforme a PKIX. Consulta Creazione di attestatori utilizzando l'interfaccia a riga di comando informazioni sull'uso delle chiavi PKIX e di Cloud KMS.
Genera una coppia di chiavi
Una coppia di chiavi PKIX è composta da una chiave privata, che il firmatario utilizza per firmare digitalmente le attestazioni, e una chiave pubblica, che aggiungi all'attestatore. Al momento del deployment, Autorizzazione binaria utilizza questa chiave pubblica per verificare l'attestazione firmata chiave privata.
Genera la chiave privata:
Per generare una nuova coppia di chiavi PKIX asimmetrica locale e memorizzarla in un file:
PKIX (Cloud KMS)
Questo passaggio mostra come eseguire un'attestazione utilizzando le chiavi generate e archiviati in Cloud Key Management Service.
Configura le variabili di ambiente per archiviare le informazioni sulla coppia di chiavi gestite da Cloud KMS:
Se hai già una coppia di chiavi, puoi impostare questo ambiente variabili e saltare il passaggio successivo.
KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID KMS_KEY_LOCATION=KMS_KEY_LOCATION KMS_KEYRING_NAME=KMS_KEYRING_NAME KMS_KEY_NAME=KMS_KEY_NAME KMS_KEY_VERSION=KMS_KEY_VERSION
Sostituisci quanto segue:
- KMS_KEY_PROJECT_ID: l'ID del progetto in cui le chiavi vengono memorizzate
- KMS_KEY_LOCATION: posizione della chiave
- KMS_KEYRING_NAME: il nome del keyring
- KMS_KEY_NAME: il nome della chiave
- KMS_KEY_VERSION: la versione della chiave
[Facoltativo] Configura una chiave KMS:
Crea una chiave KMS la cui chiave pubblica può essere archiviata in un attestatore. Questo passaggio configura anche le variabili di ambiente che utilizzi di seguito.
Per creare una chiave e impostare le variabili di ambiente:
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
Crea un keyring KMS:
gcloud kms keyrings create ${KMS_KEYRING_NAME} \ --location ${KMS_KEY_LOCATION} \ --project ${KMS_KEY_PROJECT_ID}
Crea la chiave:
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} \ --project ${KMS_KEY_PROJECT_ID}
Per ulteriori informazioni sulla creazione di chiavi KMS, consulta Crea una chiave asimmetrica.
Aggiungi la chiave pubblica all'attestatore:
gcloud --project="${ATTESTOR_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}"
PKIX (chiave locale)
Per generare la chiave privata, esegui questi comandi:
PRIVATE_KEY_FILE="/tmp/ec_private.pem" openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
PRIVATE_KEY_FILE è il nome del file che contiene la chiave privata archiviata nell'attestatore.
Estrai la chiave pubblica dalla chiave privata e archiviala in un file:
PUBLIC_KEY_FILE="/tmp/ec_public.pem" openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
PUBLIC_KEY_FILE è il nome del file che contiene chiave pubblica archiviata nell'attestatore.
Per aggiungere la chiave pubblica esportata nell'attestatore, esegui la seguire il codice.
gcloud --project="${ATTESTOR_PROJECT_ID}" \ container binauthz attestors public-keys add \ --attestor="${ATTESTOR_NAME}" \ --pkix-public-key-file=${PUBLIC_KEY_FILE} \ --pkix-public-key-algorithm=ecdsa-p256-sha256
Autorizzazione binaria utilizza la chiave pubblica nell'attestatore per verificare l'attestazione.
Configura il criterio
Ora puoi configurare il criterio nel progetto deployer. In questo passaggio, esportare il file YAML del criterio nel sistema locale e modificare la regola predefinita in modo da richiedere un'attestazione da parte dell'attestatore definito sopra.
Per configurare il criterio:
Crea un nuovo file di criteri che consenta le immagini di sistema gestite da Google. imposta
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/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME} name: projects/${DEPLOYER_PROJECT_ID}/policy EOM
Importa il file YAML del criterio in Autorizzazione binaria:
gcloud --project=${DEPLOYER_PROJECT_ID} \ container binauthz policy import /tmp/policy.yaml
Per ulteriori informazioni sulla configurazione di un criterio, consulta Configurazione di un criterio utilizzando l'interfaccia a riga di comando.
Testa il criterio
In questo tutorial creerai un'attestazione, ad esempio "Hello World!" pubblica. di Container Registry e Artifact Registry. Inizialmente, il responsabile blocca di eseguire il deployment delle immagini perché l'attestazione richiesta non esiste.
Per provare a eseguire il deployment dell'immagine:
Container Registry
kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080
Artifact Registry
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 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 è una dichiarazione di un attestatore che un il processo richiesto nella pipeline sia stato completato l'immagine in questione sia autorizzata per il deployment. L'attestazione stessa è record con firma digitale contenente il percorso completo di una versione dell'immagine come del registro delle immagini container, nonché l'identità dell'attestatore.
In questo tutorial, la tua attestazione dichiara semplicemente che autorizzi l'immagine per il deployment. Puoi creare l'attestazione nel progetto di attestazione.
Per creare un'attestazione:
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"
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}
Crea 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 una chiave locale:
Genera il payload di attestazione:
gcloud --project=${ATTESTATION_PROJECT_ID} \ container binauthz create-signature-payload \ --artifact-url=${IMAGE_TO_ATTEST} > /tmp/generated_payload.json
Il file JSON del payload include i seguenti contenuti:
Container Registry
{ "critical": { "identity": { "docker-reference": "gcr.io/google-samples/hello-app" }, "image": { "docker-manifest-digest": "sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea 882eb722c3be4" }, "type": "Google cloud binauthz container signature" } }
Artifact Registry
{ "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.
Se usi file PKIX locali, firma il payload con la tua chiave privata PKIX locale e crea una firma file:
openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
Il file di output è una versione firmata del file JSON del payload che hai creato sopra.
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 ATTESTOR_NAME
.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 ${ATTESTOR_PROJECT_ID})
Crea e convalida l'attestazione:
gcloud container binauthz attestations create \ --project="${ATTESTATION_PROJECT_ID}" \ --artifact-url="${IMAGE_TO_ATTEST}" \ --attestor="projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \ --signature-file=/tmp/ec_signature \ --public-key-id="${PUBLIC_KEY_ID}" \ --validate
Il flag
validate
controlla che l'attestazione possa essere verificata dal configurato nel criterio.
Verifica che l'attestazione sia stata creata:
gcloud --project=${ATTESTATION_PROJECT_ID} \ container binauthz attestations list \ --attestor=$ATTESTOR_NAME --attestor-project=$ATTESTOR_PROJECT_ID
Per ulteriori informazioni sulla creazione di attestazioni, consulta Creazione di attestazioni.
Ripeti il test del criterio
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 utilizza il digest per cercare
le attestazioni. Qui, Autorizzazione binaria consente di eseguire il deployment dell'immagine
all'immagine è associata un'attestazione.
Per eseguire il deployment dell'immagine:
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
Dopo aver eseguito correttamente il deployment dell'immagine container e verificato che funziona, puoi eliminare il cluster che hai creato GKE:
gcloud --project=${DEPLOYER_PROJECT_ID} \ container clusters delete \ --zone=us-central1-a \ test-cluster
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
Puoi anche eliminare i progetti Google Cloud che hai creato per questo tutorial.