Utilizzare il controllo SLSA

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

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

L'esempio in questa guida utilizza Cloud Source Repositories per il codice sorgente repository, Artifact Registry per il registro delle immagini e Cloud Build per creare l'immagine e produrre 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 CV è disponibile senza costi durante la fase di anteprima
  • Cloud Build
  • Cloud Source Repositories
  • GKE

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza Calcolatore prezzi.

Prima di iniziare

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
  2. Install the Google Cloud CLI.

  3. To initialize the gcloud CLI, run the following command: 

    gcloud init

  4. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  5. Make sure that billing is enabled for your Google Cloud project.

  6. Enable the Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories APIs: 

    gcloud services enable artifactregistry.googleapis.com binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com
  7. Install the Google Cloud CLI.

  8. To initialize the gcloud CLI, run the following command: 

    gcloud init

  9. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  10. Make sure that billing is enabled for your Google Cloud project.

  11. Enable the Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories APIs: 

    gcloud services enable artifactregistry.googleapis.com binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com
  12. Assicurati che la CLI gcloud sia aggiornata all'ultima versione.
  13. Installa lo strumento a riga di comando kubectl.
  14. 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.

Ruoli obbligatori

Questa sezione mostra come impostare i ruoli per questo controllo.

Panoramica

Se pubblichi tutti i prodotti menzionati in questa guida nello stesso non devi impostare alcuna autorizzazione. L'autorizzazione di codice 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 del CV, chiedi all'amministratore di concedere all'agente di servizio di autorizzazione binaria in ogni progetto i seguenti ruoli IAM:

  • Lettore Artifact Registry (roles/artifactregistry.reader) sull'account di servizio Compute Engine del progetto cluster
  • Se il progetto del cluster è diverso dal progetto dei criteri: Valutatore criteri di autorizzazione binaria (roles/binaryauthorization.policyEvaluator) sull'agente di servizio di Autorizzazione binaria del progetto cluster, affinché possa accedere al progetto dei criteri
  • Se il progetto di attestazione è diverso dal progetto dei criteri: Visualizzatore occorrenze Container Analysis (roles/containeranalysis.occurrences.viewer) sull'agente di servizio di Autorizzazione binaria del progetto di criteri, affinché possa accedere al progetto di attestazione

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

L'amministratore potrebbe anche essere in grado di assegnare all'agente di servizio di autorizzazione binaria in ogni progetto le autorizzazioni richieste tramite ruoli personalizzati o altri ruoli predefiniti.

Concedi ruoli utilizzando gcloud CLI

Per garantire che gli account di servizio in ogni progetto dispongano delle risorse necessarie autorizzazioni per valutare questo controllo, concedi agli account di servizio in ogni progetto i seguenti ruoli IAM:

  1. Se il progetto in cui esegui il cluster è diverso da quello in cui risiede il criterio, devi concedere all'agente di servizio di Autorizzazione binaria del progetto del cluster l'autorizzazione per accedere al criterio nel progetto del criterio.

    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.iam.gserviceaccount.com"

      Sostituisci CLUSTER_PROJECT_ID con l'ID del progetto del cluster.

    2. Consenti a CV di valutare il criterio nel 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 il criterio.

  2. Consenti all'agente di servizio del progetto di criteri di accedere alle attestazioni:

    1. Ottenere l'agente di servizio di Autorizzazione binaria associato al criterio progetto:

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

      Sostituisci POLICY_PROJECT_ID con l'ID del progetto che contiene il criterio.

    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. Consenti all'autorizzazione predefinita dell'account di servizio Compute Engine di eseguire il pull un'immagine dal repository:

    1. Recupera l'account di servizio Compute Engine associato progetto cluster:

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

      Sostituisci CLUSTER_PROJECT_ID con l'ID del progetto cluster che contiene il tuo criterio.

    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 che archivia le immagini da eseguire il deployment.

(Facoltativo) Crea e carica un'immagine di esempio

Questa sezione è inclusa a scopo illustrativo, allo scopo di mostrare come creare un immagine di esempio con provenienza conforme a SLSA. La provenienza viene utilizzata in seguito la guida per dimostrare il controllo. Scopri di più sulla provenienza 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 localmente:

    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 compilazione, 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 posizione di Artifact Registry, per 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, per 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 usare 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 dell'accesso di Artifact Registry. Per saperne di più su Cloud Build, consulta Panoramica di Cloud Build.

Per creare il repository:

  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: ID progetto dell'artefatto
    • LOCATION: la posizione di Artifact Registry, per 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 repository del codice sorgente nome
    • SOURCE_REPO_PROJECT_ID: l'ID progetto Cloud Build
    • LOCATION: la località

  3. Per attivare una build, esegui il push dei file che hai creato in precedenza guida.

    git push

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

  4. Per controllare l'ultima immagine e ottenerne il digest, segui questi passaggi:

    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 posizione di Artifact Registry
      • ARTIFACT_PROJECT_ID: l'ID progetto per gli elementi
      • ARTIFACT_REPO_NAME: il nome del repository
      • DIRECTORY: la directory

    2. Copia il digest dell'immagine più recente. Il digest è simile a: quanto segue: 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: ID progetto per gli artefatti
    • LOCATION: la posizione di Artifact Registry
    • ARTIFACT_REPO_NAME: il repository degli artefatti nome
    • 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 personalizzata. Se l'output non contiene il blocco, verifica che Cloud Build sia stato invocato da un attivatore di compilazione. Cloud Build non produce informazioni sulla provenienza quando manualmente.

Crea un criterio relativo alla piattaforma

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

Per creare un criterio della piattaforma con un controllo SLSA, segui questi passaggi:

  1. Crea il file YAML dei criteri 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 delle norme.
    • 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 dell'immagine.
    • EXEMPT_IMAGE_PATH: un percorso facoltativo a una o più immagini esenti, ad esempio not-built-by-cloud-build. Il blocco imageAllowlist è incluso in queste norme della piattaforma in modo da poter esentare le immagini prive di provenienza in modo che non violino le norme della piattaforma. Se invece vuoi registrare le violazioni da queste immagini, ometti questo blocco.
    • ATTESTATION_PROJECT_ID: l'ID progetto che per archiviare 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 dell'immagine. A scopo illustrativo, per forzare una violazione di questo controllo, imposta SOURCE_REPO_NAME a un altro repository di codice sorgente rispetto al luogo in cui si trova l'immagine.
    • POLICY_PROJECT_ID: l'ID del progetto che contiene il criterio CV.
    • POLICY_ID: l'ID di questo criterio.

    • CEL_EXPRESSION: un'espressione CEL che fornisce vincoli aggiuntivi al criterio SLSA. Per per aggiungere un vincolo personalizzato che richieda inoltre che le immagini vengano da un percorso 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 il criterio della piattaforma:

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

    • POLICY_ID: un ID criterio della piattaforma scelto da te. Se il criterio 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 al file del criterio.
    • POLICY_PROJECT_ID: l'ID progetto del criterio.

    Esegui la persone che seguo :

    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

Attiva CV

Puoi creare un nuovo cluster o aggiornarne uno esistente per utilizzare il monitoraggio delle conversioni con criteri della piattaforma basati su controlli.

Crea un cluster che utilizza il monitoraggio CV

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

Prima di utilizzare uno qualsiasi dei dati di comando riportati di seguito, effettua le seguenti sostituzioni:

  • CLUSTER_NAME: un nome di cluster.
  • LOCATION: la posizione, ad esempio us-central1 o asia-south1.
  • POLICY_PROJECT_ID: l'ID del progetto in cui è archiviato il criterio.
  • POLICY_ID: l'ID criterio.
  • CLUSTER_PROJECT_ID: l'ID progetto del cluster.

Esegui la persone che seguo :

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 delle conversioni

In questa sezione crei un cluster che utilizza sia l'applicazione dei criteri project-singleton sia il monitoraggio dei CV con i criteri della piattaforma basati su controlli:

Prima di utilizzare uno qualsiasi dei dati di comando riportati di seguito, effettua le seguenti sostituzioni:

  • CLUSTER_NAME: un nome di cluster.
  • LOCATION: la posizione, ad esempio us-central1 o asia-south1.
  • POLICY_PROJECT_ID: l'ID del progetto in cui è archiviato il criterio.
  • POLICY_ID: l'ID criterio.
  • CLUSTER_PROJECT_ID: l'ID progetto del cluster.

Esegui la persone che seguo :

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 aggiorni un cluster in modo da utilizzare il monitoraggio dei video con criteri della piattaforma basati solo su controlli. Se nel cluster è già attivata l'applicazione dei criteri relativi ai progetti singoli, l'esecuzione di questo comando la disattiva. Valuta invece la possibilità di aggiornare il cluster con applicazione forzata Monitoraggio CV abilitato.

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 è archiviato il criterio
  • POLICY_ID: l'ID criterio
  • CLUSTER_PROJECT_ID: l'ID progetto del cluster

Esegui il seguente 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 forzata e il monitoraggio delle conversioni

In questa sezione aggiorni un cluster in modo che utilizzi il criterio di singleton progetto applicazione delle norme e monitoraggio delle conversioni con una piattaforma basata su controlli criteri.

Prima di utilizzare uno qualsiasi dei dati di comando 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 è archiviato il criterio
  • POLICY_ID: l'ID criterio
  • CLUSTER_PROJECT_ID: l'ID progetto del cluster

Esegui il seguente 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 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 è dipiegato. Poiché l'immagine è stata creata con la provenienza e da un repository di codice sorgente attendibile, non violerà il controllo SLSA del CV 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 risiede l'immagine. Puoi anche attivare manualmente la compilazione, che salta la generazione dell'origine. Controlla quindi le voci di log.

Visualizza i log per le voci del CV

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

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

Visualizzare i log degli errori di configurazione del CV

Per visualizzare i log degli errori di configurazione del CV, esegui il seguente comando:

gcloud logging read \
     --order="desc" \
     --freshness=7d \
     --project=CLUSTER_PROJECT_ID \
    'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "configErrorEvent"'

Il seguente output mostra un errore di configurazione in cui non viene trovato un criterio 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 dei criteri della piattaforma CV

Se nessuna immagine viola le norme relative alla piattaforma che hai attivato, nessuna voce vengono visualizzate nei log.

Per visualizzare le voci di log del CV degli ultimi sette giorni, esegui il seguente 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 del progetto del cluster.

Tipi di controlli

I log CV controllano le informazioni sulle violazioni in checkResults. Nella voce, il valore checkType indica il controllo. I valori per ogni controllo sono come segue:

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

Log di esempio

La voce di logging CV di esempio che segue descrive un'immagine non conforme che viola un controllo delle directory attendibili:

{
  "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 ripulire il monitoraggio dei CV configurato in precedenza in questa guida.

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

Disattivare Autorizzazione binaria in un cluster

Per disattivare l'applicazione sia di CV sia di Autorizzazione di binari nel tuo cluster, esegui il seguente 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

Disattivare il monitoraggio dei criteri basato su controlli in un cluster

Per disattivare la verifica 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 precedente flag --enable-binauthz.

Elimina il criterio

Per eliminare il criterio, esegui questo comando. Non è necessario eliminare il criterio della piattaforma basato su controlli per disattivare il controllo dei criteri basato su controlli.

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

Sostituisci quanto segue:

  • POLICY_ID: l'ID del criterio
  • POLICY_PROJECT_ID: l'ID progetto del criterio

Passaggi successivi