Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica della convalida continua

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

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, quando attivi sia l'applicazione forzata di Autorizzazione binaria CV con criteri basati su controlli, puoi assicurarti che il criterio la conformità viene 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, del criterio della piattaforma in modo che corrisponda al criterio del singleton progetto. In questo modo Il CV ti informa dell'esecuzione di pod che violano la tua versione criteri.
Monitoraggio dei metadati dell'immagine: il CV fornisce controlli specifici per le modifiche ai metadati delle immagini, tra cui:
- Attestazioni: CV registra quando sulle attestazioni del pod le immagini non sono più valide.
- Aggiornamento: registri CV quando rileva che i pod le immagini non sono più aggiornate.
- Provenienza: il CV può verificare che i pod immagini sono state create con un builder affidabile, utilizzando configurazioni di build che risiedono in repository di codice sorgente attendibile.
- Firme Sigstore: i log CV vengono registrati quando sui pod le immagini non hanno 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 dry run: quando abiliti la modalità dry run, Autorizzazione binaria consente 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 deployment di emergenza: quando esegui il deployment dei pod utilizzando il deployment di emergenza, Autorizzazione binaria ignora l'applicazione del criterio singleton progetto e i log un singolo evento a Cloud Audit Logs. Se invece usi un criterio della piattaforma corrispondente CV continua a registrare regolarmente i pod che violano i criteri, tra cui i pod di cui è stato eseguito il deployment tramite deployment di emergenza.

Come funziona il 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 sull'immagine siano conformi criteri della piattaforma.

Violazioni dei log CV dei criteri 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 CV valuta le immagini di un pod utilizzando un criterio della piattaforma, potrebbero soddisfare alcuni controlli e violare 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 ai criteri è terminata nell'intervallo tra le convalide, Le voci di log generate in CV possono essere visualizzate dopo la chiusura, durante la prossima valutazione.

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

CV non termina i pod in esecuzione.

Il CV utilizza una risorsa del feed

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

Criteri della piattaforma CV

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

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

I criteri della piattaforma funzionano solo con le variabili personalizzate e non li supportano Applicazione di 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, devi configurare un criterio di applicazione forzata per singleton progetto 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.

I criteri relativi alla piattaforma sono specifici della piattaforma. GKE è l'unico completamente gestita.

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 dalle valutazione tramite CV.

Autorizzazioni obbligatorie

Per elencare o descrivere i criteri relativi alla piattaforma, è necessario il Ruolo binaryauthorization.policyViewer. Per creare, modificare ed eliminare la piattaforma devi avere il ruolo binaryauthorization.policyEditor. Per saperne di più, vedi 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 che descrivi il criterio esistente, salvarlo in un file YAML, aggiungere il nuovo controllo aggiornare il criterio utilizzando il file aggiornato.

Criteri relativi a più piattaforme

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 relativi alle piattaforme, assegna a ciascuno un nome con un nome risorsa univoco. Quando esegui un comando gcloud CLI, fai riferimento il 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 ciascun GKE sia che si tratti di un criterio della piattaforma locale o di uno in un altro progetto.

Più controlli per criterio della piattaforma

Puoi configurare più controlli in ciascun criterio della piattaforma aggiungendoli alla sezione checks blocco del criterio. Per scoprire di più sui controlli specifici che può configurare, consulta la sezione Controlli.

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

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

Configurazione per un singolo progetto

Puoi impostare il CV in un singolo progetto.

In una configurazione a progetto singolo, Autorizzazione binaria configura automaticamente ruoli richiesti nell'agente di servizio di Autorizzazione binaria.

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

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 un CV in più progetti con la piattaforma criteri, i criteri della piattaforma, le immagini, il cluster GKE gli altri tipi di risorse dipendenti da CV possono risiedere in un progetto diverso.

Quando imposti più progetti, è importante conoscere lo scopo di ciascun progetto. le risorse a cui deve accedere il CV e la sua configurazione i ruoli e le autorizzazioni IAM di conseguenza.

Come usare il CV

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

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

Assegni

Questa sezione descrive i controlli specifici forniti dal CV.

I criteri basati sui controlli hanno il seguente formato canonico:

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

Il campo displayName in checks e checkSets è facoltativo. Viene utilizzato solo quando CV registra violazioni dei criteri. Viene omesso in alcune delle più avanti in questa guida.

Controllo Nega sempre

Il controllo "Sempre negato" garantisce che tutte le immagini soggette a questo controllo non vadano a buon fine la valutazione delle prestazioni. Ogni volta che il CV esamina i pod in esecuzione con questo controllo, genera una voce di log per ciascuno dei pod.

Puoi combinare il controllo Alwaysdeny con liste consentite o più set di controlli per assicura che Autorizzazione binaria produca sempre i log per i pod in determinati d'uso diversi.

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 di come può essere utilizzato il controllo Alwaysdeny, consulta Utilizzare più set di controlli.

Controllo dell'aggiornamento delle immagini

Il controllo di aggiornamento delle immagini calcola la durata dell'esecuzione di un'immagine e 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"

Semplice controllo dell'attestazione della firma

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 equivale alla valutazione dell'attestazione in una 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 legacy (deprecata).

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

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. Tu specifichi di autenticazione direttamente nel criterio, nel blocco attestationAuthenticators.

In un criterio della piattaforma, simpleSigningAttestationCheck può avere più attestationAuthenticators e più chiavi in ogni pkixPublicKeySet. La viene soddisfatto quando ogni pod le immagini abbiano un'attestazione valida firmata con qualsiasi chiave nel pkixPublicKeySet di qualsiasi autenticato.

I criteri della piattaforma CV sono diversi da un singolo progetto delle norme nei seguenti modi:

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. Invece il CV cerca le attestazioni in ogni progetto elencato campo containerAnalysisAttestationProjects.
Le attestazioni sono ancora archiviate nelle occorrenze di Artifact Analysis, ma possono essere archiviati in più progetti.
Devi specificare esplicitamente uno o più progetti che contengono attestazioni utilizzando il nome risorsa projects/ATTESTATION_PROJECT_ID.

CV non supporta i tag immagine, ad eccezione di quelli specificati in esente in formato Docker.

Se il deployment delle immagini viene eseguito con un tag immagine anziché un digest, la valuta innanzitutto in base a immagini esenti, poiché le liste consentite possono includere tag. Se l'immagine non è esente, CV cerca di trovare il digest dell'immagine. Poiché non ce n'è uno, l'immagine viola la verifica.

Controllo SLSA

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

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

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

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

Le immagini devono essere state create da un generatore di fiducia. Cloud Build è l'unico builder affidabile supportato dal controllo SLSA.
Cloud Build deve aver generato le attestazioni in attestation-project1 o attestation-project2.
Le immagini devono essere create utilizzando un file di configurazione di primo livello da una delle due 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 violerebbe.

Controllo della firma del Sigstore

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

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 esempio di criterio della piattaforma descrive come configurare un Sigstore controllo della firma:

  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 è quando ciascuno dei pod le immagini abbiano un'attestazione valida firmata any nel valore publicKeySet di qualsiasi strumento di autenticazione.

Controllo della directory attendibile

Il controllo della directory attendibile controlla che i pod le immagini risiedono in uno dei fornito directory attendibili specificate in un criterio della piattaforma.

Quando utilizzi questo controllo, ti consigliamo di salvaguardare anche i repository che indichi come directory attendibili nelle tue norme impedendo 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 tutti i pod si trovano nelle directory elencate, sono conformi alle norme. Pod che non risiedono nella che violano il criterio e CV registra le violazioni.

Controllo delle vulnerabilità

Il controllo delle vulnerabilità utilizza la vulnerabilità di Artifact Analysis per verificare se le immagini dei pod contengono vulnerabilità. Sono inclusi nuove vulnerabilità identificate dall'analisi delle vulnerabilità sin dal pod è stato eseguito il deployment. Nel controllo delle vulnerabilità, puoi configurare la vulnerabilità soglie del livello di gravità e vulnerabilità specifiche (come CVE). Immagini con vulnerabilità che violano il controllo delle vulnerabilità viene registrato in Logging.

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

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 Livelli di gravità associati al CVSS (Common Vulnerability Scoring System) con qualsiasi vulnerabilità che Artifact Analysis possa identificare. Inoltre, blockedCves elenca specifiche esposizioni di vulnerabilità comuni (CVE). Se una vulnerabilità identificata supera una delle gravità specificate livelli o corrisponde a una delle CVE elencate in blockedCves e non corrisponde una delle CVE elencate in allowedCves, poi CV registra una voce Logging.

Convalida i criteri aggiornati

Dopo aver aggiornato le norme relative alla piattaforma CV, ti consigliamo vivamente di verificare che Autorizzazione binaria e CV continuano a funzionare come previsto.

Convalidare 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 convalidare il funzionamento di Autorizzazione binaria e CV puoi eseguire il deployment di pod di test e quindi controllare Autorizzazione binaria in 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 solo le immagini 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 del tag con il carattere jolly *).
Il nome di un'immagine con un digest.
Il nome di un'immagine contenente sia un tag sia un digest.

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

us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c corrisponde esattamente a un nome, un tag e un digest 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 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 corrispondenze con qualsiasi nome con un un certo prefisso. * corrisponde a suffissi che non includono /. ** corrispondenze suffissi che possono includere /, ma ** possono essere utilizzati solo dopo un /. Tieni presente che * e ** non possono essere utilizzati con tag o sintesi.

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 escludere le immagini in base a un criterio della piattaforma livello. Tutte le immagini in exempt-images1 e exempt-images2 e le relative sottodirectory sono escluse da CV il monitoraggio.

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 gli attributi i set di controlli (checkSets) elencati in gkePolicy.

Esenzione a livello di checkSet

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

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

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

esenzione a livello di controlli

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

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

Utilizza più set di controlli

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

Ogni set di controlli ha come ambito uno spazio dei nomi Kubernetes o l'account di servizio. 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 per quell'ambito.

Quando un set di controlli è senza ambito, è chiamato insieme di controlli predefinito, il che significa che i controlli si applichino a tutti i pod, indipendentemente dallo spazio dei nomi Kubernetes nell'ambito dell'account di servizio.

La maggior parte dei criteri di esempio nelle guide di visualizzazione continua utilizza solo un valore predefinito set di controlli.

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 set di controlli ha come ambito prod-namespace, quindi i suoi controlli interessano solo i pod in esecuzione in quell'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 il CV valuta il set di controlli denominato Prod check set, controlla per i pod di immagini in esecuzione nell'istanza prod-namespace spazio dei nomi:

Le immagini sono archiviate nella directory prod-images attendibile.
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, controllando se le immagini nel pod provengono dalla directory dev-images.

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

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

Verifica che gli ambiti del set abbiano le seguenti regole:

In un criterio della piattaforma può essere presente un solo set di controlli per ambito.
Se un criterio contiene 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ò esistere un solo set di controlli predefiniti e deve essere elencato per ultimo.

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

CV precedente

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

Per supportare gli utenti di video personalizzati precedenti, è possibile abilitarla che eseguono GKE. Il CV utilizza quindi Criterio di applicazione di Autorizzazione binaria per controllare tutti i pod in esecuzione su dei cluster nel progetto, inclusi i cluster per i quali L'applicazione di Autorizzazione binaria non è abilitata.

Scopri come utilizzare un CV precedente (deprecato) e visualizzare gli eventi CV legacy in Cloud Logging.