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 attivare la crittografia dei dati in transito per le comunicazioni dei pod tra i nodi 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 dell'interfaccia di rete (NIC) per garantire la riservatezza dei dati in transito, indipendentemente dal servizio o dall'applicazione in esecuzione sulla VM (incluso GKE). Questo livello di crittografia è applicabile a tutto il traffico dei pod e dei nodi GKE. Le chiavi di crittografia vengono fornite e gestite da Google.

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

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

Puoi attivare la crittografia trasparente tra nodi in ambienti con un singolo cluster o più 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 memorizzate nella memoria del nodo GKE. In alcuni ambienti o giurisdizioni regolamentati o per soddisfare requisiti di conformità specifici, potresti voler criptare ulteriormente queste chiavi e controllarne l'accesso. A questo scopo, ti consigliamo di utilizzare la crittografia trasparente tra nodi con nodi GKE riservati che utilizzano chiavi di crittografia gestite dal cliente (CMEK). I nodi GKE riservati che utilizzano CMEK criptano i contenuti della memoria dei nodi con le chiavi che gestisci.
La crittografia trasparente tra nodi per GKE è supportata solo su cluster GKE Dataplane V2.
GKE Autopilot non è supportato.
La crittografia trasparente tra nodi per GKE utilizza WireGuard. WireGuard non è FIPS conforme.
Le chiavi di crittografia non vengono ruotate dinamicamente. La rotazione delle chiavi deve essere gestita manualmente riavviando i nodi.
La crittografia trasparente tra nodi e i nodi GKE riservati funzionano solo su Container-Optimized OS (COS) e Ubuntu e non su Windows.
La crittografia trasparente tra nodi non cripta il traffico di rete avviato dal nodo GKE o da un pod che utilizza hostNetwork.
La crittografia trasparente tra nodi non cripta il traffico di rete inviato a un pod esposto su una porta del nodo. Anche se ExternalTrafficPolicy: Cluster è configurato sul servizio, il traffico inoltrato dal primo nodo che riceve il traffico dal client al pod di backend non è criptato.
Il numero massimo di nodi supportati con la crittografia trasparente tra nodi attivata per configurazioni a cluster singolo o multi-cluster è 500.
La crittografia trasparente tra nodi potrebbe comportare un numero di richieste superiore a quello supportato per i nodi. Puoi aspettarti un aumento medio della CPU del 15% su nodi n2-standard-8 con il sistema operativo Ubuntu e un throughput di 2 Gbps.

L'aumento dell'utilizzo della CPU non è attribuito a nessun pod perché non è conosciuto da kube-scheduler. Il pod con un aumento del traffico potrebbe utilizzare tutte le risorse della CPU sul nodo. Ciò può impedire ad altri pod di ottenere le risorse della CPU di cui hanno bisogno, anche se sono configurati correttamente. Ciò può causare problemi per i pod che tentano 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 su cui è abilitata la crittografia trasparente tra nodi. In alternativa, puoi pianificare un pod con un valore PriorityClass basso che ha una richiesta di CPU elevata, ma non la utilizza mai.
La crittografia trasparente tra nodi comporta una latenza di 150 microsecondi su due nodi nella stessa zona che non utilizzano i nodi Confidential GKE.
Quando attivi 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 attivi la crittografia trasparente tra nodi, gli indirizzi IP dei pod non sono visibili nella VPC. Le funzionalità che dipendono dall'ispezione dei pacchetti, come Mirroring pacchetto e le regole firewall VPC basate su CIDR del pod, non sono compatibili con la crittografia trasparente inter-nodo.
Quando attivi la crittografia trasparente tra nodi nei cluster collegati a subnet VPC diverse, devi creare manualmente le 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 attivare contemporaneamente il criterio di rete FQDN e la crittografia trasparente tra nodi.
Non puoi attivare questa funzionalità contemporaneamente alla visibilità tra nodi.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

Attiva l'API Google Kubernetes Engine.

Attiva l'API Google Kubernetes Engine

Se vuoi utilizzare Google Cloud CLI per questa attività, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti le posizioni predefinite, puoi evitare errori in gcloud CLI come il seguente: 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

Attivare la crittografia trasparente tra nodi con GKE

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

Attivare la crittografia trasparente tra nodi in un nuovo cluster

Per attivare 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 l'area geografica di calcolo del cluster.
Nota: ti consigliamo di creare nuovi cluster con la crittografia inter-nodi attivata anziché con la crittografia inter-nodi disattivata e attivarla successivamente. L'attivazione della crittografia inter-nodi in un secondo momento potrebbe comportare il riavvio del pool di nodi.
Per verificare la configurazione, utilizza 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)]
```
Nota: verifica che il numero di peer sia inferiore di uno rispetto al numero di nodi nel cluster. Ad esempio, in un cluster con 24 nodi, il numero di peer deve essere 23. Se il numero di peer non è inferiore di uno rispetto al numero di nodi nel cluster, riavvia di nuovo l'agente anetd sui nodi.

Attivare la crittografia trasparente tra nodi in un cluster esistente

Per attivare 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 l'area geografica di calcolo del cluster.
Nota: ti consigliamo di eseguire questa operazione durante un periodo di manutenzione, poiché potrebbe interrompere il traffico verso il tuo pod. L'aggiornamento del cluster e l'installazione della rete di crittografia inter-nodi potrebbero 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 l'area geografica di calcolo del cluster.
Attendi che venga visualizzato lo stato "IN ESECUZIONE". L'attivazione della crittografia inter-nodi in GKE riavviare automaticamente i nodi. Potrebbero essere necessarie diverse ore prima che il riavvio dei nodi e l'applicazione dei criteri ai nuovi nodi vengano completati.
Per verificare che i nodi siano stati riavviati:
```
kubectl get nodes
```
Controlla il campo AGE di ogni 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 inferiore di uno rispetto al numero di nodi nel cluster. Ad esempio, in un cluster con 24 nodi, il numero di peer deve essere di 23. Se il numero di peer non è inferiore di uno rispetto al numero di nodi nel cluster, riavvia di nuovo l'agente anetd sui nodi.

Attivare la crittografia trasparente tra nodi nei cluster

La crittografia trasparente tra nodi non è supportata nei cluster Autopilot. Se il tuo parco include cluster Autopilot, questi non potranno comunicare con i cluster standard in cui è attivata la crittografia.

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

Attiva la crittografia trasparente tra nodi in un nuovo cluster o in un cluster esistente.
Registra il cluster in un parco risorse.
Attiva 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 inferiore di uno rispetto al numero di nodi di tutti i cluster registrati. Ad esempio, in un cluster con 24 nodi, il numero di peer deve essere 23. Se il numero di peer non è inferiore di uno rispetto al numero di nodi nel cluster, riavvia di nuovo l'agente anetd sui nodi.

Disattivare la crittografia trasparente tra nodi

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

La crittografia trasparente inter-nodo è abilitata per l'intero cluster e non puoi disattivarla parzialmente nelle singole risorse Kubernetes, come gli spazi dei nomi o i pod.
Esegui questa operazione durante un periodo di manutenzione, in quanto interromperà il traffico del tuo pod.

Su un singolo cluster

Per disattivare 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 calcolo del tuo cluster.

Disattiva 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 disattiva la crittografia:
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
Sostituisci PROJECT_ID con l'ID progetto.

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

Disattivare per un intero parco risorse di cluster

Per disattivare la crittografia trasparente tra nodi in un parco:
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
Sostituisci PROJECT_ID con l'ID progetto.
Per disattivare la crittografia trasparente tra nodi e rimuovere l'API ora inutilizzata, disabilita l'API GKE Dataplane V2 a livello di parco. In questo modo verrà disattivato il controller GKE Dataplane V2 in esecuzione nel tuo 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 veicoli. Prima di disattivarla, assicurati che questa API non sia utilizzata da altri elementi del tuo parco per evitare comportamenti imprevisti.

Per gestire in modo efficiente i cluster con lo stesso nome e garantire l'attivazione della crittografia multi-cluster:
1. Annullare la registrazione del vecchio cluster dal parco risorse prima di crearne uno nuovo con lo stesso nome.
2. Registra di nuovo il nuovo cluster al momento della sua ricreazione.
3. Se dimentichi di annullare la registrazione di un cluster, elimina il vecchio abbonamento e ricrea il nuovo cluster con un nuovo abbonamento.
Se non segui questi passaggi, la crittografia multi-cluster potrebbe non attivarsi sul nuovo cluster finché l'appartenenza al parco risorse non viene ricreata.

Come funziona la crittografia trasparente tra nodi con GKE

Le sezioni seguenti descrivono il funzionamento della crittografia trasparente tra nodi quando la attivi 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. Quando i cluster fanno parte dello stesso parco risorse, appartengono allo stesso dominio di crittografia.

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

La comunicazione tra pod tra i nodi dello stesso cluster è criptata utilizzando la coppia di chiave pubblica/privata.
La comunicazione tra pod di 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 va a buon fine.

Generazione e utilizzo delle chiavi di crittografia

Quando la funzionalità è attivata, ogni nodo GKE del cluster genera automaticamente una coppia di chiave pubblica/privata nota come chiavi di crittografia.

La chiave privata viene archiviata in memoria (non su disco) e non esce mai dal node. L'utilizzo di GKE Confidential Node consente di ridurre ulteriormente il rischio di compromissione delle chiavi perché anche la memoria del nodo viene criptata (con chiavi diverse).
La chiave pubblica viene condivisa con altri nodi che utilizzano il piano di controllo GKE Dataplane V2 ed è accessibile a tutti i nodi nello stesso dominio di crittografia.

Dopo lo scambio delle 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.

Tieni presente quanto segue quando utilizzi le coppie di chiavi private o pubbliche e la chiave di sessione:

Coppia di chiavi privata/pubblica:
- La chiave pubblica viene distribuita nel cluster e tutti i nodi del cluster possono accedervi.
- La coppia di chiavi viene ruotata al riavvio del nodo. GKE non ruota le chiavi a intervalli regolari. Per attivare manualmente una rotazione della chiave, scarica e riavvia il nodo. In questo modo, la coppia di chiavi originale viene invalidata e viene generata una nuova coppia di chiavi.
Chiave sessione:
- Questa chiave non è configurabile.
- Questa chiave viene ruotata periodicamente ogni due minuti.
- La chiave di sessione è esclusiva dei nodi coinvolti nel tunnel.