Creare attestazioni con Kritis Signer

Questo tutorial spiega come compilare Kritis Signer e utilizzarlo per verificare la presenza di vulnerabilità nelle immagini container prima di creare attestazioni di Autorizzazione binaria.

Panoramica

Kritis Signer è uno strumento a riga di comando open source che può creare attestazioni di Autorizzazione binaria in base a un criterio configurato. Puoi anche utilizzare Kritis Signer per creare attestazioni dopo aver controllato un'immagine per rilevare le vulnerabilità identificate da Artifact Analysis.

Inoltre, Cloud Build può eseguire Kritis Signer come builder personalizzato in una pipeline di build.

In questo tutorial esegui una compilazione una tantum del compilatore personalizzato di Kritis Signer, quindi esegui pipeline di compilazione di esempio. Ogni pipeline di esempio contiene i seguenti passaggi di compilazione:

  1. Crea un'immagine container di esempio.
  2. Esegui il push dell'immagine in Container Registry.
  3. Controlla e firma l'immagine: utilizza Kritis Signer per creare un'attestazione in base al criterio.

Nel passaggio di compilazione di controllo e firma di ogni pipeline, Kritis Signer esegue quanto segue:

  1. Analizza l'immagine appena creata con Artifact Analysis e recupera un elenco di vulnerabilità.
  2. Controlla l'elenco delle vulnerabilità rispetto alle regole di firma delle vulnerabilità nel criterio e poi:
    1. Se tutte le vulnerabilità identificate soddisfano le regole di firma delle vulnerabilità, Kritis Signer crea l'attestazione.
    2. Se una delle vulnerabilità identificate viola le regole di firma delle vulnerabilità, Kritis Signer non crea l'attestazione.

Al momento del deployment, l'applicazione di Autorizzazione binaria verifica la presenza di un'attestazione verificabile. In caso contrario, l'applicazione delle norme non consente il deployment dell'immagine.

Questo tutorial spiega anche come eseguire Kritis Signer in modalità di sola verifica in una pipeline Cloud Build. In questa modalità, Kritis Signer non crea un'attestazione, ma controlla solo se i risultati relativi alle vulnerabilità soddisfano le regole di firma delle vulnerabilità nel criterio. In caso contrario, il passaggio di compilazione di Kritis Signer va a buon fine e la pipeline continua a essere eseguita, altrimenti il passaggio non va a buon fine e la pipeline esce.

Obiettivi

In questo tutorial imparerai a:

  1. Configura Kritis Signer come un builder personalizzato di Cloud Build.
  2. Visualizza un criterio che contiene regole di firma delle vulnerabilità.
  3. Esegui Kritis Signer per creare attestazioni in base ai risultati dell'analisi delle vulnerabilità.
  4. Esegui Kritis Signer in modalità solo controllo.

Costi

Questo tutorial utilizza i seguenti prodotti Google Cloud.

  • Container Registry
  • Artifact Analysis
  • Cloud Build
  • Cloud Key Management Service

Utilizza il Calcolatore prezzi per generare una stima dei costi in base all'utilizzo previsto.

Prima di iniziare

In questa sezione esegui una configurazione una tantum del sistema.

Configura l'ambiente

  1. Memorizza il progetto Google Cloud in una variabile di ambiente.

    export PROJECT_ID=PROJECT_ID
    

    Sostituisci PROJECT_ID con il tuo progetto Google Cloud.

  2. Imposta l'ID progetto predefinito per il tuo progetto Google Cloud:

    gcloud config set project $PROJECT_ID
    
  3. Memorizza il numero del progetto in una variabile di ambiente per i passaggi futuri:

    export PROJECT_NUMBER=$(gcloud projects list --filter="${PROJECT_ID}" \
     --format="value(PROJECT_NUMBER)")
    
  4. Abilita le API:

    Per assicurarti che i servizi richiesti per questa guida siano abilitati, esegui questo comando:

    gcloud services enable \
      cloudbuild.googleapis.com \
      containerregistry.googleapis.com \
      containerscanning.googleapis.com \
      cloudkms.googleapis.com
    

Configurare i ruoli IAM

Esegui i seguenti comandi per configurare l'account di servizio Cloud Build con i seguenti ruoli:

  • containeranalysis.notes.editor: aggiunge il ruolo Editor di note di analisi degli elementi per gestire l'attestatore.
  • containeranalysis.notes.occurrences.viewer: aggiunge il ruolo Occorrenze di analisi degli elementi per le note per gestire sia le occorrenze di vulnerabilità sia quelle di attestazione.
  • roles/containeranalysis.occurrences.editor: aggiunge il ruolo Editor occorrenze Artifact Analysis per creare occorrenze di attestazione in Artifact Analysis.
  • cloudkms.signer: aggiunge il ruolo Firmatario Cloud KMS CryptoKey che consente all'account di servizio di accedere al servizio di firma Cloud KMS.

    gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com --role roles/containeranalysis.notes.editor
    gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com --role roles/containeranalysis.notes.occurrences.viewer
    gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com --role roles/containeranalysis.occurrences.editor
    gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com --role roles/cloudkms.signer
    

Configurare il generatore personalizzato di Kritis Signer

In questa sezione esegui una configurazione una tantum del compilatore personalizzato di Kritis Signer. Dopo aver ottenuto, compilato e inviato Kritis Signer, puoi utilizzarlo in qualsiasi pipeline Cloud Build.

Questa sezione illustra come:

  • Clona il repository Kritis.
  • Crea il builder personalizzato di Cloud Build di Kritis Signer.
  • Esegui il push di Kritis Signer in Container Registry per renderlo disponibile per l'utilizzo come passaggio di compilazione di Cloud Build.

Esegui i seguenti comandi per ottenere il codice e i file di configurazione utilizzati in questa guida:

  1. Clona il repository Kritis:

    git clone https://github.com/grafeas/kritis.git
    

    Questo repository contiene quanto segue:

    • Codice sorgente di Kritis che include anche Kritis Signer.
    • Un file di configurazione Cloud Build utilizzato da Cloud Build per compilare il generatore personalizzato di firme Kritis.
    • Un criterio di esempio che contiene regole di firma delle vulnerabilità.
    • File di configurazione Cloud Build di esempio. Ogni file di configurazione utilizza Kritis Signer in una pipeline di analisi delle vulnerabilità.
  2. Vai alla directory kritis/:

    cd kritis
    
  3. Crea e registra il generatore personalizzato di Kritis Signer.

    Questo passaggio di configurazione una tantum compila il builder personalizzato di Kritis Signer e lo registra con Cloud Build. Una volta registrato, il builder personalizzato è disponibile per l'utilizzo in qualsiasi pipeline Cloud Build.

    gcloud builds submit . --config deploy/kritis-signer/cloudbuild.yaml
    

Visualizzare un criterio esistente

Questa sezione mostra un esempio di criterio di firma Kritis.

Questo criterio configura Kritis Signer in modo da richiedere ad Artifact Analysis di eseguire la scansione dell'immagine per rilevare le vulnerabilità. Al termine della scansione, Kritis Signer controlla i risultati delle vulnerabilità restituiti rispetto alle regole di firma delle vulnerabilità indicate nelle norme.

Puoi modificare le regole di firma delle vulnerabilità in questo criterio per creare un'attestazione in base a quanto segue:

  • Livelli di gravità delle vulnerabilità identificate.
  • Vulnerabilità specifiche.

Puoi anche impostare il criterio in modo che crei (ALLOW_ALL) o meno (BLOCK_ALL) un'attestazione in modo incondizionato.

Per visualizzare il criterio di Kritis Signer, esegui il seguente comando:

cat samples/signer/policy-strict.yaml

Le norme sono simili alle seguenti:

apiVersion: kritis.grafeas.io/v1beta1
kind: VulnzSigningPolicy
metadata:
  name: my-vsp
spec:
  imageVulnerabilityRequirements:
    maximumFixableSeverity: MEDIUM
    maximumUnfixableSeverity: MEDIUM
    allowlistCVEs:
    - projects/goog-vulnz/notes/CVE-2021-20305

Dove:

  • maximumUnfixableSeverity e maximumFixableSeverity definiscono le soglie di gravità delle vulnerabilità ed esposizioni comuni (CVE) a cui Kritis Signer crea le attestazioni. maximumUnfixableSeverity definisce la soglia di gravità per la quale non è attualmente disponibile una correzione. maximumFixableSeverity definisce la soglia di gravità per la quale è attualmente disponibile una correzione. maximumUnfixableSeverity e maximumFixableSeverity possono essere impostati su uno tra i seguenti livelli di gravità:

    • CRITICAL
    • HIGH
    • MEDIUM
    • LOW

    Per ulteriori informazioni sui livelli di gravità, consulta Livelli di gravità.

    In alternativa, puoi impostare maximumUnfixableSeverity e maximumFixableSeverity su quanto segue:

    • BLOCK_ALL: l'attestazione non viene creata se viene identificata una vulnerabilità.
    • ALLOW_ALL: l'attestazione viene sempre creata.
  • allowlistCVEs è un elenco di CVE specifiche da inserire nella lista consentita. Kritis Signer ignora le CVE in questo elenco quando valuta se creare un'attestazione. Ogni voce nella lista consentita deve corrispondere esattamente al nome della nota di Artifact Analysis per la CVE. Scopri di più sulle origini delle vulnerabilità di Artifact Analysis. Per saperne di più sulle note, consulta Spazio di archiviazione dei metadati.

Crea una chiave di firma Cloud KMS

Per creare l'attestazione vengono utilizzate le chiavi di Cloud Key Management Service.

  1. Crea un nuovo keyring Cloud KMS con il nomeKEY_RING:

    gcloud kms keyrings create KEY_RING \
       --location global
    
  2. Crea una nuova chiave Cloud KMS denominata KEY_NAME all'interno del keyring:

    gcloud kms keys create KEY_NAME \
        --keyring KEY_RING \
        --location global \
        --purpose "asymmetric-signing" \
        --default-algorithm "rsa-sign-pkcs1-2048-sha256"
    
  3. Memorizza l'algoritmo di hashing e Cloud KMS in una variabile di ambiente per i passaggi futuri:

    export KMS_DIGEST_ALG=SHA256
    export KMS_KEY_NAME=projects/$PROJECT_ID/locations/global/keyRings/KEY_RING/cryptoKeys/KEY_NAME/cryptoKeyVersions/1
    

Definisci un nome per la nota

Tutte le attestazioni fanno riferimento a una nota di Artifact Analysis. Kritis Signer crea automaticamente una nota per un determinato nome. Puoi anche riutilizzare i nomi delle note esistenti.

export NOTE_ID=my-signer-note
export NOTE_NAME=projects/${PROJECT_ID}/notes/${NOTE_ID}

Creare attestazioni con Kritis Signer in una pipeline Cloud Build

Questa sezione mostra come utilizzare lo strumento Cloud Build personalizzato di Kritis Signer per creare attestazioni di Autorizzazione binaria in base ai risultati analisi delle vulnerabilità.

I passaggi che seguono mostrano come funziona Kritis Signer utilizzando i file di configurazione di build di esempio nel repository di Kritis Signer. Ogni file di configurazione di esempio contiene i seguenti passaggi di compilazione:

  1. Un passaggio docker build che crea un'immagine container Docker.
  2. Un passaggio docker push che esegue il push dell'immagine container appena creata in Container Registry.
  3. Un passaggio vulnsign che controlla e firma l'immagine container:

    1. In attesa che Artifact Analysis restituisca i risultati relativi alle vulnerabilità nell'immagine del container appena creata.
    2. Controllare i risultati rispetto alle regole di firma delle vulnerabilità nelle norme.
    3. Crea l'attestazione se i risultati soddisfano le regole relative alle vulnerabilità.

Invii ciascuna delle build di esempio a Cloud Build. Ogni build produce un risultato relativo alle vulnerabilità:

  • Caso di errore: il risultato della vulnerabilità viola le regole di firma della vulnerabilità. Questa build non va a buon fine e non viene creata alcuna attestazione.
  • Caso di successo: il risultato della vulnerabilità soddisfa le regole di firma della vulnerabilità. Questa build è riuscita e viene creata un'attestazione.

Invia la build di esempio del caso di errore

In questa sezione, crei un'immagine container e la scansioni per rilevare eventuali vulnerabilità. La compilazione non riesce perché l'immagine del contenitore si basa su un'istantanea specifica di Debian 10, che contiene una serie di vulnerabilità con livello di gravità HIGH. Queste vulnerabilità violano la regola di firma delle vulnerabilità. Di conseguenza, il compilatore non genera un'attestazione.

  1. (Facoltativo) Visualizza il file del criterio di firma della vulnerabilità per la richiesta di errore.

    cat samples/signer/policy-strict.yaml
    
  2. Invia la build:

    gcloud builds submit \
      --substitutions=_KMS_KEY_NAME=$KMS_KEY_NAME,_KMS_DIGEST_ALG=$KMS_DIGEST_ALG,_NOTE_NAME=$NOTE_NAME \
      --config=samples/signer/cloudbuild-bad.yaml samples/signer
    

    Viene visualizzato un output simile al seguente:

    "ERROR: (gcloud.builds.submit) build BUILD_ID completed with status "FAILURE"
    
  3. Salva l'ID build dell'ultima build:

    export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
    
  4. Verifica il risultato:

     gcloud storage cat gs://${PROJECT_NUMBER}.cloudbuild-logs.googleusercontent.com/log-${BUILD_ID}.txt | grep "does not pass VulnzSigningPolicy"
    

Invia la build di esempio della richiesta di assistenza andata a buon fine

In questa sezione crei un'immagine contenitore contenente vulnerabilità che non violano le regole di firma delle vulnerabilità. In questo caso, il compilatore personalizzato di Kritis Signer crea un'attestazione.

Per inviare la build di esempio del caso di successo a Cloud Build, segui questi passaggi:

  1. (Facoltativo) Visualizza il file delle norme di firma delle vulnerabilità per la richiesta di successo.

    cat samples/signer/policy-loose.yaml
    
  2. Invia la build:

    gcloud builds submit \
      --substitutions=_KMS_KEY_NAME=$KMS_KEY_NAME,_KMS_DIGEST_ALG=$KMS_DIGEST_ALG,_NOTE_NAME=$NOTE_NAME \
      --config=samples/signer/cloudbuild-good.yaml samples/signer
    
  3. Salva l'ID build dell'ultima build:

    export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
    
  4. Verifica il risultato:

    gcloud builds describe $BUILD_ID | grep status
    

Utilizzare Kritis Signer in modalità solo controllo

Questa sezione mostra come utilizzare Kritis Signer in modalità check-only. In questa modalità, Kritis Signer non crea un'attestazione. Controlla solo se l'immagine presenta vulnerabilità prima di completare o interrompere il passaggio di compilazione in base alle regole di firma delle vulnerabilità.

Invia la build di esempio del caso di errore

  1. (Facoltativo) Visualizza il file del criterio di firma della vulnerabilità per la richiesta di errore.

    cat samples/policy-check/policy-strict.yaml
    

    Nel passaggio di compilazione di Kritis Signer, tieni presente che il flag mode è impostato su check-only.

  2. Invia la build:

    gcloud builds submit \
      --config=samples/policy-check/cloudbuild-bad.yaml samples/policy-check
    

    Tieni presente che la compilazione non va a buon fine.

  3. Salva l'ID build dell'ultima build:

    export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
    
  4. Verifica il risultato:

     gcloud storage cat gs://${PROJECT_NUMBER}.cloudbuild-logs.googleusercontent.com/log-${BUILD_ID}.txt | grep "does not pass VulnzSigningPolicy"
    

Invia la build di esempio della richiesta di assistenza andata a buon fine

  1. (Facoltativo) Visualizza il file delle norme di firma delle vulnerabilità per la richiesta di successo.

    cat samples/policy-check/policy-loose.yaml
    
  2. Invia la build:

    gcloud builds submit \
     --config=samples/policy-check/cloudbuild-good.yaml samples/policy-check
    
  3. Salva l'ID build dell'ultima build:

    export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
    
  4. Verifica il risultato:

    gcloud builds describe $BUILD_ID | grep status
    

Creare un attestatore

Per creare un criterio che richieda le attestazioni create utilizzando il metodo descritto in questa guida, devi prima creare un attestatore.

Per creare un attestatore:

  1. Recupera il materiale della chiave pubblica dalla chiave Cloud KMS che hai creato in precedenza in questa guida:

    gcloud kms keys versions get-public-key 1 \
    --key KEY_NAME \
    --keyring KEY_RING \
    --location global \
    --output-file OUTPUT_PATH
    
    • KEY_NAME: il nome della chiave
    • KEY_RING: il nome della chiave automatizzata
    • OUTPUT_PATH: un percorso file, ad esempio my-key.pem
  2. Crea un attestatore utilizzando il materiale della chiave pubblica nel file e la nota che hai creato in precedenza in questa guida. Puoi creare un attestatore tramite la console Google Cloud o gcloud CLI.

  3. Crea un criterio che richieda le attestazioni e fornisci l'attestatore che hai creato in questa sezione. Puoi creare un criterio tramite la console Google Cloud o la CLI gcloud.

Creare un'attestazione

Per creare un'attestazione utilizzando l'attestatore, consulta Creare un'attestazione utilizzando Cloud KMS.

Esegui la pulizia

Per eliminare le risorse utilizzate in questo documento, puoi eliminare il progetto:

gcloud projects delete ${PROJECT_ID}

Passaggi successivi