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 catena di fornitura del software basata su container verificando che un'immagine container disponga di 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, di solito nell'ambito di una pipeline di integrazione continua (CI).

In questo tutorial, il cluster GKE, le attestazioni e gli attestatori si trovano tutti in un unico progetto. Una configurazione a progetto singolo è particolarmente utile per testare o sperimentare il servizio. Per un esempio più realistico, vedi Configurazione di più progetti.

I passaggi riportati di seguito descrivono le attività che esegui dalla riga di comando. Per seguire questi passaggi utilizzando la console Google Cloud , consulta Inizia 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 che l'enforcer di Autorizzazione binaria utilizza per verificare la firma di un'attestazione
  • Configura un criterio che richiede un'attestazione
  • Crea una coppia di chiavi crittografiche per firmare le attestazioni e verificarle in un secondo momento
  • Firma un digest dell'immagine container, creando una firma
  • Creare un'attestazione utilizzando la firma
  • Testa il criterio eseguendo il deployment di un'immagine container su GKE

Costi

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

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il calcolatore prezzi.

I nuovi Google Cloud utenti potrebbero avere diritto a una prova gratuita.

Prima di iniziare

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

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

    Go to project selector

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

  4. Install the Google Cloud CLI.

  5. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  6. To initialize the gcloud CLI, run the following command: 

    gcloud init

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

    Go to project selector

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

  9. Install the Google Cloud CLI.

  10. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  11. To initialize the gcloud CLI, run the following command: 

    gcloud init
  12. Installa kubectl per interagire con GKE.

Attiva Autorizzazione binaria

Impostare 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 progetto.

Abilita le API richieste

Abilita le API per:

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 abilitata. Questo è il cluster in cui vuoi che vengano eseguite 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:

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. Vengono fornite 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

Visualizzare la policy predefinita

Un criterio in Autorizzazione binaria è un insieme di regole che governano il deployment delle immagini container. Puoi avere un criterio per progetto. Per impostazione predefinita, il criterio è configurato per consentire il deployment di tutte le immagini container.

L'autorizzazione binaria consente di esportare e importare un file di policy in formato YAML. Questo formato riflette la struttura di una policy così come viene archiviata dal 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 contiene quanto segue:

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_ALLOW
globalPolicyEvaluationMode: ENABLE
name: projects/PROJECT_ID/policy

La regola predefinita è definita nel nodo defaultAdmissionRule. evaluationMode specifica che il criterio consente tutti i tentativi di deployment delle immagini. In questo tutorial, aggiornerai la regola predefinita per richiedere le attestazioni.

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

Per aggiungere un'immagine esente all'allowlist, aggiungi quanto segue al file delle norme: 

admissionWhitelistPatterns:
  - namePattern: EXEMPT_IMAGE_PATH

Sostituisci EXEMPT_IMAGE_PATH con il percorso di un'immagine da esentare. 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 che lo strumento di applicazione 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 ed è in genere 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 un numero qualsiasi di attestatori, ognuno dei quali rappresenta una parte che partecipa al processo di autorizzazione per un'immagine container.

Creare la nota Artifact Analysis

  1. 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: il nome dell'attestatore che preferisci.
    • attestor-note: il nome della nota dell'attestatore che preferisci.

  2. Crea un file JSON in /tmp/note_payload.json che descriva la nota Container Analysis:

    cat > /tmp/note_payload.json << EOM
{
  "name": "projects/${PROJECT_ID}/notes/${NOTE_ID}",
  "attestation": {
    "hint": {
      "human_readable_name": "Attestor Note"
    }
  }
}
EOM

  3. Crea la nota inviando una richiesta HTTP all'API REST 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}"

  4. 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:

  1. Crea l'attestatore in Autorizzazione binaria:

    gcloud container binauthz attestors create ${ATTESTOR_NAME} \
--attestation-authority-note=${NOTE_ID} \
--attestation-authority-note-project=${PROJECT_ID}

  2. 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 associata, che creerai più avanti in questa guida.

Genera una coppia di chiavi

Autorizzazione binaria utilizza chiavi crittografiche per verificare in modo sicuro l'identità dei firmatari. In questo modo, solo le immagini container autorizzate possono essere sottoposte a deployment. La coppia di chiavi è costituita da una chiave privata e una chiave pubblica. Il firmatario utilizza la chiave privata per firmare il digest dell'immagine container, producendo una firma che viene poi archiviata in un'attestazione. La chiave pubblica è memorizzata nell'attestatore. Al momento del deployment, lo strumento di applicazione di Autorizzazione binaria utilizza la chiave pubblica dell'attestatore per verificare la firma nell'attestazione prima di consentire il deployment del container.

In questo tutorial, utilizzi il formato Public-Key Infrastructure (X.509) (PKIX) per le chiavi di crittografia. Questo tutorial utilizza l'algoritmo di firma digitale con curva ellittica (ECDSA) consigliato per generare una coppia di chiavi PKIX. Puoi anche utilizzare chiavi RSA o PGP per firmare le immagini.

Per ulteriori informazioni sugli algoritmi di firma, consulta Finalità e algoritmi delle chiavi.

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 di Cloud KMS, consulta la sezione Creazione di attestatori mediante gcloud CLI.

PKIX (Cloud KMS)

Per creare la coppia di chiavi in Cloud KMS:

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

  2. Per creare il keyring, esegui questo comando:

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

  3. 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}

  4. 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}"

  5. Recupera l'ID chiave pubblica dall'attestatore nel seguente modo:

    Puoi visualizzare l'ID della tua 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:

  1. Crea la chiave privata:

    PRIVATE_KEY_FILE="/tmp/ec_private.pem"
openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}

  2. 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}

  3. Aggiungi la chiave pubblica all'attestatore.

    Ora aggiungi la chiave pubblica che hai esportato all'attestatore in modo che possa essere utilizzata da Autorizzazione binarian 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
    ni:///sha-256;ybf_gINTzsBKLCaRIeQnExNhKFkGONXXXlr63QeZY-Q

  4. Salva l'ID 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, utilizza gcloud 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 la tua policy. In questo passaggio, esporta il file YAML della policy nel sistema locale e modifica la regola predefinita in modo che richieda un'attestazione da parte dell'attestatore definito in precedenza.

Per configurare le norme:

  1. Crea un nuovo file di policy che consenta le immagini di sistema gestite da Google, imposti evaluationMode su REQUIRE_ATTESTATION e aggiunga 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

  2. 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, vedi Configurare un criterio utilizzando gcloud CLI.

Testare la policy

Puoi testare il criterio configurato sopra provando a eseguire il deployment di un'immagine container di esempio nel cluster. I criteri bloccheranno il deployment perché non è stata eseguita l'attestazione richiesta.

Per questo tutorial, puoi utilizzare immagini di esempio da Artifact Registry. L'immagine di Artifact Registry si trova nel percorso us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0. Il percorso contiene 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 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 stampa il seguente messaggio, che indica che l'immagine non è stata 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 procedere 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 container associata. Il processo di creazione di un'attestazione viene talvolta chiamato "firma di un'immagine". Un firmatario può essere una persona o, più spesso, un processo automatizzato che viene eseguito quando viene creata un'immagine container. La firma viene creata utilizzando la chiave privata di una coppia di chiavi. Al momento del deployment, lo strumento di 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 il deployment dell'immagine.

Per creare un'attestazione:

  1. Imposta le variabili che memorizzano il percorso del registro e il digest dell'immagine:

    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}

  2. Per creare l'attestazione:

    PKIX Cloud KMS

    Per creare l'attestazione utilizzando la chiave Cloud KMS, esegui il comando seguente:

    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:

    1. 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 ha i seguenti contenuti:

      {
"critical": {
  "identity": {
    "docker-reference": "us-docker.pkg.dev/google-samples/containers/gke/hello-app"
  },
  "image": {
    "docker-manifest-digest": "sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea
882eb722c3be4"
  },
  "type": "Google cloud binauthz container signature"
}
}

    2. Per firmare il payload con la chiave privata PKIX e generare un file di firma, 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.

    3. 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 verifica che l'attestazione possa essere verificata dall'attestatore configurato nelle norme.

  3. Verifica che l'attestazione sia stata creata:

    gcloud container binauthz attestations list \
    --attestor=$ATTESTOR_NAME --attestor-project=$PROJECT_ID

Per saperne di più sulla creazione di attestazioni, consulta la sezione Creare attestazioni.

Esegui di nuovo il test della policy

Ancora una volta, 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. In questo caso, Autorizzazione binaria consente il deployment dell'immagine perché è stata eseguita l'attestazione richiesta.

Per eseguire il deployment dell'immagine:

kubectl run hello-server --image ${IMAGE_TO_ATTEST} --port 8080

Per verificare che l'immagine sia stata implementata:

kubectl get pods

Il comando stampa un messaggio simile al seguente, che indica che il deployment è stato eseguito correttamente:

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