Questa pagina è stata tradotta dall'API Cloud Translation.

Cripta i dati in transito in GKE con chiavi di crittografia gestite dall'utente

Standard

Questa pagina mostra come abilitare la crittografia dei dati in transito per le comunicazioni dei pod nei nodi di Google Kubernetes Engine (GKE) con chiavi di crittografia gestite dall'utente.

Per impostazione predefinita, Google cripta tutti i dati in transito tra le VM a livello di controller di interfaccia di rete (NIC) per garantire la riservatezza dei dati in transito, a prescindere dal servizio o dall'applicazione in esecuzione sulla VM (incluso GKE). Questo livello di crittografia è applicabile a tutti i nodi GKE e al traffico di pod. Le chiavi di crittografia vengono fornite e gestite da Google.

Con la crittografia trasparente tra nodi per GKE, Google ti offre un maggiore controllo sulle chiavi di crittografia utilizzate per criptare il traffico dei pod nei nodi GKE. GKE esegue questa crittografia utilizzando WireGuard in GKE Dataplane V2, oltre alla crittografia predefinita fornita dai NIC delle VM.

Fornire questo controllo sulle chiavi di crittografia direttamente in GKE è utile se operi in un settore regolamentato e hai bisogno aziendale di controlli di sicurezza e conformità.

Puoi abilitare la crittografia trasparente tra nodi in ambienti singolo e multi-cluster. Per ulteriori informazioni sul funzionamento di questa funzionalità, consulta Come funziona la crittografia trasparente tra nodi con GKE.

Limitazioni

Questa funzionalità, da sola, non garantisce che Google non possa accedere alle chiavi di crittografia archiviate nella memoria del nodo GKE. In alcuni ambienti o giurisdizioni regolamentati, oppure per soddisfare requisiti di conformità specifici, potresti voler criptare ulteriormente queste chiavi e controllare l'accesso. A questo scopo, ti consigliamo di utilizzare la crittografia trasparente tra nodi con Confidential GKE Node che utilizzano chiavi di crittografia gestite dal cliente (CMEK). I Confidential GKE Node che utilizzano CMEK criptano i contenuti della memoria dei nodi con le chiavi che gestisci.
La crittografia trasparente tra nodi per GKE è supportata solo nei cluster GKE Dataplane V2.
GKE Autopilot non è supportato.
La crittografia trasparente tra nodi per GKE utilizza WireGuard. WireGuard non è conforme alle norme FIPS.
Le chiavi di crittografia non vengono ruotate in modo dinamico. La rotazione della chiave deve essere gestita manualmente riavviando i nodi.
La crittografia trasparente tra nodi e i nodi Confidential GKE Node funzionano solo su Container-Optimized OS (COS) e Ubuntu, non su Windows.
La crittografia trasparente tra nodi non cripta il traffico di rete avviato dal nodo GKE o da un pod utilizzando hostNetwork.
La crittografia trasparente tra nodi non cripta il traffico di rete inviato a un pod esposto sulla porta di un nodo. Anche quando ExternalTrafficPolicy: Cluster è configurato nel servizio, il traffico inoltrato dal primo nodo che riceve traffico dal client al pod di backend non è criptato.
Il numero massimo di nodi supportati con la crittografia trasparente tra nodi abilitata per configurazioni cluster singolo o multi-cluster è 500.
La crittografia trasparente tra nodi potrebbe causare una sottoscrizione eccessiva dei nodi. Potresti aspettarti un aumento medio della CPU del 15% sui nodi n2-standard-8 con il sistema operativo Ubuntu con velocità effettiva di 2 Gbps.

L'aumento dell'utilizzo della CPU non è attribuito ad alcun pod perché kube-scheduler non ne è a conoscenza. Il pod con traffico maggiore potrebbe usare tutte le risorse della CPU sul nodo. Ciò può impedire ad altri pod di ottenere le risorse CPU di cui hanno bisogno, anche se sono configurate correttamente. Ciò può causare problemi ai pod che cercano di eseguire carichi di lavoro sensibili o che devono essere in grado di rispondere rapidamente alle richieste. Come soluzione alternativa, puoi mantenere una quantità significativa di CPU non pianificata sui nodi in cui è abilitata la crittografia trasparente tra nodi. In alternativa, puoi pianificare un pod con un livello PriorityClass basso, che ha una richiesta di CPU di grandi dimensioni, ma non utilizza mai questa CPU.
La crittografia trasparente tra nodi comporta una latenza di 150 microsecondi su due nodi nella stessa zona che non utilizzano Confidential GKE Node.
Quando abiliti la crittografia trasparente tra nodi, le funzionalità di osservabilità del traffico utilizzate per monitorare il traffico sui pod potrebbero non funzionare come previsto perché i dati in transito sono criptati con chiavi non accessibili all'infrastruttura di Google sottostante.
Quando abiliti la crittografia trasparente tra nodi, gli indirizzi IP dei pod non sono visibili sul VPC. Le funzionalità che dipendono dall'ispezione dei pacchetti, come Mirroring pacchetto e le regole firewall VPC basate su CIDR pod, non sono compatibili con la crittografia trasparente tra nodi.
Quando abiliti la crittografia trasparente tra nodi tra cluster collegati a subnet VPC diverse, devi creare manualmente regole firewall per consentire le comunicazioni tra i nodi del cluster.
La crittografia trasparente tra nodi disattiva alcune funzionalità di livello 7 di GKE Dataplane V2. Di conseguenza, non puoi abilitare contemporaneamente i criteri di rete dei nomi di dominio completi e la crittografia trasparente tra nodi.
Non puoi attivare questa funzionalità contemporaneamente alla visibilità delle intrusioni.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

Abilita l'API Google Kubernetes Engine.

Abilita l'API Google Kubernetes Engine

Se vuoi utilizzare Google Cloud CLI per questa attività, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
Nota: per le installazioni esistenti dell'interfaccia a riga di comando gcloud, assicurati di impostare le proprietà compute/region e compute/zone. Impostando le località predefinite, puoi evitare errori nellgcloud CLI come segue: One of [--zone, --region] must be supplied: Please specify location.

Segui le istruzioni per abilitare GKE Enterprise.
La crittografia trasparente tra nodi di GKE è supportata solo su Google Cloud CLI 458.0.0 e versioni successive e sulle seguenti versioni di GKE:
- 1.26.10-gke.1024000 o versioni successive
- 1.27.7-gke.1506000 o versioni successive
- 1.28.2-gke.1098000 o versioni successive

Abilita la crittografia trasparente tra nodi con GKE

Puoi abilitare la crittografia trasparente tra nodi con GKE su un singolo cluster o in un ambiente multi-cluster.

Abilita la crittografia trasparente tra nodi in un nuovo cluster

Per abilitare la crittografia trasparente tra nodi in un nuovo cluster:
```
gcloud container clusters create CLUSTER_NAME \
    --region=REGION
    --enable-datapane-v2 \
    --in-transit-encryption inter-node-transparent
```
Sostituisci quanto segue:
- CLUSTER_NAME con il nome del cluster.
- REGION con la regione di computing del tuo cluster.
Nota: ti consigliamo di creare nuovi cluster con la crittografia tra nodi abilitata, anziché crearli con la crittografia tra nodi disabilitata e poi abilitarla. L'abilitazione della crittografia tra nodi in un secondo momento potrebbe comportare il riavvio del pool di nodi.
Per verificare la configurazione, usa il comando seguente per controllare lo stato della crittografia:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```
L'output è simile al seguente:
```
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
```
Nota: verifica che il numero di peer sia uno inferiore al numero di nodi nel cluster. Ad esempio, in un cluster con 24 nodi, il numero di peer dovrebbe essere 23. Se il numero di peer non è di uno in meno rispetto al numero di nodi nel cluster, riavvia l'agente anetd sui nodi.

Abilita la crittografia trasparente tra nodi su un cluster esistente

Per abilitare la crittografia trasparente tra nodi su un cluster esistente:
```
gcloud container clusters update CLUSTER_NAME \
  --in-transit-encryption inter-node-transparent
  --region=REGION
```
Sostituisci quanto segue:
- CLUSTER_NAME con il nome del cluster.
- REGION con la regione di computing del tuo cluster.
Nota: consigliamo di eseguire questa operazione durante un periodo di manutenzione, poiché potrebbe interrompere il traffico verso il pod. L'aggiornamento e l'installazione del cluster della rete di crittografia tra nodi può richiedere diverse ore.
Per verificare che il comando Google Cloud CLI sia stato completato correttamente :
```
gcloud container clusters describe CLUSTER_NAME \
    --region=REGION
    --format json | jq .status
```
Sostituisci quanto segue:
- CLUSTER_NAME con il nome del cluster.
- REGION con la regione di computing del tuo cluster.
Attendi finché lo stato non diventa "IN ESECUZIONE". Se abiliti la crittografia tra nodi in GKE, i nodi verranno riavviati automaticamente. Potrebbero essere necessarie diverse ore prima che il riavvio del nodo venga eseguito e che i nuovi nodi eseguano l'applicazione dei criteri.
Per confermare che i nodi sono stati riavviati:
```
kubectl get nodes
```
Controlla il campo AGE di ciascun nodo e procedi se il campo AGE riflette i nuovi nodi.
Per verificare la configurazione, puoi utilizzare il seguente comando per controllare lo stato della crittografia:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```
L'output è simile al seguente:
```
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
```
Verifica che il numero di peer sia uno inferiore al numero di nodi nel cluster. Ad esempio, in un cluster con 24 nodi, il numero di peer dovrebbe essere 23. Se il numero di peer non è uno inferiore al numero di nodi nel cluster, riavvia l'agente anetd sui nodi.

Abilita la crittografia trasparente tra nodi tra i cluster

La crittografia trasparente tra nodi non è supportata nei cluster Autopilot. Se il tuo parco risorse include cluster Autopilot, non sarà in grado di comunicare con i cluster Standard per cui è abilitata la crittografia.

Per abilitare la crittografia trasparente tra nodi in un ambiente multi-cluster:

Abilita la crittografia trasparente tra nodi su un nuovo cluster o in un cluster esistente.
Registra il cluster in un parco risorse.
Abilita la crittografia trasparente tra nodi per il parco risorse:
```
gcloud container fleet dataplane-v2-encryption enable --project PROJECT_ID
```
Sostituisci PROJECT_ID con l'ID progetto.
Verifica lo stato su tutti i nodi:
```
kubectl -n kube-system get pods -l k8s-app=cilium -o name | xargs -I {} kubectl -n kube-system exec -ti {} -- cilium status
```
L'output è simile al seguente:
```
...
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 5)]
...
```
Nota: verifica che il numero di peer sia uno inferiore al numero di nodi di tutti i cluster registrati. Ad esempio, in un cluster con 24 nodi, il numero di peer dovrebbe essere 23. Se il numero di peer non è di uno in meno rispetto al numero di nodi nel cluster, riavvia l'agente anetd sui nodi.

Disabilita la crittografia trasparente tra nodi

In alcuni casi, potresti voler disabilitare la crittografia trasparente tra nodi nel cluster GKE per migliorare le prestazioni o risolvere i problemi di connettività della tua applicazione. Prima di procedere con questa operazione, considera quanto segue:

La crittografia trasparente tra nodi è abilitata per l'intero cluster e non puoi disabilitarla parzialmente in singole risorse Kubernetes, ad esempio spazi dei nomi o pod.
Esegui questa operazione durante un periodo di manutenzione perché interromperà il traffico del tuo pod.

In un unico cluster

Per disabilitare la crittografia trasparente tra nodi in un singolo cluster:

gcloud container clusters update CLUSTER_NAME \
    --region=REGION
    --in-transit-encryption none

Sostituisci quanto segue:

CLUSTER_NAME: con il nome del tuo cluster.
REGION: con la regione di computing del cluster.

Disabilita in un cluster che fa parte di un parco risorse

Puoi disattivare la crittografia per un cluster in un parco risorse utilizzando una delle due opzioni seguenti:

Per rimuovere completamente il cluster dal parco risorse, annulla la registrazione del cluster.
In alternativa, mantieni il cluster nel parco risorse, ma disabilita la crittografia:
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
Sostituisci PROJECT_ID con l'ID progetto.

La disabilitazione della crittografia con questo comando avvia la rimozione dei nodi remoti dall'elenco dei peer di Wireguard in ogni cluster. Questo processo può richiedere diversi minuti, a seconda del numero di cluster e nodi coinvolti. Per visualizzare il conteggio dei peer aggiornato, devi aggiornare manualmente l'elenco dei peer WireGuard su ogni cluster. Puoi usare lo strumento di gestione dei cluster o il seguente comando:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```

Disabilita per un intero parco risorse di cluster

Per disattivare la crittografia trasparente tra nodi in un parco risorse:
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
Sostituisci PROJECT_ID con l'ID progetto.
Per disabilitare la crittografia trasparente tra nodi e rimuovere l'API ora inutilizzata, disabilita l'API GKE Dataplane V2 a livello di parco risorse. Verrà disattivato il controller GKE Dataplane V2 in esecuzione nel parco risorse.
```
gcloud services disable gkedataplanev2.googleapis.com \
    --project=PROJECT_ID
```
Sostituisci PROJECT_ID con l'ID progetto.

Nota: questa API è responsabile della funzionalità di crittografia trasparente tra nodi per il tuo parco risorse. Assicurati di verificare che questa API non sia utilizzata da nessun altro nel tuo parco risorse prima di disabilitarla per evitare comportamenti imprevisti.

Per gestire in modo efficiente i cluster con lo stesso nome e garantire l'attivazione della crittografia multi-cluster, segui questi passaggi:
1. Annulla la registrazione del cluster precedente dal parco risorse prima di crearne uno nuovo con lo stesso nome.
2. Registra di nuovo il nuovo cluster al momento della nuova creazione.
3. Se dimentichi di annullare la registrazione di un cluster, elimina la vecchia appartenenza e ricrea il nuovo cluster con una nuova appartenenza.
Se non segui questi passaggi, la crittografia multi-cluster potrebbe non essere attivata nel nuovo cluster finché l'appartenenza al parco risorse non viene ricreata.

Come funziona la crittografia trasparente tra nodi con GKE

Le seguenti sezioni descrivono come funziona la crittografia trasparente tra nodi quando la abiliti nel cluster:

Crittografia del traffico di rete tra due pod su nodi diversi

Con la crittografia trasparente tra nodi abilitata, GKE Dataplane V2 cripta il traffico tra pod se i pod si trovano su nodi diversi, indipendentemente dal cluster a cui appartengono. Se i cluster fanno parte dello stesso parco risorse, appartengono allo stesso dominio di crittografia.

Nello stesso parco risorse possono coesistere cluster con configurazioni di crittografia trasparenti tra nodi diverse. Se hai un ambiente multi-cluster in cui solo alcuni cluster utilizzano la crittografia trasparente tra nodi, si applicano le seguenti considerazioni:

La comunicazione tra pod tra nodi nello stesso cluster viene criptata utilizzando la coppia di chiave pubblica/privata.
La comunicazione tra pod tra un nodo in un cluster in cui è abilitata la crittografia trasparente tra nodi e un nodo in un cluster in cui non è abilitata la crittografia trasparente tra nodi non è abilitata.

Generazione e utilizzo delle chiavi di crittografia

Quando la funzionalità è abilitata, ogni nodo GKE nel cluster genera automaticamente una coppia di chiave pubblica/privata note come chiavi di crittografia.

La chiave privata viene archiviata in memoria (non su disco) e non lascia mai il nodo. L'utilizzo dei nodi riservati di GKE riduce ulteriormente il rischio di compromissione delle chiavi, in quanto anche la memoria dei nodi è criptata (con chiavi diverse).
La chiave pubblica viene condivisa con altri nodi utilizzando il piano di controllo GKE Dataplane V2 ed è accessibile a tutti i nodi nello stesso dominio di crittografia.

Una volta scambiate le chiavi, ogni nodo può stabilire un tunnel WireGuard con altri nodi nello stesso dominio di crittografia. Ogni tunnel è univoco per una determinata coppia di nodi.

Quando gestisci le coppie di chiavi private o pubbliche e la chiave di sessione, considera quanto segue:

Coppia di chiavi privata/pubblica:
- La chiave pubblica è distribuita nel cluster e tutti i nodi nel cluster possono accedere alla chiave pubblica.
- La coppia di chiavi viene ruotata al riavvio del nodo. GKE non ruota le chiavi a intervalli regolari. Per attivare manualmente la rotazione della chiave, svuota e riavvia il nodo. Questa operazione rende la coppia di chiavi originale non valida e genera una nuova coppia di chiavi.
Chiave sessione:
- Questa chiave non è configurabile.
- Questa chiave viene ruotata periodicamente ogni due minuti.
- La chiave di sessione è esclusiva per i nodi coinvolti nel tunnel.