Informazioni sull'autorità del control plane GKE

Questo documento descrive le opzioni offerte da Google Kubernetes Engine (GKE) per migliorare la visibilità e il controllo della sicurezza del control plane gestito. Queste opzioni sono collettivamente denominate GKE control plane authority. Questo documento è destinato a leader della sicurezza delle informazioni, amministratori della conformità e analisti che vogliono soddisfare le esigenze di privacy e sicurezza rigorose per la gestione dei dati sensibili.

Informazioni sulle funzionalità di GKE control plane authority

In GKE, Cloud de Confiance by S3NS gestisce completamente la configurazione di sicurezza di control plane, inclusa la crittografia dell'archiviazione at-rest e la configurazione delle chiavi e delle Certificate Authority (CA) che firmano e verificano le credenziali nei cluster. I nodi del control plane per i cluster GKE esistono in progetti che Cloud de Confiance gestisce. Per i dettagli su cosafa Cloud de Confiance , consulta Responsabilità condivisa di GKE.

GKE control plane authority è un insieme facoltativo di funzionalità di visibilità e controllo che ti consentono di verificare e gestire aspetti specifici di questi nodi del control plane completamente gestiti. Queste funzionalità sono ideali se hai requisiti come i seguenti:

  • Operi in un settore altamente regolamentato come la finanza, l'assistenza sanitaria o la pubblica amministrazione con requisiti di conformità specifici
  • Gestisci dati sensibili con requisiti di sicurezza e crittografia rigorosi
  • Vuoi una maggiore visibilità su GKE per migliorare la tua fiducia durante l'esecuzione di carichi di lavoro critici
  • Devi soddisfare requisiti di conformità o audit specifici relativi alla crittografia dei dati, all'integrità del software o al logging
  • Hai carichi di lavoro altamente sensibili che elaborano dati critici e vuoi visibilità sulla crittografia e sull'accesso a questi dati
  • Vuoi applicare policy di sicurezza personalizzate che soddisfino requisiti organizzativi o normativi specifici
  • Vuoi un livello maggiore di trasparenza e visibilità negli ambienti GKE, in particolare in relazione alle azioni intraprese nel Cloud de Confiance control plane

Vantaggi di GKE control plane authority

Le funzionalità di GKE control plane authority sono ideali in ambienti altamente regolamentati con policy di sicurezza rigorose o requisiti di audit rigorosi. L'utilizzo di queste funzionalità offre vantaggi come i seguenti:

  • Maggiore visibilità e controllo: utilizza funzionalità aggiuntive di visibilità, controllo e crittografia per il control plane GKE.
  • Conformità semplificata: soddisfa i requisiti normativi e di settore con log di controllo granulari e policy di sicurezza personalizzabili.
  • Maggiore fiducia e trasparenza: ottieni informazioni dettagliate sulle azioni intrapreseCloud de Confiance nel control plane durante la risoluzione dei casi di assistenza clienti.
  • Mitigazione del rischio: rileva e rispondi in modo proattivo alle potenziali minacce a control plane gestito con log completi.
  • Gestione standardizzata di CA e chiavi: gestisci le CA dei cluster GKE utilizzando Certificate Authority Service, che ti consente di delegare la gestione dei certificati a team specifici e di applicare in modo completo le policy delle CA. Inoltre, gestisci le chiavi di crittografia dei dischi del control plane utilizzando Cloud KMS per una delega di gestione simile.

Disponibilità di GKE control plane authority

GKE control plane authority è disponibile in qualsiasi Cloud de Confiance regione. Tuttavia, per criptare i dischi di avvio del control plane e i dischi etcd con le tue chiavi, devi creare il cluster in una delle seguenti regioni:

  • asia-east1
  • asia-northeast1
  • asia-southeast1
  • europe-west1
  • europe-west4
  • us-central1
  • us-central2
  • us-east1
  • us-east4
  • us-east5
  • us-south1
  • us-west1
  • us-west3
  • us-west4

Come funziona GKE control plane authority

Le funzionalità che puoi utilizzare con il control plane sono classificate in base al tipo di controllo che vuoi, come segue. Puoi utilizzare una o più di queste funzionalità in base ai tuoi requisiti specifici.

  • Gestione di chiavi e credenziali: controlla le chiavi utilizzate da GKE per criptare i dati at-rest nel control plane e per emettere e verificare le identità nel cluster.
  • Log di accesso e log di emissioni di identità: utilizza i log della rete, della VM, e di Access Transparency per verificare l'accesso al control plane GKE utilizzando più origini. Utilizza i log di emissione delle identità in Cloud KMS e CA Service per vedere quando vengono create le identità utilizzando le chiavi e le CA che gestisci. Utilizza i log dettagliati di utilizzo dell'API Kubernetes per monitorare le azioni eseguite da queste identità nel cluster.

Gestione di chiavi e credenziali

Per impostazione predefinita, Cloud de Confiance gestisce le chiavi e le CA nei cluster GKE. Facoltativamente, puoi utilizzare Cloud KMS e CA Service per configurare le tue chiavi e CA, che utilizzerai poi durante la creazione di un nuovo cluster.

GKE utilizza queste chiavi e CA anziché quelle Cloud de Confiance predefinite per emettere e verificare le identità nel cluster e per criptare i dati nelle VM del control plane. Mantenere il controllo sulle chiavi di emissione delle identità e di crittografia dei dati può aiutarti a:

  • Rispettare le normative sulla sovranità e la privacy dei dati che impongono il controllo esclusivo delle chiavi
  • Controllare la crittografia dei dati sensibili critici in Kubernetes gestendo le tue chiavi di crittografia
  • Personalizzare la strategia di crittografia dei dati in base alle policy e ai requisiti della tua organizzazione, ad esempio i requisiti per l'utilizzo di chiavi con integrazione hardware.

CA e chiavi dei account di servizio gestite autonomamente

Puoi configurare il control plane GKE in modo che utilizzi le chiavi Cloud KMS e le CA di CA Service che gestisci. GKE utilizza queste risorse per emettere e verificare le identità nel cluster. Ad esempio, GKE utilizza CA e chiavi per emettere certificati client Kubernetes e token di connessione dei account di servizio Kubernetes.

Crea le seguenti risorse che GKE deve utilizzare per emettere le identità:

  1. Chiavi di firma dei service account: firma i token di connessione dei ServiceAccount Kubernetes per i service account nel cluster. Questi token di connessione sono token web JSON (JWT) che facilitano la comunicazione dei pod con il server API Kubernetes.
  2. Chiavi di verifica dei service account: verifica i JWT dei service account Kubernetes. Questa chiave è in genere la stessa della chiave di firma, ma viene configurata separatamente in modo da poter ruotare le chiavi in modo più sicuro.
  3. CA del cluster: emetti certificati firmati per scopi come le richieste firmate del certificato (CSR) e la comunicazione kubelet.
  4. CA peer etcd: emetti certificati firmati per la comunicazione tra le istanze etcd nel cluster.
  5. CA API etcd: emetti certificati firmati per la comunicazione con il server API etcd.
  6. CA di aggregazione: emetti certificati firmati per abilitare la comunicazione tra il server API Kubernetes e i server di estensione.

Quando GKE emette identità nel cluster, vengono visualizzati i log di controllo corrispondenti in Cloud Logging, che puoi utilizzare per monitorare le identità emesse durante il loro ciclo di vita.

Per saperne di più, consulta Eseguire le tue Certificate Authority e le tue chiavi di firma in GKE.

Crittografia del disco di avvio del control plane e di etcd

Per impostazione predefinita, GKE cripta il disco di avvio di una VM del control plane. Se il control plane esegue istanze del database etcd, GKE cripta anche quanto segue:

  • Il disco che archivia i dati etcd.
  • Il Cloud de Confiance by S3NS backup operativo interno di etcd.

Questa crittografia predefinita utilizza chiavi di crittografia che Cloud de Confiance gestisce. Per i dettagli su questa crittografia predefinita, consulta Crittografia at-rest predefinita.

Puoi facoltativamente utilizzare le tue chiavi di crittografia gestite con Cloud KMS per criptare le seguenti risorse:

  • Disco di avvio del control plane: il disco Compute Engine che ogni VM del control plane utilizza per l'avvio.
  • Disco etcd: il disco Compute Engine collegato a ogni VM del control plane che archivia i dati per le istanze etcd nel cluster.

  • Backup operativo interno di etcd: il Cloud de Confiance backup interno di etcd utilizzato per scopi operativi come ripristino di emergenza.

    Questo backup è una misura di emergenza interna a Cloud de Confiance. Se vuoi eseguire il backup e il ripristino dei cluster, utilizza Backup per GKE invece.

Per istruzioni, consulta Criptare etcd e i dischi di avvio del control plane.

Questa crittografia facoltativa aggiuntiva è ideale se devi soddisfare requisiti normativi o di conformità specifici relativi al controllo dei mezzi di crittografia nel control plane del cluster. Puoi utilizzare separatamente le tue chiavi per criptare i dischi di avvio e i dischi di archiviazione dei nodi worker nel cluster. Per i dettagli, consulta Utilizzare le chiavi di crittografia gestite dal cliente (CMEK).

Quando utilizzi GKE control plane authority per criptare i dischi di avvio del control plane, le VM del control plane GKE utilizzano automaticamente la modalità Confidential per Hyperdisk Balanced nei dischi di avvio. Questa configurazione non modifica i dischi di avvio predefiniti dei nodi worker.

Rotazione delle credenziali gestite dal cliente

Con GKE control plane authority, puoi configurare i cluster in modo che utilizzino CA e chiavi gestite dal cliente anziché le risorse gestite da Google utilizzate da GKE per impostazione predefinita. Una rotazione delle credenziali è un'operazione che esegui per aggiornare una o più di queste risorse in un cluster. Potresti eseguire una rotazione delle credenziali per motivi quali evitare la scadenza della CA o rispettare i requisiti di gestione delle credenziali della tua organizzazione.

Per eseguire una rotazione delle credenziali per un cluster che utilizza GKE control plane authority, crea nuove CA, chiavi di firma e chiavi di crittografia. Poi aggiorna il cluster in modo che utilizzi queste nuove risorse.

Per saperne di più, consulta le pagine seguenti:

Log di accesso e log di emissione delle identità

Puoi visualizzare i log in Logging per tutti gli eventi relativi all'accesso e all'identità nel control plane, inclusi i seguenti eventi:

  • Accesso diretto: i log relativi ai tentativi di accesso diretto (come SSH) ai nodi del control plane GKE ti consentono di verificare che i log SSH delle VM e le connessioni di rete delle VM corrispondano ai record SSH nei log di Access Transparency
  • Emissione e verifica delle identità: log relativi alle identità emesse utilizzando le CA e le chiavi gestite in CA Service e Cloud KMS.
  • Utilizzo delle identità in Kubernetes: log relativi alle azioni intraprese da identità specifiche sul server API Kubernetes.
  • Access Transparency: log relativi alle connessioni stabilite con il control plane e alle azioni intraprese sul control plane dal Cloud de Confiance personale. Quando l'accesso aumentato è abilitato, ottieni una maggiore granularità per il controllo dell'accesso, inclusi i dettagli dei comandi SSH nei log di Access Transparency e per le richieste di approvazione dell'accesso. Per saperne di più sull' idoneità e sulla registrazione, contatta il team dedicato al tuo Cloud de Confiance by S3NS account.

Questi log possono aiutarti a:

  • Mantenere tracce di audit complete di tutti gli eventi di accesso e identità del control plane per la conformità e la sicurezza.
  • Oltre alle protezioni integrate di Google, puoi creare il tuo monitoraggio per identificare e analizzare qualsiasi attività sospetta all'interno del control plane.
  • Verificare che solo i soggetti autorizzati accedano e interagiscano con il cluster GKE, migliorando così la security posture.
  • Visualizzare quando vengono create le identità utilizzando le chiavi e le CA gestite utilizzando i log di emissione delle identità in Cloud KMS e CA Service. Utilizzare i log dettagliati di utilizzo dell'API Kubernetes per monitorare le azioni eseguite da queste identità nel cluster.

I seguenti documenti mostrano come visualizzare ed elaborare i vari tipi di log del control plane:

Risorse aggiuntive sulla sicurezza del control plane

Questa sezione descrive altri metodi che puoi utilizzare per migliorare la tua fiducia nella sicurezza del control plane. Non è necessario utilizzare GKE control plane authority per utilizzare le seguenti risorse:

  • Integrità dell'immagine VM del control plane: GKE aggiunge log dettagliati per la creazione e gli eventi di avvio delle VM dei nodi a Cloud Logging. Inoltre, pubblichiamo VSA SLSA su GitHub che corrispondono alle immagini macchina del control plane e dei nodi worker. Puoi verificare che le VM utilizzino immagini del sistema operativo con VSA corrispondenti e verificare l'integrità di avvio di ogni VM del control plane.

    Per eseguire la verifica dell'integrità delle VM, consulta Verificare l'integrità delle VM del control plane GKE.

  • Misure di sicurezza integrate del control plane: GKE esegue varie misure di hardening sul control plane gestito. Per saperne di più, consulta Sicurezza del control plane.

Passaggi successivi