Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica della convalida continua

La convalida continua (CV) con criteri della piattaforma basati su controllo è una funzionalità di Autorizzazione binaria che consente di monitorare i pod in esecuzione su Google Kubernetes Engine (GKE) per garantire che le immagini container associate continuino a essere conformi ai criteri della piattaforma basati sul controllo di Autorizzazione binaria da te specificati.

Quando CV determina che i pod violano i criteri della piattaforma, registra le violazioni in Cloud Logging.

Le variabili personalizzate con criteri della piattaforma prevalgono sulla convalida continua legacy (ritirata).

Perché usare il CV?

Sebbene l'applicazione di Autorizzazione binaria fornisca convalide delle immagini una tantum quando esegui il deployment delle immagini container, CV monitora continuamente che le immagini associate ai pod in esecuzione continuino a essere conformi ai tuoi criteri.

Per questo motivo, quando abiliti sia l'applicazione di Autorizzazione binaria sia CV con criteri basati su controlli, puoi garantire che la conformità dei criteri venga convalidata in tutto il ciclo di vita dell'orchestrazione.

Il CV è utile nei seguenti scenari:

Modifiche ai criteri: quando aggiorni i criteri di applicazione di project-singleton di Autorizzazione binaria, Autorizzazione binaria convalida solo le immagini di cui viene eseguito il deployment dopo l'aggiornamento. I pod già in esecuzione non sono interessati. Continuano a essere eseguiti anche se Autorizzazione binaria, utilizzando il criterio aggiornato, blocca il deployment della stessa immagine.

Per questo motivo, quando aggiorni il criterio del singleton progetto di Autorizzazione binaria, ti consigliamo di creare o aggiornare anche un criterio della piattaforma CV in modo che corrisponda al criterio progetto-singleton. In questo modo CV ti informa dell'esecuzione di pod che violano i tuoi criteri aggiornati.
Monitoraggio dei metadati delle immagini: il CV fornisce controlli specifici per le modifiche ai metadati delle immagini, tra cui:
- Attestazioni: i log CV quando le attestazioni sulle immagini dei pod non sono più valide.
- Aggiornamento: i log CV quando rileva che le immagini dei pod non sono più aggiornate.
- Provenienza: CV può verificare che le immagini dei pod siano state create con un builder attendibile, utilizzando configurazioni di build che risiedono in un repository di codice sorgente attendibile.
- Firme Sigstore: i log CV quando le immagini dei pod non hanno una firma Sigstore valida.
- Directory attendibile: i log CV quando le immagini dei pod si trovano in una directory del repository non elencata nel criterio della piattaforma.
- Vulnerabilità: log CV quando le vulnerabilità vengono identificate nelle immagini dei pod.
Monitoraggio dry run: quando abiliti la modalità dry run, Autorizzazione binaria consente il deployment di tutte le immagini. Se abiliti CV con un criterio della piattaforma che corrisponde al criterio del singolo progetto, CV registra regolarmente le immagini che violano il criterio della piattaforma.
Monitoraggio di emergenza: quando esegui il deployment dei pod utilizzando il deployment di emergenza, Autorizzazione binaria ignora l'applicazione dei criteri di progetto-singleton e registra un singolo evento in Cloud Audit Logs. Tuttavia, utilizzando un criterio della piattaforma corrispondente, CV continua a registrare regolarmente i pod che violano i criteri, inclusi quelli di cui è stato eseguito il deployment tramite deployment di emergenza.

Come funziona il CV

Per utilizzare CV, devi abilitarla sui tuoi cluster GKE.

Dopo aver eseguito il deployment delle immagini sul cluster, CV monitora i pod associati per assicurarsi che siano conformi al criterio della piattaforma basato sui controlli.

CV non supporta i tag immagine, diversi da quelli specificati nelle immagini esenti.

Il CV esamina regolarmente i pod in esecuzione

Per monitorare i pod in esecuzione, il CV esamina le immagini associate a ogni pod almeno ogni 24 ore. CV monitora anche i container init e temporanei.

Durante ogni revisione, CV recupera un elenco di immagini associate a ciascun pod. CV verifica quindi che le informazioni dell'immagine siano conformi ai criteri relativi alla piattaforma.

Violazioni dei log CV dei criteri della piattaforma

Quando CV determina che le immagini violano un criterio della piattaforma, registra le violazioni e altri risultati in Cloud Logging. Viene scritta una voce di log separata per ogni criterio della piattaforma violato, per ciascun pod.

Quando CV valuta le immagini di un pod utilizzando un criterio della piattaforma, le immagini potrebbero soddisfare alcuni controlli e violarne altri. CV produce una voce di log ogni volta che un'immagine di un pod viola un controllo. La voce di log contiene solo le immagini dei pod che violano il criterio della piattaforma. Se tutte le immagini soddisfano tutti i controlli, non vengono prodotte voci di log.

CV continua a registrare le violazioni dei criteri fino a quando un pod con immagini non conformi ai criteri non viene arrestato. Quando i pod non conformi ai criteri vengono terminati durante l'intervallo tra le convalide, le voci di log finali generate da CV possono essere visualizzate dopo l'arresto, durante la successiva valutazione CV.

I pod non conformi ai criteri devono essere registrati almeno una volta, anche per i pod di breve durata.

CV non termina i pod in esecuzione.

Il CV utilizza una risorsa del feed

Per recuperare informazioni sui pod in esecuzione sul tuo cluster GKE, CV crea una risorsa del feed denominata binauthz-cv-cai-feed.

Criteri della piattaforma CV

Per utilizzare CV, devi prima configurare i criteri della piattaforma.

I criteri della piattaforma sono diversi dai criteri legacy di Autorizzazione binaria, detti anche criteri di singoli progetti. Anche se il progetto di deployment può avere un solo criterio legacy di singolo progetto, puoi configurare più criteri della piattaforma. Ogni criterio della piattaforma può risiedere in uno o più progetti.

I criteri della piattaforma funzionano solo con CV e non supportano l'applicazione di Autorizzazione binaria. Per questo motivo, se vuoi utilizzare sia l'applicazione forzata di Autorizzazione binaria sia il monitoraggio degli errori di conversione, ti consigliamo di creare un criterio del singolo progetto per l'applicazione e un criterio della piattaforma per il monitoraggio.

Ad esempio, supponiamo che tu voglia configurare Autorizzazione binaria per forzare le immagini a disporre di un'attestazione prima di poterne eseguire il deployment e che tu voglia anche assicurarti che i pod in esecuzione siano conformi allo stesso requisito. Per farlo, devi configurare un criterio di applicazione su singolo progetto con un attestatore. Dovrai quindi creare un criterio della piattaforma con un semplice controllo dell'attestazione della firma che dispone di un autenticatore basato sulla stessa nota e chiave pubblica dell'attestatore.

I criteri relativi alla piattaforma sono specifici della piattaforma. GKE è l'unica piattaforma supportata.

Puoi configurare i controlli nei criteri della piattaforma. I controlli sono raggruppati in uno o più set di controlli. Ogni set di controlli può specificare uno o più controlli.

I criteri della piattaforma possono escludere le immagini dalla valutazione tramite CV.

Autorizzazioni obbligatorie

Per elencare o descrivere i criteri della piattaforma, devi disporre del ruolo binaryauthorization.policyViewer. Per creare, modificare ed eliminare i criteri della piattaforma, devi disporre del ruolo binaryauthorization.policyEditor. Per saperne di più, vedi Gestire i criteri della piattaforma.

Aggiornamenti delle norme

L'aggiornamento di un criterio della piattaforma sovrascrive il criterio esistente con un descrittore del criterio che fornisci nel file YAML. Per aggiungere un nuovo controllo a un criterio della piattaforma esistente, ti consigliamo di describe il criterio esistente, salvarlo in un file YAML, aggiungere il nuovo controllo e quindi aggiornare il criterio utilizzando il file aggiornato.

Criteri relativi a più piattaforme

Puoi creare criteri della piattaforma nello stesso progetto del cluster (un criterio della piattaforma locale) o in qualsiasi altro progetto.

Poiché puoi configurare una serie di criteri della piattaforma, assegna a ciascuno un nome con un nome risorsa univoco. Quando esegui un comando gcloud CLI, fai riferimento al criterio della piattaforma locale tramite il relativo ID. Quando fai riferimento a un criterio della piattaforma in un altro progetto, utilizzi il nome della risorsa nel seguente formato: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID

Puoi scegliere quale criterio della piattaforma associare a ciascun cluster GKE, che si tratti di un criterio della piattaforma locale o di uno in un progetto diverso.

Più controlli per criterio della piattaforma

Puoi configurare più controlli in ogni criterio della piattaforma aggiungendoli al blocco checks del criterio. Per scoprire di più sui controlli specifici che puoi configurare, consulta la sezione Controlli.

Quando il criterio della piattaforma CV specifica più di un controllo, le immagini valutate da un controllo continuano a essere valutate dagli altri controlli.

Autorizzazione binaria valuta tutti i controlli configurati nel criterio della piattaforma per ogni immagine, a meno che l'immagine non corrisponda a un pattern della lista consentita per le immagini esenti. Per ulteriori informazioni, vedi Immagini esenti.

Configurazione per un singolo progetto

Puoi impostare il CV in un singolo progetto.

In una configurazione per un singolo progetto, Autorizzazione binaria imposta automaticamente i ruoli richiesti nell'agente di servizio di Autorizzazione binaria.

Se i cluster GKE, i criteri della piattaforma associati ai cluster e i metadati richiesti dai controlli risiedono tutti nello stesso progetto, non sono necessari ruoli IAM (Identity and Access Management).

Per scoprire di più sulla configurazione di una configurazione per più progetti per una maggiore sicurezza, consulta Separazione dei problemi.

Configurazione con più progetti

Quando configuri una configurazione di conversione di annunci in più progetti con i criteri della piattaforma, i criteri della piattaforma, le immagini, il cluster GKE e altri tipi di risorse dipendenti da CV possono risiedere in un progetto diverso.

Nella configurazione multiprogetto, è importante conoscere lo scopo di ciascun progetto e le risorse a cui CV deve accedere e configurare i ruoli e le autorizzazioni IAM richiesti di conseguenza.

Come usare il CV

Per utilizzare CV, in genere devi procedere nel seguente modo:

Decidi quali controlli utilizzare.
Crea uno o più criteri della piattaforma utilizzando un file YAML dei criteri. Il file specifica quali controlli vuoi utilizzare.
Crea il criterio relativo alla piattaforma. Il criterio può essere archiviato in un progetto a tua scelta.
Scegli se abilitare la conversione continua su singoli cluster o su un parco risorse.
Controlla i log CV in Logging per eventuali eventi.
Esamina i log e aggiorna la build e altri processi per produrre immagini che soddisfano i controlli.

Checks

Questa sezione descrive i controlli specifici forniti dal CV.

I criteri basati sui controlli hanno il seguente formato canonico:

gkePolicy:
  checkSets:
  - checks:
    - CHECK_TYPE1:
        CHECK_TYPE1_PARAMETERS
      displayName: CHECK_TYPE1_DISPLAY_NAME
    - CHECK_TYPE2:
        CHECK_TYPE2_PARAMETERS
      displayName: CHECK_TYPE2_DISPLAY_NAME
    displayName: CHECK_SET_DISPLAY_NAME

Il campo displayName in checks e checkSets è facoltativo. Viene usato solo in caso di violazioni dei criteri dei log CV. viene omesso in alcuni degli esempi più avanti in questa guida.

Controllo Nega sempre

Il controllo Negativo garantisce che tutte le immagini soggette a questo controllo non vengano valutate correttamente. Ogni volta che CV esamina i pod in esecuzione con questo controllo, produce una voce di log per ciascuno dei pod.

Puoi combinare il controllo Alwaysdeny con liste consentite o più set di controllo per assicurarti che Autorizzazione binaria produca sempre i log per i pod in determinati casi.

Per utilizzare il controllo sempre negato, aggiungi alwaysDeny: true nel blocco checks, come segue:

gkePolicy:
  checkSets:
    - displayName: "My check set"
      checks:
        - alwaysDeny: true

Il valore di alwaysDeny non può essere impostato su false. Rimuovi il segno di spunta.

Per esempi di come può essere utilizzato il controllo Alwaysdeny, consulta Utilizzare più set di controlli.

Controllo dell'aggiornamento delle immagini

Il controllo di aggiornamento delle immagini calcola la durata dell'esecuzione di un'immagine e registra quando la durata supera la soglia (maxUploadAgeDays).

Nel seguente esempio YAML del criterio della piattaforma, CV registra i pod con immagini caricate nel repository da cui è stato eseguito il deployment più di 30 giorni prima.

gkePolicy:
  checkSets:
    checks:
    - imageFreshnessCheck:
        maxUploadAgeDays: 30
      displayName: "My image freshness check"
    displayName: "My check set"

Semplice controllo dell'attestazione della firma

Puoi utilizzare il controllo dell'attestazione di firma semplice di CV per verificare che ogni immagine di un pod abbia un'attestazione valida e firmata.

Questo controllo equivale alla valutazione dell'attestazione in un criterio di applicazione di Autorizzazione binaria. Puoi configurare questo controllo con le stesse note e chiavi che hai usato nell'attestatore. Ti consigliamo di utilizzare questo controllo anziché la convalida continua legacy (deprecata).

Di seguito è riportato un esempio di criterio della piattaforma con un semplice controllo dell'attestazione della firma:

gkePolicy:
  checkSets:
    checks:
      simpleSigningAttestationCheck:
        containerAnalysisAttestationProjects:
        - "projects/my-attestation-project1"
        - "projects/my-attestation-project2"
        attestationAuthenticators:
          pkixPublicKeySet:
            pkixPublicKeys:
              publicKeyPem: |
                -----BEGIN PUBLIC KEY-----
                MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
                -----END PUBLIC KEY-----
              signatureAlgorithm: ECDSA_P256_SHA256

Invece degli attestatori di Autorizzazione binaria, i controlli di attestazione CV hanno autenticatori. Puoi specificare gli autenticatori direttamente nel criterio, nel blocco attestationAuthenticators.

In un criterio della piattaforma, simpleSigningAttestationCheck può avere più attestationAuthenticators e più chiavi in ogni pkixPublicKeySet. Il controllo viene soddisfatto quando ciascuna immagine dei pod ha un'attestazione valida firmata con qualsiasi chiave nel pkixPublicKeySet di qualsiasi autenticato.

I criteri della piattaforma CV sono diversi dai criteri di applicazione di singoli progetti per i seguenti modi:

Le chiavi PGP non sono supportate.
Gli attestatori non sono necessari. Puoi invece creare manualmente le chiavi e poi describe un criterio della piattaforma per recuperare l'ID chiave da utilizzare per creare l'attestazione.
Puoi creare e firmare manualmente il payload, creare il file JSON di attestazione e creare l'attestazione utilizzando l'API Artifact Analysis.
Puoi comunque creare una nota Artifact Analysis, ma non la specifichi nel criterio. CV cerca invece le attestazioni in ogni progetto elencato nel campo containerAnalysisAttestationProjects.
Le attestazioni sono comunque archiviate nelle occorrenze di Artifact Analysis, ma possono essere archiviate in più progetti.
Devi specificare esplicitamente uno o più progetti che contengono attestazioni utilizzando il nome risorsa projects/ATTESTATION_PROJECT_ID.

CV non supporta i tag immagine, ad eccezione di quelli specificati nelle immagini esenti.

Se il deployment delle immagini viene eseguito con un tag immagine anziché un digest, CV prima valuta le immagini in base a immagini esenti, dal momento che le liste consentite possono includere tag. Se l'immagine non è esente, CV tenta di trovare il digest dell'immagine. Poiché non ce n'è una, l'immagine viola il controllo.

Controllo SLSA

Il controllo SLSA controlla la provenienza specificata da SLSA delle immagini dei pod.

Di seguito è riportato un esempio di configurazione YAML del criterio della piattaforma CV:

gkePolicy:
  checkSets:
    checks:
      imageAllowlist:
        allowPattern: "gcr.io/my-images/not-built-by-GCB/**"
    - slsaCheck:
        rules:
          trustedBuilder: GOOGLE_CLOUD_BUILD
          attestationSource:
          - containerAnalysisAttestationProjects: "projects/attestation-project1"
          - containerAnalysisAttestationProjects: "projects/attestation-project2"
          # Require that images were built using a checked-in top-level config file.
          configBasedBuildRequired: true
          # Which repos the config file can be from.
          trustedSourceRepoPatterns:
          - "source.cloud.google.com/my-project/my-source-repo"
          - "github.com/my-github-user/*"
      displayName: "My SLSA check"
    displayName: "My check set"

Quando il CV esamina le immagini utilizzando questo criterio della piattaforma, controlla quanto segue:

Le immagini devono essere state create da un generatore di fiducia. Cloud Build è l'unico builder affidabile supportato dal controllo SLSA.
Cloud Build deve aver generato le attestazioni in attestation-project1 o attestation-project2.
Le immagini devono essere create utilizzando un file di configurazione di primo livello da uno dei seguenti repository attendibili:
- Il repository source.cloud.google.com/my-project/my-source-repo/
- Qualsiasi repository in github.com/my-github-user/
Le immagini in gcr.io/my-images/not-built-by-GCB/ o nelle relative sottodirectory (che non sono state create da Cloud Build) sono esenti dal controllo perché lo violerebbero.

Controllo della firma del Sigstore

Il controllo della firma di Sigstore verifica che le immagini siano state firmate utilizzando le firme di Sigstore.

Questo controllo supporta solo le immagini ospitate in Artifact Registry. Controlla se una firma recuperata da Artifact Registry può essere verificata da qualsiasi chiave nel criterio.

Il seguente criterio di piattaforma di esempio descrive come configurare un controllo della firma Sigstore:

  gkePolicy:
    checkSets:
    - checks:
      - displayName: sigstore-signature-check
        sigstoreSignatureCheck:
          sigstoreAuthorities:
          - displayName: sigstore-authority
            publicKeySet:
              publicKeys:
                publicKeyPem: |
                  -----BEGIN PUBLIC KEY-----
                  MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
                  -----END PUBLIC KEY-----

Nel criterio della piattaforma, sigstoreSignatureCheck può avere più sigstoreAuthorities e più chiavi in ogni publicKeySet. Il controllo è soddisfatto quando ogni immagine dei pod ha un'attestazione valida firmata con qualsiasi chiave nel publicKeySet di qualsiasi autenticato.

Controllo della directory attendibile

Il controllo della directory attendibile verifica che le immagini dei pod risiedano in una delle directory attendibili fornite specificate in un criterio della piattaforma.

Se utilizzi questo controllo, ti consigliamo di salvaguardare anche i repository che elenchi come directory attendibili nel tuo criterio da accessi non autorizzati.

Il seguente criterio della piattaforma di esempio descrive come configurare un controllo delle directory attendibili:

gkePolicy:
  checkSets:
    checks:
      trustedDirectoryCheck:
        trustedDirPatterns:
        - "gcr.io/my-project/gcr-directory"
        - "us-central1-docker.pkg.dev/my-project/ar-directory"
        displayName: "My trusted directory check"
    displayName: "My check set"

Nel criterio della piattaforma di esempio, trustedDirPatterns elenca le directory attendibili. Se tutte le immagini dei pod si trovano nelle directory elencate, sono conformi al criterio. Le immagini dei pod che non risiedono nelle directory elencate violano il criterio e CV registra le violazioni.

Controllo delle vulnerabilità

Il controllo delle vulnerabilità utilizza l'analisi delle vulnerabilità di Artifact Analysis per verificare se le immagini dei pod contengono vulnerabilità. Ciò include le nuove vulnerabilità identificate dall'analisi delle vulnerabilità dal momento del deployment del pod. Nel controllo delle vulnerabilità, puoi configurare le soglie del livello di gravità di vulnerabilità e vulnerabilità specifiche (come CVE). Le immagini con vulnerabilità che violano il controllo delle vulnerabilità vengono registrate in Logging.

Per utilizzare questo controllo, devi prima abilitare l'analisi delle vulnerabilità in Artifact Analysis.

Il seguente esempio di configurazione di criteri della piattaforma contiene un controllo di vulnerabilità:

gkePolicy:
  checkSets:
    - displayName: "Default check set"
      checks:
        - vulnerabilityCheck:
           maximumFixableSeverity: MEDIUM
           maximumUnfixableSeverity: HIGH
           allowedCves:
             - "CVE-2022-11111"
             - "CVE-2022-22222"
           blockedCves:
             - "CVE-2022-33333"
             - "CVE-2022-44444"
           containerAnalysisVulnerabilityProjects: "projects/my-project"

Nell'esempio, maximumUnfixableSeverity e maximumFixableSeverity definiscono i livelli di gravità del Common Vulnerability Scoring System (CVSS) associati a qualsiasi vulnerabilità identificabile da Artifact Analysis. Inoltre, blockedCves elenca le esposizioni a vulnerabilità comuni (CVE). Se una vulnerabilità identificata supera uno dei livelli di gravità specificati o corrisponde a uno dei CVE elencati in blockedCves e non corrisponde a uno dei CVE elencati in allowedCves, CV registra una voce in Logging.

Convalida i criteri aggiornati

Dopo aver aggiornato un criterio della piattaforma CV, ti consigliamo vivamente di verificare che Autorizzazione binaria e CV continuino a funzionare come previsto.

Convalidare la configurazione

Per verificare la configurazione, controlla sia i criteri del singolo progetto di Autorizzazione binaria sia i criteri della piattaforma CV.

Operazione di convalida

Per verificare che Autorizzazione binaria e CV funzionino come previsto, puoi eseguire il deployment dei pod di test e quindi controllare le voci di Autorizzazione binaria in Logging.

Escludi immagini con liste consentite

Quando crei un criterio della piattaforma, puoi escludere le immagini dai controlli aggiungendo i relativi URL a una lista consentita. Una lista consentita a livello di criterio esclude le immagini dall'intero criterio. Una lista consentita a livello del set di controlli è esente dal set di controlli e si applica solo quando quel set di controlli viene valutato. Una lista consentita all'interno di un segno esenta le immagini solo da quel controllo.

I pattern della lista consentita sono pattern che corrispondono a uno o più URL immagine. Un pattern della lista consentita può essere uno dei seguenti:

Prefisso del nome dell'immagine che termina con il carattere jolly * o **.
Solo il nome di un'immagine, senza tag o digest.
Il nome di un'immagine con un tag (o un prefisso del tag con il carattere jolly *).
Il nome di un'immagine con un digest.
Il nome di un'immagine contenente sia un tag sia un digest.

Di seguito sono riportati alcuni esempi di pattern di liste consentite:

us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c corrisponde esattamente a nome, tag e digest dell'immagine.
us-central1.pkg.dev/my-project/my-image:latest corrisponde al nome e al tag, con qualsiasi digest (o nessun digest).
us-central1.pkg.dev/my-image:foo* corrisponde al nome e al prefisso del tag (ad esempio myimage:foo e myimage:foobar) con qualsiasi digest (o nessun digest).
us-central1.pkg.dev/my-project/my-image@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c corrisponde al nome e al digest, con qualsiasi tag (o nessun tag).
us-central1.pkg.dev/my-project/my-image corrisponde al nome, con qualsiasi tag e/o digest.

È possibile utilizzare i caratteri jolly * e ** per trovare corrispondenze di qualsiasi nome con un determinato prefisso. * corrisponde a suffissi che non includono /. ** corrisponde a suffissi che possono includere /, ma ** può essere utilizzato solo dopo un /. Tieni presente che * e ** non possono essere utilizzati con tag o digest.

Ad esempio:

us-central1.pkg.dev/my-project/my-image* corrisponde a us-central1.pkg.dev/myproject/my-image, us-central1.pkg.dev/myproject/my-image1 e us-central1.pkg.dev/myproject/my-image2, con qualsiasi tag e/o digest.
us-central1.pkg.dev/my-project/** corrisponde a us-central1.pkg.dev/myproject/my-image e us-central1.pkg.dev/my-project/some-directory/other-image, con qualsiasi tag e/o digest.

Tieni presente che i prefissi dei nomi e dei tag non devono essere vuoti. Pertanto * o ** da soli non sono un pattern valido e nemmeno us-central1.pkg.dev/my-image:*.

Esenzione a livello di gkePolicy

L'esempio seguente mostra come escludere le immagini a livello di criterio della piattaforma. Tutte le immagini nelle directory exempt-images1 e exempt-images2 e nelle relative sottodirectory sono escluse dal monitoraggio CV.

gkePolicy:
  imageAllowlist:
  - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
  - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
  checkSets:
      checks:
        ...

Nel criterio, le immagini elencate in imageAllowlist sono esenti da tutti i set di controlli (checkSets) elencati in gkePolicy.

Esenzione a livello di checkSet

L'esempio seguente mostra come escludere le immagini a livello di set di controllo:

gkePolicy:
  checkSets:
    imageAllowlist:
    - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
    - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
    checks:
      ...

Nel criterio, le immagini elencate sotto imageAllowlist sono esenti da tutti i controlli elencati in checkSets.

esenzione a livello di controlli

L'esempio seguente mostra come escludere le immagini a livello di controllo:

gkePolicy:
  checkSets:
    checks:
      imageAllowlist:
      - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
      - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
      ...

Utilizza più set di controlli

Un criterio basato su controllo CV può contenere più set di controlli. CV valuta un set di controlli ogni volta che valuta il criterio. Gli insiemi di controlli possono essere considerati come criteri secondari che devono essere valutati in situazioni diverse. Ad esempio, se vuoi applicare controlli diversi negli ambienti di sviluppo rispetto agli ambienti di produzione, puoi inserire i controlli per ogni ambiente in un set di controlli separato, uno che viene valutato solo nell'ambiente di sviluppo e uno che viene valutato in produzione.

Ogni set di controlli ha come ambito uno spazio dei nomi Kubernetes o un account di servizio Kubernetes. L'ambito determina a quali pod si applica il set di controlli.

Quando un set di controlli è configurato con un ambito, si applica solo ai pod in esecuzione in quell'ambito.

Quando un set di controlli non ha un ambito, è chiamato set di controlli predefinito, il che significa che i controlli si applicano a tutti i pod, indipendentemente dallo spazio dei nomi Kubernetes o dall'ambito dell'account di servizio.

La maggior parte dei criteri di esempio nelle guide di Visualizzazione video utilizza solo un set di controlli predefinito.

La configurazione dei criteri di esempio seguente configura tre set di controlli:

gkePolicy:
  checkSets:
    - displayName: "Prod check set"
      scope:
        kubernetesNamespace: "prod-namespace"
      checks:
        - trustedDirectoryCheck:
            trustedDirPatterns: "gcr.io/my-project/prod-images"
        - imageFreshnessCheck:
            maxUploadAgeDays: 30
    - displayName: "Dev check set"
      scope:
        kubernetesNamespace: "dev-namespace"
      checks:
        - trustedDirectoryCheck:
            trustedDirPatterns: "gcr.io/my-project/dev-images"
    - displayName: "Default check set"
      checks:
        - alwaysDeny: true

Nella configurazione di esempio, l'ambito del primo set di controlli è prod-namespace, quindi i suoi controlli interessano solo i pod in esecuzione in quell'ambito. Il secondo set di controlli ha come ambito dev-namespace, quindi i suoi controlli interessano solo i pod in esecuzione in quell'ambito. La terza serie di controlli è un insieme di controlli predefinito. I controlli vengono applicati a tutti i pod nel cluster in esecuzione al di fuori degli ambiti prod-namespace e dev-namespace.

Quando CV valuta il set di controlli denominato Prod check set, controlla quanto segue per le immagini dei pod in esecuzione nello spazio dei nomi Kubernetes prod-namespace:

Le immagini sono archiviate nella directory prod-images attendibile.
Le immagini sono state caricate negli ultimi 30 giorni.

Quando CV valuta il set di controlli denominato Dev check set, valuta i pod in esecuzione nello spazio dei nomi Kubernetes dev-namespace, controllando se le immagini nel pod provengono dalla directory dev-images.

Il set di controlli predefinito funge da catch-all. Il controllo Always deny assicura che CV registri tutti i pod in esecuzione in qualsiasi altro spazio dei nomi.

Per utilizzare un account di servizio Kubernetes come ambito di un set di controlli, sostituisci la chiave kubernetesNamespace nell'esempio con kubernetesServiceAccount. Il valore ha il formato my-namespace:my-service-account.

Verifica che gli ambiti del set abbiano le seguenti regole:

In un criterio della piattaforma può essere presente un solo set di controlli per ambito.
Se un criterio contiene set di controlli basati sia sugli spazi dei nomi che sugli account di servizio, quest'ultimo deve essere elencato per primo, seguito dal set di controlli basato sullo spazio dei nomi.
Può esistere un solo set di controlli predefiniti e deve essere elencato per ultimo.

Se un criterio della piattaforma contiene set di controlli, deve contenere almeno un set di controlli predefinito. È consentito un criterio della piattaforma senza set di controlli, ma poiché non esistono controlli da violare, CV non produce voci di log.

CV precedente

Questa sezione descrive i criteri relativi ai file CV precedenti. Se non hai mai utilizzato questo strumento, ti consigliamo di utilizzare invece CV con criteri basati sui controlli.

Per supportare gli utenti di conversione video legacy, è possibile abilitare CV nei progetti che eseguono GKE. CV utilizza quindi il criterio di applicazione di Autorizzazione binaria per controllare tutti i pod in esecuzione su tutti i cluster nel progetto, inclusi i cluster per i quali l'applicazione di Autorizzazione binaria non è abilitata.

Scopri come utilizzare CV legacy (deprecata) e visualizzare gli eventi CV legacy in Cloud Logging.