Questa pagina è stata tradotta dall'API Cloud Translation.

Impostazione di una configurazione con più progetti

Questo tutorial descrive come utilizzare Autorizzazione binaria in una configurazione multi-progetto. Per una configurazione più semplice di un singolo progetto, consulta Inizia a utilizzare Google Cloud CLI (GKE).

Per stabilire la separazione dei compiti, puoi configurareAutorizzazione binarian in una configurazione con più progetti. Lo scopo di ogni progetto verrà trattato più avanti in questo tutorial.

Configura il progetto deployer

Il progetto di deployment gestisce i cluster Google Kubernetes Engine (GKE), in cui esegui il deployment delle immagini, e i criteri di Autorizzazione binaria che Autorizzazione binaria applica 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 di deployment:

Crea il progetto e attiva la fatturazione nella console Google Cloud se non l'hai già fatto.
Nota su Identity and Access Management: il progetto di deployment contiene il tuo cluster GKE. La configurazione di Identity and Access Management per questo progetto deve riflettere questa situazione.

Imposta le variabili di ambiente per memorizzare 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)")

Abilita API:

Artifact Registry

gcloud --project=${DEPLOYER_PROJECT_ID} \
  services enable\
  container.googleapis.com\
  artifactregistry.googleapis.com\
  binaryauthorization.googleapis.com

Ottieni il nome del account di servizio del progetto di deployment:
```
DEPLOYER_SERVICE_ACCOUNT="service-${DEPLOYER_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
```
Utilizzi il nome account di servizio in un passaggio successivo quando configuri le autorizzazioni nella notaArtifact Analysisi associata al tuo attestatore.

Configurare il progetto del soggetto che attesta

Un progetto attestatore archivia gli attestatori che possono verificare che un'immagine sia pronta per il deployment. Spesso, hai un singolo progetto attestatore che funge da archivio centralizzato per le informazioni sulle parti attendibili nel processo di autorizzazione. In questo modo, puoi gestire centralmente le chiavi di sicurezza necessarie per verificare l'identità degli attestatori e limitare l'accesso solo alle parti che le amministrano.

Per configurare il progetto del soggetto che attesta:

Crea il progetto e attiva la fatturazione nella console Google Cloud se non l'hai già fatto.
Nota di Identity and Access Management: poiché questo progetto contiene i tuoi attestatori, solo il personale di sicurezza deve disporre dell'accesso in scrittura.

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

Abilita le API Artifact Analysis e Binary Authorization:

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

Ottieni il nome del account di servizio del progetto attestatore:
```
ATTESTOR_SERVICE_ACCOUNT="service-${ATTESTOR_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
```
Utilizzi il nome account di servizio in un passaggio successivo quando configuri le autorizzazioni nella notaArtifact Analysisi associata al tuo attestatore.

Configurare il progetto di attestazioni

Un progetto di attestazione è un progetto che archivia le attestazioni che gli attestatori effettuano quando verificano un'immagine. Un progetto di attestazione separato ti consente di organizzare e ispezionare più facilmente le dichiarazioni sulla preparazione del software.

Crea il progetto e attiva la fatturazione nella console Google Cloud se non l'hai già fatto.
Nota su Identity and Access Management: tutti i ruoli coinvolti nell'autorizzazione binaria devono disporre dell'accesso in lettura alle note e alle occorrenze di Artifact Analysis in questo progetto, ma solo i gestori delle attestazioni devono disporre dell'accesso in scrittura.
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.

Abilita le API Artifact 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 di deployment. Questo è il 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 --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 di kubectl. In questo modo vengono fornite 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 attestare che un processo richiesto sia stato completato prima che un'immagine container possa essere implementata. Questa parte può essere un utente umano o, più spesso, un processo automatico come un sistema di build e test o le pipeline di integrazione continua (CI) e deployment (CD). Crea gli attestatori nel progetto attestatore.

Per creare un attestatore, devi:

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

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 l'immagine.

Creare la nota Artifact Analysis

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

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

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/${ATTESTOR_PROJECT_ID}/notes/?noteId=${NOTE_ID}"
```
Attenzione: Autorizzazione binaria non supporta l'Artifact Analysis archiviazione regionale o endpoint regionali. Ti consigliamo di utilizzare l'endpoint API globale Artifact Analysis (https://containeranalysis.googleapis.com/).

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:

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}

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, che crei di seguito.

Aggiungi un'associazione di ruolo IAM per il progetto di deployment

Devi aggiungere un'associazione di ruoli IAM per il progetto di deployment all'attestatore. Questo valore viene utilizzato da Autorizzazione binaria quando valuta una policy per determinare se il progetto dispone delle autorizzazioni per accedere a eventuali attestazioni associate.

Per aggiungere l'associazione di 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 per la nota di Artifact Analysis

Devi anche impostare le autorizzazioni per la nota di Artifact Analysis che hai creato in modo che sia accessibile sia al progetto di deployment sia al progetto di attestazione. A questo scopo, aggiorna il criterio IAM per la nota in modo da assegnare l'accesso Visualizzatore agli account di servizio del progetto.

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

Aggiungi il account di servizio e i ruoli di accesso richiesti alla policy 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"
```
Attenzione: Autorizzazione binaria non supporta l'Artifact Analysis archiviazione regionale o endpoint regionali. Ti consigliamo di utilizzare l'endpoint API globale Artifact Analysis (https://containeranalysis.googleapis.com/).

Configurare le chiavi PKIX

L'autorizzazione binaria utilizza chiavi crittografiche per verificare in modo sicuro l'identità degli attestatori. In questo modo, solo le parti verificate possono partecipare all'autorizzazione di un'immagine container. La coppia di chiavi è costituita da una chiave privata, che l'attestatore utilizza per firmare digitalmente le attestazioni, e da una chiave pubblica, che aggiungi all'attestatore come archiviata dal servizioAutorizzazione binarian.

In questo tutorial utilizzi l'algoritmo di firma digitale con curva ellittica (ECDSA) consigliato per creare la coppia di chiavi. Puoi anche utilizzare chiavi RSA o PGP per la firma. Per ulteriori informazioni sugli algoritmi di firma, consulta la sezione Finalità e algoritmi delle chiavi.

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 di Cloud KMS, consulta la sezione Creazione di attestatori mediante l'interfaccia a riga di comando.

Genera una coppia di chiavi

Una coppia di chiavi PKIX è costituita da una chiave privata, che il firmatario utilizza per firmare digitalmente 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 firmata dalla chiave privata.

Genera la chiave privata:

Per generare una nuova coppia di chiavi PKIX asimmetriche locali e archiviarla in un file:
PKIX (Cloud KMS)
Questo passaggio mostra come eseguire un'attestazione utilizzando le chiavi generate e archiviate in Cloud Key Management Service.
1. Configura le variabili di ambiente per archiviare le informazioni sulla coppia di chiavi gestita 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 archiviate 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: la versione della chiave
2. [Facoltativo] Configura una chiave KMS:
  
  Nota: puoi saltare questi passaggi se hai già una chiave KMS.
  1. Crea una chiave KMS la cui chiave pubblica può essere archiviata in un attestatore. Questo passaggio configura anche le variabili di ambiente che utilizzerai di seguito.
    
    Per creare una chiave e impostare 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 saperne di più sulla creazione di chiavi KMS, consulta Crea 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}"
PKIX (chiave locale)

Avviso: sconsigliamo vivamente di utilizzare coppie di chiavi generate localmente negli ambienti di produzione, in quanto rappresentano un rischio per la sicurezza. Ti consigliamo di utilizzare invece Cloud Key Management Service. Questo esempio viene fornito solo a scopo illustrativo.
1. Per generare la chiave privata, esegui questi comandi:
  PRIVATE_KEY_FILE="/tmp/ec_private.pem" openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
  PRIVATE_KEY_FILE è il nome del file che contiene la chiave privata memorizzata nell'attestatore.
2. Estrai la chiave pubblica dalla chiave privata e archiviala in un file:
  PUBLIC_KEY_FILE="/tmp/ec_public.pem" openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
  PUBLIC_KEY_FILE è il nome del file che contiene la chiave pubblica memorizzata nell'attestatore.
3. Per aggiungere la chiave pubblica che hai esportato all'attestatore, esegui il seguente codice.
  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
  Autorizzazione binaria utilizza la chiave pubblica nell'attestatore per verificare l'attestazione.

Configura il criterio

Ora puoi configurare il criterio nel progetto di deployment. In questo passaggio, esporti il file YAML della policy nel sistema locale e modifichi la regola predefinita in modo che richieda un'attestazione da parte dell'attestatore definito in precedenza.

Per configurare il criterio:

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/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}
    name: projects/${DEPLOYER_PROJECT_ID}/policy
EOM

Importa il file YAML della policy in Autorizzazione binaria:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container binauthz policy import /tmp/policy.yaml

Per ulteriori informazioni sulla configurazione di una policy, consulta Configurazione di una policy mediante l'interfaccia a riga di comando.

Testare la policy

In questo tutorial, crei un'attestazione per immagini pubbliche "Hello World!" di esempio da Artifact Registry. Inizialmente, l'enforcer impedisce il deployment delle immagini perché non esiste l'attestazione richiesta.

Per provare a eseguire il deployment dell'immagine:

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, 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 è una dichiarazione di un attestatore che attesta che una procedura richiesta nella pipeline è stata completata e che l'immagine del container in questione è autorizzata per il deployment. L'attestazione stessa è un record firmato digitalmente che contiene il percorso completo di una versione dell'immagine memorizzata nel registro delle immagini container, nonché l'identità dell'autore dell'attestazione.

In questo tutorial, l'attestazione indica semplicemente che autorizzi il deployment dell'immagine. Crea l'attestazione nel progetto di attestazione.

Per creare un'attestazione:

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}

Crea l'attestazione

PKIX Cloud KMS

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

Genera il payload di attestazione:

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

Il file JSON del payload ha i seguenti contenuti:

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

Firma il payload.

Se utilizzi file PKIX locali, firma il payload con la tua chiave privata PKIX locale e genera un file di 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 sopra.
Recupera l'ID chiave pubblica dall'attestatore.

Puoi visualizzare l'ID della tua chiave pubblica in qualsiasi momento utilizzando il comando: gcloud container binauthz attestors describe ATTESTOR_NAME.

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})
```

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

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 saperne di più sulla creazione di attestazioni, consulta la sezione Creazione di attestazioni.

Testa di nuovo la policy

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 il digest per cercare le attestazioni. In questo caso, Autorizzazione binaria consente il deployment dell'immagine perché l'immagine ha un'attestazione associata.

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 è andato a buon fine:

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

Ora che hai eseguito il deployment dell'immagine container e verificato che la configurazione funzioni, puoi eliminare il cluster creato in GKE:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters delete \
    --zone=us-central1-a \
    test-cluster

Impostazione di una configurazione con più progetti Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Configura il progetto deployer

Artifact Registry

Configurare il progetto del soggetto che attesta

Configurare il progetto di attestazioni

Crea un cluster

Crea un attestatore

Creare la nota Artifact Analysis

Crea l'attestatore

Aggiungi un'associazione di ruolo IAM per il progetto di deployment

Imposta le autorizzazioni per la nota di Artifact Analysis

Configurare le chiavi PKIX

Genera una coppia di chiavi

PKIX (Cloud KMS)

PKIX (chiave locale)

Configura il criterio

Testare la policy

Artifact Registry

Creare un'attestazione

Artifact Registry

PKIX Cloud KMS

PKIX (chiave locale)

Artifact Registry

Testa di nuovo la policy

Impostazione di una configurazione con più progetti