Concetti di Autorizzazione binaria

Questa pagina contiene informazioni sui concetti relativi ad Autorizzazione binaria.

Criteri

Un criterio di Autorizzazione binaria, noto anche come criterio singleton di progetto, è un insieme di regole che regolano il deployment delle immagini container.

La convalida continua (CV) utilizza un tipo diverso di criterio, chiamato criterio della piattaforma.

Un criterio è composto dai seguenti elementi:

Puoi configurare un criterio utilizzando uno dei seguenti metodi:

  • Console Google Cloud
  • gcloud comandi

Quando utilizzi i comandi gcloud, puoi esportare e modificare una definizione del criterio in formato YAML prima di importarla di nuovo nel tuo progetto. Il formato YAML riflette la struttura interna di un criterio nell'archivio di Autorizzazione binaria. Per maggiori informazioni su questo formato, consulta la pagina Riferimento YAML per i criteri.

Ogni progetto Google Cloud può avere esattamente un criterio. Devi configurare il criterio nel progetto in cui esegui la piattaforma di deployment. In una configurazione di un singolo progetto, il criterio e tutte le risorse subordinate (attestatori e attestations) si trovano nello stesso progetto. Per stabilire la separazione dei compiti, puoi utilizzare una configurazione con più progetti. In questa configurazione, la piattaforma di deployment può essere eseguita in un progetto, gli attestatori possono risiedere in un altro progetto e le attestazioni possono risiedere in un altro progetto.

Per configurare e utilizzare Autorizzazione binaria sulle piattaforme supportate, consulta Configurazione per piattaforma.

Vedi un esempio di configurazione di più progetti per GKE.

Regole

Quando configuri un criterio, sei tu a definire le relative regole. Le regole definiscono i vincoli che le immagini devono soddisfare prima di poterne eseguire il deployment. Un criterio ha una sola regola predefinita e può avere regole specifiche, a seconda della piattaforma. Per ulteriori informazioni, consulta Tipi di regole supportati per piattaforma.

Ogni regola può essere configurata con una modalità di valutazione e una modalità di applicazione forzata. Ad esempio, una regola può richiedere che un'immagine abbia una attestazione firmata prima di poterne eseguire il deployment.

Regola predefinita

A ogni criterio è associata una regola predefinita. Questa regola si applica a qualsiasi richiesta di deployment che non corrisponde a una regola specifica. In un file YAML del criterio, la regola predefinita è specificata nel nodo defaultAdmissionRule.

Per ulteriori informazioni sulla configurazione della regola predefinita, consulta Configurare un criterio.

Regole specifiche

È possibile aggiungere una o più regole specifiche a un criterio. Questo tipo di regola si applica alle immagini di cui deve essere eseguito il deployment in cluster, account di servizio o identità specifici. Il supporto di regole specifiche varia a seconda della piattaforma. Per ulteriori informazioni, consulta Tipi di regole supportati per piattaforma.

In un file YAML del criterio, ogni regola specifica del cluster è specificata in un nodo clusterAdmissionRule.

Tipi di regole supportati per piattaforma

La tabella seguente mostra i tipi di regole supportati per ciascuna piattaforma di deployment.

Piattaforma Regola predefinita Regola specifica
GKE Supportato Cluster
Spazi dei nomi Kubernetes
Account di servizio Kubernetes
Cloud Run Supportato Non supportata
Cluster collegati a GKE Supportato Cluster
Spazi dei nomi Kubernetes
Account di servizio Kubernetes
GKE su AWS Supportato Cluster
Spazi dei nomi Kubernetes
Account di servizio Kubernetes
GKE su Bare Metal Supportato Cluster
Spazi dei nomi Kubernetes
Account di servizio Kubernetes
GKE su VMware Supportato Cluster
Spazi dei nomi Kubernetes
Account di servizio Kubernetes
Anthos Service Mesh Supportato Identità del servizio Anthos Service Mesh

Modalità di valutazione

Ogni regola prevede una modalità di valutazione che specifica il tipo di vincolo che Autorizzazione binaria applica per la regola. La modalità di valutazione per una regola viene specificata utilizzando la proprietà evaluationMode nel file YAML del criterio.

Esistono tre modalità di valutazione:

  • Consenti tutte le immagini:consente il deployment di tutte le immagini.
  • Non consentire tutte le immagini: non consente il deployment di tutte le immagini.
  • Richiedi attestazioni: richiede un signer di firmare digitalmente il digest dell'immagine e creare una attestazione prima del deployment. Al momento del deployment, l'applicatore di Autorizzazione binaria utilizza un attestatore per verificare la firma nell'attestazione prima di eseguire il deployment dell'immagine associata.

Modalità di applicazione

Ogni regola prevede anche una modalità di applicazione forzata, che specifica l'azione eseguita da GKE quando un'immagine non è conforme alla regola. Una regola può avere le seguenti modalità di applicazione:

  • Blocca e audit log: blocca il deployment di immagini non conformi alla regola e scrive un messaggio nell'audit log per indicare il motivo per cui non è stato eseguito il deployment dell'immagine.

  • Prova: solo audit log: la modalità di prova è una modalità di applicazione forzata in un criterio che consente il deployment di immagini non conformi, ma scrive i dettagli del deployment in Cloud Audit Logs. La modalità di prova ti consente di testare un criterio, ad esempio nel tuo ambiente di produzione, prima che l'applicazione diventi effettiva.

La maggior parte delle regole di produzione utilizza la modalità di applicazione forzata di Blocco e log di controllo. Prova: solo audit log viene utilizzata principalmente per testare un criterio nel tuo ambiente prima che venga applicato.

La modalità di applicazione forzata per una regola viene specificata utilizzando la proprietà enforcementMode nel file YAML dei criteri.

Consulta Visualizzare gli audit log (GKE, cluster GKE, Anthos Service Mesh) o Visualizzare audit log (Cloud Run) per ulteriori informazioni sui messaggi scritti in Cloud Audit Logs.

Convalida continua

La convalida continua (CV) è una funzionalità di Autorizzazione binaria che controlla periodicamente le immagini associate ai pod in esecuzione per garantire la continua conformità ai criteri.

Scopri di più sul CV.

Immagini esenti

Un'immagine esente è un'immagine esente dalle regole dei criteri. Autorizzazione binaria consente sempre il deployment di immagini esenti. Ogni progetto include una lista consentita di immagini esenti specificate dal percorso del Registro di sistema. Le immagini nel percorso gcr.io/google_containers/*, k8s.gcr.io/** e nei percorsi aggiuntivi sono esenti per impostazione predefinita, poiché contengono le risorse necessarie per consentire a GKE di avviare correttamente un cluster con il criterio predefinito attivo.

La lista consentita delle immagini esenti viene specificata utilizzando la proprietà admissionWhitelistPatterns nel file YAML del criterio.

Pattern della lista consentita

Per inserire nella lista consentita tutte le immagini la cui posizione del Registro di sistema corrisponde al percorso specificato:

gcr.io/example-project/*

Per inserire nella lista consentita tutte le immagini la cui posizione del Registro di sistema corrisponde a una sottodirectory del percorso specificato (ad es. gcr.io/example-project/my-directory/helloworld):

gcr.io/example-project/**

Per inserire un'immagine specifica nella lista consentita:

gcr.io/example-project/helloworld

Per inserire nella lista consentita una versione specifica di un'immagine in base ai tag:

gcr.io/example-project/helloworld:latest
gcr.io/example-project/helloworld:my-tag

Per inserire nella lista consentita tutte le versioni/i tag di un'immagine:

gcr.io/example-project/helloworld:*

Per inserire nella lista consentita una versione specifica di un'immagine in base al relativo digest:

gcr.io/example-project/helloworld@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c

Scopri di più sull'utilizzo dei digest di immagini container.

Scopri come gestire le immagini esenti nella console Google Cloud utilizzando lo strumento a riga di comando o l'API REST.

Immagini di sistema gestite da Google

Considera attendibili tutte le immagini di sistema gestite da Google fa sì che Autorizzazione binaria esenti un elenco di immagini di sistema gestite da Google da un'ulteriore valutazione dei criteri. Se questa impostazione è abilitata, le immagini richieste da GKE non vengono bloccate dall'applicazione dei criteri. Il criterio di sistema viene valutato prima e in aggiunta alla valutazione dei criteri relativi agli utenti.

Puoi abilitare o disabilitare questa impostazione utilizzando la proprietà globalPolicyEvaluationMode nel file YAML dei criteri. Puoi visualizzare i contenuti del criterio di sistema utilizzando il seguente comando:

gcloud alpha container binauthz policy export-system-policy

Attestazioni

Un'attestazione è un documento digitale che certifica un'immagine. Durante il deployment, Autorizzazione binaria verifica l'attestazione prima di consentire il deployment dell'immagine.

Il processo di creazione di un'attestazione a volte è chiamato firma di un'immagine. Viene creata un'attestazione dopo la creazione di un'immagine. Ogni immagine di questo tipo ha un digest univoco a livello globale. Un signer firma il digest immagine utilizzando una chiave privata di una coppia di chiavi e la utilizza per creare l'attestazione. Al momento del deployment, l'enforcer di Autorizzazione binaria utilizza la chiave pubblica dell'attestatore per verificare la firma nell'attestazione. In genere un attestatore corrisponde a un solo firmatario.

Un'attestazione indica che l'immagine associata è stata creata eseguendo correttamente una procedura specifica e obbligatoria. Ad esempio, se il firmatario è un rappresentante della funzione di controllo qualità (QA), l'attestazione potrebbe indicare che l'immagine ha superato tutti i test funzionali end-to-end richiesti in un ambiente di gestione temporanea.

Per abilitare le attestazioni in Autorizzazione binaria, il valore evaluationMode del criterio è impostato su REQUIRE_ATTESTATION.

Scopri come creare e utilizzare attestatori e attestazioni.

Firmatari

Un signer è una persona o un processo automatizzato che crea un'attestazione firmando un descrittore di immagine univoco con una chiave privata. L'attestazione viene verificata al momento del deployment dalla chiave pubblica corrispondente archiviata in un attestatore prima del deployment dell'immagine associata.

Scopri come creare e utilizzare attestatori e attestazioni.

Attestatori

Un attestatore è una risorsa Google Cloud che Autorizzazione binaria utilizza per verificare l'attestazione al momento del deployment delle immagini. Gli attestatori contengono la chiave pubblica corrispondente alla chiave privata utilizzata da un firmato per firmare il digest dell'immagine e creare l'attestazione. L'applicatore di Autorizzazione binaria utilizza l'attestatore al momento del deployment per limitare le immagini di cui è possibile eseguire il deployment in quelle con attestazione verificabile creata prima del deployment.

Gli attestatori sono spesso gestiti dal personale delle operazioni di sicurezza che gestisce anche le coppie di chiavi pubbliche e private, mentre i firmatari sono in genere ingegneri informatici o QA DevOps o personale per la conformità responsabile della produzione di immagini di cui è possibile eseguire il deployment, della firma con la chiave privata e della creazione delle attestazioni prima di tentare di eseguirne il deployment.

Gli attestatori hanno:

Quando configuri un criterio che contiene una regola Richiedi attestazioni, devi aggiungere un attestatore per ogni persona o processo che deve verificare che l'immagine sia pronta per il deployment. Puoi aggiungere attestatori utilizzando la console Google Cloud, l'interfaccia gcloud o l'API REST di Autorizzazione binaria.

Scopri come creare e utilizzare attestatori e attestazioni.

Chiavi crittografiche

Autorizzazione binaria utilizza le firme digitali per verificare le immagini al momento del deployment quando il criterio contiene una regola Richiedi attestazioni.

Viene generata una coppia di chiavi. La chiave privata viene utilizzata dal firmatario per firmare un descrittore dell'immagine. Viene creata una attestazione.

In seguito, nel criterio viene creato e archiviato un attestatore. La chiave pubblica corrispondente alla chiave privata utilizzata per la firma viene caricata e collegata all'attestatore.

Quando viene eseguito un tentativo di deployment di un'immagine, Autorizzazione binaria utilizza gli attestatori nel criterio per verificare le attestazioni dell'immagine. Se l'attestazione può essere verificata, viene eseguito il deployment dell'immagine.

Autorizzazione binaria supporta due tipi di chiavi:

Le chiavi PKIX possono essere archiviate in locale, esternamente o in Cloud Key Management Service.

Crea una chiave di crittografia e un attestatore.

Note di Artifact Analysis

Autorizzazione binaria utilizza Artifact Analysis per archiviare i metadati attendibili utilizzati nel processo di autorizzazione. Per ogni attestatore creato, devi creare una nota di Artifact Analysis. Ogni attestazione viene archiviata come occorrenza di questa nota.

Quando Autorizzazione binaria valuta una regola che richiede che gli attestatori abbiano verificato un'immagine, controlla l'archiviazione di Artifact Analysis per verificare se sono presenti le attestazioni richieste.