Impostazione di una configurazione con più progetti

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questo tutorial descrive come utilizzare Autorizzazione binaria in una configurazione multiprogetto. Per una configurazione più semplice su un singolo progetto, consulta la pagina Iniziare a utilizzare Google Cloud CLI (GKE).

Per stabilire la separazione dei compiti, puoi configurare Autorizzazione binaria in una configurazione a più progetti. Lo scopo di ogni progetto è discusso più avanti in questo tutorial.

Obiettivi

In questo tutorial, esegui le attività seguenti:

  1. Configurare un progetto diverso per il deployment (GKE), l'attestatore e la gestione delle attestazioni, per supportare la separazione dei compiti.

  2. Configura la regola predefinita della tua criterio di Autorizzazione binaria per richiedere le attestazioni.

  3. Crea una coppia di chiavi per firmare e successivamente verificare l'attestazione.

  4. Crea un attestatore utilizzato dall'applicazione di Autorizzazione binaria per verificare l'attestatore.

  5. Firma un'immagine di esempio, creando un'attestazione.

  6. Verifica il criterio eseguendo il deployment dell'immagine di esempio.

Devi configurare il controllo dell'accesso appropriato di ogni progetto tramite Identity and Access Management (IAM).

Per una maggiore sicurezza, puoi utilizzare Controlli di servizio VPC per proteggere le risorse che crei in questo tutorial. Per ulteriori informazioni, consulta la pagina Sicurezza con i Controlli di servizio VPC.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono beneficiare di una prova gratuita.

Prima di iniziare

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

  2. Nella pagina del selettore dei progetti in Google Cloud Console, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

  3. Assicurati che la fatturazione sia attivata per il tuo progetto Cloud. Scopri come verificare se la fatturazione è abilitata su un progetto.

  4. Installa Google Cloud CLI.

  5. Per inizializzare l'interfaccia a riga di comando gcloud, esegui il comando seguente: 

    gcloud init
    6.

  6. Nella pagina del selettore dei progetti in Google Cloud Console, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

  7. Assicurati che la fatturazione sia attivata per il tuo progetto Cloud. Scopri come verificare se la fatturazione è abilitata su un progetto.

  8. Installa Google Cloud CLI.

  9. Per inizializzare l'interfaccia a riga di comando gcloud, esegui il comando seguente: 

    gcloud init
    10.
  10. Installa kubectl per interagire con GKE.

Configura il progetto del deployer

Il progetto deployer gestisce i cluster Google Kubernetes Engine (GKE), in cui esegui il deployment delle immagini e il criterio di Autorizzazione binaria applicato da Autorizzazione binaria al momento del deployment. Puoi avere più di un progetto di deployment, a seconda delle dimensioni, della complessità e di altri requisiti del tuo ambiente.

Per configurare il progetto del deployer:

  1. Crea il progetto e abilita la fatturazione in Google Cloud Console se non lo hai già fatto.

  2. Nota su Identity and Access Management: il progetto del deployer contiene il cluster GKE. La configurazione di Identity and Access Management per questo progetto dovrebbe riflettere questo aspetto.

  3. Imposta le variabili di ambiente per archiviare il progetto e il numero Google Cloud:

    DEPLOYER_PROJECT_ID=DEPLOYER_PROJECT_ID

    Sostituisci DEPLOYER_PROJECT_ID con l'ID progetto Google Cloud.

    DEPLOYER_PROJECT_NUMBER=$(gcloud projects describe "${DEPLOYER_PROJECT_ID}" \
    --format="value(projectNumber)")

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

  5. Ottieni il nome dell'account di servizio del progetto deployer:

    DEPLOYER_SERVICE_ACCOUNT="service-${DEPLOYER_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"

    Puoi utilizzare il nome dell'account di servizio in un passaggio successivo quando configuri le autorizzazioni nella nota Container Analysis associata al tuo attestatore.

Configura il progetto di attestatore

Un progetto di attestazione archivia gli attestori che possono verificare che un'immagine sia pronta per il deployment. Spesso, disponi di un singolo progetto di attestatore, che funge da archivio centralizzato per informazioni sulle parti attendibili nel processo di autorizzazione. In questo modo puoi gestire centralmente i token di sicurezza necessari per verificare l'identità degli attestatori e limitare l'accesso solo alle parti che li gestiscono.

Per configurare il progetto di attestatore:

  1. Crea il progetto e abilita la fatturazione in Google Cloud Console se non lo hai già fatto.

  2. Nota su Identity and Access Management: poiché questo progetto contiene i attestatori, solo il personale di sicurezza deve disporre dell'accesso in scrittura.

  3. 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 dell'attestatore.

    ATTESTOR_PROJECT_NUMBER=$(gcloud projects describe "${ATTESTOR_PROJECT_ID}" \
    --format="value(projectNumber)")

  4. Abilita le API Container Analysis e Binary Authorization:

    gcloud services --project=${ATTESTOR_PROJECT_ID} \
    enable containeranalysis.googleapis.com \
    binaryauthorization.googleapis.com

  5. Ottieni il nome dell'account di servizio del progetto di attestatore:

    ATTESTOR_SERVICE_ACCOUNT="service-${ATTESTOR_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"

    Puoi utilizzare il nome dell'account di servizio in un passaggio successivo quando configuri le autorizzazioni nella nota Container Analysis associata al tuo attestatore.

Configura il progetto di attestazione

Un progetto di attestato è un archivio che memorizza le attestazioni che gli attestatori eseguono quando verificano un'immagine. Un progetto di attestazione separato ti consente di organizzare e ispezionare le dichiarazioni relative all'idoneità del software più facilmente.

  1. Crea il progetto e abilita la fatturazione in Google Cloud Console se non lo hai già fatto.

  2. Nota di Identity and Access Management: tutti i ruoli coinvolti nell'autorizzazione binaria devono avere accesso in lettura alle note e alle occorrenze di Container Analysis in questo progetto, tuttavia solo i gestori di attestazione devono disporre dell'accesso in scrittura.

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

  4. Abilita le API Container Analysis e Binary Authorization:

    gcloud services --project=${ATTESTATION_PROJECT_ID} \
    enable containeranalysis.googleapis.com \
    binaryauthorization.googleapis.com

Crea un cluster

Ora puoi creare un cluster GKE nel progetto del 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 al 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 nella zona GKE us-central1-a.

Devi anche aggiornare il file kubeconfig locale per l'installazione kubectl. Questo fornisce le credenziali e le informazioni sull'endpoint necessarie 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 di attenuare il completamento di un processo richiesto prima che sia possibile eseguire il deployment di un'immagine container. Questo gruppo può essere un utente umano o, più spesso, un processo macchina come un sistema di compilazione e test oppure pipeline di integrazione continua (CI) e deployment (CD). Puoi creare attestatori nel progetto di attestatore.

Per creare un attestatore devi:

  • Crea una nota in Container Analysis per archiviare i metadati attendibili utilizzati nel processo di autorizzazione
  • Crea l'attestatore nel progetto dell'attestatore e associa la nota che hai creato
  • Aggiungi un'associazione di ruolo IAM per l'account di servizio del progetto deployer all'attestatore
  • Imposta le autorizzazioni nella nota Container Analysis

Per questo tutorial, hai un attestatore denominato test-attestor e una nota Container Analysis 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 l'immagine.

Crea la nota Container Analysis

  1. Imposta le variabili in cui è memorizzato il nome dell'attestatore e della nota Container Analysis:

    ATTESTOR_NAME=test-attestor
NOTE_ID=test-attestor-note

    Sostituisci:

    • test-attestor: nome dell'attestatore a tua scelta.
    • test-attestor-note: nome della nota dell'attestatore di tua scelta.

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

    cat > /tmp/note_payload.json << EOM
{
  "name": "projects/${ATTESTOR_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 Container 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/${ATTESTOR_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/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}"

Crea l'attestatore

Ora puoi creare l'attestatore:

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

  2. Verifica che l'attestatore sia stato creato:

    gcloud --project=${ATTESTOR_PROJECT_ID} \
    container binauthz attestors list

L'attestatore che hai creato non è ancora utilizzabile senza una coppia di chiavi PKIX associata, creata 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 ha le autorizzazioni per accedere a qualsiasi attestazione associata.

Per aggiungere l'associazione dei ruoli 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

Imposta le autorizzazioni nella nota Container Analysis

Devi inoltre impostare le autorizzazioni sulla nota Container Analysis creata in modo che sia accessibile sia al progetto di deployment che al progetto di attestatore. Per farlo, aggiorna il criterio IAM della nota per assegnare l'accesso come Visualizzatore agli account di servizio del progetto.

  1. Genera un file JSON contenente le informazioni necessarie per impostare il criterio IAM sulla 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

  2. Aggiungi l'account di servizio e hai richiesto i ruoli di accesso 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)" \
    --data-binary @/tmp/iam_request.json \
    "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"

Configura chiavi PKIX

Autorizzazione binaria utilizza chiavi di crittografia per verificare in modo sicuro l'identità degli attestatori. Questo garantisce che solo le parti verificate possano partecipare all'autorizzazione di un'immagine container. La coppia di chiavi è composta da una chiave privata, che l'attestatore utilizza per firmare le attestazioni digitali, e da una chiave pubblica, che si aggiunge all'attestatore come archiviato dal servizio di Autorizzazione binaria.

In questo tutorial, utilizzerai l'algoritmo di firma digitale della curva ellittica (ECDSA) consigliato per creare la coppia di chiavi. Per la firma puoi anche utilizzare chiavi RSA o PGP. Per scoprire di più sulla firma di algoritmi, consulta la pagina Scopo e algoritmi principali.

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

Genera una coppia di chiavi

Una coppia di chiavi PKIX è composta da una chiave privata, che il firmatore utilizza per firmare le attestazioni digitali, e da una chiave pubblica, che aggiungi all'attestatore. Al momento del deployment, Autorizzazione binaria utilizza questa chiave pubblica per verificare l'attestazione firmata dalla chiave privata.

  1. Genera la chiave privata:

    Per generare una nuova coppia di chiavi PKIX asimmetrica locale e archiviarla in un file:

    PKIX (chiave locale)

    1. Genera la chiave privata:

      PRIVATE_KEY_FILE è il nome del file contenente la chiave privata utilizzata per la firma del payload dell'attestazione.

      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 e archiviala in un file:

      PUBLIC_KEY_FILE è il nome del file contenente la chiave pubblica che verrà archiviata nell'attestatore.

      PUBLIC_KEY_FILE="/tmp/ec_public.pem"
openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
      1. Aggiungi la chiave pubblica locale all'attestatore

      Ora, aggiungi la chiave pubblica esportata all'attestatore in modo che possa essere utilizzata dall'Autorizzazione binaria per la verifica dell'identità:

      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

    PKIX (Cloud KMS)

    Questo passaggio mostra come eseguire un'attestazione utilizzando chiavi generate e archiviate in Cloud Key Management Service.

    1. 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 queste variabili di ambiente 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 sono memorizzate le chiavi
      • KMS_KEY_LOCATION: la posizione della chiave
      • KMS_KEYRING_NAME: il nome del keyring
      • KMS_KEY_NAME: il nome della chiave
      • KMS_KEY_VERSION: versione della chiave

    2. [Facoltativo] Configura una chiave KMS:

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

      2. Crea un keyring KMS:

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

      3. 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 delle chiavi KMS, consulta Creazione di una chiave asimmetrica.

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

Configura il criterio

Ora puoi configurare il criterio nel progetto del deployer. In questo passaggio, devi esportare il file YAML del criterio nel tuo sistema locale e modificare la regola predefinita in modo che richieda un'attestazione da parte dell'attestatore definito in precedenza.

Per configurare il criterio:

  1. Crea un nuovo file di criteri 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/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}
    name: projects/${DEPLOYER_PROJECT_ID}/policy
EOM

  2. 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, immagini pubbliche di "Hello World!" da Container Registry e Artifact Registry. Inizialmente, l'applicazione forzata blocca 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 stampa il seguente messaggio, a indicare che il deployment dell'immagine non è stato eseguito:

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

Crea un'attestazione

Un'attesta è una dichiarazione di un attestatore che un processo richiesto nella tua pipeline è stato completato e che l'immagine del container in questione è autorizzata al deployment. L'attestazione è un record firmato digitalmente che contiene il percorso completo di una versione dell'immagine archiviata nel registro delle immagini container, nonché l'identità dell'attestatore.

In questo tutorial, la tua attestazione indica semplicemente che autorizzi l'immagine per il deployment. Puoi creare l'attestazione nel progetto di attestazione.

Per creare un'attestazione:

  1. Imposta le variabili in cui archiviare il percorso del Registro di sistema e la sintesi 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"

  2. Genera il payload dell'attestazione:

    gcloud --project=${ATTESTATION_PROJECT_ID} \
    container binauthz create-signature-payload \
    --artifact-url=${IMAGE_PATH}@${IMAGE_DIGEST} > /tmp/generated_payload.json

    Il file JSON del payload ha 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"
  }
}

  3. Firma il payload.

    PKIX (chiave locale)

    Se utilizzi file PKIX locali, firma il payload con la chiave privata PKIX locale e genera un file della firma:

    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 in precedenza.

    PKIX (Cloud Key Management Service)

    Firma il payload utilizzando il servizio Cloud Key Management Service:

      gcloud kms asymmetric-sign \
        --location=${KMS_KEY_LOCATION} \
        --keyring=${KMS_KEYRING_NAME} \
        --key=${KMS_KEY_NAME} \
        --version=${KMS_KEY_VERSION} \
        --digest-algorithm=sha256 \
        --input-file=/tmp/generated_payload.json \
        --signature-file=/tmp/ec_signature \
        --project ${KMS_KEY_PROJECT_ID}

  4. Recupera l'ID della chiave pubblica dall'attestatore

    Puoi visualizzare l'ID della chiave pubblica in qualsiasi momento usando il comando: gcloud container binauthz attestors describe <var>ATTESTOR_NAME</var>.

    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)' --project ${ATTESTOR_PROJECT_ID})

  5. Crea un URL dell'immagine che attesta:

    IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}

  6. 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 dall'attestatore configurato nel criterio.

  7. 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 scoprire di più sulla creazione di attestazioni, consulta la sezione 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 sia il percorso dell'immagine sia il digest per cercare le attestazioni. In Autorizzazione binaria, il deployment dell'immagine viene eseguito perché ha un'attestazione associata.

Per eseguire il deployment dell'immagine:

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

Per verificare che il deployment dell'immagine sia stato eseguito:

kubectl get pods

Il comando stampa un messaggio simile al seguente, che indica che il deployment è riuscito:

NAME                            READY     STATUS    RESTARTS   AGE
hello-server-579859fb5b-h2k8s   1/1       Running   0          1m

Ora che hai eseguito il deployment dell'immagine container e hai verificato che la tua configurazione funzioni, puoi eliminare il cluster che hai creato in 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.

  1. Elimina il cluster che hai creato in GKE:

    gcloud container clusters delete \
    --zone=us-central1-a \
    test-cluster

  2. Puoi anche eliminare i progetti Google Cloud che hai creato per questo tutorial.

Passaggi successivi