Questa pagina contiene informazioni sui concetti relativi ad Autorizzazione binaria.
Norme
Un'policy di Autorizzazione binaria, nota anche come policy singleton del progetto, è un insieme di regole che regolano il deployment delle immagini container.
La convalida continua (CV) utilizza un tipo diverso di policy, chiamato policy della piattaforma.
Un criterio è composto dalle seguenti parti:
- Regole di deployment
- Elenco delle immagini esenti
Puoi configurare un criterio utilizzando uno dei seguenti metodi:
- ConsoleGoogle Cloud
gcloud
comandi
Quando utilizzi i comandi gcloud
, esporti e modifichi una definizione del criterio
in formato YAML prima di importarla di nuovo nel progetto. Il formato YAML
riflette la struttura interna di un criterio nello spazio di archiviazione di Autorizzazione binaria.
Per ulteriori informazioni su questo formato, consulta
Riferimento YAML per i criteri.
Ogni Google Cloud progetto può avere esattamente un criterio. Devi configurare il criterio nel progetto in cui esegui la piattaforma di deployment. In una configurazione a progetto singolo, la policy e tutte le risorse secondarie, ovvero attestatori e attestazioni, 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 ancora.
Per configurare e utilizzare Autorizzazione binaria sulle piattaforme supportate, consulta Configurazione per piattaforma.
Vedi un esempio di configurazione multi-progetto per GKE.
Regole
Quando configuri una norma, ne definisci le regole. Le regole definiscono i vincoli che le immagini devono soddisfare prima di poter essere sottoposte a deployment. Un criterio ha una regola predefinita e può avere regole specifiche, a seconda della piattaforma. Per saperne di più, consulta Tipi di regole supportati per piattaforma.
Ogni regola può essere configurata con una modalità di valutazione e una modalità di applicazione. Ad esempio, una regola può richiedere che un'immagine abbia una attestazione firmata prima di poter essere implementata.
Regola predefinita
Ogni criterio ha una regola predefinita. Questa regola si applica a qualsiasi richiesta di deployment
che non corrisponde a una regola specifica. In un file YAML dei criteri, la regola predefinita è
specificata nel nodo defaultAdmissionRule
.
Per saperne di più sulla configurazione della regola predefinita, vedi Configurazione di una policy.
Regole specifiche
A un criterio possono essere aggiunte una o più regole specifiche. Questo tipo di regola si applica alle immagini da implementare in cluster, account di servizio o identità specifici. Il supporto di regole specifiche varia in base alla piattaforma. Per saperne di più, consulta Tipi di regole supportati per piattaforma.
In un file YAML della policy, 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 implementazione.
Piattaforma | Regola predefinita | Regola specifica |
---|---|---|
GKE | Supportato | Cluster Spazi dei nomi Kubernetes Service account Kubernetes |
Cloud Run | Supportato | Non supportata |
Cluster collegati a GKE | Supportato | Cluster Spazi dei nomi Kubernetes Service account Kubernetes |
GKE su AWS | Supportato | Cluster Spazi dei nomi Kubernetes Service account Kubernetes |
Google Distributed Cloud | Supportato | Cluster Spazi dei nomi Kubernetes Service account Kubernetes |
Google Distributed Cloud | Supportato | Cluster Spazi dei nomi Kubernetes Service account Kubernetes |
Cloud Service Mesh | Supportato | Identità di servizio Cloud Service Mesh |
Modalità di valutazione
Ogni regola ha una modalità di valutazione che specifica il tipo di vincolo che
Autorizzazione binarian applica alla regola. La modalità di valutazione di una regola viene specificata utilizzando la proprietà evaluationMode
nel file YAML dei criteri.
Esistono tre modalità di valutazione:
- Consenti tutte le immagini:consente il deployment di tutte le immagini.
- Non consentire alcuna immagine:non consente il deployment di tutte le immagini.
- Richiedi attestazioni:richiede che un firmatario firmi digitalmente il digest dell'immagine e crei un'attestazione prima del deployment. Al momento del deployment, l'applicazione forzata 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 ha anche una modalità di applicazione, che specifica l'azione intrapresa da GKE quando un'immagine non è conforme alla regola. Una regola può avere le seguenti modalità di applicazione:
Blocca e registra nel log di controllo: blocca il deployment delle immagini che non sono conformi alla regola e scrive un messaggio nel log di controllo per indicare il motivo per cui l'immagine non è stata sottoposta a deployment.
Prova: solo log di controllo: 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 consente di testare una norma, ad esempio nell'ambiente di produzione, prima che l'applicazione entri in vigore.
La maggior parte delle regole di produzione utilizza la modalità di applicazione Blocca e audit log. Prova generale: solo log di controllo viene utilizzato principalmente per testare una norma nel tuo ambiente prima che diventi effettiva.
La modalità di applicazione di una regola viene specificata utilizzando la proprietà
enforcementMode
nel file YAML dei criteri.
Per ulteriori informazioni sui messaggi scritti in Cloud Audit Logs, consulta Visualizzare gli audit log (GKE, Google Distributed Cloud, Cloud Service Mesh) o Visualizzare gli audit log (Cloud Run).
Convalida continua
La convalida continua è una funzionalità dell'autorizzazione binaria che controlla periodicamente le immagini associate ai pod in esecuzione per verificare la conformità continua ai criteri.
Immagini esenti
Un'immagine esente è un'immagine esentata dalle regole delle norme.
Autorizzazione binaria consente sempre il deployment delle immagini esenti. Ogni progetto ha
una lista consentita di immagini esenti specificate dal percorso del registro. Le immagini nei percorsi
gcr.io/google_containers/*
, k8s.gcr.io/**
e nei percorsi aggiuntivi sono esenti per
impostazione predefinita, in quanto contengono le risorse necessarie per consentire a GKE
di avviare correttamente un cluster con il criterio predefinito attivo.
Per aggiungere un'immagine esente all'allowlist, aggiungi quanto segue al file delle norme:
admissionWhitelistPatterns: - namePattern: EXEMPT_IMAGE_PATH
Sostituisci EXEMPT_IMAGE_PATH
con il percorso di un'immagine da esentare. Per esentare altre immagini, aggiungi altre voci - namePattern
. Scopri di più su admissionWhitelistPatterns
.
Pattern della lista consentita
Per inserire nella lista consentita tutte le immagini la cui posizione del registro corrisponde al percorso specificato:
gcr.io/example-project/*
Per inserire nella lista consentita tutte le immagini la cui posizione del registro è 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 al tag:
gcr.io/example-project/helloworld:latest gcr.io/example-project/helloworld:my-tag
Per inserire nella lista consentita tutte le versioni e 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 delle immagini container.
Scopri come gestire le immagini esenti nella consoleGoogle Cloud , utilizzando lo strumento a riga di comando o l'API REST.
Immagini di sistema gestite da Google
Accetta tutte le immagini di sistema gestite da Google fa sì che l'Autorizzazione binaria esenti un elenco di immagini di sistema gestite da Google da un'ulteriore valutazione delle policy. Se questa impostazione è attivata, le immagini richieste da GKE non vengono bloccate dall'applicazione dei criteri. Il criterio di sistema viene valutato prima e in aggiunta alla valutazione del criterio utente.
Puoi attivare o disattivare questa impostazione utilizzando la proprietà
globalPolicyEvaluationMode
nel file YAML dei criteri. Puoi visualizzare i contenuti della norma
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.
La procedura di creazione di un'attestazione è talvolta chiamata firma di un'immagine. Un'attestazione viene creata dopo la creazione di un'immagine. Ogni immagine di questo tipo ha un digest univoco a livello globale. Un firmatario firma il digest dell'immagine utilizzando una chiave privata di una coppia di chiavi e utilizza la firma per creare l'attestazione. Al momento del deployment, lo strumento di applicazione di Autorizzazione binaria utilizza la chiave pubblica dell'attestatore per verificare la firma nell'attestazione. In genere, un attestatore corrisponde esattamente a un 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 tua funzione di controllo qualità, l'attestazione potrebbe indicare che l'immagine ha superato tutti i test funzionali end-to-end richiesti in un ambiente di staging.
Per abilitare le attestazioni in Autorizzazione binaria, evaluationMode
del criterio è
impostato su REQUIRE_ATTESTATION
.
Scopri come creare e utilizzare attestatori e attestazioni.
Firmatari
Un firmatario è 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 dell'immagine. Gli attestatori contengono la chiave pubblica corrispondente alla chiave privata utilizzata da un firmatario per firmare il digest dell'immagine e creare l'attestazione. L'applicazione di Autorizzazione binaria utilizza l'attestatore al momento del deployment per limitare le immagini che possono essere sottoposte a deployment a quelle con un'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 software o personale di controllo qualità o conformità DevOps responsabile della produzione di immagini distribuibili, della loro firma con la chiave privata e della creazione delle attestazioni prima di tentare di eseguirne il deployment.
Gli attestatori hanno:
- Una nota di Artifact Analysis corrispondente
- Una o più chiavi pubbliche crittografiche che corrispondono alla chiave privata utilizzata dal firmatario per creare un'attestazione.
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'interfacciagcloud
o l'API REST Binary Authorization.
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 di immagine. Viene creata un'attestazione.
A questo punto, viene creato un attestatore e memorizzato nel criterio. La chiave pubblica corrispondente alla chiave privata utilizzata per la firma viene caricata e allegata all'attestatore.
Quando viene effettuato un tentativo di deployment di un'immagine, l'autorizzazione binaria utilizza gli attestatori nel criterio per verificare le attestazioni dell'immagine. Se l'attestazione può essere verificata, l'immagine viene implementata.
Autorizzazione binaria supporta due tipi di chiavi:
- Infrastruttura a chiave pubblica (X.509) (PKIX)
- PGP
Le chiavi PKIX possono essere archiviate localmente, esternamente o in Cloud Key Management Service.
Crea una chiave crittografica 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 che crei, devi creare una nota di Artifact Analysis. Ogni attestazione viene memorizzata 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.