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 il CV determina che i pod violano i criteri della piattaforma, registra le violazioni in Cloud Logging.

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

Perché usare il CV?

Sebbene l'applicazione di Autorizzazione binaria fornisca convalide delle immagini una tantum quando esegui il deployment delle immagini container, CV monitora continuamente e le immagini associate ai pod in esecuzione continuano a essere conformi ai 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 alle norme: quando aggiorni Autorizzazione binaria criteri di applicazione per singoli progetti, Autorizzazione binaria convalida solo le immagini il cui deployment viene eseguito dopo aggiornamento. I pod già in esecuzione non sono interessati. Continuano a essere pubblicate anche se Autorizzazione binaria, utilizzando il criterio aggiornato, ora blocca dalla stessa immagine di cui viene eseguito il deployment.

    Per questo motivo, quando aggiorni il campo project-singleton di Autorizzazione binaria, ti consigliamo di creare o aggiornare anche un CV, di Google Cloud in modo che corrisponda al criterio di singolo progetto. 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: registri CV quando rileva che i pod le immagini 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 CV quando dei pod risiedono in una directory di repository non elencata nel tuo criteri della piattaforma.
    • Vulnerabilità: CV registra quando le vulnerabilità vengono identificate in formato Docker.

  • Monitoraggio della prova: quando attivi la prova, Autorizzazione binaria consente di eseguire il deployment di tutte le immagini. Attivando CV con un criterio della piattaforma che corrisponda al tuo criterio di singolo progetto, CV registra regolarmente le immagini che violano i criteri 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 CV

Per utilizzare un CV, devi abilitarlo sul tuo cluster GKE.

Dopo aver eseguito il deployment delle immagini sul cluster, CV monitora per assicurarsi che siano conformi alla tua piattaforma basata sui controlli. .

CV non supporta tag immagine diversi da quelli specificati in immagini esenti.

Il CV esamina regolarmente i pod in esecuzione

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

Durante ogni revisione, il CV recupera un elenco di immagini associate in ogni pod. Il CV verifica quindi che le informazioni sulle immagini rispettino le norme della piattaforma.

Il CV registra le violazioni delle norme della piattaforma

Quando CV stabilisce che le immagini violano un criterio della piattaforma, Registra le violazioni e altri risultati in Cloud Logging. R viene scritta una voce di log separata per ogni criterio della piattaforma violato, ad in 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. CV una voce di log ogni volta che un'immagine di un pod viola un controllo. Il log contiene solo le immagini dei pod che violano il criterio della piattaforma. Se tutte le immagini soddisfano tutti i controlli, non vengono prodotte voci di log.

CV continua a registrare le violazioni dei criteri finché un pod con e 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 casi di breve durata i pod.

CV non termina i pod in esecuzione.

Il CV utilizza una risorsa del feed

Per recuperare informazioni sui pod in esecuzione nel cluster GKE, la risorsa CV crea un feed denominato 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 deployment possa avere un solo criterio project-singleton legacy, 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 l'applicazione forzata di Autorizzazione binaria e CV il monitoraggio, crei un criterio di singolo progetto per l'applicazione e una piattaforma criteri per il monitoraggio.

Ad esempio, supponiamo che tu voglia configurare Autorizzazione binaria far sì che le immagini dispongano di un'attestazione prima di e vuoi assicurarti che i pod in esecuzione siano conformi requisito. Per farlo, configura un criterio di applicazione a livello di progetto singolo con un attestatore. Quindi creerai un del criterio della piattaforma con un semplice controllo dell'attestazione della firma. che ha un autenticatore basato sulla stessa nota e 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 set 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

Aggiornare un criterio della piattaforma sovrascrive il criterio esistente con un descrittore del criterio da te fornito il 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 (uno criteri della piattaforma) 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, utilizzerai 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 criterio 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 di immagini esenti. Per ulteriori informazioni, vedi Immagini esenti.

Configurazione per un singolo progetto

Puoi configurare il CV in un singolo progetto.

In una configurazione di un singolo progetto, 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 si trovano tutti nello stesso progetto, non sono richiesti ruoli IAM (Identity and Access Management) aggiuntivi.

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

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 ciascuno 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 usare il CV

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

  1. Decidi quali controlli utilizzare.
  2. Componi uno o più criteri della piattaforma utilizzando un file YAML dei criteri. Il file specifica i controlli che vuoi utilizzare.
  3. Crea il criterio relativo alla piattaforma. Il criterio può essere archiviato in un progetto a tua scelta.
  4. Scegli se attivare il CV su singoli cluster o su un parco risorse.
  5. Controlla i log CV in Logging per gli eventi.
  6. Rivedi i log e aggiorna la build e altri processi per produrre immagini che soddisfare i controlli.

Assegni

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 quando CV registra violazioni dei criteri. Viene omesso in alcune delle 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 controlli per assicurarti che l'autorizzazione di codice generi sempre log per i pod in determinati casi.

Per utilizzare il controllo sempre negato, aggiungi alwaysDeny: true nel blocco checks, come che 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 di rifiuto sempre, consulta Utilizzare più set di controlli.

Controllo dell'aggiornamento delle immagini

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

Nel seguente esempio YAML del criterio della piattaforma, CV registra i pod con di 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"

Verifica di attestazione della firma semplice

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

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 utilizzate 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 autenticatori 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. Puoi invece creare manualmente le chiavi e quindi descrivere un criterio della piattaforma per recuperare l'ID chiave da utilizzare per creare l'attestazione.
  • Crei e firmi manualmente il payload, crei il file JSON di attestazione, e creerai l'attestazione utilizzando l'API Artifact Analysis.
  • Crei comunque una nota Artifact Analysis, ma non specificarlo 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 il deployment delle immagini viene eseguito con un tag immagine anziché un digest, CV la valuta innanzitutto in base a immagini esenti, poiché le liste consentite possono includere tag. Se l'immagine non è esente, il CV tenta di trovare il digest dell'immagine. Poiché non ce ne sono, l'immagine viola il controllo.

Controllo SLSA

Il controllo SLSA verifica la provenienza specificata da SLSA dei pod in formato Docker.

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 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 di uno dei seguenti repository attendibili:

    • Il repository source.cloud.google.com/my-project/my-source-repo/
    • Qualsiasi repository in github.com/my-github-user/

  • Le immagini in gcr.io/my-images/not-built-by-GCB/ o nelle relative sottodirectory (che non sono state create da Cloud Build) sono esenti dal controllo in quanto lo violerebbero.

Controllo della firma del 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 ci sono la firma recuperata da Artifact Registry può essere verificata da qualsiasi chiave nelle norme.

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 della directory attendibile 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 esempio di criterio della piattaforma descrive come configurare un account attendibile controllo della directory:

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 i valori 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 la vulnerabilità soglie del livello di gravità 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 attivare la ricerca di vulnerabilità in Analisi degli elementi.

Il seguente esempio di configurazione dei criteri della piattaforma contiene una vulnerabilità verifica:

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'analisi degli elementi 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 di codice binario e CV continuino a funzionare come previsto.

Convalida la configurazione

Per verificare la configurazione, controlla entrambi i criteri di singolo progetto di Autorizzazione binaria e i criteri relativi alla piattaforma CV.

Operazione di convalida

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

Escludi immagini con liste consentite

Quando crei un criterio della piattaforma, puoi escludere le immagini dai controlli aggiungendo i loro URL a una lista consentita. Una lista consentita a livello di criterio esclude le immagini dalle l'intera norma. Una lista consentita a livello del set di controlli è esente dal controllo impostato e si applica solo quando viene valutato il set di controlli. Una lista consentita all'interno di un segno di spunta consente di escludere le immagini solo da tale controllo.

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

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

Di seguito sono riportati alcuni esempi di pattern 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 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 trovare corrispondenze con qualsiasi nome con un un certo 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 i tag o i digest.

Ad esempio:

  • us-central1.pkg.dev/my-project/my-image* corrispondenze 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/** corrispondenze 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 solo * o ** non è un pattern valido né 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 escludere le immagini a livello di set di controllo:

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 controllo CV può contenere più set 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 a quali pod si applica il set di controlli.

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 configurazione dei criteri di esempio seguente configura tre set di controlli:

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

Nella configurazione di esempio, 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 con ambito dev-namespace, quindi i suoi controlli interessano solo i pod in esecuzione in quell'ambito. La terza serie di controlli è un insieme di controlli predefinito. I controlli si applicano a tutti i pod del 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, esamina 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 presente un solo set di controlli per ambito.

  • Se un criterio contiene un controllo basato sia sugli spazi dei nomi che sugli account di servizio di servizi, il set di controlli con ambito a livello di account di servizio deve essere elencato per primo, seguito da il set di controlli basato sullo spazio dei nomi.

  • Può essere impostato un solo controllo predefinito e deve essere elencato per ultimo.

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

CV legacy

Questa sezione descrive i criteri relativi ai file CV precedenti. Se non hai mai utilizzato CV, ti consigliamo di utilizzare invece CV 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 un CV precedente (deprecato) e visualizzare gli eventi CV legacy in Cloud Logging.

Passaggi successivi