Questa pagina spiega come creare un attestatore in Autorizzazione binaria utilizzando Google Cloud CLI. In alternativa, puoi eseguire questi passaggi utilizzando la Google Cloud console o l'API REST. Questa attività fa parte della configurazione di Autorizzazione binaria.
Utenti di Cloud Build: in alternativa, potete utilizzare l'attestatore built-by-cloud-build
per eseguire il deployment solo delle immagini create da Cloud Build.
Un attestatore è una Google Cloud risorsa che Autorizzazione binaria utilizza per verificare un'attestazione. Per saperne di più sulle attestazioni, consulta la panoramica di Autorizzazione binaria.
Per creare un attestatore:
- Crea una nota in Artifact Analysis per archiviare i metadati attendibili utilizzati nella procedura di attestazione.
- Configura una coppia di chiavi PKIX (Public-Key Infrastructure (X.509)) che può essere utilizzata per verificare l'identità dell'attestatore. (Le coppie di chiavi asimmetriche generate da Cloud Key Management Service (Cloud KMS) sono in formato compatibile con PKIX.)
- Crea l'attestatore stesso in Autorizzazione binaria e associa la nota e la chiave pubblica che hai creato.
In una configurazione a progetto singolo, crei l'attestatore nello stesso Google Cloud progetto in cui configuri il criterio di Autorizzazione binaria policy. Per un tutorial end-to-end a progetto singolo che include questi passaggi, consulta la pagina Guida introduttiva all'utilizzo di Google Cloud CLI o Guida introduttiva all'utilizzo della Google Cloud console.
In una configurazione multi-progetto, ti consigliamo di avere progetti separati: un progetto di deployment, in cui è configurato il criterio; un progetto attestatore, in cui sono archiviati gli attestatori; e un progetto di attestazione per le attestazioni. Per un tutorial end-to-end multi-progetto che include questi passaggi, consulta la pagina Configurazione multi-progetto.
Prima di iniziare
Prima di creare gli attestatori:
Configurare l'ambiente del progetto
In questa sezione, configuri le variabili di ambiente.
Configura le variabili di ambiente per archiviare i nomi e i numeri dei progetti. Se i progetti attestatore e di deployment sono lo stesso progetto, utilizza lo stesso ID progetto per entrambe le variabili.
DEPLOYER_PROJECT_ID=DEPLOYER_PROJECT_ID=
DEPLOYER_PROJECT_NUMBER="$(
gcloud projects describe "${DEPLOYER_PROJECT_ID}" \
--format="value(projectNumber)"
)"
ATTESTOR_PROJECT_ID=ATTESTOR_PROJECT_ID
ATTESTOR_PROJECT_NUMBER="$(
gcloud projects describe "${ATTESTOR_PROJECT_ID}" \
--format="value(projectNumber)"
)"
Devi anche recuperare i nomi dei account di servizio per i progetti:
DEPLOYER_SERVICE_ACCOUNT="service-${DEPLOYER_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
ATTESTOR_SERVICE_ACCOUNT="service-${ATTESTOR_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
Creare una nota di Artifact Analysis
Autorizzazione binaria utilizza Artifact Analysis per archiviare i metadati attendibili utilizzati nella procedura di autorizzazione. Per ogni attestatore che crei, devi creare una nota di Artifact Analysis note. Ogni attestazione viene archiviata come occorrenza di questa nota.
Per creare la nota:
Configura le variabili di ambiente per archiviare l'ID della nota e una descrizione leggibile:
NOTE_ID=NOTE_ID NOTE_URI="projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}" DESCRIPTION=DESCRIPTIONSostituisci quanto segue:
NOTE_ID: il nome interno della nota in caratteri alfanumerici senza spazi, ad esempiotest-attestor-noteNOTE_URI: il percorso completo della risorsa notaDESCRIPTION: un nome visualizzato leggibile per la nota, ad esempioTest Attestor Note
Crea un file JSON che descriva la nota:
cat > /tmp/note_payload.json << EOF { "name": "${NOTE_URI}", "attestation": { "hint": { "human_readable_name": "${DESCRIPTION}" } } } EOFCrea 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)" \ -H "x-goog-user-project: ${ATTESTOR_PROJECT_ID}" \ --data-binary @/tmp/note_payload.json \ "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/?noteId=${NOTE_ID}"Per verificare che la nota sia stata creata correttamente, esegui questo comando:
curl \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "x-goog-user-project: ${ATTESTOR_PROJECT_ID}" \ "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/"
Impostare le autorizzazioni IAM per la nota
Devi concedere un ruolo Identity and Access Management (IAM) al account di servizio del progetto attestatore sulla risorsa nota di Artifact Analysis. Per farlo, aggiungi il account di servizio del progetto attestatore al ruolo containeranalysis.notes.occurrences.viewer nel criterio IAM della nota.
Per aggiungere il ruolo:
Genera un file JSON che contenga le informazioni necessarie per impostare il ruolo IAM sulla nota:
cat > /tmp/iam_request.json << EOM { "resource": "${NOTE_URI}", "policy": { "bindings": [ { "role": "roles/containeranalysis.notes.occurrences.viewer", "members": [ "serviceAccount:${ATTESTOR_SERVICE_ACCOUNT}" ] } ] } } EOMAggiungi il account di servizio e i ruoli di accesso richiesti al criterio IAM per la nota che hai creato:
curl -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "x-goog-user-project: ${ATTESTOR_PROJECT_ID}" \ --data-binary @/tmp/iam_request.json \ "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"
Utilizzo multi-progetto
Se archivi l'attestatore in un progetto ed esegui il deployment in un progetto separato,
devi concedere il ruolo roles/binaryauthorization.attestorsVerifier al
account di servizio associato al progetto di deployment sull'attestatore.
Configurare le chiavi di crittografia
Autorizzazione binaria ti consente di utilizzare le chiavi PKIX per verificare le attestazioni.
Generare una coppia di chiavi
In questa guida, utilizzi l'algoritmo di firma digitale con curva ellittica (ECDSA) consigliato per generare una coppia di chiavi PKIX. Puoi anche utilizzare coppie di chiavi RSA o PGP. Per ulteriori informazioni sugli algoritmi di firma, consulta la sezione Finalità e algoritmi delle chiavi.
Una coppia di chiavi PKIX è composta da una chiave privata che i firmatari utilizzano per firmare le attestazioni e da una chiave pubblica che aggiungi all'attestatore. Al momento del deployment, Autorizzazione binaria utilizza questa chiave pubblica per verificare l'attestazione.
PKIX (Cloud KMS)
Per creare la coppia di chiavi in Cloud KMS:
Per configurare le variabili di ambiente necessarie per creare la coppia di chiavi, esegui questi comandi:
KMS_KEY_PROJECT_ID=
KMS_KEY_PROJECT_IDKMS_KEY_LOCATION=KMS_KEY_LOCATIONKMS_KEYRING_NAME=KMS_KEYRING_NAMEKMS_KEY_NAME=KMS_KEY_NAMEKMS_KEY_VERSION=KMS_KEY_VERSIONKMS_KEY_PURPOSE=asymmetric-signing KMS_KEY_ALGORITHM=KMS_KEY_ALGORITHMKMS_PROTECTION_LEVEL=KMS_PROTECTION_LEVELSostituisci quanto segue:
KMS_KEY_PROJECT_ID: l'ID del progetto in cui sono archiviate le chiaviKMS_KEY_LOCATION: la località della chiaveKMS_KEYRING_NAME: il nome del keyringKMS_KEY_NAME: il nome della chiaveKMS_KEY_VERSION: la versione della chiaveKMS_KEY_ALGORITHM: l'algoritmo; è consigliatoec-sign-p256-sha256KMS_PROTECTION_LEVEL: il livello di protezione, ad esempiosoftware
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}Sostituisci quanto segue:
KMS_KEY_NAME: il nome della chiaveKMS_KEY_LOCATION: la località della chiaveKMS_KEYRING_NAME: il nome del keyringKMS_KEY_PURPOSE: lo scopo della chiave, impostato suASYMMETRIC_SIGNKMS_KEY_ALGORITHM: l'algoritmo, è consigliatoec-sign-p256-sha256KMS_PROTECTION_LEVEL: il livello di protezione, ad esempiosoftware
PKIX (chiave locale)
Per generare una nuova coppia di chiavi PKIX asimmetriche locali e archiviarla in un file:
Genera la chiave privata:
PRIVATE_KEY_FILE è il nome del file contenente la chiave privata utilizzata per firmare il payload dell'attestazione.
PRIVATE_KEY_FILE="/tmp/ec_private.pem" openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}Estrai la chiave pubblica dalla chiave privata e archiviala in un file:
PUBLIC_KEY_FILE è il nome del file contenente la chiave pubblica archiviata nell'attestatore.
PUBLIC_KEY_FILE="/tmp/ec_public.pem" openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
Creare l'attestatore
Per creare l'attestatore:
Configura una variabile di ambiente per archiviare il nome dell'attestatore come definito in Autorizzazione binaria:
ATTESTOR_NAME=ATTESTOR_NAME
dove ATTESTOR_NAME è il nome dell'attestatore che vuoi creare (ad esempio,
build-secureoprod-qa).Crea la risorsa 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}"Aggiungi un'associazione di ruoli IAM per il progetto di deployment all'attestatore. Questo viene utilizzato da Autorizzazione binaria quando valuta un criterio per determinare se il progetto dispone delle autorizzazioni per accedere a eventuali attestazioni associate.
gcloud container binauthz attestors add-iam-policy-binding \ "projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \ --member="serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}" \ --role=roles/binaryauthorization.attestorsVerifierPer aggiungere la chiave pubblica all'attestatore:
PKIX (Cloud KMS)
Per aggiungere la chiave pubblica da una coppia di chiavi Cloud KMS all'attestatore, esegui questo comando:
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 aggiungere una chiave pubblica PKIX archiviata localmente a un attestatore, esegui questo comando:
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-sha256Se aggiungi una chiave pubblica a un attestatore e non specifichi un ID chiave (che può essere qualsiasi stringa), gli viene assegnato automaticamente un ID nel formato RFC 6920:
ni:///sha-256;..., dove...è un hash codificato di chiave pubblica. Questo valore viene restituito nel campoiddell'output del comando. L'ID restituito può essere salvato inPUBLIC_KEY_IDe utilizzato per creare un'attestazione.
Salvare l'ID della chiave pubblica
Per creare un'attestazione, devi avere l'ID della chiave pubblica.
Per salvare l'ID della chiave pubblica, puoi copiarlo dall'output del comando binauthz attestors public-keys add riportato sopra.
In alternativa, puoi visualizzare l'ID della chiave pubblica dell'attestatore in qualsiasi momento utilizzando questo comando:
gcloud container binauthz attestors describe ${ATTESTOR}.
Per salvare l'ID della 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)')
Verificare che l'attestatore sia stato creato
Per verificare che l'attestatore sia stato creato, esegui questo comando:
gcloud container binauthz attestors list \
--project="${ATTESTOR_PROJECT_ID}"
Passaggi successivi
- Scopri come creare attestazioni per l'attestatore.
- Aggiorna il criterio di Autorizzazione binaria per richiedere le attestazioni utilizzando la Google Cloud console, il Google Cloud CLI e l'API REST.