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

Standard

Auf dieser Seite wird gezeigt, wie Sie die Verschlüsselung von Daten während der Übertragung für die Pod-Kommunikation zwischen Google Kubernetes Engine-Knoten (GKE) mit vom Nutzer verwalteten 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.

Mit der transparenten Verschlüsselung zwischen Knoten in GKE haben Sie mehr Kontrolle über die Verschlüsselungsschlüssel, die zum Verschlüsseln des Pod-Traffics über GKE-Knoten verwendet werden. GKE führt diese Verschlüsselung zusätzlich zur Standardverschlüsselung von VM-NICs mit WireGuard in GKE Dataplane V2 durch.

Eine solche Kontrolle der Verschlüsselungsschlüssel direkt in GKE ist nützlich, wenn Sie in einer regulierten Branche tätig sind und Compliance- und Sicherheitsprüfungen aus geschäftlichen Gründen benötigen.

Sie können die transparente Verschlüsselung zwischen Knoten in Einzel- und Multi-Cluster-Umgebungen aktivieren. Weitere Informationen zur Funktionsweise dieser Funktion finden Sie unter Funktionsweise der transparenten 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 Speicherinhalt 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.
Die transparente Verschlüsselung zwischen Knoten in GKE verwendet WireGuard. WireGuard ist nicht FIPS-konform.
Verschlüsselungsschlüssel werden nicht dynamisch rotiert. Die Schlüsselrotation muss manuell durch einen Neustart der Knoten erfolgen.
Die transparente Verschlüsselung zwischen Knoten funktioniert zusammen mit Confidential GKE Nodes nur unter Container-Optimized OS (COS) und Ubuntu, nicht unter Windows.
Die transparente Verschlüsselung zwischen Knoten verschlüsselt keinen Netzwerk-Traffic, der vom GKE-Knoten oder von einem Pod mit hostNetwork initiiert wurde.
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 zu einer Überbelegung der Knoten führen. 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 er vom kube-scheduler nicht erkannt wird. 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 zu Problemen bei Pods führen, die versuchen, sensible Arbeitslasten auszuführen oder schnell auf Anfragen antworten müssen. Als Behelfslösung können Sie einen erheblichen Teil der CPU auf Knoten ungeplant halten, für die die transparente Verschlüsselung zwischen Knoten aktiviert ist. 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 auf 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. Features, die von der Paketprüfung abhängen, wie die Paketspiegelung und Pod-CIDR-basierte VPC-Firewallregeln, sind nicht mit der transparenten Verschlüsselung zwischen Knoten 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 Aufgaben aus, 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 für einen neuen Cluster aktivieren

So aktivieren Sie die transparente Verschlüsselung zwischen Knoten für einen 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 Engine-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 für einen 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 Engine-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 Aktualisierung und Installation des Clusters zwischen den 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 Engine-Region Ihres Clusters.
Warten Sie, bis der Status „WIRD AUSGEFÜHRT“ angezeigt wird. Durch Aktivieren der knotenübergreifenden Verschlüsselung in GKE 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.
Mit dem folgenden Befehl können Sie den Verschlüsselungsstatus prüfen:
```
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 aktivieren

Die transparente Verschlüsselung zwischen Knoten wird in Autopilot-Clustern nicht unterstützt. Wenn Ihre Flotte Autopilot-Cluster enthält, können sie 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 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. Bei 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 kann es sinnvoll sein, die transparente Verschlüsselung zwischen Knoten in Ihrem GKE-Cluster zu deaktivieren, um Leistungsverbesserungen zu erzielen oder Fehler bei 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 in einzelnen Kubernetes-Ressourcen wie Namespaces oder Pods nicht teilweise deaktiviert werden.
Führen Sie diesen Vorgang während eines Wartungsfensters aus, da er den Traffic zu Ihrem Pod stören wird.

Auf einem einzelnen Cluster

So deaktivieren Sie die transparente Verschlüsselung zwischen Knoten für einen 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 durch die Compute Engine-Region Ihres Clusters.

In einem Cluster deaktivieren, der Teil einer Flotte ist

Sie können die Verschlüsselung für einen Cluster in einer Flotte mit einer der folgenden beiden Optionen deaktivieren:

Heben Sie die Registrierung des Clusters auf, um den Cluster vollständig aus der Flotte zu entfernen.
Alternativ können Sie den Cluster in der Flotte behalten, 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 die Remoteknoten aus der WireGuard-Peer-Liste auf jedem Cluster entfernt. Dieser Vorgang kann je nach Anzahl der betroffenen Cluster und Knoten einige Minuten dauern. Um die aktualisierte Peer-Anzahl zu sehen, müssen Sie die WireGuard-Peers-Liste für jeden Cluster manuell aktualisieren. Sie können dafür das Clusterverwaltungstool oder den folgenden Befehl verwenden:
```
kubectl -n kube-system exec -ti anetd-XXXX -- cilium status | grep Encryption
```

Für eine gesamte 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. Achten Sie darauf, dass diese API von keinem anderen Nutzer in Ihrer Flotte verwendet wird, bevor Sie sie deaktivieren. So vermeiden Sie unerwartetes Verhalten.

So verwalten Sie Cluster mit demselben Namen effizient und sorgen für die Aktivierung der Multi-Cluster-Verschlüsselung:
1. Heben Sie die Registrierung des alten Clusters für die Flotte auf, bevor Sie einen neuen mit demselben Namen erstellen.
2. Registrieren Sie den neuen Cluster bei der Neuerstellung noch einmal.
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.

So funktioniert die transparente 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 Teil derselben Flotte sind, gehören sie zur selben 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 Anforderungen:

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.

Erstellung 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. Die Verwendung von GKE Confidential Nodes verringert das Risiko, dass Schlüssel manipuliert werden, da auch der Knotenarbeitsspeicher verschlüsselt ist (mit verschiedenen Schlüsseln).
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 einrichten. Jeder Tunnel ist für ein bestimmtes Knotenpaar eindeutig.

Beachten Sie beim Umgang mit privaten oder öffentlichen Schlüsselpaaren und dem Sitzungsschlüssel Folgendes:

Paar aus 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 rotiert, wenn der Knoten neu gestartet wird. GKE rotiert Schlüssel nicht in regelmäßigen Abständen. 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 es wird ein neues Schlüsselpaar generiert.
Sitzungsschlüssel:
- Dieser Schlüssel ist nicht konfigurierbar.
- Dieser Schlüssel wird regelmäßig alle zwei Minuten rotiert.
- Der Sitzungsschlüssel ist ausschließlich für die Knoten verfügbar, die am Tunnel beteiligt sind.