Utilizzare il controllo SLSA

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

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 repository di codice sorgente, Artifact Registry per il registro delle immagini e Cloud Build per creare l'immagine e determinarne la provenienza.

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

Costi

Questa guida utilizza i seguenti servizi Google Cloud:

  • Artifact Registry
  • Autorizzazione binaria, ma il 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. Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.
  2. Installa Google Cloud CLI.

  3. Per initialize gcloud CLI, esegui questo comando: 

    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. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

  6. Abilita le API Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories. 

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

  8. Per initialize gcloud CLI, esegui questo comando: 

    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. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

  11. Abilita le API Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories. 

    gcloud services enable artifactregistry.googleapis.com binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com
    12.
  12. Assicurati che gcloud CLI sia aggiornato 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 esegui nello stesso progetto tutti i prodotti menzionati in questa guida, non devi impostare alcuna autorizzazione. Autorizzazione binaria configura i ruoli correttamente quando viene abilitata. 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 CV SLSA, chiedi all'amministratore di concedere all'agente di servizio di Autorizzazione binaria in ogni progetto i seguenti ruoli IAM:

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

Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso.

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

Concedi ruoli utilizzando gcloud CLI

Per assicurarti che gli account di servizio in ogni progetto dispongano delle autorizzazioni necessarie per valutare questo controllo, concedi agli account di servizio di 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 l'autorizzazione all'agente di servizio di Autorizzazione binaria del progetto di cluster per accedere al criterio nel progetto del criterio.

    1. Recupera l'agente di servizio di Autorizzazione binaria del progetto 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 progetto del cluster.

    2. Consenti al 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 del criterio di accedere alle attestazioni:

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

      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'account di servizio Compute Engine predefinito di eseguire il pull dell'immagine dal repository:

    1. Ottieni l'account di servizio Compute Engine associato al 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 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 ospita le immagini di cui deve essere eseguito il deployment.

(Facoltativo) Crea e carica un'immagine di esempio

Questa sezione è inclusa a scopo illustrativo per mostrare come creare una semplice 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 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 tuo repository di codice sorgente, ad esempio slsa-check-test-repo
    • SOURCE_REPO_PROJECT_ID: l'ID progetto di repository

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

    1. Crea l'origine dell'immagine:

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

    2. Rendi il file eseguibile:

      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 ad 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, ad esempio us-west2, europe-central2 o asia-east1
      • ARTIFACT_PROJECT_ID: l'ID del progetto che archivia gli artefatti Artifact Registry
      • ARTIFACT_REPO_NAME: 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, potrebbe essere necessario configurare autorizzazioni IAM aggiuntive. Scopri di più sul controllo dell'accesso ad Artifact Registry. Per saperne di più su Cloud Build, consulta la 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: l'ID progetto dell'artefatto
    • LOCATION: la posizione 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: nome del repository di codice sorgente
    • SOURCE_REPO_PROJECT_ID: l'ID progetto Cloud Build
    • LOCATION: la località

  3. Per attivare una build, esegui il push dei file creati in precedenza in questa guida.

    git push

    Una volta creata l'immagine, Cloud Build genera una prova e carica l'immagine nel repository Artifact Registry.

  4. Per controllare l'immagine più recente e recuperarne la sintesi:

    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. La sintesi è 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: 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 un criterio della piattaforma

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

Per creare un criterio della piattaforma con un controllo SLSA:

  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
    displayName: My check set
EOF

    Sostituisci quanto segue:

    • POLICY_PATH: un percorso per il file dei criteri.
    • ARTIFACT_LOCATION: la posizione del repository in Artifact Registry.
    • ARTIFACT_PROJECT_ID: l'ID del progetto che contiene i tuoi artefatti.
    • ARTIFACT_REPO_NAME: il repository che contiene l'immagine.
    • EXEMPT_IMAGE_PATH: un percorso facoltativo di una o più immagini esenti, ad esempio not-built-by-cloud-build. Il blocco imageAllowlist è incluso in questo criterio della piattaforma in modo da poter escludere le immagini prive di provenienza in modo da non violare i criteri della piattaforma. Per registrare invece le violazioni da 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 il criterio del CV.
    • POLICY_ID: l'ID di questo criterio.

  2. Crea il criterio della piattaforma:

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

    • POLICY_ID: un ID criterio della piattaforma a tua scelta. 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 dei criteri.
    • POLICY_PROJECT_ID: l'ID progetto del criterio.

    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

Attiva CV

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

Creazione di un cluster che utilizza il monitoraggio CV

In questa sezione creerai un cluster che utilizza solo il monitoraggio del 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: 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 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 dei criteri project-singleton sia il monitoraggio 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: 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 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 aggiorni un cluster per utilizzare il monitoraggio del CV solo con i criteri della piattaforma basati su controlli. Se nel cluster è già abilitata l'applicazione dei criteri singleton per il progetto, l'esecuzione di questo comando la disattiva. Valuta invece la possibilità di aggiornare il cluster con l'applicazione forzata e il monitoraggio CV abilitati.

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

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

In questa sezione aggiorni un cluster per utilizzare sia l'applicazione forzata dei criteri a livello di progetto sia il monitoraggio del 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: 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 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 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'

    Viene eseguito il deployment del pod. Poiché l'immagine è stata creata con 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, ignorando la generazione della provenienza. Quindi, verifica la presenza di voci di log.

Visualizzazione dei log per le voci CV

CV registra le violazioni dei criteri della piattaforma in Cloud Logging entro 24 ore. Generalmente puoi visualizzare le voci entro un paio d'ore.

Se nessuna immagine viola i criteri della piattaforma che hai abilitato, non vengono visualizzate voci nei log.

Per visualizzare le voci di log CV relative agli 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 del CV controllano le informazioni sulla violazione in checkResults. Nella voce, il valore checkType indica il controllo. I valori di ciascun controllo sono i seguenti:

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

Esempio di log

La voce CV Logging di esempio riportata di seguito 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 ripulire il monitoraggio del CV configurato in precedenza in questa guida.

Puoi disabilitare il monitoraggio CV o sia Autorizzazione binaria sia CV nel cluster.

Disabilita Autorizzazione binaria in un cluster

Per disabilitare l'applicazione sia di CV che di Autorizzazione binaria nel 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 dei criteri basati su controlli in un cluster

Per disabilitare CV con criteri basati su controllo nel cluster e riabilitare l'applicazione forzata utilizzando il criterio di Autorizzazione binaria, esegui il comando seguente:

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 è equivalente al flag precedente --enable-binauthz.

Elimina il criterio

Per eliminare il criterio, esegui questo comando. Non è necessario eliminare il criterio della piattaforma basata su controlli per disabilitare il controllo dei criteri basati 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