Utilizzare il controllo SLSA

Questa pagina mostra come utilizzare il controllo SLSA della convalida continua (CV) di Autorizzazione binaria, che verifica la provenienza conforme a SLSA delle immagini container associate ai pod in esecuzione su cluster GKE in cui è abilitata la CV.

Per utilizzare questo controllo, devi creare immagini con Cloud Build, che produce la provenienza conforme a SLSA.

L'esempio in questa guida utilizza Cloud Source Repositories per il repository di codice sorgente, Artifact Registry per il registro delle immagini e Cloud Build per creare l'immagine e generare la provenienza.

L'unico builder attendibile supportato dal controllo SLSA è Cloud Build.

Costi

Questa guida utilizza i seguenti servizi Google Cloud :

  • Artifact Registry
  • Autorizzazione binaria, ma la CV è disponibile senza costi durante la fase di anteprima
  • Cloud Build
  • Cloud Source Repositories
  • GKE

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il calcolatore prezzi.

Prima di iniziare

  1. Installa Google Cloud CLI.

  2. Configura gcloud CLI per utilizzare la tua identità federata.

    Per saperne di più, consulta Accedi a gcloud CLI con la tua identità federata.

  3. Per inizializzare gcloud CLI, esegui questo comando: 

    gcloud init

  4. Crea o seleziona un progetto Google Cloud .

    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 cui 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.

    • Crea 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 .

  5. Verifica che la fatturazione sia attivata per il tuo progetto Google Cloud .

  6. Abilita le API Artifact Registry, Autorizzazione binaria, Cloud Build, GKE e Cloud Source Repositories, se non sono già abilitate:

    Ruoli richiesti per abilitare le API

    Per abilitare le API, devi disporre dell'autorizzazione serviceusage.services.enable. Se hai creato il progetto, probabilmente hai già questa autorizzazione tramite il ruolo Proprietario (roles/owner). In caso contrario, puoi ottenere questa autorizzazione tramite il ruolo Amministratore di Service Usage (roles/serviceusage.serviceUsageAdmin). Scopri come concedere i ruoli. 

    gcloud services enable artifactregistry.googleapis.com binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com
  7. Assicurati che gcloud CLI sia aggiornata all'ultima versione.
  8. Installa lo strumento a riga di comando kubectl.
  9. Se le policy di Autorizzazione binaria e i cluster GKE si trovano in progetti diversi, assicurati che l'Autorizzazione binaria sia abilitata in entrambi i progetti.

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 i ruoli correttamente quando la attivi. 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 SLSA CV, chiedi all'amministratore di concedere i seguenti ruoli IAM all'agente di servizio di Autorizzazione binaria in ogni progetto:

  • Artifact Registry Reader (roles/artifactregistry.reader) sul account di servizio Compute Engine del progetto del cluster
  • Se il progetto del cluster è diverso dal progetto della policy: Binary Authorization Policy Evaluator (roles/binaryauthorization.policyEvaluator) sull'agente di servizio di Autorizzazione binaria del progetto del cluster, per consentirgli di accedere al progetto della policy
  • Se il progetto di attestazione è diverso dal progetto della policy: Container Analysis Occurrences Viewer (roles/containeranalysis.occurrences.viewer) sul service agent di Autorizzazione binaria del progetto della policy, per consentirgli di accedere al progetto di attestazione

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 Autorizzazione binaria in ogni progetto le autorizzazioni richieste tramite ruoli personalizzati o altri ruoli predefiniti.

Concedi i ruoli utilizzando gcloud CLI

Per assicurarti che i service account di ogni progetto dispongano delle autorizzazioni necessarie per valutare questo controllo, concedi ai service account di ogni progetto i seguenti ruoli IAM:

  1. Se il progetto in cui esegui il cluster è diverso da quello in cui si trova la policy, devi concedere l'autorizzazione all'agente di servizio di Autorizzazione binaria del progetto del cluster per accedere alla policy nel progetto della policy.

    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."

      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 del progetto della policy di accedere alle attestazioni:

    1. Ottieni l'agente di servizio di Autorizzazione binaria associato al progetto della policy:

      PROJECT_NUMBER=$(gcloud projects list \
  --filter="projectId:POLICY_PROJECT_ID" \
  --format="value(PROJECT_NUMBER)")
POLICY_PROJECT_SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization."

      Sostituisci POLICY_PROJECT_ID con l'ID del progetto che contiene la tua policy.

    2. Concedi il ruolo:

      gcloud projects add-iam-policy-binding ATTESTATION_PROJECT_ID \
    --member="serviceAccount:$POLICY_PROJECT_SERVICE_ACCOUNT" \
    --role='roles/containeranalysis.occurrences.viewer'

      Sostituisci ATTESTATION_PROJECT_ID con l'ID del progetto che contiene le tue attestazioni.

  3. Concedi al account di servizio Compute Engine predefinito l'autorizzazione per eseguire il pull dell'immagine dal repository:

    1. Ottieni il account di servizio Compute Engine associato al progetto del cluster:

      PROJECT_NUMBER=$(gcloud projects list \
  --filter="projectId:CLUSTER_PROJECT_ID" \
  --format="value(PROJECT_NUMBER)")
COMPUTE_ENGINE_SERVICE_ACCOUNT="$PROJECT_NUMBER-compute@"

      Sostituisci CLUSTER_PROJECT_ID con l'ID del progetto del cluster che contiene la policy.

    2. Concedi il ruolo:

      gcloud projects add-iam-policy-binding ARTIFACT_PROJECT_ID \
    --member="serviceAccount:$COMPUTE_ENGINE_SERVICE_ACCOUNT" \
    --role='roles/artifactregistry.reader'

      Sostituisci ARTIFACT_PROJECT_ID con l'ID del progetto Artifact Registry in cui sono archiviate le immagini di cui eseguire il deployment.

(Facoltativo) Crea e carica un'immagine di esempio

Questa sezione è inclusa a scopo illustrativo per mostrare come creare un'immagine di esempio con provenienza conforme a SLSA. La provenienza viene utilizzata più avanti nella guida per dimostrare il controllo. Scopri di più sulla provenienza della build di Cloud Build.

Crea il repository di esempio

Per creare un repository in Cloud Source Repositories, segui questi passaggi:

  1. Crea il repository e clonalo in locale:

    gcloud source repos create SOURCE_REPO_NAME \
    --project=SOURCE_REPO_PROJECT_ID && \
gcloud source repos clone SOURCE_REPO_NAME \
    --project=SOURCE_REPO_PROJECT_ID && \
cd SOURCE_REPO_NAME

    Sostituisci quanto segue:

    • SOURCE_REPO_NAME: il nome del repository del codice sorgente, ad esempio: slsa-check-test-repo
    • SOURCE_REPO_PROJECT_ID: l'ID progetto del repository

  2. Per creare i file di origine, di configurazione e di build, segui questi passaggi:

    1. Crea l'origine dell'immagine:

      cat > quickstart.sh <<EOF
#!/bin/sh
echo "Hello, world! The time is $(date)."
sleep infinity
EOF

    2. Rendi eseguibile il file:

      chmod +x quickstart.sh

    3. Crea il file di configurazione Dockerfile:

      cat > Dockerfile <<EOF
FROM alpine
COPY quickstart.sh /
CMD ["/quickstart.sh"]
EOF

    4. Crea il file cloudbuild.yaml di Cloud Build, che esegue il push dell'immagine in Artifact Registry:

      cat > cloudbuild.yaml <<EOF
steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE', '.' ]
options:
  requestedVerifyOption: VERIFIED
images:
- 'LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE'
EOF

      Sostituisci quanto segue:

      • LOCATION: la località di Artifact Registry, ad esempio us-west2, europe-central2 o asia-east1
      • ARTIFACT_PROJECT_ID: l'ID del progetto che archivia gli artefatti di Artifact Registry
      • ARTIFACT_REPO_NAME: il nome del repository Artifact Registry, ad esempio: slsa-check-test-repo
      • DIRECTORY: la directory, ad esempio: slsa-check
      • IMAGE: il percorso dell'immagine, ad esempio: slsa-check-image

    5. Esegui il commit dei file in Cloud Source Repositories:

      git add .
git commit -a

Crea e carica l'immagine di esempio

Per semplificare l'utilizzo di questa guida, ti consigliamo di utilizzare lo stesso progetto per SOURCE_REPO_PROJECT_ID e ARTIFACT_PROJECT_ID. Se utilizzi progetti diversi, potresti dover configurare autorizzazioni IAM aggiuntive. Scopri di più sul controllo degli accessi di Artifact Registry. Per scoprire di più su Cloud Build, consulta Panoramica di Cloud Build.

Per creare il repository, segui questi passaggi:

  1. Crea il repository Artifact Registry:

    gcloud artifacts repositories create ARTIFACT_REPO_NAME \
    --project=ARTIFACT_PROJECT_ID \
    --repository-format=docker \
    --location=LOCATION \
    --description="Docker repository"

    Sostituisci quanto segue:

    • ARTIFACT_REPO_NAME: il nome del repository
    • ARTIFACT_PROJECT_ID: l'ID progetto degli artefatti
    • LOCATION: la località di Artifact Registry, ad esempio us-west2, europe-central2 o asia-east1

  2. Crea il trigger di build di Cloud Build:

    gcloud beta builds triggers create cloud-source-repositories \
    --project=SOURCE_REPO_PROJECT_ID \
    --repo=SOURCE_REPO_NAME \
    --region=LOCATION \
    --branch-pattern=.* \
    --build-config=cloudbuild.yaml

    Sostituisci quanto segue:

    • SOURCE_REPO_NAME: il nome del repository del codice sorgente
    • SOURCE_REPO_PROJECT_ID: l'ID progetto Cloud Build
    • LOCATION: la località

  3. Attiva una build eseguendo il push dei file creati in precedenza in questa guida.

    git push

    Quando l'immagine viene creata correttamente, Cloud Build genera la provenienza e carica l'immagine nel repository Artifact Registry.

  4. Per verificare la presenza dell'immagine più recente e recuperarne il digest:

    1. Assicurati che Cloud Build abbia creato l'immagine:

      gcloud artifacts docker images list LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/REPO_NAME/DIRECTORY \
    --project=ARTIFACT_PROJECT_ID \
    --sort-by=create_time

      Sostituisci quanto segue:

      • LOCATION: la località di Artifact Registry
      • ARTIFACT_PROJECT_ID: l'ID progetto per gli artefatti
      • ARTIFACT_REPO_NAME: il nome del repository
      • DIRECTORY: la directory

    2. Copia il digest dell'immagine più recente. Il digest è simile al seguente: sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59

  5. (Facoltativo) Visualizza la provenienza dell'immagine:

    gcloud artifacts docker images describe \
  LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE@DIGEST \
    --project=ARTIFACT_PROJECT_ID \
    --show-provenance

    Sostituisci quanto segue:

    • ARTIFACT_PROJECT_ID: l'ID progetto per gli artefatti
    • LOCATION: la località di Artifact Registry
    • ARTIFACT_REPO_NAME: il nome del repository di artefatti
    • DIRECTORY: la directory
    • IMAGE: il percorso dell'immagine
    • DIGEST: il digest associato all'immagine

    L'output comando è simile al seguente:

    image_summary:
  digest: sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59
  fully_qualified_digest: us-west2-docker.pkg.dev/my-project/slsa-check-repo/slsa-check-image@sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59
  registry: us-west2-docker.pkg.dev
  repository: slsa-check-repo
  slsa_build_level: 3
provenance_summary:
  provenance:
  - build:
      intotoStatement:
        _type: https://in-toto.io/Statement/v0.1
        predicateType: https://slsa.dev/provenance/v0.1
        slsaProvenance:
          builder:
            id: https://cloudbuild.googleapis.com/GoogleHostedWorker
          materials:
          - digest:
              sha1: de4e4227fff1d00d6f7785a827608627e4a369ea
            uri: git+https://source.cloud.google.com/my-project/slsa-check-source-repo
          metadata:
            ...
envelope:
  payload: eyJfdHlwZSI6I ... taW1hZ2U6dGFnMSJ9XX0=
  payloadType: application/vnd.in-toto+json
  signatures:
  - keyid: projects/verified-builder/locations/global/keyRings/attestor/cryptoKeys/provenanceSigner/cryptoKeyVersions/1
    sig: MEQCIBCCkho_re4EfAT-NBSSmAXOZlv4lU_vWzEru97tU8KmAiAKcAa99umWngzNQADmPixqYjbKjLOKQEUvrI5chSrf7g==
  - keyid: projects/verified-builder/locations/global/keyRings/attestor/cryptoKeys/builtByGCB/cryptoKeyVersions/1
    sig: MEUCIFOEq_7RpiZAB4vUlit3hkZ2yI0n37-5Y87l0JbU-EZSAiEA9TNZZcv_MnzKffTnswHWZR2DSLmYiklr5twWfIec-zo=

    L'output deve contenere il blocco provenance_summary affinché il controllo SLSA funzioni. Se l'output non contiene il blocco, verifica che Cloud Build sia stato richiamato da un trigger di build. Cloud Build non produce informazioni sulla provenienza quando viene attivato manualmente.

Crea una policy della piattaforma

Per generare la provenienza, devi utilizzare un trigger di Cloud Build per creare l'immagine, come descritto in Crea e carica l'immagine di esempio.

Per creare una policy della piattaforma con un controllo SLSA:

  1. Crea il file YAML della policy della piattaforma:

    cat > POLICY_PATH <<EOF
gkePolicy:
  checkSets:
  - checks:
    - displayName: My SLSA check
      imageAllowlist:
        # This policy exempts images that are in the following artifact registry
        allowPattern:
        - ARTIFACT_LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/EXEMPT_IMAGE_PATH/**
      slsaCheck:
        rules:
        - attestationSource:
            containerAnalysisAttestationProjects:
            - projects/ATTESTATION_PROJECT_ID
          configBasedBuildRequired: true
          trustedBuilder: GOOGLE_CLOUD_BUILD
          trustedSourceRepoPatterns:
          - source.cloud.google.com/SOURCE_REPO_PROJECT_ID/SOURCE_REPO_NAME
          customConstraints: CEL_EXPRESSION
    displayName: My check set
EOF

    Sostituisci quanto segue:

    • POLICY_PATH: un percorso per il file della policy.
    • ARTIFACT_LOCATION: la località del repository in Artifact Registry.
    • ARTIFACT_PROJECT_ID: l'ID del progetto che contiene gli artefatti.
    • ARTIFACT_REPO_NAME: il repository che contiene l'immagine.
    • EXEMPT_IMAGE_PATH: un percorso facoltativo per una o più immagini esenti, ad esempio: not-built-by-cloud-build. Il blocco imageAllowlist è incluso in questa policy della piattaforma in modo da poter esentare le immagini prive di provenienza, in modo che non violino la policy della piattaforma. Per registrare invece le violazioni di queste immagini, ometti questo blocco.
    • ATTESTATION_PROJECT_ID: l'ID progetto che archivia le attestazioni create da Cloud Build.
    • SOURCE_REPO_PROJECT_ID: l'ID del progetto che contiene il codice sorgente.
    • SOURCE_REPO_NAME: il repository che contiene l'immagine. A scopo illustrativo, per forzare una violazione di questo controllo, imposta SOURCE_REPO_NAME su un repository di codice sorgente diverso da quello in cui si trova l'immagine.
    • POLICY_PROJECT_ID: l'ID del progetto che contiene la policy CV.
    • POLICY_ID: l'ID di questa policy.

    • CEL_EXPRESSION: un'espressione CEL che fornisce vincoli aggiuntivi alla policy SLSA. Ad esempio, per aggiungere un vincolo personalizzato che richiede inoltre che le immagini provengano da un percorso di directory specifico, sostituisci CEL_EXPRESSION con la seguente espressione:

      payload.predicate.externalParameters.buildConfigSource.path != "" && payload.predicate.externalParameters.buildConfigSource.repository.contains("github.com/my-repo/my-production-repo")

  2. Crea la policy della piattaforma:

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

    • POLICY_ID: un ID della policy della piattaforma a tua scelta. Se la policy si trova in un altro progetto, puoi utilizzare il nome completo della risorsa: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID.
    • POLICY_PATH: il 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 policy della piattaforma basate su controlli.

Crea un cluster che utilizza il monitoraggio CV

In questa sezione creerai un cluster che utilizza solo il monitoraggio CV con policy della piattaforma basate su controlli.

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

  • CLUSTER_NAME: un nome per il 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 della 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 forzata e il monitoraggio CV

In questa sezione, creerai un cluster che utilizza sia l'applicazione delle policy project-singleton sia il monitoraggio CV con policy della piattaforma basate su controlli:

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

  • CLUSTER_NAME: un nome per il 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 della 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 per utilizzare il monitoraggio CV solo con policy della piattaforma basate su controlli. Se nel cluster è già abilitata l'applicazione delle policy singleton del progetto, l'esecuzione di questo comando la disabilita. Ti consigliamo invece di aggiornare il cluster con l'applicazione forzata e il monitoraggio CV abilitati.

Prima di utilizzare i dati dei comandi 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 è 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 della CV

In questa sezione aggiornerai un cluster per utilizzare sia l'applicazione delle policy singleton del progetto sia il monitoraggio CV con le policy della piattaforma basate su controlli.

Prima di utilizzare i dati dei comandi 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 è 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

Esegui il deployment dell'immagine

  1. Configura kubectl:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del tuo cluster
    • LOCATION: la località del cluster
    • CLUSTER_PROJECT_ID: l'ID progetto del cluster

  2. Esegui il deployment del pod:

    kubectl run hello-app \
    --image='LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE@DIGEST'

    Il pod è stato sottoposto a deployment. Poiché l'immagine è stata creata con la provenienza e da un repository di codice sorgente attendibile, non violerà il controllo CV SLSA e non verranno generate voci di log.

    Per forzare una violazione del controllo SLSA, puoi impostare SOURCE_REPO_NAME su un repository di codice sorgente diverso da quello in cui si trova l'immagine. Puoi anche attivare manualmente la build, saltando la generazione della provenienza. Quindi, controlla le voci di log.

Visualizza i log per le voci CV

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

CV registra gli errori e le violazioni in Cloud Logging entro 24 ore. In genere, le voci vengono visualizzate entro poche ore.

Visualizza i log degli errori di configurazione della CV

Per visualizzare i log degli errori di configurazione della 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"
}

Visualizza le violazioni della convalida delle policy della piattaforma CV

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

Per visualizzare le voci di log di 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 controlli

I log di CV controllano le informazioni sulle violazioni in 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 log CV di esempio 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 CV configurato in precedenza in questa guida.

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

Disabilita Autorizzazione binaria in un cluster

Per disattivare l'applicazione di CV e 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 località del cluster
  • CLUSTER_PROJECT_ID: l'ID progetto del cluster

Disabilita il monitoraggio delle policy basato su controlli in un cluster

Per disattivare la CV con policy basate su controlli nel cluster e riattivare l'applicazione utilizzando le norme relative all'applicazione delle norme di Autorizzazione binaria, esegui questo 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 equivale al flag precedente --enable-binauthz.

Elimina la policy

Per eliminare la policy, esegui il comando seguente. Non è necessario eliminare la policy della piattaforma basata su controlli per disattivare l'audit delle policy basate 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