Questa pagina è stata tradotta dall'API Cloud Translation.

Inizia a utilizzare Google Cloud CLI (GKE)

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.

Al momento del deployment, Autorizzazione binaria utilizza gli attestatori per verificare le firme digitali nelle attestazioni. Le attestazioni vengono create dai firmatari, in genere all'interno di 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 esempio più realistico, consulta la sezione sulla configurazione di più progetti.

I passaggi riportati di seguito 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:

Creare un cluster Google Kubernetes Engine Cluster (GKE) con Autorizzazione binaria abilitata
Crea un attestatore utilizzato dall'applicazione di Autorizzazione binaria per verificare la firma di 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 del contenitore, creando una firma
Creare un'attestazione utilizzando la firma
Testa il criterio eseguendo il deployment di un'immagine container in GKE

Costi

In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Prima di iniziare

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Install the Google Cloud CLI.

To initialize the gcloud CLI, run the following command:

gcloud init

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Install the Google Cloud CLI.

To initialize the gcloud CLI, run the following command:

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

Creare un cluster con Autorizzazione binaria abilitata

Crea il cluster

Crea un cluster GKE con Autorizzazione binaria attivata. Si tratta del cluster in cui vuoi eseguire le immagini container di cui è stato eseguito il deployment. Quando crei il cluster, passi il flag --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE alla Comando gcloud container clusters create.

Per creare il cluster:

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 us-central1-a zona GKE.

Configura `kubectl`

Devi anche aggiornare il file kubeconfig locale per il tuo kubectl dell'installazione. Vengono fornite le credenziali e le informazioni sugli 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 governano 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. Quando configuri un criterio utilizzando i comandi gcloud, modifichi questo file.

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 nel node defaultAdmissionRule. evaluationMode specifica che il criterio consente tutti i tentativi di deployment delle immagini. In questo tutorial, aggiorni per richiedere le attestazioni.

globalPolicyEvaluationMode esenta le immagini di sistema gestite da Google dall'applicazione di Autorizzazione binaria.

Per aggiungere un'immagine esente alla lista consentita, aggiungi quanto segue al file delle norme:

admissionWhitelistPatterns:
  - namePattern: EXEMPT_IMAGE_PATH

Sostituisci EXEMPT_IMAGE_PATH con il percorso dell'immagine da escludere. Per esentare altre immagini, aggiungi altre voci - namePattern. Scopri di più su admissionWhitelistPatterns.

Per ulteriori informazioni sulla struttura di un criterio, consulta il riferimento YAML per i criteri.

Crea un attestatore

Un attestatore è l'autorità di verifica utilizzata dall'agente di applicazione di Autorizzazione binaria 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, puoi avere un numero qualsiasi di attestatori, ciascuno dei quali rappresenta una parte che partecipa alla procedura di autorizzazione di un'immagine contenitore.

Crea la nota di analisi degli elementi

Imposta le variabili che memorizzano il nome dell'attestatore e la nota di analisi degli elementi:
```
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 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 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 che hai creato non è ancora utilizzabile senza una coppia di chiavi PKIX associata, che puoi creare di seguito.

Per una configurazione con più progetti, devi impostare le autorizzazioni nella nota Analisi contenitore come descritto in Configurazione con più progetti. Questa operazione non è obbligatoria in uno scenario con un solo progetto, perché il progetto ha i requisiti roles/containeranalysis.notes.occurrences.viewer per impostazione predefinita.

Genera una coppia di chiavi

Autorizzazione binaria utilizza chiavi crittografiche per verificare in modo sicuro l'identità dei signers. Ciò garantisce consente di eseguire il deployment solo delle immagini container autorizzate. La coppia di chiavi è 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 è 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 contenitore.

In questo tutorial utilizzerai il formato PKIX (Public-Key Infrastructure (X.509)) per le chiavi crittografiche. 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.

Finalità e algoritmi delle chiavi per ulteriori informazioni sugli algoritmi di firma.

Le chiavi generate e memorizzate da Cloud Key Management Service (Cloud KMS) sono conformi a PKIX. Per ulteriori informazioni sull'utilizzo delle chiavi PKIX e di Cloud KMS, consulta la sezione Creare attestatori mediante l'interfaccia a riga di comando gcloud.

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 il seguente comando:

gcloud kms keyrings create ${KMS_KEYRING_NAME} \
  --location ${KMS_KEY_LOCATION}

Per creare la chiave, esegui il seguente 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 il tuo ID chiave pubblica in qualsiasi momento utilizzando 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:

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 all'attestatore in modo che possa essere utilizzata da Authorization Binary 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
```
Nota: questo comando restituisce il PUBLIC_KEY_ID che utilizzi per creare un'attestazione. Si trova nel campo id dell'output e ha il seguente aspetto:ni:///sha-256;ybf_gINTzsBKLCaRIeQnExNhKFkGONXXXlr63QeZY-Q.
Salva l'ID della chiave pubblica.

Per salvare l'ID chiave pubblica, puoi copiarlo dall'output di public-keys add riportato sopra. Per visualizzare l'ID chiave pubblica del tuo attestatore dopo averlo aggiunto, utilizzagcloud 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 a REQUIRE_ATTESTATION e aggiunge un nodo denominato requireAttestationsBy 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 dei criteri in Autorizzazione binaria:
```
gcloud container binauthz policy import /tmp/policy.yaml
```

Per ulteriori informazioni sulla configurazione di un criterio, consulta Configurare un criterio utilizzando l'interfaccia a riga di comando gcloud.

Testa il criterio

Puoi testare il criterio configurato sopra tentando di eseguire il deployment di un'immagine container di esempio nel cluster. Il criterio bloccherà il deployment perché non è stata eseguita la verifica obbligatoria.

Per questo tutorial, puoi utilizzare immagini di esempio da Container Registry e Artifact Registry. L'immagine di Container Registry si trova nel percorsogcr.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}}'

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 per poter andare al passaggio successivo:

kubectl delete deployment hello-server

Creare un'attestazione

Un'attestazione è un documento digitale creato da un firmatario che certifica che GKE è autorizzato a eseguire il deployment dell'immagine del container associata. Il processo di creazione di un'attestazione viene a volte chiamato "firma di un'immagine". Un firmatario può essere una persona o, più spesso, un processo automatico 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, l'applicazione di Autorizzazione binaria utilizza la chiave pubblica dell'attestatore per verificare la firma nell'attestazione.

In questo tutorial, l'attestazione indica semplicemente che autorizzi l'immagine per il deployment.

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"
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 Cloud KMS

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 dell'attestazione:

gcloud container binauthz create-signature-payload \
--artifact-url=${IMAGE_TO_ATTEST} > /tmp/generated_payload.json

Il file JSON del payload ha 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 di firma, esegui il seguente 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 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 la sezione Creare attestazioni.

Riprovare il 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:

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 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

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).
Attivare la modalità di prova per disattivare l'applicazione
Utilizzare il deployment di emergenza per bypassare l'applicazione forzata

Inizia a utilizzare Google Cloud CLI (GKE)

Obiettivi

Costi

Prima di iniziare

Attiva Autorizzazione binaria

Imposta il progetto predefinito

Abilita le API richieste

Container Registry

Artifact Registry

Creare un cluster con Autorizzazione binaria abilitata

Crea il cluster

Configura kubectl

Visualizza il criterio predefinito

Crea un attestatore

Crea la nota di analisi degli elementi

Crea l'attestatore

Genera una coppia di chiavi

PKIX (Cloud KMS)

PKIX (chiave locale)

Configura il criterio

Testa il criterio

Creare un'attestazione

Container Registry

Artifact Registry

PKIX Cloud KMS

PKIX (chiave locale)

Riprovare il criterio

Esegui la pulizia

Passaggi successivi

Configura `kubectl`