Crea attestazioni con Kritis Signer

Questo tutorial spiega come creare Kritis Signer. e usalo per verificare la presenza di vulnerabilità nelle immagini container prima di crearle Attestazioni di Autorizzazione binaria.

Panoramica

Kritis Signer è uno strumento a riga di comando open source che consente Attestazioni di Autorizzazione binaria basate su un il criterio che configuri. Puoi anche utilizzare Kritis Signer per creare attestazioni dopo aver controllato un'immagine per verificare la presenza di vulnerabilità identificate da Analisi degli artefatti.

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

In questo tutorial eseguirai una build una tantum della versione personalizzata di Kritis Signer Builder ed eseguire pipeline di build di esempio. Ogni pipeline di esempio contiene i seguenti passaggi di build:

  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 basata su attestazione sulle norme.

Nel passaggio di build "check-and-sign" di ogni pipeline, Kritis Signer esegue seguenti:

  1. Scansiona 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à in il criterio e quindi:
    1. Se tutte le vulnerabilità identificate soddisfano la vulnerabilità di firma, Kritis Signer crea l'attestazione.
    2. Se una delle vulnerabilità identificate viola la vulnerabilità di firma, Kritis Signer non crea l'attestazione.

Al momento del deployment, l'applicazione forzata di Autorizzazione binaria controlla se è presente l'attestazione. Senza uno, l'applicazione forzata impedisce il deployment dell'immagine.

Il tutorial spiega anche come eseguire Kritis Signer in modalità di solo controllo in un della pipeline di Cloud Build. In questa modalità, Kritis Signer non crea dell'attestazione, controlla solo se i risultati di vulnerabilità soddisfano regole di firma delle vulnerabilità nel criterio. Se lo fanno, Kritis Signer crea il passaggio ha esito positivo e la pipeline continua a essere eseguita, altrimenti il passaggio non riesce dalla pipeline stessa.

Obiettivi

In questo tutorial imparerai a:

  1. Configura Kritis Signer come builder personalizzato di Cloud Build.
  2. Visualizza un criterio che contiene regole di firma delle vulnerabilità.
  3. Esegui Kritis Signer nella creazione di attestazioni basate sull'analisi delle vulnerabilità che consentono di analizzare i dati e visualizzare i risultati.
  4. Esegui Kritis Signer in modalità di 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, eseguirai una configurazione una tantum del sistema.

Configura l'ambiente

  1. Archivia 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 sul tuo progetto Google Cloud:

    gcloud config set project $PROJECT_ID

  3. Archivia 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 la seguente comando:

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

Configura i ruoli IAM

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

  • containeranalysis.notes.editor: aggiunge la classe Ruolo di Editor note di Artifact Analysis per gestire o l'attestatore.
  • containeranalysis.notes.occurrences.viewer: aggiunge la classe Ruolo Artifact Analysis Occurrences for Notes (Occorrenze di Artifact Analysis per Note) per gestire sia e le occorrenze di vulnerabilità e attestazioni.
  • roles/containeranalysis.occurrences.editor: aggiunge la classe Analisi degli artefatti Ruolo Editor occorrenze per creare occorrenze di attestazione in Artifact Analysis.

  • cloudkms.signer: aggiunge il ruolo Firmatario CryptoKey Cloud KMS che Consente all'account di servizio di accedere al servizio di firma di 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 builder personalizzato Kritis Signer

In questa sezione, eseguirai una configurazione una tantum del prompt personalizzato di Kritis Signer Builder. Dopo avere ottenuto, creato ed eseguito il push di Kritis Signer, puoi utilizzarla in qualsiasi pipeline di Cloud Build.

In questa sezione viene illustrato come:

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

Esegui questi comandi per ottenere il codice e i file di configurazione utilizzati in questo guida:

  1. Clona il repository Kritis:

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

    Questo repository contiene:

    • Codice sorgente di Kritis che include anche Kritis Signer.
    • Un file di configurazione di Cloud Build utilizzato da Cloud Build per per creare il builder personalizzato Kritis Signer.
    • Un criterio di esempio che contiene regole di firma delle vulnerabilità.
    • Esempio di file di configurazione di Cloud Build. Ogni configurazione usa Kritis Signer in una pipeline di analisi delle vulnerabilità.

  2. Vai alla directory kritis/:

    cd kritis

  3. Crea e registra il builder personalizzato Kritis Signer.

    Questo passaggio di configurazione una tantum crea il builder personalizzato Kritis Signer e la registra con Cloud Build. Una volta registrato, lo strumento disponibili per l'uso in qualsiasi pipeline Cloud Build.

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

Visualizza un criterio esistente

Questa sezione mostra un esempio di criterio di Kritis Signer.

Questo criterio consente di configurare Kritis Signer in modo che richieda Artifact Analysis per analizzare l'immagine alla ricerca di vulnerabilità. Dopo il giorno la scansione è stata completata, i controlli di Kritis Signer hanno restituito le regole di firma delle vulnerabilità nel criterio.

Puoi modificare le regole di firma delle vulnerabilità in questo criterio per creare un basata su quanto segue:

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

Puoi anche impostare il criterio in modo da creare o meno in modo incondizionato (ALLOW_ALL) crea un'attestazione (BLOCK_ALL).

Per visualizzare il criterio di Kritis Signer, esegui questo 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 Comune Soglie di gravità Vulnerabilità ed esposizioni (CVE) a cui Kritis Signer crea attestazioni. maximumUnfixableSeverity definisce la soglia per gravità per cui una correzione non è attualmente disponibile. maximumFixableSeverity definisce la soglia di gravità per cui è attualmente disponibile una correzione. maximumUnfixableSeverity e maximumFixableSeverity possono essere impostati su uno dei seguenti livelli di gravità:

    • CRITICAL
    • HIGH
    • MEDIUM
    • LOW

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

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

    • BLOCK_ALL: l'attestazione non viene creata se sono presenti vulnerabilità identificati.
    • ALLOW_ALL: l'attestazione viene sempre creata.

  • allowlistCVEs è un elenco di CVE specifici da inserire nella lista consentita. Kritis Signer ignora CVE in questo elenco quando valuti se creare un'attestazione. Ogni voce della lista consentita deve corrispondere esattamente al valore di Artifact Analysis nome della nota per il CVE. Scopri di più su Artifact Analysis Origini delle vulnerabilità. Per ulteriori informazioni sulle note, consulta Archiviazione dei metadati.

Crea una chiave di firma di Cloud KMS

Le chiavi di Cloud Key Management Service vengono utilizzate per creare l'attestazione.

  1. Crea un nuovo keyring di Cloud KMS con il nome KEY_RING:

    gcloud kms keyrings create KEY_RING \
   --location global

  2. Crea una nuova chiave Cloud KMS denominata KEY_NAME all'interno di il keyring:

    gcloud kms keys create KEY_NAME \
    --keyring KEY_RING \
    --location global \
    --purpose "asymmetric-signing" \
    --default-algorithm "rsa-sign-pkcs1-2048-sha256"

  3. Archivia l'algoritmo digest e Cloud KMS in una variabile di ambiente per passaggi successivi:

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

Definisci il nome di una 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}

Creazione di attestazioni con Kritis Signer in una pipeline di Cloud Build

Questa sezione illustra come utilizzare Cloud Builder personalizzato di Kritis Signer per creano attestazioni di Autorizzazione binaria in base ai risultati dell'analisi delle vulnerabilità.

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

  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 a Container Registry.

  3. Un passaggio vulnsign che controlla e firma l'immagine container in base a:

    1. In attesa che Artifact Analysis restituisca la vulnerabilità sull'immagine container appena creata.
    2. Verifica dei risultati rispetto alle regole di firma delle vulnerabilità nel .
    3. Creazione dell'attestazione se i risultati soddisfano la vulnerabilità le regole del caso.

Invierai ognuna delle build di esempio a Cloud Build. Ogni build produce un risultato di vulnerabilità:

  • Caso di errore: il risultato della vulnerabilità viola la vulnerabilità regole di firma. Questa build ha esito negativo e non viene creata alcuna attestazione.
  • Caso di successo: il risultato di vulnerabilità soddisfa la vulnerabilità regole di firma. Questa build riesce e viene creata un'attestazione.

Invia la build di esempio del caso di errore

In questa sezione creerai un'immagine container e la analizzerai per individuare eventuali vulnerabilità. La build non va a buon fine perché l'immagine container si basa su uno snapshot specifico di Debian 10, che contiene un certo numero di vulnerabilità con livello di gravità HIGH. Queste vulnerabilità violano la regola di firma delle vulnerabilità. Come il generatore non produce un'attestazione.

  1. (Facoltativo) Visualizza il file del criterio di firma delle 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

    L'output visualizzato sarà simile al seguente:

    "ERROR: (gcloud.builds.submit) build BUILD_ID completed with status "FAILURE"

  3. Salva l'ID build dall'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 del caso di successo

In questa sezione creerai un'immagine container che contiene vulnerabilità che non violino le regole di firma delle vulnerabilità. In questo caso, Kritis Signer personalizzato crea un'attestazione.

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

  1. (Facoltativo) Visualizza il file del criterio di firma delle vulnerabilità per il caso 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 dall'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à di solo controllo

Questa sezione mostra come utilizzare Kritis Signer in modalità check-only. In questo , Kritis Signer non crea un'attestazione. Controlla solo l'immagine delle vulnerabilità prima di completare o meno il passaggio di build in base le regole di firma delle vulnerabilità.

Invia la build di esempio del caso di errore

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

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

    Nel passaggio di creazione 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 build non riesce.

  3. Salva l'ID build dall'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 del caso di successo

  1. (Facoltativo) Visualizza il file del criterio di firma delle vulnerabilità per il caso 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 dall'ultima build:

    export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")

  4. Verifica il risultato:

    gcloud builds describe $BUILD_ID | grep status

Crea un attestatore

Per creare un criterio che richiede le attestazioni che crei utilizzando 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 create 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: nome della chiave
    • KEY_RING: nome del keyring
    • OUTPUT_PATH: un percorso file, ad esempio my-key.pem

  2. Crea un attestatore utilizzando il materiale della chiave pubblica nel file e nella nota creato in precedenza in questa guida. Puoi creare un attestatore tramite la console Google Cloud oppure tramite gcloud CLI.

  3. Crea un criterio che richieda attestazioni e fornisca l'attestatore creati in questa sezione. Puoi creare un criterio tramite la console Google Cloud oppure gcloud CLI

Crea un'attestazione

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

Esegui la pulizia

Per eseguire la pulizia delle risorse utilizzate in questo documento, puoi eliminare il progetto:

gcloud projects delete ${PROJECT_ID}

Passaggi successivi