Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica della convalida continua

La convalida continua (CV) con criteri della piattaforma basati su controlli è 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 su controlli di Autorizzazione binaria specificati.

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

La CV con i criteri della piattaforma sostituisce la convalida continua precedente (ritirata).

Perché utilizzare il CV?

Sebbene l'applicazione dell'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, se attivi sia l'applicazione dell'Autorizzazione binaria sia la CV con criteri basati su controlli, puoi assicurarti che la conformità ai criteri sia convalidata durante l'intero ciclo di vita dell'orchestrazione.

Il CV è utile nei seguenti scenari:

Modifiche ai criteri: quando aggiorni i criteri di applicazione a livello di progetto di Autorizzazione binaria, quest'ultima convalida solo le immagini di cui viene eseguito il deployment dopo l'aggiornamento. I pod già in esecuzione non sono interessati. Continuano a essere eseguite anche se l'Autorizzazione binaria, utilizzando il criterio aggiornato, ora bloccherebbe il deployment della stessa immagine.

Per questo motivo, quando aggiorni il criterio project-singleton di Autorizzazione binaria, ti consigliamo di creare o aggiornare anche un criterio della piattaforma CV in modo che corrisponda al criterio project-singleton. In questo modo, la CV ti informa dei pod in esecuzione che violano le tue norme aggiornate.
Monitoraggio dei metadati delle immagini: CV fornisce controlli specifici per le modifiche ai metadati delle immagini, tra cui:
- Attestazioni: i log del CV vengono generati quando le attestazioni sulle immagini dei pod non sono più valide.
- Aggiornamento: il CV registra 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 si trovano in un repository di origine attendibile.
- Firme Sigstore: i log di CV vengono generati quando le immagini dei pod non contengono una firma Sigstore valida.
- Directory attendibile: i log di CV vengono generati quando le immagini dei pod si trovano in una directory del repository non elencata nelle norme della piattaforma.
- Vulnerabilità: CV registra quando vengono identificate vulnerabilità nelle immagini dei pod.
Monitoraggio della prova: quando attivi la prova, Autorizzazione binaria consente di eseguire il deployment di tutte le immagini. Se attivi CV con una norma della piattaforma che corrisponde alla norma del progetto singleton, CV registra regolarmente le immagini che violano la norma della piattaforma.
Monitoraggio di breakglass: quando esegui il deployment di pod utilizzando breakglass, l'autorizzazione binaria aggira l'applicazione dei criteri a livello di progetto e registra un singolo evento in Cloud Audit Logs. Tuttavia, utilizzando un criterio della piattaforma corrispondente, la CV continua a registrare regolarmente i pod che violano i criteri, inclusi quelli di cui è stato eseguito il deployment utilizzando breakglass.

Come funziona il CV

Per utilizzare CV, devi attivarlo sui tuoi cluster GKE.

Dopo aver eseguito il deployment delle immagini nel cluster, CV monitora i pod associati per assicurarsi che siano conformi alle norme della piattaforma basata su controlli.

CV non supporta i tag immagine, ad eccezione di 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 di inizializzazione e i container effimeri.

Durante ogni revisione, CV recupera un elenco di immagini associate a ciascun pod. Il CV verifica quindi che le informazioni sulle immagini soddisfino le norme della piattaforma.

Il CV registra le violazioni delle norme della piattaforma

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

Quando il CV valuta le immagini di un pod utilizzando le norme 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. L'elemento di log contiene solo le immagini dei pod che violano le norme della piattaforma. Se tutte le immaginisoddisfano tutti i controlli, non vengono prodotte voci di log.

Il CV continua a registrare le violazioni delle norme fino al termine di un pod con immagini non conformi alle norme. Quando i pod non conformi alle norme vengono terminati durante l'intervallo tra le convalide, le voci di log finali generate dal CV possono essere visualizzate dopo la terminazione, durante la successiva valutazione del 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 feed

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

Norme della piattaforma CV

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

I criteri della piattaforma sono diversi dai criteri di Autorizzazione binaria precedenti, chiamati anche criteri project-singleton. Sebbene il progetto di implementazione possa avere un solo criterio project-singleton precedente, puoi configurare più criteri della piattaforma. Ogni criterio della piattaforma può trovarsi in uno o più progetti.

I criteri della piattaforma funzionano solo con CV e non supportano l'applicazione dell'Autorizzazione binaria. Per questo motivo, se vuoi utilizzare sia l'applicazione dell'Autorizzazione binaria sia il monitoraggio dei CV, ti consigliamo di creare un criterio singleton per il progetto per l'applicazione e un criterio per la piattaforma per il monitoraggio.

Ad esempio, supponiamo che tu voglia configurare l'autorizzazione binaria per verificare che le immagini abbiano un'attestazione prima che sia consentito eseguire il loro deployment e che tu voglia anche assicurarti che i pod in esecuzione siano conformi allo stesso requisito. Per farlo, configura un criterio di applicazione a livello di progetto singolo con un attestatore. Poi crei un criterio della piattaforma con un semplice controllo di attestazione della firma che ha un autenticatore basato sulla stessa nota e sulla stessa chiave pubblica dell'attestatore.

Le norme della piattaforma sono specifiche per la 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 insieme di controlli può specificare uno o più controlli.

I criteri della piattaforma possono esentare le immagini dalla valutazione da parte del CV.

Autorizzazioni obbligatorie

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

Aggiornamenti delle norme

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

Più norme della piattaforma

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 di risorsa univoco. Quando esegui un comando gcloud CLI, fai riferimento al criterio della piattaforma locale utilizzando il relativo ID. Quando fai riferimento a un criterio della piattaforma in un altro progetto, utilizza il nome della risorsa nel seguente formato: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID

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

Più controlli per norma della piattaforma

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

Quando i criteri della piattaforma del CV specificano più di un controllo, le immagini valutate da un controllo continuano a essere valutate dagli altri controlli.

L'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, consulta la sezione Immagini esenti.

Configurazione di un singolo progetto

Puoi configurare il CV in un singolo progetto.

In una configurazione di un singolo progetto, Autorizzazione binaria configura automaticamente i propri ruoli obbligatori nell'agente di servizio di Autorizzazione binaria.

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

Per scoprire di più sulla configurazione di una configurazione multi-project per una maggiore sicurezza, consulta Separazione degli aspetti.

Configurazione con più progetti

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

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

Come utilizzare il CV

Per utilizzare CV, in genere devi:

Decidi quali controlli utilizzare.
Componi uno o più criteri della piattaforma utilizzando un file YAML dei criteri. Il file specifica i controlli che vuoi utilizzare.
Crea il criterio della piattaforma. Il criterio può essere archiviato in un progetto a tua scelta.
Scegli se attivare il CV su singoli cluster o su un parco risorse.
Controlla i log di CV in Logging per gli eventi.
Esamina i log e aggiorna la build e altre procedure per produrre immagini chesoddisfano i controlli.

Assegni

Questa sezione descrive i controlli specifici forniti da CV.

I criteri basati su 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 utilizzato solo quando il CV registra violazioni delle norme. Viene omesso in alcuni degli esempi riportati più avanti in questa guida.

Controllo di rifiuto sempre

Il controllo di rifiuto sempre garantisce che tutte le immagini soggette a questo controllo non superino la valutazione. Ogni volta che CV esamina i pod in esecuzione con questo controllo, produce una voce di log per ciascun pod.

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

Per utilizzare il controllo di rifiuto sempre, 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 invece il controllo.

Per esempi su come utilizzare il controllo di rifiuto sempre, consulta Utilizzare più set di controlli.

Controllo dell'aggiornamento delle immagini

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

Nel seguente esempio di file YAML dei criteri della piattaforma, CV registra i pod con le immagini caricate nel repository da cui sono stati dimessi più di 30 giorni fa.

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

Verifica di attestazione della firma semplice

Puoi utilizzare il controllo di attestazione della firma semplice del CV per verificare che ciascuna delle immagini di un pod abbia un'attestazione firmata valida.

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

Di seguito è riportato un esempio di criterio della piattaforma con un semplice controllo di 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

I controlli di attestazione del CV prevedono authenticators anziché attestatori di autorizzazione binaria. Specifica 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 ogni immagine dei pod ha un'attestazione valida firmata con qualsiasi chiave in pkixPublicKeySet di qualsiasi autenticatore.

I criteri della piattaforma CV sono diversi dai criteri di applicazione project-singleton per i seguenti motivi:

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

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

Se le immagini vengono implementate con un tag immagine anziché con un digest, CV lo valuta prima rispetto alle immagini esenti, poiché le liste consentite possono includere i tag. Se l'immagine non è esente, il CV tenta di trovare il digest dell'immagine. Poiché non esiste, l'immagine viola il controllo.

Controllo SLSA

Il controllo SLSA verifica la provenienza specificata dall'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 CV esamina le immagini utilizzando queste norme della piattaforma, controlla quanto segue:

Le immagini devono essere state create da un compilatore attendibile. Cloud Build è l'unico builder attendibile 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 di uno dei seguenti repository attendibili:
- Il repository source.cloud.google.com/my-project/my-source-repo/
- Eventuali 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 in quanto lo violerebbero.

Controllo della firma Sigstore

Il controllo delle firme Sigstore verifica che le immagini siano state firmate utilizzando le firme Sigstore.

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

Il seguente criterio della piattaforma di esempio descrive come configurare un controllo delle firme di 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 ciascuna delle immagini dei pod ha un'attestazione valida firmata con qualsiasi chiave in publicKeySet di qualsiasi autenticatore.

Controllo della directory attendibile

Il controllo delle directory attendibili verifica che le immagini dei pod si trovino in una delle directory attendibili fornite che specifichi in un criterio della piattaforma.

Quando utilizzi questo controllo, ti consigliamo di proteggere anche i repository elencati come directory attendibili nelle tue norme contro l'accesso non autorizzato.

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

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 alle norme. Le immagini dei pod che non si trovano nelle directory elencate violano le norme e il CV registra le violazioni.

Controllo delle vulnerabilità

Il controllo delle vulnerabilità utilizza l'analisi delle vulnerabilità di Artifact Analysis per verificare se le immagini di Pod contengono vulnerabilità. Sono incluse 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à della vulnerabilità e vulnerabilità specifiche (come le CVE). Le immagini con vulnerabilità che violano il controllo delle vulnerabilità vengono registrate in Logging.

Per utilizzare questo controllo, devi prima attivare analisi delle vulnerabilità in Artifact Analysis.

Il seguente esempio di configurazione delle norme della piattaforma contiene un controllo delle 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à che l'Artifact Analysis può identificare. Inoltre, blockedCves elenca vulnerabilità ed esposizioni comuni (CVE) specifiche. Se una vulnerabilità identificata supera uno dei livelli di gravità specificati o corrisponde a una delle CVE elencate in blockedCves e non corrisponde a una delle CVE elencate in allowedCves, CV registra una voce nel logging.

Convalida i criteri aggiornati

Dopo aver aggiornato le norme della piattaforma CV, ti consigliamo vivamente di verificare che l'Autorizzazione binaria e CV continuino a funzionare come previsto.

Convalida la configurazione

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

Convalida operazione

Per verificare che l'Autorizzazione binaria e la CV funzionino come previsto, puoi eseguire il deployment di pod di test e poi controllare le voci di Autorizzazione binaria nel logging.

Immagini esenti con liste consentite

Quando crei un criterio della piattaforma, puoi esentare le immagini dai controlli aggiungendo i relativi URL a una lista consentita. Una lista consentita a livello di criteri esenta le immagini dall'intera norma. Una lista consentita a livello di insieme di controlli esenta dall'insieme di controlli e si applica solo quando questo viene valutato. Una lista consentita all'interno di un controllo esenta le immagini solo da quel controllo.

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

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

Di seguito sono riportati alcuni esempi di pattern della lista consentita:

us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c corrisponde a un nome, un tag e un digest esatti 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 senza tag).
us-central1.pkg.dev/my-project/my-image corrisponde al nome, con qualsiasi tag e/o digest.

I caratteri jolly * e ** possono essere utilizzati per associare qualsiasi nome a un determinato prefisso. * corrisponde ai suffissi che non includono /. ** corrisponde ai suffissi che possono includere /, ma ** può essere utilizzato solo dopo un /. Tieni presente che * e ** non possono essere utilizzati con i tag o i 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 pattern validi, così come us-central1.pkg.dev/my-image:*.

Esenzione a livello di gkePolicy

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

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

Nelle norme, le immagini elencate in imageAllowlist sono esenti da tutti gli insieme di controlli (checkSets) elencati in gkePolicy.

Esenzione a livello di checkSet

L'esempio seguente mostra come esentare le immagini a livello di set di controlli:

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

Nelle norme, le immagini elencate in imageAllowlist sono esenti da tutti i controlli elencati in checkSets.

esenzione a livello di controlli

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

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

Utilizzare più insiemi di controlli

Un criterio basato su controlli del CV può contenere più di un insieme di controlli. Il CV valuta un insieme di controlli ogni volta che valuta il criterio. Puoi considerare i set di controlli come sottocriteri che devono essere valutati in situazioni diverse. Ad esempio, se vuoi applicare controlli diversi negli ambienti di sviluppo rispetto a quelli di produzione, puoi inserire i controlli per ciascun ambiente in un insieme di controlli separato, uno che viene valutato solo nell'ambiente di sviluppo e uno che viene valutato in produzione.

Ogni insieme di controlli è limitato a uno spazio dei nomi Kubernetes o a un account di servizio Kubernetes. L'ambito determina i pod a cui si applica il set di controllo.

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

Quando un insieme di controlli non ha ambito, si parla di insieme 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 ai CV utilizza solo un insieme di controlli predefinito.

La seguente configurazione di criteri di esempio 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, il primo insieme di controlli è limitato a prod-namespace, quindi i relativi controlli interessano solo i pod in esecuzione in questo ambito. Il secondo insieme di controlli è limitato a dev-namespace, pertanto i suoi controlli interessano solo i pod in esecuzione in questo ambito. Il terzo insieme di controlli è un insieme di controlli predefinito. I controlli si applicano a tutti i pod nel cluster in esecuzione al di fuori degli ambiti prod-namespace e dev-namespace.

Quando CV valuta l'insieme 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 vengono archiviate nella directory attendibile prod-images.
Le immagini sono state caricate negli ultimi 30 giorni.

Quando CV valuta il set di controllo 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 di rifiuto sempre garantisce 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 insieme di controlli, sostituisci la chiave kubernetesNamespace nell'esempio con kubernetesServiceAccount. Il valore ha il formato my-namespace:my-service-account.

Verifica che gli ambiti impostati abbiano le seguenti regole:

In un criterio della piattaforma può essere impostato un solo set di controlli per ambito.
Se un criterio contiene sia set di controllo basati sullo spazio dei nomi sia set di controllo basati sull'account di servizio, il set di controllo basato sull'account di servizio deve essere elencato per primo, seguito dal set di controllo basato sullo spazio dei nomi.
Può essere impostato un solo controllo predefinito, che 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 ci sono controlli da violare, CV non genera voci di log.

CV legacy

Questa sezione descrive le norme relative ai CV precedenti. Se non hai mai utilizzato la campagna video per la rete di ricerca, ti consigliamo di utilizzare la campagna video per la rete di ricerca con criteri basati su controlli.

Per supportare gli utenti di CV precedenti, CV può essere attivato nei progetti che eseguono GKE. CV utilizza quindi il criterio di applicazione dell'autorizzazione binaria per controllare tutti i pod in esecuzione su tutti i cluster del progetto, inclusi i cluster per i quali l'applicazione dell'autorizzazione binaria non è abilitata.

Scopri come utilizzare la versione precedente di CV (ritirata) e visualizzare gli eventi della versione precedente di CV in Cloud Logging.