Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica della convalida continua

La convalida continua (CV) con i criteri della piattaforma basati su controlli è una funzionalità di Autorizzazione binaria che consente di monitorare i pod eseguiti 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 la CV determina che i pod violano i criteri della piattaforma, registra le violazioni in Cloud Logging.

Il CV con criteri della piattaforma prevale sulla convalida continua legacy (deprecata).

Perché utilizzare il CV?

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

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

Il CV è utile nei seguenti scenari:

Modifiche ai criteri: quando aggiorni i criteri di applicazionedi Autorizzazione binaria, Autorizzazione binaria convalida solo le immagini di cui è stato 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, ora blocca il deployment della stessa immagine.

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

Come funziona il CV

Per utilizzare CV, devi abilitarlo sui tuoi cluster GKE.

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

Il CV non supporta 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 ciascun pod almeno ogni 24 ore. Il CV monitora anche i container init.

Durante ogni revisione, il CV recupera un elenco di immagini associate a ciascun pod. Il CV verifica quindi che le informazioni dell'immagine soddisfino i criteri della piattaforma.

Violazioni dei criteri della piattaforma nei log CV

Quando il 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 ogni pod.

Quando il CV valuta le immagini di un pod utilizzando un criterio della piattaforma, le immagini potrebbero soddisfare alcuni controlli e violarne altri. Il CV genera una voce di log ogni volta che un'immagine di un pod viola uno o più controlli. La voce di log contiene solo le immagini che violano i criteri della piattaforma. Se tutte le immagini soddisfano tutti i controlli, non vengono generate voci di log.

Fino a quando non viene terminato un pod con immagini non conformi ai criteri, il CV continua a registrare violazioni dei criteri. I pod non conformi ai criteri terminati durante l'intervallo tra i controlli vengono registrati durante la successiva revisione del CV.

Il 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 feed denominata binauthz-cv-cai-feed.

Norme relative alla piattaforma CV

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

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

I criteri della piattaforma funzionano solo con il 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 del CV, ti consigliamo di creare un criterio a livello di singolo progetto per l'applicazione e un criterio della piattaforma per il monitoraggio.

Ad esempio, supponi di voler configurare Autorizzazione binaria in modo che le immagini dispongano di un'attestazione prima del relativo deployment e vuoi anche assicurarti che i pod in esecuzione siano conformi allo stesso requisito. Per farlo, devi configurare un criterio di applicazione a livello di singolo progetto con un attestatore. Puoi quindi creare un criterio della piattaforma con un semplice controllo dell'attestazione di firma in cui un autenticatore si basa sulla stessa nota e sulla stessa 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 avere il 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 describe il criterio esistente, salvarlo in un file YAML, aggiungere il nuovo controllo e quindi aggiornare il criterio utilizzando il file aggiornato.

Più criteri 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 più criteri della piattaforma, assegna a ciascuno un nome di 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 il criterio della piattaforma da associare a ogni cluster GKE, che si tratti di un criterio della piattaforma locale o di un criterio in un altro progetto.

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 solo 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 di lista consentita delle immagini esenti. Per saperne di più, vedi Immagini esenti.

Configurazione di un singolo progetto

Puoi impostare il CV in un singolo progetto.

In una configurazione a progetto singolo, Autorizzazione binaria configura 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 richiesti ruoli aggiuntivi di Identity and Access Management (IAM).

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

Configurazione con più progetti

Quando configuri una configurazione CV multiprogetto 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 multiprogetto, è importante conoscere lo scopo di ogni progetto e le risorse a cui il CV deve accedere e configurare di conseguenza i ruoli e le autorizzazioni IAM richiesti.

Come usare il CV

Per utilizzare il CV, in genere:

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

Checks

Questa sezione descrive i controlli specifici forniti dal 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 in caso di violazioni dei criteri dei log CV. È omesso in alcuni degli esempi più avanti in questa guida.

Nega sempre controllo

Il controllo Always-Deny garantisce che tutte le immagini soggette a questo controllo non superino la valutazione. Ogni volta che il CV esamina i pod in esecuzione con questo controllo, produce una voce di log per ciascuno dei pod.

Puoi combinare il controllo Always-Deny con liste consentite o più set di controlli per assicurarti che Autorizzazione binaria generi sempre log per i pod in determinati casi.

Per utilizzare il controllo Always-Deny, 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 Always-Deny, consulta Utilizzare più insiemi di controlli.

Controllo di aggiornamento delle immagini

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

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

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

Controllo semplice dell'attestazione di firma

Puoi utilizzare il controllo dell'attestazione di firma semplice del CV per verificare che ciascuna 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 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

Al posto 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 è soddisfatto quando ogni immagine dei pod ha un'attestazione valida firmata con una chiave any in pkixPublicKeySet dell'autenticatore qualsiasi.

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

Le chiavi PGP non sono supportate.
Gli attestatori non sono necessari. Puoi invece creare le chiavi manualmente e poi describe un criterio della piattaforma per recuperare l'ID chiave che utilizzerai 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.
È comunque possibile creare una nota Artifact Analysis, ma non specificarla nel criterio. Il CV cerca invece le attestazioni in ogni progetto elencato nel campo containerAnalysisAttestationProjects.
Le attestazioni sono ancora 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.

Il 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é con un digest, il CV le valuta prima di tutto a fronte di immagini esenti, poiché le liste consentite possono includere tag. Se l'immagine non è esente, il CV prova a trovare il digest dell'immagine. Poiché non c'è nessuno, l'immagine viola il controllo.

Controllo SLSA

Il controllo SLSA verifica la provenienza specificata SLSA delle immagini dei pod.

Di seguito è riportato un esempio di configurazione YAML dei criteri 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, verifica quanto segue:

Le immagini devono essere state create da un builder affidabile. 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 sue sottodirectory (non create da Cloud Build) sono esenti dal controllo in quanto violerebbero.

Controllo della firma di 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 le firme recuperate da Artifact Registry possono essere verificate correttamente da qualsiasi chiave nel criterio.

Il seguente esempio di criterio della piattaforma descrive come configurare un controllo della firma del negozio 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 viene soddisfatto quando ciascuna immagine dei pod ha un'attestazione valida firmata con una chiave qualsiasi nel campo publicKeySet dell'autenticatore qualsiasi.

Controllo directory attendibile

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

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

Il criterio della piattaforma di esempio riportato di seguito 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 risiedono nelle directory elencate, sono conformi al criterio. Le immagini dei pod che non risiedono nelle directory elencate violano il criterio 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 dei pod contengono vulnerabilità. Ciò include le nuove vulnerabilità identificate dall'analisi delle vulnerabilità dopo il deployment del pod. Nel controllo delle vulnerabilità, puoi configurare soglie del livello di gravità della 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.

La seguente configurazione dei criteri della piattaforma di esempio 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 sistema CVSS (Common Vulnerability Scoring System) associati a qualsiasi vulnerabilità che Artifact Analysis può identificare. Inoltre, blockedCves elenca specifiche esposizioni di 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, esamina sia i criteri singleton del progetto di Autorizzazione binaria sia i criteri della piattaforma CV.

Convalida operazione

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 di set di controlli è esente dal set di controlli e si applica solo quando questo set di controlli viene valutato. Una lista consentita all'interno di un controllo 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 di un'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 prefisso di tag con il carattere jolly *).
Il nome di un'immagine con un digest.
Il nome di un'immagine con un tag e 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 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 (come 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 qualsiasi nome con un determinato prefisso. * corrisponde a 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 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, solo * o ** non sono un pattern valido, così come non lo è 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 dei 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 controlli:

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 in imageAllowlist sono esenti da tutti i controlli elencati in checkSets.

esenzione a livello di controllo

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ù insiemi di controlli

Un criterio basato su controllo CV può contenere più di un insieme di controlli. Il CV valuta un insieme di controlli ogni volta che valuta il criterio. Puoi considerare gli insiemi di controlli come criteri secondari che devono essere valutati in diverse situazioni. Ad esempio, se vuoi applicare controlli diversi negli ambienti di sviluppo rispetto agli ambienti di produzione, puoi inserirli in un set di controlli separato, uno che viene valutato solo nell'ambiente di sviluppo e l'altro 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 controllo 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 CV utilizza solo un set di controlli predefinito.

La seguente configurazione dei criteri di esempio configura tre insiemi 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 set di controlli è limitato all'ambito prod-namespace, pertanto i relativi controlli interessano solo i pod in esecuzione in quell'ambito. Il secondo set di controlli ha come ambito dev-namespace, perciò i relativi controlli interessano solo i pod in esecuzione in quell'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 la CV valuta il set di controlli denominato Prod check set, controlla quanto segue per verificare la presenza di immagini dei pod in esecuzione nello spazio dei nomi Kubernetes prod-namespace:

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

Quando il CV valuta il set di controlli denominato Dev check set, valuta i pod in esecuzione nello spazio dei nomi Kubernetes dev-namespace, verificando 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 il 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.

Controlla che gli ambiti impostati abbiano le seguenti regole:

È possibile impostare un solo controllo per ambito in un criterio della piattaforma.
Se un criterio contiene set di controlli basati sullo spazio dei nomi e sugli account di servizio, il set di controlli deve essere elencato per primo, seguito dal set di controlli basato sullo spazio dei nomi.
È possibile impostare un solo controllo predefinito, che deve essere elencato per ultimo.

Se un criterio della piattaforma contiene dei 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 produce voci di log.

CV legacy

Questa sezione descrive i criteri precedenti di CV. Se non hai mai utilizzato il CV, ti consigliamo di utilizzare invece il CV con criteri basati su controlli.

Per supportare gli utenti CV legacy, è possibile abilitare i CV sui progetti che eseguono GKE. Il 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 le variabili personalizzate (CV) legacy (deprecate) e visualizzare gli eventi CV legacy in Cloud Logging.