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 messaggi in transito per i pod comunicazioni tra Google Kubernetes Engine (GKE) nodi 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 la crittografia WireGuard in GKE Dataplane V2, in 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 funzione da sola non garantisce che Google non possa accedere ai archiviate 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 tale scopo, ti consigliamo di utilizzare elementi trasparenti tra nodi la crittografia con Confidential GKE Node che utilizzano chiavi di crittografia gestite dal cliente (CMEK). I Confidential GKE Node che usano CMEK criptano i contenuti della memoria i 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 della chiave deve essere manualmente mediante il riavvio dei 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 quando ExternalTrafficPolicy: Cluster è configurato sul 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 abilitato per le configurazioni a cluster singolo o multi-cluster è 500.
La crittografia trasparente tra nodi potrebbe far sì che i nodi con più iscrizioni. 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 viene attribuito ad alcun pod perché da parte di kube-scheduler. Il pod con maggiore traffico potrebbe utilizzare a tutte le risorse della CPU sul nodo. Questo può impedire ad altri pod di ottenere 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 abiliti la crittografia trasparente tra nodi, gli indirizzi IP dei pod visibile sul VPC. Funzionalità che dipendono dall'ispezione dei pacchetti come Mirroring pacchetto e VPC basato su CIDR pod Le regole firewall non sono compatibili con la crittografia trasparente tra nodi.
Quando abiliti la crittografia trasparente tra nodi tra i cluster collegati in 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 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 attività:

Attiva l'API Google Kubernetes Engine.

Abilita l'API Google Kubernetes Engine

Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi inizializzare con gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
Nota: per gcloud CLI esistente di installazione, assicurati di impostare compute/region e compute/zone proprietà. Se imposti località predefinite, puoi evitare errori in gcloud CLI come i seguenti: 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

Abilita 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 tuo cluster.
- REGION con la regione di computing del tuo cluster.
Nota: ti consigliamo di creare nuovi cluster con crittografia tra nodi attiva, invece di crearle con la crittografia tra nodi disabilitata la successiva attivazione. Attivare la crittografia tra nodi in un secondo momento potrebbe comportano 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 uno in meno rispetto al numero di nodi nel tuo cluster. Ad esempio, in un cluster con 24 nodi, il numero dovrebbero avere 23 anni. Se il numero di peer non è uno inferiore a quello di nodi nel cluster, riavvia di nuovo l'agente anetd sui nodi.

Abilita la crittografia trasparente tra nodi in un cluster esistente

Per abilitare la crittografia trasparente tra nodi in 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 tuo cluster.
- REGION con la regione di computing del tuo 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 tuo cluster.
- REGION con la regione di computing del tuo cluster.
Attendi fino a quando lo stato non indica "IN ESECUZIONE". Abilitazione della crittografia tra nodi in GKE riavvia automaticamente i nodi. L'operazione potrebbe ore affinché si verifichi il riavvio del nodo e applicare i criteri.
Per verificare che i nodi siano stati riavviati:
```
kubectl get nodes
```
Controlla il campo AGE di ciascun nodo e procedi se il campo AGE riflette 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 dovrebbe 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 abilitare la crittografia trasparente tra nodi in un ambiente multi-cluster:

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

Disattiva la crittografia trasparente tra nodi

In alcuni casi, potresti voler disattivare la crittografia trasparente tra nodi in del tuo cluster GKE per migliorare le prestazioni o per risolvere i problemi e la connettività per la tua applicazione. Prima di procedere con l'operazione, tieni in considerazione quanto segue:

La crittografia trasparente tra nodi è abilitata per l'intero cluster non può disabilitarlo parzialmente in singole risorse Kubernetes, o pod.
Esegui questa operazione durante un periodo di manutenzione perché per interrompere il traffico del pod.

Su un singolo 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 le 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 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 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 app peer aggiornato, devi aggiornare manualmente nell'elenco dei peer di WireGuard su ciascun cluster. Puoi utilizzare la gestione del 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 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. Assicurati di verificare che questa API non sia utilizzata da qualsiasi altro parco risorse prima di disattivarlo per evitare imprevisti comportamento degli utenti.

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 del parco risorse prima di crearne uno nuovo con lo stesso nome.
2. Registra nuovamente il nuovo al momento della ricreazione.
3. Se dimentichi di annullare la registrazione un cluster, elimina la vecchia appartenenza e ricrea il nuovo cluster nuovo abbonamento.
Se non segui questi passaggi, la crittografia multi-cluster potrebbe non verrà attivata sul nuovo cluster finché l'appartenenza al parco risorse non verrà ricreata.

Come funziona la crittografia trasparente tra nodi con GKE

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

Crittografia del traffico di rete tra due pod su nodi diversi

Con la crittografia trasparente tra nodi abilitata, GKE Dataplane V2 cripta Traffico dai pod ai pod se i pod si trovano su nodi diversi, indipendentemente dal cluster a cui appartengono questi nodi. Quando i cluster fanno parte dello stesso flotta, appartengono alla stessa flotta un dominio di crittografia.

I cluster con diverse configurazioni di crittografia trasparente tra nodi possono coesistono nella stessa flotta. 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 nello stesso cluster è criptata utilizzando la coppia di chiave 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 utilizzando il controllo GKE Dataplane V2 ed è accessibile a tutti i nodi nello stesso dominio di crittografia.

Dopo lo scambio delle chiavi, ciascun nodo può stabilire un tunnel WireGuard con ad altri nodi nello stesso dominio di crittografia. Ogni tunnel è univoco per un una coppia di nodi.

Considera quanto segue quando gestisci le coppie di chiavi private o pubbliche chiave di sessione:

Coppia di chiavi private/pubbliche:
- La chiave pubblica è distribuita nel cluster e in tutti i nodi all'interno un cluster può accedere alla chiave pubblica.
- La coppia di chiavi viene ruotata al riavvio del nodo. GKE Le chiavi non vengono ruotate a intervalli regolari. Per attivare manualmente una chiave la rotazione, svuotare e riavviare 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 dei nodi coinvolti nel tunnel.