Utilizzare il controllo della firma di Sigstore

Questa pagina mostra come utilizzare la verifica della firma Sigstore per la convalida continua (CV) di Autorizzazione binaria. Il controllo verifica le firme generate da Sigstore delle immagini container associate ai pod in esecuzione in un cluster GKE in cui è attivata la CV. La differenza principale tra questo controllo e il controllo di attestazione della firma semplice è che il flusso di lavoro di firma Sigstore non utilizza le note di analisi degli elementi per collegare le firme alle immagini. Tutte le firme vengono memorizzate 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 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

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
  2. Install the Google Cloud CLI.
  3. To initialize the gcloud CLI, run the following command:

    gcloud init
  4. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

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

  6. Enable the Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine, Artifact Registry APIs:

    gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com artifactregistry.googleapis.com
  7. Install the Google Cloud CLI.
  8. To initialize the gcloud CLI, run the following command:

    gcloud init
  9. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

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

  11. Enable the Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine, Artifact Registry APIs:

    gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com artifactregistry.googleapis.com
  12. Assicurati che la CLI gcloud sia aggiornata all'ultima versione.
  13. Installa lo strumento a riga di comando kubectl.
  14. 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.
  15. Installa lo strumento a riga di comando cosign.

Ruoli obbligatori

Questa sezione mostra come impostare i ruoli per questo controllo.

Panoramica

Se pubblichi tutti i prodotti menzionati in questa guida nello stesso non devi impostare alcuna autorizzazione. Autorizzazione binaria configura i ruoli correttamente quando lo abiliti. 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 Sigstore del CV, 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 dal progetto dei criteri: Valutatore criteri di autorizzazione binaria (roles/binaryauthorization.policyEvaluator) sull'agente di servizio di Autorizzazione binaria del progetto cluster
  • Se il progetto del repository di immagini è diverso dal progetto dei criteri: Lettore Artifact Registry (roles/artifactregistry.reader) sull'agente di servizio di Autorizzazione binaria del progetto di criteri

Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.

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

Concedi ruoli utilizzando gcloud CLI

Per assicurarti che l'agente di servizio di Autorizzazione binaria in ogni progetto disponga autorizzazioni necessarie per valutare la firma di CV Sigstore verifica, concedi all'agente di servizio di Autorizzazione binaria in ogni progetto seguenti ruoli IAM:

  1. Concedi l'autorizzazione per il servizio di Autorizzazione binaria del progetto del cluster Agente per accedere al criterio nel progetto del criterio.

    1. Recupera l'agente di servizio di Autorizzazione binaria del progetto del 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 del progetto del cluster.

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

  2. Consenti all'agente di servizio di Autorizzazione binaria del progetto di criteri di accedere alle firme nel tuo repository:

    1. Recupera l'agente di servizio di Autorizzazione binaria del progetto di criteri:

      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 contenente 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 tuo repository.

Crea una coppia di chiavi

In questa sezione crei una coppia di chiavi asimmetriche con l'algoritmo di firma digitale con curva ellittica (ECDSA).

Utilizzi la chiave privata per firmare l'immagine, che crea l'attestazione. Tu includi la chiave pubblica nei criteri della piattaforma. Quando CV controlla la un'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.

Cosignificato di Cloud KMS PKIX

  1. Configura le variabili di ambiente necessarie per creare la coppia di chiavi. Per farlo, ti consigliamo di compilare i segnaposto nel seguente comando: ed esegui 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 la raccolta di chiavi Cloud KMS
    • KMS_KEY_NAME: un nome per la chiave Cloud KMS
  2. 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}
    
  3. Registra la posizione 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 questo file posizione in una variabile per i comandi futuri.

    PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
    

PKIX Cloud KMS gcloud

Per creare la coppia di chiavi in Cloud KMS:

  1. Configura le variabili di ambiente necessarie per creare la coppia di chiavi. Per farlo, consigliamo di compilare i segnaposto nel seguente comando, e poi di eseguirlo.

    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 la raccolta di chiavi Cloud KMS
    • KMS_KEY_NAME: un nome per Cloud KMS chiave
  2. Crea il keyring:

    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}
    
  4. 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 il criterio della piattaforma CV con un controllo della firma di Sigstore, segui questi passaggi:

  1. Crea il file dei criteri della piattaforma per il 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 del criterio.

  2. Crea il criterio della piattaforma:

    Prima di utilizzare i dati dei comandi riportati di seguito, effettua le seguenti sostituzioni:

    • POLICY_ID: un ID criterio della piattaforma scelto da te. 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 delle norme.
    • POLICY_PROJECT_ID: l'ID del progetto di norme.

    Esegui la persone che seguo :

    Linux, macOS o Cloud Shell

    gcloud beta container binauthz policy create POLICY_ID \
        --platform=gke \
        --policy-file=POLICY_PATH \
        --project=POLICY_PROJECT_ID

    Windows (PowerShell)

    gcloud beta container binauthz policy create POLICY_ID `
        --platform=gke `
        --policy-file=POLICY_PATH `
        --project=POLICY_PROJECT_ID

    Windows (cmd.exe)

    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 delle conversioni con criteri della piattaforma basati su controlli.

Crea un cluster che utilizza il monitoraggio CV

In questa sezione crei un cluster che utilizza solo il monitoraggio dei 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: un nome di 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 la persone che seguo :

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 il monitoraggio dell'applicazione e del CV

In questa sezione creerai un cluster che utilizza Applicazione dei criteri project-singleton e monitoraggio delle conversioni 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: un nome di 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 la persone che seguo :

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 in modo da utilizzare il monitoraggio dei video con criteri della piattaforma basati solo su controlli. Se nel cluster è già attivata l'applicazione dei criteri relativi ai progetti singoli, l'esecuzione di questo comando la disattiva. Valuta invece la possibilità di aggiornare il cluster con applicazione forzata Monitoraggio CV abilitato.

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

  • CLUSTER_NAME: il 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 il seguente 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 delle conversioni

In questa sezione, aggiorni un cluster in modo da utilizzare sia l'applicazione dei criteri per progetti singoli sia il monitoraggio dei 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: il 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 il seguente 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

Test CV

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

Quindi tenti di eseguire il deployment di un'immagine non firmata diversa. 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 deve avere una firma valida. Per creare il cluster firma, procedi nel seguente modo:

  1. Crea le variabili utilizzate 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
  2. 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 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 ad Artifact Registry.

    cosign sign --key ${PRIVATE_KEY_FILE} ${IMAGE_TO_SIGN}
    
  3. Rispondere alla richiesta di Cosign:

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

Verificare manualmente la firma

Per verificare manualmente la firma, procedi nel seguente modo:

  1. 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 presenta 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 si trova in un elemento dell'elenco layers, nella mappa annotations. La 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 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: dimensioni del dizionario annotations in byte
    • DIGEST_OF_ANNOTATIONS: sintesi del dizionario annotations
    • BASE64_SIGNATURE: la firma non elaborata della codifica in formato Base64. Questa è la firma che verrà utilizzata per la verifica
    • BUNDLE: metadati specifici di Sigstore

    Maggiori dettagli sul formato manifest sono disponibili nelle specifiche della firma cosign di Sigstore.

    Riga di comando

    1. Trova l'elemento corretto:

      Elenca gli elementi archiviati con l'immagine:

      gcloud artifacts docker tags list ${IMAGE_PATH}
      

      Un output di esempio è simile al seguente:

      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'elemento con il tag sha256-abc123.sig contiene la firma nel relativo manifest.

    2. Recupera il manifest

      Per ottenere il manifest dell'elemento con il tag sha256-IMAGE_DIGEST_SHA.sig, esegui il seguente 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 posizione 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 si trova in un elemento dell'elenco layers, nella mappa annotations. La 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 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: dimensioni del dizionario annotations in byte
    • DIGEST_OF_ANNOTATIONS: sintesi del dizionario annotations
    • BASE64_SIGNATURE: la firma non elaborata della codifica in formato Base64. Questa è la firma che verrà utilizzata per la verifica
    • BUNDLE: metadati specifici di Sigstore

    Maggiori dettagli sul formato manifest sono disponibili nelle specifiche della firma cosign di Sigstore.

  2. Verifica manualmente la firma:

    Utilizza cosign verify per verificare la firma caricata:

    PKIX Cloud KMS

    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}
    

    L'output del comando indica The signatures were verified against the specified public key se la verifica è andata a buon fine.

Esegui il deployment dell'immagine firmata

Per eseguire il deployment di un'immagine firmata:

  1. 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
  2. Esegui il deployment di un'immagine e verificalo 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, CV non produce voci di log relative a questo pod.

Esegui il deployment di un'immagine non firmata

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

Poiché le norme richiedono le firme e questa immagine non ne ha una, la CV registra regolarmente la violazione durante l'esecuzione del contenitore.

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 record di log durante l'esecuzione del pod.

Visualizza i log per le voci del CV

Puoi cercare le voci di Cloud Logging per trovare errori di configurazione del CV e violazioni della convalida dei criteri della piattaforma CV.

Errori e violazioni dei log CV di Cloud Logging entro 24 ore. Di solito puoi visualizzare le voci entro poche ore.

Visualizza i log degli errori di configurazione CV

Per visualizzare i log degli errori di configurazione del CV, esegui il seguente comando:

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

L'output seguente mostra un errore di configurazione in cui un CV criterio della piattaforma non trovato:

{
  "insertId": "141d4f10-72ea-4a43-b3ec-a03da623de42",
  "jsonPayload": {
    "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent",
    "configErrorEvent": {
      "description": "Cannot monitor cluster 'us-central1-c.my-cluster': Resource projects/123456789/platforms/gke/policies/my-policy does not exist."
    }
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "cluster_name": "my-cluster",
      "location": "us-central1-c",
      "project_id": "my-project"
    }
  },
  "timestamp": "2024-05-28T15:31:03.999566Z",
  "severity": "WARNING",
  "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
  "receiveTimestamp": "2024-05-28T16:30:56.304108670Z"
}

Visualizza le violazioni dei criteri della piattaforma CV

Se nessuna immagine viola le norme relative alla piattaforma che hai attivato, nessuna voce vengono visualizzate 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 del progetto del cluster.

Tipi di controlli

I log CV controllano le informazioni sulle violazioni per checkResults. Nella voce, il valore checkType indica il controllo. I valori per ogni controllo sono come segue:

  • ImageFreshnessCheck
  • SigstoreSignatureCheck
  • SimpleSigningAttestationCheck
  • SlsaCheck
  • TrustedDirectoryCheck
  • VulnerabilityCheck

Log di esempio

L'esempio seguente di voce di log CV 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 dei CV configurato in precedenza in questa guida.

Puoi disattivare il monitoraggio CV o sia l'Autorizzazione binaria sia il monitoraggio CV nel tuo cluster.

Disabilita Autorizzazione binaria in un cluster

Per disattivare l'applicazione sia di CV sia di Autorizzazione di binari nel tuo cluster, esegui il seguente 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

Disattivare il monitoraggio dei criteri basato su controlli in un cluster

Per disattivare la verifica con criteri basati su controlli nel cluster e riattivare l'applicazione utilizzando il criterio di applicazione di Autorizzazione binaria, esegui il seguente comando:

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 precedente flag --enable-binauthz.

Elimina il criterio

Per eliminare il criterio, esegui il seguente comando. Non è necessario eliminare il criterio della piattaforma basata sui controlli per disabilitare il controllo dei criteri basati sui 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

Passaggi successivi