Daten während der Übertragung in GKE mit nutzerverwalteten Verschlüsselungsschlüsseln verschlüsseln

Standard

Auf dieser Seite erfahren Sie, wie Sie die Verschlüsselung von übertragenen Daten für die Pod-Kommunikation über GKE-Knoten (Google Kubernetes Engine) mit benutzerverwalteten Verschlüsselungsschlüsseln aktivieren.

Standardmäßig verschlüsselt Google alle Daten bei der Übertragung zwischen VMs auf der Ebene der Netzwerkschnittstellen-Controller (NIC, Network Interface Controller), um die Vertraulichkeit der Daten bei der Übertragung zu gewährleisten, unabhängig davon, welcher Dienst oder welche Anwendung auf der VM (einschließlich GKE) ausgeführt wird. Diese Verschlüsselungsebene gilt für alle GKE-Knoten und für Pod-Traffic. Die Verschlüsselungsschlüssel werden von Google bereitgestellt und verwaltet.

Durch die transparente Verschlüsselung zwischen Knoten für die GKE gibt Ihnen Google mehr Kontrolle über die Schlüssel, mit denen der Pod-Traffic zwischen GKE-Knoten verschlüsselt wird. Die Verschlüsselung erfolgt in der GKE mit WireGuard in GKE Dataplane V2, zusätzlich zur Standardverschlüsselung durch die VM-Netzwerkschnittstellen.

Die Kontrolle über die Verschlüsselungsschlüssel direkt in der GKE ist besonders in regulierten Branchen und für Unternehmen hilfreich, die bestimmte Vorschriften einhalten und Sicherheitsüberprüfungen durchführen müssen.

Sie können die transparente Verschlüsselung zwischen Knoten in Einzel- und Mehrfachclusterumgebungen aktivieren. Weitere Informationen zur Funktionsweise dieser Funktion finden Sie unter Transparente Verschlüsselung zwischen Knoten mit GKE.

Beschränkungen

Dieses Feature allein sorgt nicht dafür, dass Google nicht auf die im GKE-Knotenarbeitsspeicher gespeicherten Verschlüsselungsschlüssel zugreifen kann. In einigen regulierten Umgebungen oder Gerichtsbarkeiten oder zur Erfüllung bestimmter Compliance-Anforderungen können Sie diese Schlüssel weiter verschlüsseln und den Zugriff genauer steuern. Dazu empfehlen wir die transparente Verschlüsselung zwischen Knoten mit Confidential GKE Nodes, die vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) verwenden. Confidential GKE Nodes, die CMEK verwenden, verschlüsseln den Arbeitsspeicherinhalt der Knoten mit Schlüsseln, die Sie verwalten.
Die transparente Verschlüsselung zwischen Knoten für GKE wird nur in GKE Dataplane V2-Clustern unterstützt.
GKE Autopilot wird nicht unterstützt.
Für die transparente Verschlüsselung zwischen Knoten in der GKE wird WireGuard verwendet. WireGuard ist nicht FIPS.
Verschlüsselungsschlüssel werden nicht dynamisch rotiert. Die Schlüsselrotation muss manuell durch Neustarten der Knoten durchgeführt werden.
Die transparente Verschlüsselung zwischen Knoten funktioniert in Kombination mit Confidential GKE Nodes nur mit Container-Optimized OS (COS) und Ubuntu, nicht mit Windows.
Die transparente Verschlüsselung zwischen Knoten verschlüsselt keinen Netzwerkverkehr, der vom GKE-Knoten oder einem Pod mithilfe von hostNetwork initiiert wird.
Die transparente Verschlüsselung zwischen Knoten verschlüsselt keinen Netzwerk-Traffic, der an einen über einen Knotenport verfügbar gemachten Pod gesendet wird. Selbst wenn ExternalTrafficPolicy: Cluster für den Dienst konfiguriert ist, ist der Traffic, der vom ersten Knoten, der Traffic vom Client zum Backend-Pod empfängt, weitergeleitet wird, nicht verschlüsselt.
Die maximale Anzahl von Knoten, die bei aktivierter transparenter Verschlüsselung zwischen Knoten für Einzelcluster- oder Multi-Cluster-Konfigurationen unterstützt wird, beträgt 500.
Die transparente Verschlüsselung zwischen Knoten kann dazu führen, dass die Knoten überlastet werden. Auf n2-standard-8-Knoten mit dem Ubuntu-Betriebssystem mit einem Durchsatz von 2 Gbit/s können Sie eine durchschnittliche Erhöhung der CPU-Auslastung von 15 % erwarten.

Die Erhöhung der CPU-Auslastung wird keinem Pod zugeordnet, da sie dem kube-Scheduler nicht bekannt ist. Der Pod mit erhöhtem Traffic kann alle CPU-Ressourcen auf dem Knoten verwenden. Das kann verhindern, dass andere Pods die benötigten CPU-Ressourcen erhalten, selbst wenn sie ordnungsgemäß konfiguriert sind. Dies kann Probleme für Pods verursachen, auf denen sensible Arbeitslasten ausgeführt werden oder die schnell auf Anfragen reagieren müssen. Als Problemumgehung können Sie auf Knoten, auf denen die transparente Verschlüsselung zwischen Knoten aktiviert ist, einen erheblichen Teil der CPU nicht planen. Alternativ können Sie einen Pod mit einer niedrigen PriorityClass planen, der über eine große CPU-Anfrage verfügt, diese CPU aber nie verwendet.
Die transparente Verschlüsselung zwischen Knoten verursacht eine Latenz von 150 Mikrosekunden bei zwei Knoten in derselben Zone, die keine Confidential GKE Nodes verwenden.
Wenn Sie die transparente Verschlüsselung zwischen Knoten aktivieren, funktionieren die Beobachtbarkeitsfunktionen des Traffics, die zum Verfolgen des Traffics auf den Pods verwendet werden, möglicherweise nicht wie erwartet, da die Daten während der Übertragung mit Schlüsseln verschlüsselt werden, die für die zugrunde liegende Google-Infrastruktur nicht zugänglich sind.
Wenn Sie die transparente Verschlüsselung zwischen Knoten aktivieren, sind Pod-IP-Adressen in der VPC nicht sichtbar. Funktionen, die von der Paketprüfung abhängen, wie Paketspiegelung und Pod-CIDR-basierte VPC-Firewallregeln, sind mit der transparenten Verschlüsselung zwischen Knoten nicht kompatibel.
Wenn Sie die transparente Verschlüsselung zwischen Knoten über mit verschiedenen VPC-Subnetzen verknüpften Clustern aktivieren, müssen Sie manuell Firewallregeln erstellen, um die Kommunikation zwischen den Clusterknoten zu ermöglichen.
Die transparente Verschlüsselung zwischen Knoten deaktiviert einige Layer-7-Funktionen von GKE Dataplane V2. Daher können Sie die FQDN-Netzwerkrichtlinie und die transparente Verschlüsselung zwischen Knoten nicht gleichzeitig aktivieren.
Sie können diese Funktion nicht gleichzeitig mit der knoteninternen Sichtbarkeit aktivieren.

Hinweise

Führen Sie die folgenden Schritte durch, bevor Sie beginnen:

Aktivieren Sie die Google Kubernetes Engine API.

Google Kubernetes Engine API aktivieren

Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

Folgen Sie der Anleitung zu GKE Enterprise aktivieren.
Die transparente GKE-Knotenverschlüsselung wird nur in Google Cloud CLI-Version 458.0.0 und höher und den folgenden GKE-Versionen unterstützt:
- 1.26.10-gke.1024000 oder höher
- 1.27.7-gke.1506000 oder höher
- 1.28.2-gke.1098000 oder höher

Transparente Verschlüsselung zwischen Knoten mit GKE aktivieren

Sie können die transparente Verschlüsselung zwischen Knoten mit GKE in einem einzelnen Cluster oder in einer Multi-Cluster-Umgebung aktivieren.

Transparente Verschlüsselung zwischen Knoten in einem neuen Cluster aktivieren

So aktivieren Sie die transparente Verschlüsselung zwischen Knoten in einem neuen Cluster:
```
gcloud container clusters create CLUSTER_NAME \
    --region=REGION \
    --enable-datapane-v2 \
    --in-transit-encryption inter-node-transparent
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME durch den Namen Ihres Clusters.
- REGION durch die Compute-Region Ihres Clusters.
Hinweis: Wir empfehlen, neue Cluster mit aktivierter Verschlüsselung zwischen Knoten zu erstellen, anstatt sie mit deaktivierter Verschlüsselung zwischen Knoten zu erstellen und anschließend zu aktivieren. Die Aktivierung der Verschlüsselung zwischen Knoten zu einer späteren Zeit kann zu Neustarts des Knotenpools führen.
Verifizieren Sie Ihre Konfiguration mit dem folgenden Befehl, der den Verschlüsselungsstatus prüft:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```
Die Ausgabe sieht in etwa so aus:
```
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
```
Hinweis: Prüfen Sie, ob die Anzahl der Peers um eins kleiner ist als die Anzahl der Knoten in Ihrem Cluster. In einem Cluster mit 24 Knoten sollte die Anzahl der Peers beispielsweise 23 betragen. Wenn die Anzahl der Peers nicht um eins kleiner ist als die Anzahl der Knoten im Cluster, starten Sie den anetd-Agent auf Ihren Knoten neu.

Transparente Verschlüsselung zwischen Knoten für einen vorhandenen Cluster aktivieren

So aktivieren Sie die transparente Verschlüsselung zwischen Knoten in einem vorhandenen Cluster:
```
gcloud container clusters update CLUSTER_NAME \
  --in-transit-encryption inter-node-transparent \
  --region=REGION
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME durch den Namen Ihres Clusters.
- REGION durch die Compute-Region Ihres Clusters.
Hinweis: Wir empfehlen, diesen Vorgang während eines Wartungsfensters auszuführen, da er den Traffic zu Ihrem Pod stören kann. Die Clusteraktualisierung und die Installation des Netzwerks für die Verschlüsselung zwischen Knoten kann mehrere Stunden dauern.
So prüfen Sie, ob der Befehl des Google Cloud CLI erfolgreich ausgeführt wurde:
```
gcloud container clusters describe CLUSTER_NAME \
    --region=REGION \
    --format json | jq .status
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME durch den Namen Ihres Clusters.
- REGION durch die Compute-Region Ihres Clusters.
Warten Sie, bis der Status „RUNNING“ (WIRD AUSGEFÜHRT) lautet. Wenn Sie die Verschlüsselung zwischen Knoten in GKE aktivieren, werden die Knoten automatisch neu gestartet. Es kann mehrere Stunden dauern, bis der Neustart erfolgt und die neuen Knoten Richtlinien erzwingen.
So prüfen Sie, ob die Knoten neu gestartet wurden:
```
kubectl get nodes
```
Prüfen Sie das Feld AGE jedes Knotens und fahren Sie fort, wenn das Feld AGE neue Knoten enthält.
Verifizieren Sie Ihre Konfiguration mit dem folgenden Befehl, der den Verschlüsselungsstatus prüft:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```
Die Ausgabe sieht in etwa so aus:
```
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 2)]
```
Prüfen Sie, ob die Anzahl der Peers um eins kleiner ist als die Anzahl der Knoten in Ihrem Cluster. In einem Cluster mit 24 Knoten sollte die Anzahl der Peers beispielsweise 23 betragen. Wenn die Anzahl der Peers nicht um eins kleiner ist als die Anzahl der Knoten im Cluster, starten Sie den anetd-Agent auf Ihren Knoten neu.

Transparente Verschlüsselung zwischen Knoten für mehrere Cluster aktivieren

Die transparente Verschlüsselung zwischen Knoten wird in Autopilot-Clustern nicht unterstützt. Wenn Ihre Flotte Autopilot-Cluster enthält, können diese nicht mit Standardclustern kommunizieren, für die die Verschlüsselung aktiviert ist.

So aktivieren Sie die transparente Verschlüsselung zwischen Knoten in einer Multi-Cluster-Umgebung:

Aktivieren Sie die transparente Verschlüsselung zwischen Knoten in einem neuen Cluster oder in einem vorhandenen Cluster.
Cluster bei einer Flotte registrieren.
Aktivieren Sie die transparente Verschlüsselung zwischen Knoten für die Flotte:
```
gcloud container fleet dataplane-v2-encryption enable --project PROJECT_ID
```
Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.
Prüfen Sie den Status auf allen Knoten:
```
kubectl -n kube-system get pods -l k8s-app=cilium -o name | xargs -I {} kubectl -n kube-system exec -ti {} -- cilium status
```
Die Ausgabe sieht in etwa so aus:
```
...
Encryption: Wireguard [cilium_wg0 (Pubkey: <key>, Port: 51871, Peers: 5)]
...
```
Hinweis: Prüfen Sie, ob die Anzahl der Peers um eins kleiner ist als die Anzahl der Knoten aller registrierten Cluster. In einem Cluster mit 24 Knoten sollte die Anzahl der Peers beispielsweise 23 betragen. Wenn die Anzahl der Peers nicht um eins kleiner ist als die Anzahl der Knoten im Cluster, starten Sie den anetd-Agent auf Ihren Knoten neu.

Transparente Verschlüsselung zwischen Knoten deaktivieren

In einigen Fällen möchten Sie die transparente Verschlüsselung zwischen Knoten in Ihrem GKE-Cluster deaktivieren, um die Leistung zu verbessern oder Probleme mit der Konnektivität Ihrer Anwendung zu beheben. Beachten Sie Folgendes, bevor Sie mit diesem Vorgang fortfahren:

Die transparente Verschlüsselung zwischen Knoten ist für den gesamten Cluster aktiviert und kann nicht teilweise in einzelnen Kubernetes-Ressourcen wie Namespaces oder Pods deaktiviert werden.
Führen Sie diesen Vorgang während eines Wartungsfensters aus, da er den Traffic zu Ihrem Pod stören wird.

In einem einzelnen Cluster

So deaktivieren Sie die transparente Verschlüsselung zwischen Knoten in einem einzelnen Cluster:

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

Ersetzen Sie Folgendes:

CLUSTER_NAME durch den Namen Ihres Clusters.
REGION: mit der Computing-Region Ihres Clusters.

In einem Cluster deaktivieren, der zu einer Flotte gehört

Sie haben zwei Möglichkeiten, die Verschlüsselung für einen Cluster in einer Flotte zu deaktivieren:

Wenn Sie den Cluster vollständig aus der Flotte entfernen möchten, heben Sie die Registrierung des Clusters auf.
Alternativ können Sie den Cluster in der Flotte belassen, aber die Verschlüsselung deaktivieren:
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

Wenn Sie die Verschlüsselung mit diesem Befehl deaktivieren, werden Remote-Knoten aus der Wireguard-Peer-Liste in jedem Cluster entfernt. Je nach Anzahl der beteiligten Cluster und Knoten kann dieser Vorgang mehrere Minuten dauern. Wenn Sie die aktualisierte Anzahl der Peers sehen möchten, müssen Sie die Liste der WireGuard-Peers in jedem Cluster manuell aktualisieren. Sie können Ihr Clusterverwaltungstool oder den folgenden Befehl verwenden:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```

Für eine ganze Clusterflotte deaktivieren

So deaktivieren Sie die transparente Verschlüsselung zwischen Knoten in einer Flotte:
```
gcloud container fleet dataplane-v2-encryption disable --project PROJECT_ID
```
Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.
Wenn Sie die transparente Verschlüsselung zwischen Knoten deaktivieren und die jetzt nicht mehr verwendete API entfernen möchten, deaktivieren Sie die GKE Dataplane V2 API auf Flottenebene. Dadurch wird der GKE Dataplane V2-Controller deaktiviert, der in Ihrer Flotte ausgeführt wird.
```
gcloud services disable gkedataplanev2.googleapis.com \
    --project=PROJECT_ID
```
Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

Hinweis: Diese API ist für das Feature zur transparenten Verschlüsselung zwischen Knoten in Ihrer Flotte verantwortlich. Prüfen Sie, ob diese API nicht von anderen Elementen Ihrer Flotte verwendet wird, bevor Sie sie deaktivieren, um unerwartetes Verhalten zu vermeiden.

So verwalten Sie Cluster mit demselben Namen effizient und sorgen dafür, dass die Verschlüsselung für mehrere Cluster aktiviert ist:
1. Melden Sie den alten Cluster von der Flotte ab, bevor Sie einen neuen mit demselben Namen erstellen.
2. Registrieren Sie den neuen Cluster noch einmal, nachdem Sie ihn neu erstellt haben.
3. Wenn Sie vergessen haben, die Registrierung eines Clusters aufzuheben, löschen Sie die alte Mitgliedschaft und erstellen Sie den neuen Cluster mit einer neuen Mitgliedschaft neu.
Wenn Sie diese Schritte nicht ausführen, wird die Multi-Cluster-Verschlüsselung möglicherweise erst auf dem neuen Cluster aktiviert, wenn die Flottenmitgliedschaft neu erstellt wird.

Funktionsweise der transparenten Verschlüsselung zwischen Knoten mit GKE

In den folgenden Abschnitten wird beschrieben, wie die transparente Verschlüsselung zwischen Knoten funktioniert, wenn Sie sie in Ihrem Cluster aktivieren:

Verschlüsselung des Netzwerktraffics zwischen zwei Pods auf verschiedenen Knoten

Wenn die transparente Verschlüsselung zwischen Knoten aktiviert ist, verschlüsselt GKE Dataplane V2 Pod-zu-Pod-Traffic, wenn sich Pods auf verschiedenen Knoten befinden, unabhängig davon, zu welchem Cluster diese Knoten gehören. Wenn die Cluster zu demselben Gerätepool gehören, gehören sie auch zurselben Verschlüsselungsdomain.

Cluster mit unterschiedlichen knotenübergreifenden Konfigurationen für die transparente Verschlüsselung können in derselben Flotte nebeneinander existieren. Wenn Sie eine Multi-Cluster-Umgebung haben, in der nur einige Cluster die transparente Verschlüsselung zwischen Knoten verwenden, gelten die folgenden Überlegungen:

Die Pod-zu-Pod-Kommunikation zwischen Knoten im selben Cluster wird mit dem öffentlichen/privaten Schlüsselpaar verschlüsselt.
Die Pod-zu-Pod-Kommunikation zwischen einem Knoten in einem Cluster, für den die transparente Verschlüsselung zwischen Knoten aktiviert ist, und einem Knoten in einem Cluster, für den die transparente Verschlüsselung zwischen Knoten nicht aktiviert ist, schlägt fehl.

Generierung und Verwendung von Verschlüsselungsschlüsseln

Wenn die Funktion aktiviert ist, generiert jeder GKE-Knoten im Cluster automatisch ein öffentliches/privates Schlüsselpaar. Die Schlüssel werden als Verschlüsselungsschlüssel bezeichnet.

Der private Schlüssel wird im Arbeitsspeicher (nicht auf dem Laufwerk) gespeichert und verlässt den Knoten nie. Durch die Verwendung von GKE Confidential Nodes wird das Risiko von manipulierten Schlüsseln weiter gesenkt, da auch der Knotenspeicher (mit unterschiedlichen Schlüsseln) verschlüsselt wird.
Der öffentliche Schlüssel wird mithilfe der GKE Dataplane V2-Steuerungsebene für andere Knoten freigegeben und ist für alle Knoten in derselben Verschlüsselungsdomain zugänglich.

Nach dem Austausch der Schlüssel kann jeder Knoten einen WireGuard-Tunnel mit anderen Knoten in derselben Verschlüsselungsdomain herstellen. Jeder Tunnel ist für ein bestimmtes Knotenpaar eindeutig.

Beachten Sie Folgendes, wenn Sie mit privaten oder öffentlichen Schlüsselpaaren und dem Sitzungsschlüssel arbeiten:

Schlüsselpaar mit privatem/öffentlichem Schlüssel:
- Der öffentliche Schlüssel wird im Cluster verteilt und alle Knoten im Cluster können auf den öffentlichen Schlüssel zugreifen.
- Das Schlüsselpaar wird beim Neustart des Knotens rotiert. In GKE werden Schlüssel nicht in regelmäßigen Abständen rotiert. Um eine Schlüsselrotation manuell auszulösen, leeren Sie den Knoten und starten ihn neu. Dadurch wird das ursprüngliche Schlüsselpaar ungültig und ein neues Schlüsselpaar wird generiert.
Sitzungsschlüssel:
- Dieser Schlüssel kann nicht konfiguriert werden.
- Dieser Schlüssel wird alle zwei Minuten rotiert.
- Der Sitzungsschlüssel ist nur für die am Tunnel beteiligten Knoten bestimmt.