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 sui cluster GKE in cui è abilitata la CV.

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

L'esempio in questa guida utilizza Cloud Source Repositories per il repository del codice sorgente, 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 in base all'utilizzo previsto, utilizza il 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. Se utilizzi un provider di identità (IdP) esterno, devi prima accedere a gcloud CLI con la tua identità federata.

  4. Per inizializzare gcloud CLI, esegui questo comando:

    gcloud init
  5. 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.

  6. Verify that billing is enabled for your Google Cloud project.

  7. 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
  8. Install the Google Cloud CLI.

  9. Se utilizzi un provider di identità (IdP) esterno, devi prima accedere a gcloud CLI con la tua identità federata.

  10. Per inizializzare gcloud CLI, esegui questo comando:

    gcloud init
  11. 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.

  12. Verify that billing is enabled for your Google Cloud project.

  13. 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
  14. Assicurati che gcloud CLI sia aggiornato all'ultima versione.
  15. Installa lo strumento a riga di comando kubectl.
  16. 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.
  17. 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 correttamente i ruoli quando lo attivi. Se esegui i prodotti in progetti diversi, devi impostare i ruoli come descritto in questa sezione.

    Per assicurarti che l'agente di servizio Binary Authorization in ogni progetto disponga delle autorizzazioni necessarie per valutare il controllo CV SLSA, chiedi all'amministratore di concedere all'agente di servizio Binary Authorization 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 criterio di autorizzazione binaria (roles/binaryauthorization.policyEvaluator) nell'agente di servizio di autorizzazione binaria del progetto del cluster, per accedere al progetto dei criteri
    • Se il progetto di attestazione è diverso dal progetto di criteri: Visualizzatore occorrenze Container Analysis (roles/containeranalysis.occurrences.viewer) sull'agente di servizio di autorizzazione binaria del progetto di criteri, per consentirgli di accedere al progetto di attestazione

    Per ulteriori informazioni 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 Binary Authorization in ogni progetto le autorizzazioni richieste tramite ruoli personalizzati o altri ruoli predefiniti.

    Concedi ruoli utilizzando gcloud CLI

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

    1. Se il progetto in cui esegui il cluster è diverso da quello in cui si trova il criterio, devi concedere l'autorizzazione all'agente di servizio di Autorizzazione binaria del progetto del cluster 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 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 delle 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.iam.gserviceaccount.com"
        

        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. Consenti all'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 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 la tua 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 che archivia le immagini da deployment.

    (Facoltativo) Crea e carica un'immagine di esempio

    Questa sezione è inclusa a scopo illustrativo, per mostrarti 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 di Cloud Build.

    Crea il repository di esempio

    Per creare un repository in Cloud Source Repositories:

    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, configurazione e build, procedi nel seguente modo:

      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 su 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 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 ulteriori autorizzazioni IAM. Scopri di più sul controllo dell'accesso ad Artifact Registry. Per scoprire 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: il nome del repository del codice sorgente.
      • SOURCE_REPO_PROJECT_ID: l'ID progetto Cloud Build
      • LOCATION: la posizione
    3. Attiva una build eseguendo il push dei file che hai creato in precedenza in questa guida.

      git push
      

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

    4. Per controllare l'ultima immagine e ottenere il relativo riepilogo:

      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 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 posizione 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 del 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 per il funzionamento del controllo SLSA. 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 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 delle norme.
      • ARTIFACT_LOCATION: la posizione 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 a una o più immagini esenti, ad esempio: not-built-by-cloud-build. Il blocco imageAllowlist è incluso in queste norme della piattaforma per consentirti di esonerare le immagini prive di provenienza in modo che non violino le norme della piattaforma. Per registrare invece le violazioni di queste immagini, ometti questo blocco.
      • ATTESTATION_PROJECT_ID: L'ID progetto che memorizza 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 ulteriori vincoli per le norme SLSA. Ad esempio, per aggiungere un vincolo personalizzato che richieda ulteriormente 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 policy della piattaforma a tua scelta. Se la norma 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 del file delle norme.
      • 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 criteri della piattaforma basati su controlli.

    Crea un cluster che utilizza il monitoraggio CV

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

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

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

    In questa sezione, creerai un cluster che utilizza sia l'applicazione dei criteri project-singleton sia il monitoraggio delle vulnerabilità comuni con criteri della piattaforma basati su controlli:

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

    • CLUSTER_NAME: un 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 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 in modo che utilizzi il monitoraggio CV solo con i criteri della piattaforma basati su controlli. Se il cluster ha già l'applicazione dei criteri project-singleton abilitata, l'esecuzione di questo comando la disabilita. Ti consigliamo invece di aggiornare il cluster con l'applicazione e il monitoraggio delle vulnerabilità e delle esposizioni comuni 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 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 CV

    In questa sezione, aggiornerai un cluster in modo che utilizzi sia l'applicazione dei criteri singleton del progetto sia il monitoraggio delle vulnerabilità comuni con i criteri della piattaforma basati su controlli.

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

    • CLUSTER_NAME: un 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 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 posizione 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 viene sottoposto a deployment. Poiché l'immagine è stata creata con la provenienza e da un repository di codice sorgente attendibile, non violerà il controllo SLSA 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 si trova l'immagine. Puoi anche attivare manualmente la build, che ignora la generazione della provenienza. Quindi, controlla le voci di log.

    Visualizzare i log per le voci CV

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

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

    Visualizzare i log degli errori di configurazione di CV

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

    Visualizzare le violazioni della convalida delle norme della piattaforma CV

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

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

    I log di CV controllano le informazioni sulle violazioni per 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 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 delle conversioni che hai configurato in precedenza in questa guida.

    Puoi disattivare il monitoraggio delle vulnerabilità comuni o sia Autorizzazione binaria che le vulnerabilità comuni nel tuo cluster.

    Disabilitare Autorizzazione binaria in un cluster

    Per disattivare l'applicazione sia di CV che di 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 posizione del cluster
    • CLUSTER_PROJECT_ID: l'ID progetto del cluster

    Disabilita il monitoraggio delle policy basato sui controlli in un cluster

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

    Elimina la policy

    Per eliminare la policy, esegui questo comando. Non è necessario eliminare la policy della piattaforma basata su controlli per disattivare il controllo delle policy basato 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