Utilizzare il controllo della firma di Sigstore

Questa pagina mostra come utilizzare la verifica della firma di Sigstore di convalida continua di Autorizzazione binaria. Il controllo verifica le firme generate da Sigstore delle immagini container associate ai pod in esecuzione in un cluster Google Kubernetes Engine (GKE) in cui è abilitato CV. La differenza principale tra questo controllo e il semplice controllo dell'attestazione di firma è che il flusso di lavoro per la firma di Sigstore non utilizza le note di Artifact Analysis per collegare le firme alle immagini. Tutte le firme sono archiviate insieme all'immagine che firmano.

Questo controllo supporta solo i repository Artifact Registry.

Costi

Questa guida utilizza i seguenti servizi Google Cloud:

Autorizzazione binaria, ma il CV è disponibile senza costi durante la fase di anteprima
GKE
Cloud Key Management Service
Artifact Registry

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

Prima di iniziare

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.

Installa Google Cloud CLI.

Per initialize gcloud CLI, esegui questo comando:

gcloud init

Nota: se hai già installato gcloud CLI in precedenza, assicurati di disporre della versione più recente eseguendo

gcloud components
      update

Crea o seleziona un progetto Google Cloud.

Crea un progetto Google Cloud:
```
gcloud projects create PROJECT_ID
```
Sostituisci PROJECT_ID con un nome per il progetto Google Cloud che stai creando.
Seleziona il progetto Google Cloud che hai creato:
```
gcloud config set project PROJECT_ID
```
Sostituisci PROJECT_ID con il nome del tuo progetto Google Cloud.

Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

Abilita le API Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine, Artifact Registry.

gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com artifactregistry.googleapis.com

Installa Google Cloud CLI.

Per initialize gcloud CLI, esegui questo comando:

gcloud init

Nota: se hai già installato gcloud CLI in precedenza, assicurati di disporre della versione più recente eseguendo

gcloud components
      update

Crea o seleziona un progetto Google Cloud.

Crea un progetto Google Cloud:
```
gcloud projects create PROJECT_ID
```
Sostituisci PROJECT_ID con un nome per il progetto Google Cloud che stai creando.
Seleziona il progetto Google Cloud che hai creato:
```
gcloud config set project PROJECT_ID
```
Sostituisci PROJECT_ID con il nome del tuo progetto Google Cloud.

Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

Abilita le API Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine, Artifact Registry.

gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com artifactregistry.googleapis.com

Assicurati che gcloud CLI sia aggiornato all'ultima versione.
Installa lo strumento a riga di comando kubectl.
Se i criteri di Autorizzazione binaria e i cluster GKE si trovano in progetti diversi, assicurati che Autorizzazione binaria sia abilitata in entrambi i progetti.
Installa lo strumento a riga di comando cosign.

Ruoli obbligatori

Questa sezione mostra come impostare i ruoli per questo controllo.

Panoramica

Se esegui nello stesso progetto tutti i prodotti menzionati in questa guida, non devi impostare alcuna autorizzazione. Autorizzazione binaria configura i ruoli correttamente quando viene abilitata. Se esegui i prodotti in progetti diversi, devi impostare i ruoli come descritto in questa sezione.

Per assicurarti che l'agente di servizio di Autorizzazione binaria in ogni progetto disponga delle autorizzazioni necessarie per valutare il controllo della firma del CV Sigstore, chiedi all'amministratore di concedere all'agente di servizio di Autorizzazione binaria in ogni progetto i seguenti ruoli IAM:

Se il progetto del cluster è diverso da quello del criterio: Valutatore dei criteri di Autorizzazione binaria (roles/binaryauthorization.policyEvaluator) nell'agente di servizio di Autorizzazione binaria nel progetto del cluster
Se il progetto del repository di immagini è diverso da quello del criterio: Lettore di Artifact Registry (roles/artifactregistry.reader) nell'agente di servizio di Autorizzazione binaria del progetto del criterio

Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso.

L'amministratore potrebbe anche essere in grado di concedere all'agente di servizio di Autorizzazione binaria in ogni progetto le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Concedi ruoli utilizzando gcloud CLI

Per garantire che l'agente di servizio di Autorizzazione binaria in ogni progetto disponga delle autorizzazioni necessarie per valutare il controllo della firma dell'archivio CV, concedi all'agente di servizio di Autorizzazione binaria in ogni progetto i seguenti ruoli IAM:

Concedi all'agente di servizio di Autorizzazione binaria del progetto del cluster l'autorizzazione ad accedere al criterio nel progetto del criterio.
1. Recupera l'agente di servizio di Autorizzazione binaria del progetto cluster:
```
PROJECT_NUMBER=$(gcloud projects list --filter="projectId:CLUSTER_PROJECT_ID" \
  --format="value(PROJECT_NUMBER)")
CLUSTER_SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
```
  Sostituisci CLUSTER_PROJECT_ID con l'ID progetto del cluster.
2. Consenti al CV di valutare il criterio nel cluster:
```
gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \
    --member="serviceAccount:$CLUSTER_SERVICE_ACCOUNT" \
    --role='roles/binaryauthorization.policyEvaluator'
```
  Sostituisci POLICY_PROJECT_ID con l'ID del progetto che contiene il criterio.
Consenti all'agente di servizio di Autorizzazione binaria del progetto del criterio di accedere alle firme nel tuo repository:
1. Recupera l'agente di servizio di Autorizzazione binaria del progetto del criterio:
```
PROJECT_NUMBER=$(gcloud projects list \
  --filter="projectId:POLICY_PROJECT_ID" \
  --format="value(PROJECT_NUMBER)")
SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
```
  Sostituisci POLICY_PROJECT_ID con l'ID del progetto che contiene il criterio.
2. Concedi il ruolo:
```
gcloud projects add-iam-policy-binding REPOSITORY_PROJECT_ID \
    --member="serviceAccount:$SERVICE_ACCOUNT" \
    --role='roles/artifactregistry.reader'
```
  Sostituisci REPOSITORY_PROJECT_ID con l'ID del progetto che contiene il repository.

Crea una coppia di chiavi

In questa sezione creerai una coppia di chiavi asimmetrica Elliptic Curve Digital Signature Algorithm (ECDSA).

Dovrai utilizzare la chiave privata per firmare l'immagine, che crea l'attestazione. Includi la chiave pubblica nel criterio della piattaforma. Quando il CV controlla l'attestazione, utilizza la chiave pubblica per verificare l'attestazione.

Puoi utilizzare Cloud Key Management Service (Cloud KMS) o chiavi locali, ma ti consigliamo di utilizzare le chiavi Cloud KMS per la produzione.

Contrassegno PKIX Cloud KMS

Configura le variabili di ambiente necessarie per creare la coppia di chiavi. Per farlo, ti consigliamo di inserire i segnaposto nel comando seguente e di eseguire il comando.
```
KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
KMS_KEYRING_NAME=KMS_KEYRING_NAME
KMS_KEY_NAME=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
```
Sostituisci quanto segue:
- KMS_KEY_PROJECT_ID: il tuo ID progetto
- KMS_KEYRING_NAME: un nome per il keyring Cloud KMS
- KMS_KEY_NAME: un nome per la chiave Cloud KMS
Genera la chiave con l'interfaccia a riga di comando Cosign:
```
cosign generate-key-pair \
  --kms gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}
```
Nota: potrebbe essere necessario eseguire il comando gcloud auth application-default login per configurare correttamente le credenziali.
Registra il percorso della chiave pubblica:

Cosign salva automaticamente la chiave pubblica generata come cosign.pub nella directory in cui è stato eseguito il comando generate-key-pair. Salva la posizione del file in una variabile per i comandi futuri.
```
PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
```

gcloud Cloud KMS di PKIX

Per creare la coppia di chiavi in Cloud KMS, segui questi passaggi:

Configura le variabili di ambiente necessarie per creare la coppia di chiavi. Per farlo, ti consigliamo di inserire i segnaposto nel comando seguente e di eseguire il comando.
```
KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
KMS_KEYRING_NAME=KMS_KEYRING_NAME
KMS_KEY_NAME=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
```
Sostituisci quanto segue:
- KMS_KEY_PROJECT_ID: il tuo ID progetto
- KMS_KEYRING_NAME: un nome per il keyring Cloud KMS
- KMS_KEY_NAME: un nome per la chiave Cloud KMS

Crea il keyring:

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

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}

Esporta il materiale della chiave pubblica in un file:

PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
gcloud kms keys versions get-public-key 1 \
    --key=${KMS_KEY_NAME} \
    --keyring=${KMS_KEYRING_NAME} \
    --location=${KMS_KEY_LOCATION} \
    --output-file=${PUBLIC_KEY_FILE} \
    --project=${KMS_KEY_PROJECT_ID}

Chiave locale

Per creare la coppia di chiavi localmente:

  cosign generate-key-pair
  PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
  PRIVATE_KEY_FILE="$(pwd)/cosign.key"

Crea il criterio della piattaforma

Per creare i criteri della piattaforma CV con un controllo della firma di Sigstore:

Crea il file dei criteri della piattaforma di controllo della firma di Sigstore:

cat > POLICY_PATH <<EOF
gkePolicy:
  checkSets:
  - checks:
    - displayName: sigstore-signature-check
      sigstoreSignatureCheck:
        sigstoreAuthorities:
        - displayName: sigstore-authority
          publicKeySet:
            publicKeys:
              publicKeyPem: |
$(awk '{printf "                %s\n", $0}' ${PUBLIC_KEY_FILE})
EOF

Sostituisci POLICY_PATH con il percorso del file dei criteri.

Crea il criterio della piattaforma:

Prima di utilizzare uno qualsiasi dei dati di comando riportati di seguito, effettua le seguenti sostituzioni:
- POLICY_ID: un ID criterio della piattaforma a tua scelta. Se il criterio si trova in un altro progetto, puoi utilizzare il nome completo della risorsa: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID.
- POLICY_PATH: un percorso al file dei criteri.
- POLICY_PROJECT_ID: l'ID progetto del criterio.
Esegui questo comando:
Linux, macOS o Cloud Shell

Nota: assicurati di aver inizializzato Google Cloud CLI con autenticazione e un progetto eseguendo gcloud init; oppure gcloud auth login e gcloud config set project.
```
gcloud beta container binauthz policy create POLICY_ID \
    --platform=gke \
    --policy-file=POLICY_PATH \
    --project=POLICY_PROJECT_ID
```
Windows (PowerShell)

Nota: assicurati di aver inizializzato Google Cloud CLI con autenticazione e un progetto eseguendo gcloud init; oppure gcloud auth login e gcloud config set project.
```
gcloud beta container binauthz policy create POLICY_ID `
    --platform=gke `
    --policy-file=POLICY_PATH `
    --project=POLICY_PROJECT_ID
```
Windows (cmd.exe)

Nota: assicurati di aver inizializzato Google Cloud CLI con autenticazione e un progetto eseguendo gcloud init; oppure gcloud auth login e gcloud config set project.
```
gcloud beta container binauthz policy create POLICY_ID ^
    --platform=gke ^
    --policy-file=POLICY_PATH ^
    --project=POLICY_PROJECT_ID
```

Attiva CV

Puoi creare un nuovo cluster o aggiornarne uno esistente per utilizzare il monitoraggio CV con i criteri della piattaforma basati su controlli.

Creazione di un cluster che utilizza il monitoraggio CV

In questa sezione creerai un cluster che utilizza solo il monitoraggio del CV con criteri della piattaforma basati su controlli.

Prima di utilizzare uno qualsiasi dei dati di comando riportati di seguito, effettua le seguenti sostituzioni:

CLUSTER_NAME: nome di un cluster.
LOCATION: la località, ad esempio us-central1 o asia-south1.
POLICY_PROJECT_ID: l'ID del progetto in cui è archiviato il criterio.
POLICY_ID: l'ID criterio.
CLUSTER_PROJECT_ID: l'ID progetto del cluster.

Esegui questo comando:

Linux, macOS o Cloud Shell

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows (PowerShell)

gcloud beta container clusters create CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows (cmd.exe)

gcloud beta container clusters create CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

Crea un cluster che utilizza l'applicazione forzata e il monitoraggio CV

In questa sezione creerai un cluster che utilizza sia l'applicazione dei criteri project-singleton sia il monitoraggio CV con criteri della piattaforma basati su controlli:

Prima di utilizzare uno qualsiasi dei dati di comando riportati di seguito, effettua le seguenti sostituzioni:

CLUSTER_NAME: nome di un cluster.
LOCATION: la località, ad esempio us-central1 o asia-south1.
POLICY_PROJECT_ID: l'ID del progetto in cui è archiviato il criterio.
POLICY_ID: l'ID criterio.
CLUSTER_PROJECT_ID: l'ID progetto del cluster.

Esegui questo comando:

Linux, macOS o Cloud Shell

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows (PowerShell)

gcloud beta container clusters create CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows (cmd.exe)

gcloud beta container clusters create CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

Aggiorna un cluster per utilizzare il monitoraggio CV

In questa sezione aggiorni un cluster per utilizzare il monitoraggio del CV solo con i criteri della piattaforma basati su controlli. Se nel cluster è già abilitata l'applicazione dei criteri singleton per il progetto, l'esecuzione di questo comando la disattiva. Valuta invece la possibilità di aggiornare il cluster con l'applicazione forzata e il monitoraggio CV abilitati.

Prima di utilizzare uno qualsiasi dei dati di comando riportati di seguito, effettua le seguenti sostituzioni:

CLUSTER_NAME: nome del cluster
LOCATION: la località, ad esempio us-central1 o asia-south1
POLICY_PROJECT_ID: l'ID del progetto in cui è archiviato il criterio
POLICY_ID: l'ID criterio
CLUSTER_PROJECT_ID: l'ID progetto del cluster

Esegui questo comando:

Linux, macOS o Cloud Shell

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows (PowerShell)

gcloud beta container clusters update CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows (cmd.exe)

gcloud beta container clusters update CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

Aggiorna un cluster per utilizzare l'applicazione forzata e il monitoraggio CV

In questa sezione aggiorni un cluster per utilizzare sia l'applicazione forzata dei criteri a livello di progetto sia il monitoraggio del CV con criteri della piattaforma basati su controlli.

Prima di utilizzare uno qualsiasi dei dati di comando riportati di seguito, effettua le seguenti sostituzioni:

CLUSTER_NAME: nome di un cluster
LOCATION: la località, ad esempio us-central1 o asia-south1
POLICY_PROJECT_ID: l'ID del progetto in cui è archiviato il criterio
POLICY_ID: l'ID criterio
CLUSTER_PROJECT_ID: l'ID progetto del cluster

Esegui questo comando:

Linux, macOS o Cloud Shell

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows (PowerShell)

gcloud beta container clusters update CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows (cmd.exe)

gcloud beta container clusters update CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

CV di prova

In questa sezione, eseguirai il test del CV eseguendo il deployment di un'immagine firmata. In questo caso, il controllo della firma del CV Sigstore verifica la firma e non produce alcuna voce di log.

Quindi, tenti di eseguire il deployment di un'altra immagine non firmata. In questo caso, il controllo del CV non riesce a trovare una firma valida e registra la violazione in Cloud Logging.

Firma un'immagine

Per soddisfare il controllo, l'immagine richiede una firma valida. Per creare la firma:

Crea le variabili che utilizzi per firmare l'immagine:
```
IMAGE_PATH=IMAGE_PATH
IMAGE_DIGEST=sha256:IMAGE_DIGEST_SHA
IMAGE_TO_SIGN="${IMAGE_PATH}@${IMAGE_DIGEST}"
```
Sostituisci quanto segue:
- IMAGE_PATH: il percorso dell'immagine
- IMAGE_DIGEST_SHA: l'hash SHA del digest dell'immagine
Firma l'immagine ed esegui il push della firma in Artifact Registry:
Cloud KMS PKIX
Firma l'immagine con una chiave ospitata in Cloud KMS ed esegui il push della firma in Artifact Registry:
```
cosign sign \
    --key gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME} \
    ${IMAGE_TO_SIGN}
```
Chiave locale
Firma l'immagine con una chiave privata locale ed esegui il push della firma in Artifact Registry.
```
cosign sign --key ${PRIVATE_KEY_FILE} ${IMAGE_TO_SIGN}
```
Rispondi alla richiesta di firma:

Dopo aver eseguito il comando cosign sign, Cosign chiede se vuoi caricare la firma nel log di trasparenza Rekor. Rispondi y o n alle richieste. Per saperne di più su Rekor, consulta la documentazione di Rekor.

Verificare manualmente la firma

Per verificare manualmente la firma:

Assicurati che la firma esista in Artifact Registry:
Console Google Cloud
1. Vai alla pagina Artifact Registry nella console Google Cloud.
  
  Vai ad Artifact Registry
2. Nell'elenco dei repository, fai clic sul nome del repository che contiene l'immagine.
3. Fai clic sul nome dell'immagine che hai firmato.
4. Individua l'elemento contenente la firma. Questo elemento ha il tag: sha256-[image digest].sig. Deve essere presente un solo elemento con il tag.
5. Fai clic su Manifest.
6. Dovresti vedere un file in formato JSON con vari campi. Ogni firma risiede in un elemento dell'elenco layers, nella mappa annotations. Le firme si trovano nella chiave dev.cosignproject.cosign/signature.
  
  Di seguito è riportato un esempio di manifest:
```
  {
        "schemaVersion": 2,
        "mediaType": "application/vnd.oci.image.manifest.v1+json",
        "config": {
            "mediaType": "application/vnd.oci.image.config.v1+json",
            "size": SIZE_OF_LAYERS,
            "digest": "DIGEST_OF_LAYERS"
        },
        "layers": [
            {
                "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json",
                "size": SIZE_OF_ANNOTATIONS,
                "digest": "DIGEST_OF_ANNOTATIONS",
                "annotations": {
                    "dev.cosignproject.cosign/signature": "BASE64_SIGNATURE",
                    "dev.sigstore.cosign/bundle": "BUNDLE"
                }
            }
        ]
  }
```
Il file manifest di esempio include quanto segue:
- SIZE_OF_LAYERS: dimensione dell'array layers in byte
- DIGEST_OF_LAYERS: il digest dell'array layers
- SIZE_OF_ANNOTATIONS: dimensione del dizionario annotations in byte
- DIGEST_OF_ANNOTATIONS: digest del dizionario annotations
- BASE64_SIGNATURE: la firma non elaborata codificata in formato base64. Questa è la firma che verrà utilizzata per la verifica
- BUNDLE: metadati specifici per Sigstore
Ulteriori dettagli sul formato del file manifest sono disponibili nella specifica della firma cosign di Sigstore.
Riga di comando
1. Trova l'artefatto corretto:
  
  Elenca gli elementi archiviati con l'immagine:
```
gcloud artifacts docker tags list ${IMAGE_PATH}
```
  Un output di esempio ha il seguente aspetto:
```
Listing items under project PROJECT_ID, location REPOSITORY_LOCATION, repository REPOSITORY_NAME.
TAG                         IMAGE                                                         DIGEST
latest                      us-east1-docker.pkg.dev/my-project/my-repo/my-image           sha256:abc123
sha256-abc123.sig           us-east1-docker.pkg.dev/my-project/my-repo/my-image           sha256:def456
```
  Nell'output, l'artefatto con il tag sha256-abc123.sig contiene la firma nel manifest.
2. Recupera il manifest
  
  Per ottenere il manifest dell'artefatto con il tag sha256-IMAGE_DIGEST_SHA.sig, esegui questo comando:
```
curl -X GET -H "Content-Type: application/json" \
            -H "Authorization: Bearer $(gcloud auth print-access-token)" \
            -H "X-Goog-User-Project: REPOSITORY_PROJECT_ID" \
            "https://REPOSITORY_LOCATION-docker.pkg.dev/v2/REPOSITORY_PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME/manifests/sha256-IMAGE_DIGEST_SHA.sig"
```
  Sostituisci quanto segue:
  - REPOSITORY_PROJECT_ID: l'ID del progetto che contiene il repository
  - REPOSITORY_LOCATION: la località del repository
  - REPOSITORY_NAME: il nome del repository
  - IMAGE_NAME: il nome dell'immagine
  Dovresti vedere un file in formato JSON con vari campi. Ogni firma risiede in un elemento dell'elenco layers, nella mappa annotations. Le firme si trovano nella chiave dev.cosignproject.cosign/signature.
  
  Di seguito è riportato un esempio di manifest:
```
{
    "schemaVersion": 2,
    "mediaType": "application/vnd.oci.image.manifest.v1+json",
    "config": {
        "mediaType": "application/vnd.oci.image.config.v1+json",
        "size": SIZE_OF_LAYERS,
        "digest": "DIGEST_OF_LAYERS"
    },
    "layers": [
        {
            "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json",
            "size": SIZE_OF_ANNOTATIONS,
            "digest": "DIGEST_OF_ANNOTATIONS",
            "annotations": {
                "dev.cosignproject.cosign/signature": "BASE64_SIGNATURE",
                "dev.sigstore.cosign/bundle": "BUNDLE"
            }
        }
    ]
}
```
Il file manifest di esempio include quanto segue:
- SIZE_OF_LAYERS: dimensione dell'array layers in byte
- DIGEST_OF_LAYERS: il digest dell'array layers
- SIZE_OF_ANNOTATIONS: dimensione del dizionario annotations in byte
- DIGEST_OF_ANNOTATIONS: digest del dizionario annotations
- BASE64_SIGNATURE: la firma non elaborata codificata in formato base64. Questa è la firma che verrà utilizzata per la verifica
- BUNDLE: metadati specifici per Sigstore
Ulteriori dettagli sul formato del file manifest sono disponibili nella specifica della firma cosign di Sigstore.
Verifica manualmente la firma:

Utilizza cosign verify per verificare la firma caricata:
Cloud KMS PKIX
```
cosign verify --key gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME} \
      ${IMAGE_PATH}@${IMAGE_DIGEST}
```
Chiave locale
```
cosign verify --key {PUBLIC_KEY_FILE} ${IMAGE_PATH}@${IMAGE_DIGEST}
```
Nota: a seconda che tu abbia caricato la firma nel log di trasparenza pubblico Rekor, potrebbe essere necessario aggiungere il flag della riga di comando --insecure-ignore-tlog per verificare la firma.

Se la verifica è andata a buon fine, l'output comando indica The signatures were verified against the specified public key.

Esegui il deployment dell'immagine firmata

Per eseguire il deployment di un'immagine firmata:

Configura kubectl:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID
```
Sostituisci quanto segue:
- CLUSTER_NAME: il nome del cluster
- LOCATION: la località del cluster
- CLUSTER_PROJECT_ID: l'ID progetto del cluster
Esegui il deployment di un'immagine e verifica il deployment in base al criterio di Autorizzazione binaria:
```
kubectl run hello-app-signed --image=${IMAGE_PATH}@${IMAGE_DIGEST}
```
È stato eseguito il deployment del pod. Poiché l'immagine è firmata, il CV non produce voci di log relative a questo pod.

Nota: in caso di errori durante il deployment, potrebbe essere necessario concedere all'agente di servizio Compute Engine l'autorizzazione per accedere al repository. Leggi la documentazione relativa a Google Cloud SDK.

Esegui il deployment di un'immagine non firmata

In questa sezione eseguirai il deployment di un'immagine non firmata.

Poiché il criterio richiede firme e questa immagine non ne ha una, CV registra regolarmente la violazione mentre il container è in esecuzione.

Per eseguire il deployment dell'immagine, esegui questo comando:

  kubectl run hello-app-unsigned \
      --image=UNSIGNED_IMAGE_PATH@UNSIGNED_IMAGE_DIGEST

È stato eseguito il deployment del pod. Poiché l'immagine non ha un'attestazione, il CV produce voci di log mentre il pod è in esecuzione.

Visualizzazione dei log per le voci CV

CV registra le violazioni dei criteri della piattaforma in Cloud Logging entro 24 ore. Generalmente puoi visualizzare le voci entro un paio d'ore.

Se nessuna immagine viola i criteri della piattaforma che hai abilitato, non vengono visualizzate voci nei log.

Per visualizzare le voci di log CV relative agli ultimi sette giorni, esegui questo comando:

gcloud logging read \
     --order="desc" \
     --freshness=7d \
     --project=CLUSTER_PROJECT_ID \
    'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "policyName"'

Sostituisci CLUSTER_PROJECT_ID con l'ID progetto del cluster.

Tipi di controllo

I log del CV controllano le informazioni sulla violazione in checkResults. Nella voce, il valore checkType indica il controllo. I valori di ciascun controllo sono i seguenti:

ImageFreshnessCheck
SigstoreSignatureCheck
SimpleSigningAttestationCheck
SlsaCheck
TrustedDirectoryCheck
VulnerabilityCheck

Esempio di log

La voce CV Logging di esempio riportata di seguito descrive un'immagine non conforme che viola un controllo della directory attendibile:

{
  "insertId": "637c2de7-0000-2b64-b671-24058876bb74",
  "jsonPayload": {
    "podEvent": {
      "endTime": "2022-11-22T01:14:30.430151Z",
      "policyName": "projects/123456789/platforms/gke/policies/my-policy",
      "images": [
        {
          "result": "DENY",
          "checkResults": [
            {
              "explanation": "TrustedDirectoryCheck at index 0 with display name \"My trusted directory check\" has verdict NOT_CONFORMANT. Image is not in a trusted directory",
              "checkSetName": "My check set",
              "checkSetIndex": "0",
              "checkName": "My trusted directory check",
              "verdict": "NON_CONFORMANT",
              "checkType": "TrustedDirectoryCheck",
              "checkIndex": "0"
            }
          ],
          "image": "gcr.io/my-project/hello-app:latest"
        }
      ],
      "verdict": "VIOLATES_POLICY",
      "podNamespace": "default",
      "deployTime": "2022-11-22T01:06:53Z",
      "pod": "hello-app"
    },
    "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent"
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "project_id": "my-project",
      "location": "us-central1-a",
      "cluster_name": "my-test-cluster"
    }
  },
  "timestamp": "2022-11-22T01:44:28.729881832Z",
  "severity": "WARNING",
  "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
  "receiveTimestamp": "2022-11-22T03:35:47.171905337Z"
}

Esegui la pulizia

Questa sezione descrive come ripulire il monitoraggio del CV configurato in precedenza in questa guida.

Puoi disabilitare il monitoraggio CV o sia Autorizzazione binaria sia CV nel cluster.

Disabilita Autorizzazione binaria in un cluster

Per disabilitare l'applicazione sia di CV che di Autorizzazione binaria nel cluster, esegui questo comando:

gcloud beta container clusters update CLUSTER_NAME \
    --binauthz-evaluation-mode=DISABLED \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID

Sostituisci quanto segue:

CLUSTER_NAME: il nome del cluster
LOCATION: la località del cluster
CLUSTER_PROJECT_ID: l'ID progetto del cluster

Disabilita il monitoraggio dei criteri basati su controlli in un cluster

Per disabilitare CV con criteri basati su controllo nel cluster e riabilitare l'applicazione forzata utilizzando il criterio di Autorizzazione binaria, esegui il comando seguente:

gcloud beta container clusters update CLUSTER_NAME  \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --location=LOCATION \
    --project="CLUSTER_PROJECT_ID"

Sostituisci quanto segue:

CLUSTER_NAME: il nome del cluster
LOCATION: la località del cluster
CLUSTER_PROJECT_ID: l'ID progetto del cluster

Tieni presente che --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE è equivalente al flag precedente --enable-binauthz.

Elimina il criterio

Per eliminare il criterio, esegui questo comando. Non è necessario eliminare il criterio della piattaforma basata su controlli per disabilitare il controllo dei criteri basati su controlli.

gcloud beta container binauthz policy delete POLICY_ID \
    --platform=gke \
    --project="POLICY_PROJECT_ID"

Sostituisci quanto segue:

POLICY_ID: l'ID del criterio
POLICY_PROJECT_ID: l'ID progetto del criterio

Utilizzare il controllo della firma di Sigstore

Costi

Prima di iniziare

Ruoli obbligatori

Panoramica

Concedi ruoli utilizzando gcloud CLI

Crea una coppia di chiavi

Contrassegno PKIX Cloud KMS

gcloud Cloud KMS di PKIX

Chiave locale

Crea il criterio della piattaforma

Linux, macOS o Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Attiva CV

Creazione di un cluster che utilizza il monitoraggio CV

Linux, macOS o Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Crea un cluster che utilizza l'applicazione forzata e il monitoraggio CV

Linux, macOS o Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Aggiorna un cluster per utilizzare il monitoraggio CV

Linux, macOS o Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

Aggiorna un cluster per utilizzare l'applicazione forzata e il monitoraggio CV

Linux, macOS o Cloud Shell

Windows (PowerShell)

Windows (cmd.exe)

CV di prova

Firma un'immagine

Cloud KMS PKIX

Chiave locale

Verificare manualmente la firma

Console Google Cloud

Riga di comando

Cloud KMS PKIX

Chiave locale

Esegui il deployment dell'immagine firmata

Esegui il deployment di un'immagine non firmata

Visualizzazione dei log per le voci CV

Tipi di controllo

Esempio di log

Esegui la pulizia

Disabilita Autorizzazione binaria in un cluster

Disabilita il monitoraggio dei criteri basati su controlli in un cluster

Elimina il criterio

Passaggi successivi