Creare attestazioni con Kritis Signer

Questo tutorial spiega come creare 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 in grado di 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 verificare la presenza di vulnerabilità identificate da Artifact Analysis.

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

In questo tutorial eseguirai una build una tantum del builder personalizzato Kritis Signer, quindi eseguirai 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 sul criterio.

Nel passaggio di creazione di controllo e firma di ogni pipeline, Kritis Signer svolge le seguenti operazioni:

  1. Scansiona l'immagine appena creata con Artifact Analysis e recupera un elenco di vulnerabilità.
  2. Controlla l'elenco di vulnerabilità rispetto alle regole di firma delle vulnerabilità nel criterio, quindi:
    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, il sistema di applicazione di Autorizzazione binaria verifica la presenza di un'attestazione verificabile. In caso contrario, l'applicazione forzata non consente il deployment dell'immagine.

Questo tutorial spiega anche come eseguire Kritis Signer in modalità di solo controllo in una pipeline Cloud Build. In questa modalità, Kritis Signer non crea un'attestazione, ma controlla solo se i risultati della vulnerabilità soddisfano le regole di firma delle vulnerabilità nel criterio. Se ciò avviene, il passaggio di build di Kritis Signer ha esito positivo 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 builder personalizzato di Cloud Build.
  2. Visualizza un criterio contenente regole di firma delle vulnerabilità.
  3. Esegui Kritis Signer per creare attestazioni basate sui risultati dell'analisi delle vulnerabilità.
  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 del sistema una tantum.

configura l'ambiente

  1. Archivia il tuo 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 di 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 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

Configura i ruoli IAM

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

  • containeranalysis.notes.editor: aggiunge il ruolo Editor note di Artifact Analysis per gestire l'attestatore.
  • containeranalysis.notes.occurrences.viewer: aggiunge il ruolo Artifact Analysis Occurrences for Notes per gestire sia le occorrenze di vulnerabilità sia quelle di attestazione.
  • roles/containeranalysis.occurrences.editor: aggiunge il ruolo Editor occorrenze di Artifact Analysis 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 generatore personalizzato di Kritis Signer. Dopo aver ottenuto, creato ed eseguito il push di Kritis Signer, puoi utilizzarla in qualsiasi pipeline di Cloud Build.

Questa sezione mostra come:

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

Esegui i comandi seguenti 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 di Cloud Build che viene utilizzato da Cloud Build per creare il builder personalizzato Kritis Signer.
    • Un criterio di esempio contenente regole di firma delle vulnerabilità.
    • Esempio di file di configurazione di Cloud Build. 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 builder personalizzato Kritis Signer.

    Questo passaggio di configurazione da eseguire una sola volta crea il builder personalizzato Kritis Signer e lo registra con Cloud Build. Una volta registrato, il builder personalizzato è disponibile per l'uso in qualsiasi pipeline di 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 ad Artifact Analysis di scansionare l'immagine per rilevare le vulnerabilità. Al termine della scansione, Kritis Signer controlla che i risultati di vulnerabilità vengano restituiti alle regole di firma delle vulnerabilità presenti nel criterio.

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 da creare incondizionatamente (ALLOW_ALL) o non creare un'attestazione (BLOCK_ALL).

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

cat samples/signer/policy-strict.yaml

La norma è simile alla seguente:

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) rispetto alle quali Kritis Signer crea le attestazioni. maximumUnfixableSeverity definisce la soglia di gravità per la quale una correzione non è attualmente disponibile. maximumFixableSeverity definisce la soglia di gravità per la quale è attualmente disponibile una correzione. maximumUnfixableSeverity e maximumFixableSeverity possono essere impostati ciascuno su uno dei seguenti livelli di gravità:

    • CRITICAL
    • HIGH
    • MEDIUM
    • LOW

    Per saperne di più sui livelli di gravità, consulta Livelli di gravità.

    In alternativa, puoi impostare maximumUnfixableSeverity e maximumFixableSeverity come 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 nota di Artifact Analysis per CVE. Scopri di più sulle origini di vulnerabilità di Artifact Analysis. Per ulteriori informazioni sulle note, consulta la sezione Archiviazione dei metadati.

Crea una chiave di firma di Cloud KMS

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

  1. Crea un nuovo keyring 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 del 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 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}

Crea attestazioni con Kritis Signer in una pipeline Cloud Build

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

I passaggi seguenti mostrano il funzionamento di Kritis Signer utilizzando i file di configurazione della build di esempio nel repository di Kritis Signer. Ogni file di configurazione di esempio contiene i 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 in Container Registry.

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

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

Dovrai inviare ciascuna delle build di esempio a Cloud Build. Ogni build produce un risultato di vulnerabilità:

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

Invia la build di esempio in caso di errore

In questa sezione creerai un'immagine container e ne eseguirai la scansione per rilevare eventuali vulnerabilità. La build non riesce perché l'immagine container si basa su uno snapshot specifico 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 builder non produce un'attestazione.

  1. (Facoltativo) Visualizza il file dei criteri 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

    Verrà 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:

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

Invia la build di esempio relativa ai casi di successo

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

Per inviare la build di esempio con caso di successo a Cloud Build:

  1. (Facoltativo) Visualizza il file dei criteri di firma delle vulnerabilità per il caso di esito positivo.

    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à di solo controllo

Questa sezione mostra come utilizzare Kritis Signer in modalità check-only. In questa modalità, Kritis Signer non crea un'attestazione. Verifica la presenza di vulnerabilità nell'immagine solo prima di completare o non completare il passaggio di build in base alle regole di firma delle vulnerabilità.

Invia la build di esempio in caso di errore

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

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

    Nel passaggio di build 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 ha esito negativo.

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

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

  4. Verifica il risultato:

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

Invia la build di esempio relativa ai casi di successo

  1. (Facoltativo) Visualizza il file dei criteri di firma delle vulnerabilità per il caso di esito positivo.

    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

Crea 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: 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 la nota creata in precedenza in questa guida. Puoi creare un attestatore tramite la console Google Cloud o gcloud CLI.

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

Crea un'attestazione

Per creare un'attestazione utilizzando l'attestatore, vedi Creare un'attestazione con 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