Panoramica della convalida continua

La convalida continua (CV) è 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 sui controlli di Autorizzazione binaria da te specificati.

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

La CV con criteri della piattaforma ha la precedenza sulla convalida continua precedente.

Perché utilizzare 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 la 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 applicazione di un singolo progetto di 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. L'esecuzione continua anche se Autorizzazione binaria, utilizzando il criterio aggiornato, ora blocca il deployment della stessa immagine.

Per questo motivo, quando aggiorni il criterio di singleton progetto di Autorizzazione binaria, ti consigliamo di creare o aggiornare anche un criterio della piattaforma CV in modo che corrisponda al criterio di singolo progetto. In questo modo il CV ti informa della presenza di pod in esecuzione che violano i criteri aggiornati.
Monitoraggio dei metadati dell'immagine: 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.
- Directory attendibile: registra CV quando le immagini dei pod si trovano in una directory del repository non elencata nei criteri della piattaforma.
- Vulnerabilità: registra CV quando vengono identificate delle vulnerabilità nelle immagini dei pod.
Monitoraggio della prova: quando abiliti la prova, Autorizzazione binaria consente il deployment di tutte le immagini. Se attivi il CV con un criterio della piattaforma che corrisponde a quello del singolo progetto, il CV registra regolarmente le immagini che violano i criteri della piattaforma.
Monitoraggio di deployment di emergenza: quando esegui il deployment di pod utilizzando il deployment di emergenza, Autorizzazione binaria ignora l'applicazione dei criteri di singolo progetto e registra un singolo evento negli Cloud Audit Logs. Utilizzando un criterio della piattaforma corrispondente, tuttavia, il 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 abilitarlo sui tuoi cluster GKE.

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

La 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 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 siano conformi ai criteri della piattaforma.

Violazioni dei log CV delle norme della piattaforma

Quando il CV stabilisce che le immagini violano i criteri della piattaforma, registra le violazioni e altri risultati su Cloud Logging.

Quando CV valuta le immagini di un pod utilizzando un criterio della piattaforma, le immagini potrebbero soddisfare alcuni controlli e violarne altri. La CV produce una voce di log ogni volta che le immagini di un pod violano uno o più controlli.

Se tutte le immagini soddisfano tutti i controlli, non vengono generate voci di log.

Fino alla chiusura di un pod con immagini non conformi ai criteri, CV continua a registrare le violazioni dei criteri. I pod non conformi ai criteri che vengono terminati durante l'intervallo tra i controlli vengono registrati durante la successiva revisione CV.

La CV non termina i pod in esecuzione.

La 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.

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, denominati anche criteri singleton progetto. 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 forzata di Autorizzazione binaria. Per questo motivo, se vuoi utilizzare sia l'applicazione di Autorizzazione binaria che il monitoraggio della CV, ti consigliamo di creare un criterio di singolo progetto per l'applicazione e un criterio della piattaforma per il monitoraggio.

Ad esempio, supponiamo che tu voglia configurare Autorizzazione binaria per fare in modo che le immagini abbiano un'attestazione prima del deployment e che tu voglia assicurarti che i pod in esecuzione siano conformi allo stesso requisito. Per farlo, devi configurare un criterio di applicazione del singleton a livello di progetto con un attestatore. Successivamente, creerai un criterio della piattaforma con un semplice controllo dell'attestazione di firma e che prevede un autenticatore basato sulla stessa nota e chiave pubblica dell'attestatore.

Le norme relative alla piattaforma sono specifiche 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 insieme 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ù, 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 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, devi assegnare a ciascuno un nome univoco per la risorsa. Quando esegui un comando dell'interfaccia a riga di comando gcloud, fai riferimento al criterio della piattaforma locale utilizzando 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 ogni 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 sui controlli.

Quando i criteri della piattaforma CV specificano 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 per 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 per un singolo progetto, Autorizzazione binaria imposta automaticamente i ruoli richiesti nell'agente di servizio 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 necessari ruoli aggiuntivi di Identity and Access Management (IAM).

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

Configurazione con più progetti

Quando configuri una configurazione CV multi-progetto con criteri della piattaforma, il criterio della piattaforma, le immagini, il cluster GKE e altri tipi di risorse dipendenti da CV possono risiedere in un progetto diverso.

Nella configurazione con più progetti, è 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 utilizzare il CV

Per utilizzare il CV, in genere devi eseguire le seguenti operazioni:

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 flotta.
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.

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 le violazioni dei criteri dei log CV. Viene omesso in alcuni degli esempi riportati più avanti in questa guida.

Nega sempre

Il controllo Always-deny garantisce che tutte le immagini soggette a questo controllo non superino la valutazione. Ogni volta che la CV esamina i pod in esecuzione con questo controllo, genera 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 su come utilizzare il controllo Always-deny, vedi Utilizzare più set di controlli.

Controllo di aggiornamento delle immagini

Il controllo di 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 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"

Semplice controllo dell'attestazione di firma

Puoi utilizzare il controllo dell'attestazione di firma semplice della CVS per verificare che ciascuna immagine di un pod abbia un'attestazione valida 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 utilizzato nell'attestatore. Ti consigliamo di utilizzare questo controllo anziché la convalida continua precedente.

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

Anziché gli attestatori di Autorizzazione binaria, i controlli di attestazione CV dispongono di autenticatori. Puoi specificare gli autori di autenticazione direttamente nel criterio, nel blocco attestationAuthenticators.

Nel 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 una chiave qualsiasi in pkixPublicKeySet dell'autenticatore qualsiasi.

I criteri della piattaforma CV sono diversi dai criteri per l'applicazione forzata di un singolo progetto per i seguenti motivi:

Le chiavi PGP non sono supportate.
Gli attestatori non sono necessari. Puoi invece creare manualmente le chiavi e quindi describe il criterio della piattaforma per recuperare l'ID chiave che utilizzerai per creare l'attestato.
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. La CV cerca invece gli 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.

La 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, CV le valuta innanzitutto in base alle immagini esenti, poiché le liste consentite possono includere tag. Se l'immagine non è esente, CV tenta di trovare il digest dell'immagine. Poiché non è presente, l'immagine viola il controllo.

Controllo SLSA

Il controllo SLSA verifica la provenienza specificata da 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 costruttore 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 relative sottodirectory (non create da Cloud Build) sono esenti dal controllo perché violerebbero.

Controllo directory attendibile

Il controllo della directory attendibile verifica che le immagini dei pod si trovino in una o più directory attendibili specificate nel criterio della piattaforma.

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

Il seguente esempio di criteri della piattaforma 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à. Sono incluse le nuove vulnerabilità identificate dall'analisi delle vulnerabilità dopo il deployment del pod. Nel controllo delle vulnerabilità, puoi configurare soglie del livello di gravità delle vulnerabilità e soglie 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 Common Vulnerability Scoring System (CVSS) associati a qualsiasi vulnerabilità che Artifact Analysis può identificare. Inoltre, in blockedCves sono elencate 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 una delle CVE elencate in allowedCves, CV registra una voce in Logging.

Convalida i criteri aggiornati

Dopo aver aggiornato i criteri 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.

Immagini esenti 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 esclude le immagini solo da quel controllo.

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

Un prefisso del nome di 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 *).
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 di 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.

I caratteri jolly * e ** possono essere utilizzati per trovare 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. Quindi * o ** da soli 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 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 alla voce imageAllowlist sono esenti da tutti i set di controlli (checkSets) elencati in gkePolicy.

checkSet (Esenzione a livello di set)

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 alla voce imageAllowlist sono esenti da tutti i controlli elencati alla voce 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ù insiemi di controlli

Un criterio basato su controllo CV può contenere più di un insieme di controlli. La CVS valuta un controllo impostato ogni volta che valuta il criterio. Puoi considerare i set di controlli come criteri secondari da valutare 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 controllo.

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, viene chiamato set di controlli predefinito, il che significa che i controlli si applicano a tutti i pod, indipendentemente dal loro 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 controllo predefinito.

La seguente configurazione di 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 ha come ambito 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. Il terzo insieme di controlli è un controllo predefinito. I suoi controlli si applicano a tutti i pod nel cluster in esecuzione al di fuori degli ambiti prod-namespace e dev-namespace.

Quando CV valuta il set di controllo denominato Prod check set, verifica 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 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 Always-deny garantisce 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 formato del valore è my-namespace:my-service-account.

Verifica che gli ambiti dei set abbiano le seguenti regole:

In un criterio della piattaforma può essere impostato un solo controllo per ambito.
Se un criterio contiene set di controlli con ambito a livello di spazio dei nomi e account di servizio, il set di controlli con ambito a livello di account di servizio deve essere elencato per primo, seguito da quello con ambito a livello di spazio dei nomi.
Può essere impostato 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, la CV non produce voci di log.

Curriculum vitae precedente

Questa sezione descrive i criteri CV precedenti. Se non hai mai utilizzato i CV, ti consigliamo di utilizzare invece le norme della piattaforma CV.

Per supportare gli utenti di CV legacy, è possibile abilitare CV sui progetti che eseguono GKE. CV utilizza quindi il criterio di applicazione di Autorizzazione binaria per verificare 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 e visualizzare gli eventi CV legacy in Cloud Logging.