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 di Google Kubernetes Engine (GKE) con chiavi di crittografia gestite dall'utente.

Per impostazione predefinita, Google cripta tutti i dati in transito tra VM nel controller dell'interfaccia di rete (NIC) livello di sicurezza per garantire la riservatezza dei dati in transito, indipendentemente da un servizio o un'applicazione in esecuzione sulla VM (incluso GKE). Questo di crittografia applicabile a tutti i nodi GKE e ai pod per via del traffico. Le chiavi di crittografia vengono fornite e gestite da Google.

Con la crittografia trasparente tra nodi per GKE, Google ti offre maggiore controllo sulle chiavi di crittografia utilizzate per criptare il traffico dei pod 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 conformità e controlli di sicurezza.

Puoi abilitare la crittografia trasparente tra nodi in cluster singoli e multipli ambienti cloud-native. Per ulteriori informazioni su questa funzione, vedi Come funziona la crittografia trasparente tra nodi funziona 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 specifiche requisiti, ti consigliamo di criptare ulteriormente queste chiavi 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 in modo dinamico. La rotazione delle chiavi deve essere gestita manualmente riavviando i nodi.
Crittografia trasparente tra nodi insieme a Confidential GKE Node funziona 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 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 abilitato per le configurazioni a cluster singolo o multi-cluster è 500.
La crittografia trasparente tra nodi potrebbe comportare un numero di richieste superiore a quello supportato dai nodi. Ci si potrebbe aspettare il 15% di aumento della CPU in media su n2-standard-8 con il sistema operativo Ubuntu con velocità effettiva 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. Questo può impedire ad altri pod di ottenere Le risorse della CPU di cui hanno bisogno, anche se sono configurate correttamente. Questo può causare problemi ai pod che tentano di eseguire carichi di lavoro sensibili devono poter rispondere rapidamente alle richieste. Come soluzione alternativa, puoi mantiene una quantità significativa di CPU non pianificata sui nodi che hanno tra nodi crittografia trasparente attivata. In alternativa, puoi pianificare un pod con un 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 di nodi nella stessa zona che non utilizzano Confidential GKE Node.
Quando abiliti la crittografia trasparente tra nodi, l'osservabilità del traffico le funzionalità usate per monitorare il traffico sui pod potrebbero non funzionare come previsto perché i dati in transito sono criptati con chiavi non accessibili all'infrastruttura 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 il mirroring dei pacchetti 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 il criterio di rete del nome di dominio completo e la crittografia trasparente tra nodi.
Non puoi attivare questa funzionalità contemporaneamente alla visibilità intranodi.

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, scarica 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 GKE è supportata solo su Google Cloud CLI versione 458.0.0 e successive e successive Versioni 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 abilitare la crittografia trasparente tra nodi con GKE su un in 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 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 di 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 comando seguente per controllare stato 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 dovrebbero avere 23 anni. 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 intervento di manutenzione perché questa operazione potrebbe interrompere il traffico verso il tuo pod. La l'aggiornamento e l'installazione della rete di crittografia tra nodi potrebbe richiedono 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 comando seguente per controllare stato 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 in meno rispetto al numero di nodi nella tua in un cluster Kubernetes. Ad esempio, in un cluster con 24 nodi, il numero di peer deve essere di 23. Se il numero di peer non è inferiore a quello dei nodi nella riavvia nuovamente l'agente anetd sui nodi.

Abilita la crittografia trasparente tra nodi tra i cluster

La crittografia trasparente tra nodi non è supportata su Autopilot cluster. Se il parco risorse include cluster Autopilot, non potranno possono comunicare con i cluster standard per cui è abilitata 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.
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 inferiore di uno rispetto al numero di nodi di tutti i cluster registrati. Ad esempio, in un cluster con 24 nodi, il numero delle app peer dovrebbe 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 perché e interrompere il traffico del tuo pod.

Su un singolo cluster

Per disattivare la crittografia trasparente tra nodi su 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 tuo cluster 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 disabilitazione della crittografia con questo comando avvia la rimozione dei nodi remoti dall'elenco dei peer Wireguard su ciascun cluster. Questa procedura può richiedere fino a diversi minuti per il completamento, 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 la 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 disabilitare la crittografia trasparente tra nodi e rimuovere l'API non utilizzata, Disabilita l'API GKE Dataplane V2 a livello del parco risorse. Questa operazione disattiverà 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 crittografia trasparente tra nodi per il tuo parco risorse. 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 che l'infrastruttura sia multi-cluster crittografia, segui questa procedura:
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 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, quanto segue considerazioni applicabili:

La comunicazione tra pod tra i nodi dello stesso cluster è criptata utilizzando la coppia di chiavi pubblica/privata.
Comunicazione tra pod tra un nodo in un cluster con tra nodi la crittografia trasparente abilitata e un nodo in un cluster che la crittografia trasparente tra nodi abilitata non riesce.

Generazione e utilizzo delle chiavi di crittografia

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

La chiave privata viene archiviata in memoria (non su disco) e non lascia mai la nodo. Utilizzo di GKE Confidential Ulteriori nodi riduce il rischio di compromissione delle chiavi perché anche la memoria del nodo criptati (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 dello 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. Questa operazione invalida la chiave originale e genera una nuova coppia di chiavi.
Chiave di sessione:
- Questa chiave non è configurabile.
- Questa chiave viene ruotata periodicamente ogni due minuti.
- La chiave di sessione è esclusiva per i nodi coinvolti nel tunnel.