Utilizzare il controllo della firma Sigstore

Questa pagina mostra come utilizzare la convalida continua (CV) di Autorizzazione binaria controllo della firma Sigstore. Il controllo verifica le firme generate da Sigstore delle immagini container associate ai pod in esecuzione in un cluster GKE in cui è abilitata la verifica della firma. 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 artefatti 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. 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 senza costi per l'esecuzione, il test e il deployment dei workload.
  2. Installa Google Cloud CLI.

  3. Se utilizzi un provider di identità (IdP) esterno, devi prima accedere a gcloud CLI con la tua identità federata.

  4. Per inizializzare gcloud CLI, esegui questo comando:

    gcloud init
  5. Crea o seleziona un Google Cloud progetto.

    Ruoli richiesti per selezionare o creare un progetto

    • Seleziona un progetto: la selezione di un progetto non richiede un ruolo IAM specifico. Puoi selezionare qualsiasi progetto per il quale ti è stato concesso un ruolo.
    • Crea un progetto: per creare un progetto, devi disporre del ruolo Autore progetto (roles/resourcemanager.projectCreator), che contiene l'autorizzazione resourcemanager.projects.create. Scopri come concedere i ruoli.
    • Creare 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 progetto Google Cloud .

  6. Verifica che la fatturazione sia abilitata per il tuo progetto Google Cloud .

  7. Abilita le API Autorizzazione binaria, Cloud Key Management Service, Google Kubernetes Engine e Artifact Registry:

    Ruoli richiesti per abilitare le API

    Per abilitare le API, devi disporre del ruolo IAM Amministratore utilizzo dei servizi (roles/serviceusage.serviceUsageAdmin), che include l'autorizzazione serviceusage.services.enable. Scopri come concedere i ruoli.

    gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com artifactregistry.googleapis.com
  8. Installa Google Cloud CLI.

  9. Se utilizzi un provider di identità (IdP) esterno, devi prima accedere a gcloud CLI con la tua identità federata.

  10. Per inizializzare gcloud CLI, esegui questo comando:

    gcloud init
  11. Crea o seleziona un Google Cloud progetto.

    Ruoli richiesti per selezionare o creare un progetto

    • Seleziona un progetto: la selezione di un progetto non richiede un ruolo IAM specifico. Puoi selezionare qualsiasi progetto per il quale ti è stato concesso un ruolo.
    • Crea un progetto: per creare un progetto, devi disporre del ruolo Autore progetto (roles/resourcemanager.projectCreator), che contiene l'autorizzazione resourcemanager.projects.create. Scopri come concedere i ruoli.
    • Creare 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 progetto Google Cloud .

  12. Verifica che la fatturazione sia abilitata per il tuo progetto Google Cloud .

  13. Abilita le API Autorizzazione binaria, Cloud Key Management Service, Google Kubernetes Engine e Artifact Registry:

    Ruoli richiesti per abilitare le API

    Per abilitare le API, devi disporre del ruolo IAM Amministratore utilizzo dei servizi (roles/serviceusage.serviceUsageAdmin), che include l'autorizzazione serviceusage.services.enable. Scopri come concedere i ruoli.

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

Ruoli obbligatori

Questa sezione mostra come impostare i ruoli per questo controllo.

Panoramica

Se esegui tutti i prodotti menzionati in questa guida nello stesso progetto, non devi impostare alcuna autorizzazione. Autorizzazione binaria configura correttamente i ruoli 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 Binary Authorization in ogni progetto disponga delle autorizzazioni necessarie per valutare il controllo della firma CV Sigstore, chiedi all'amministratore di concedere i seguenti ruoli IAM all'agente di servizio Binary Authorization in ogni progetto:

  • Se il progetto del cluster è diverso dal progetto del criterio: Valutatore criterio di autorizzazione binaria (roles/binaryauthorization.policyEvaluator) nell'agente di servizio di autorizzazione binaria del progetto del cluster
  • Se il progetto del repository di immagini è diverso dal progetto delle policy: Lettore di Artifact Registry (roles/artifactregistry.reader) sull'agente di servizio Autorizzazione binaria del progetto delle policy

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

L'amministratore potrebbe anche essere in grado di concedere all'agente di servizio Binary Authorization 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 delle autorizzazioni necessarie per valutare il controllo della firma CV Sigstore, concedi all'agente di servizio di autorizzazione binaria in ogni progetto i seguenti ruoli IAM:

  1. Concedi l'autorizzazione al service agent di Autorizzazione binaria del progetto del cluster per accedere alla policy nel progetto policy.

    1. Recupera il service agent 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 progetto del cluster.

    2. Consenti a CV di valutare la policy sul 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 la tua policy.

  2. Consenti all'agente di servizio Binary Authorization del progetto delle policy di accedere alle firme nel tuo repository:

    1. Ottieni il service agent di Autorizzazione binaria del progetto della policy:

      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 la tua policy.

    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.

Creare una coppia di chiavi

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

Utilizzi la chiave privata per firmare l'immagine, creando l'attestazione. Devi includere la chiave pubblica nelle norme della piattaforma. Quando CV controlla l'attestazione, utilizza la chiave pubblica per verificarla.

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

PKIX Cloud KMS Cosign

  1. Configura le variabili di ambiente necessarie per creare la coppia di chiavi. Per farlo, ti consigliamo di compilare i segnaposto nel seguente comando e poi 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 le chiavi automatizzate Cloud KMS
    • KMS_KEY_NAME: un nome per la chiave Cloud KMS
  2. Genera la chiave con la CLI 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 la posizione di questo file 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, ti consigliamo di compilare i segnaposto nel seguente comando e poi 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 le chiavi automatizzate Cloud KMS
    • KMS_KEY_NAME: un nome per la chiave Cloud KMS
  2. Crea le chiavi automatizzate:

    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 la policy della piattaforma

Per creare il criterio della piattaforma CV con un controllo della firma Sigstore, fai quanto segue:

  1. Crea il file di policy della piattaforma di controllo della firma 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 della policy.

  2. Crea la policy della piattaforma:

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

    • POLICY_ID: Un ID policy della piattaforma a tua scelta. Se la norma 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 del file della policy.
    • POLICY_PROJECT_ID: l'ID progetto della policy.

    Esegui questo comando:

    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

Abilita CV

Puoi creare un nuovo cluster o aggiornarne uno esistente per utilizzare il monitoraggio CV con le norme della piattaforma basate su controlli.

Crea un cluster che utilizza il monitoraggio CV

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

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

  • CLUSTER_NAME: un nome del cluster.
  • LOCATION: la località, ad esempio us-central1 o asia-south1.
  • POLICY_PROJECT_ID: l'ID del progetto in cui è archiviata la policy.
  • POLICY_ID: l'ID policy.
  • 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 e il monitoraggio CV

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

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

  • CLUSTER_NAME: un nome del cluster.
  • LOCATION: la località, ad esempio us-central1 o asia-south1.
  • POLICY_PROJECT_ID: l'ID del progetto in cui è archiviata la policy.
  • POLICY_ID: l'ID policy.
  • 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, aggiornerai un cluster in modo che utilizzi il monitoraggio CV solo con i criteri della piattaforma basati su controlli. Se il cluster ha già l'applicazione dei criteri project-singleton abilitata, l'esecuzione di questo comando la disabilita. Ti consigliamo invece di aggiornare il cluster con l'applicazione e il monitoraggio delle vulnerabilità e delle esposizioni comuni abilitati.

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

  • CLUSTER_NAME: il nome del cluster
  • LOCATION: la posizione, ad esempio us-central1 o asia-south1
  • POLICY_PROJECT_ID: l'ID del progetto in cui è archiviata la policy
  • POLICY_ID: l'ID della policy
  • 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 e il monitoraggio CV

In questa sezione, aggiorni un cluster in modo che utilizzi sia l'applicazione dei criteri singleton del progetto sia il monitoraggio delle vulnerabilità comuni con i criteri della piattaforma basati su controlli.

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

  • CLUSTER_NAME: un nome del cluster
  • LOCATION: la posizione, ad esempio us-central1 o asia-south1
  • POLICY_PROJECT_ID: l'ID del progetto in cui è archiviata la policy
  • POLICY_ID: l'ID della policy
  • 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

Test CV

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

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

Firmare un'immagine

Per superare il controllo, l'immagine deve avere una firma valida. Per creare la firma:

  1. 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
  2. Firma l'immagine ed esegui il push della firma in Artifact Registry:

    PKIX Cloud KMS

    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}
    
  3. Rispondi al prompt di Cosign:

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

Verificare manualmente la firma

Per verificare manualmente la firma:

  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 ha il tag: sha256-[image digest].sig. Deve essere presente un solo elemento con il tag.

    5. Fai clic su Manifest.

    6. Dovresti visualizzare un file in formato JSON con vari campi. Ogni firma si trova in un elemento dell'elenco layers, nella mappa annotations. Le firme si trovano nella chiave dev.cosignproject.cosign/signature.

      Di seguito è riportato un manifest di esempio:

      {
            "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: dimensioni 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: 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 di Sigstore

    Per maggiori dettagli sul formato del manifest, consulta le specifiche 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 esempio di output è il 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'artefatto con il tag sha256-abc123.sig contiene la firma nel manifest.

    2. Scarica 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 posizione del repository
      • REPOSITORY_NAME: il nome del repository
      • IMAGE_NAME: il nome dell'immagine

      Dovresti visualizzare un file in formato JSON con vari campi. Ogni firma si trova in un elemento dell'elenco layers, nella mappa annotations. Le firme si trovano nella chiave dev.cosignproject.cosign/signature.

      Ecco 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: dimensioni 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: 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 di Sigstore

    Per maggiori dettagli sul formato del manifest, consulta le 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}
    

    Se la verifica è andata a buon fine, l'output del 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:

  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 posizione del cluster
    • CLUSTER_PROJECT_ID: l'ID progetto del cluster
  2. 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, CV non produce voci di log correlate 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, 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, CV produce voci di log mentre il pod è in esecuzione.

Visualizzare i log per le voci CV

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

CV registra errori e violazioni in Cloud Logging entro 24 ore. Di solito puoi visualizzare le voci entro poche ore.

Visualizzare i log degli errori di configurazione di CV

Per visualizzare i log degli errori di configurazione di CV, esegui questo 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 non viene trovata una policy della piattaforma CV:

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

Visualizzare le violazioni della convalida delle norme della piattaforma CV

Se nessuna immagine viola le norme della piattaforma che hai attivato, nei log non vengono visualizzate voci.

Per visualizzare le voci di log CV degli 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 di CV controllano le informazioni sulle violazioni per checkResults. Nella voce, il valore checkType indica il controllo. I valori per ogni controllo sono i seguenti:

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

Log di esempio

La seguente voce di logging 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 eseguire la pulizia del monitoraggio del CV che hai configurato in precedenza in questa guida.

Puoi disattivare il monitoraggio di CV o sia Autorizzazione binaria che CV nel tuo cluster.

Disabilita Autorizzazione binaria in un cluster

Per disattivare l'applicazione sia di CV che di Autorizzazione binaria nel tuo 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 posizione del cluster
  • CLUSTER_PROJECT_ID: l'ID progetto del cluster

Disabilita il monitoraggio delle policy basato sui controlli in un cluster

Per disattivare CV 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 posizione 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 la policy

Per eliminare la policy, esegui questo comando. Non è necessario eliminare la policy della piattaforma basata su controlli per disabilitare il controllo delle policy basato su controlli.

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

Sostituisci quanto segue:

  • POLICY_ID: l'ID della policy
  • POLICY_PROJECT_ID: l'ID progetto della policy

Passaggi successivi