Inizia a utilizzare Google Cloud CLI (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:

gcloud --project=${PROJECT_ID} \
    services enable\
    container.googleapis.com\
    containerregistry.googleapis.com\
    binaryauthorization.googleapis.com

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

Configura kubectl

Devi anche aggiornare il file kubeconfig locale per l'installazione di kubectl. 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 criterio per progetto. Per impostazione predefinita, il criterio è configurato per consentire il deployment di tutte le immagini container.

L'autorizzazione binaria ti consente di esportare e importare un file di criteri in formato YAML. Questo formato riflette la struttura di un criterio così come viene memorizzato 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 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, 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 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 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 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 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 Analisi degli elementi per archiviare i metadati attendibili utilizzati nella procedura di autorizzazione
• Crea l'attestatore stesso 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 contenitore 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 Artifact Analysis

1. Imposta le variabili che memorizzano il nome dell'attestatore e la 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 di 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 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}"
   

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 potrai creare più avanti in questa guida.

Genera una coppia di chiavi

L'Autorizzazione binaria utilizza le chiavi crittografiche per verificare in modo sicuro l'identità dei firmatari. In questo modo, si garantisce che venga eseguito il deployment solo delle immagini container autorizzate. La coppia di chiavi è composta da una chiave privata e una chiave pubblica. Il firmatario utilizza la chiave privata per firmare il digest dell'immagine del contenitore, producendo una firma che viene poi archiviata in un'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 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 la firma delle immagini.

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

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.

Configura il criterio

Ora puoi configurare il criterio. In questo passaggio esporti il file YAML della norma sul tuo sistema locale e modifichi la regola predefinita in modo che richieda un'attestazione da parte dell'attestatore che hai definito sopra.

Per configurare il criterio:

1. Crea un nuovo file di criteri che consenta le immagini di sistema gestite da Google, imposta evaluationMode su REQUIRE_ATTESTATION e aggiungi 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, 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'applicazione di esempio "Hello, World!".

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 stampa il seguente messaggio, che indica che l'immagine non è stata dimessa:

No resources found.

Puoi trovare 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 passare 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 viene 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:

1. Imposta le variabili che memorizzano il percorso del registry 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}
   

2. Per creare l'attestazione:

   PKIX Cloud KMS

   Per creare l'attestazione utilizzando la chiave Cloud KMS, esegui il 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:

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

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

   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 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 ulteriori informazioni sulla creazione di attestazioni, consulta la sezione Creare attestazioni.

Riprovare il criterio

Di nuovo, 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 dispiata:

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