Kubernetes-Secrets zu KMS v2 migrieren

Erfahren Sie, wie Sie vorhandene Kubernetes-Secret-Objekte mit Key Management Service-(KMS-)Providerversion 2 in einem Cluster, das Sie mit Kubernetes Engine (OKE) erstellt haben, erneut verschlüsseln.

Die Kubernetes-Cluster-Control Plane speichert sensible Konfigurationsdaten (wie Authentifizierungstoken, Zertifikate und Zugangsdaten) als Kubernetes-Secret-Objekte in etcd. Wenn Sie ein Cluster mit Kubernetes Engine erstellen, können Sie einen Masterverschlüsselungsschlüssel im Oracle Cloud Infrastructure Vault-Service angeben, um die Datenverschlüsselungsschlüssel zu verschlüsseln, die Kubernetes-Secrets im Ruhezustand schützen. Weitere Informationen finden Sie unter Kubernetes-Secrets-at-Rest in etcd verschlüsseln.

Kubernetes verwendet einen KMS-Provider für die Kommunikation zwischen dem Kubernetes-API-Server und dem Kubernetes Engine-KMS-Plug-in. Die KMS-Providerversion ist von der Version des Masterverschlüsselungsschlüssels in Vault getrennt. Bei der Migration von KMS-Providerversion 1 zu KMS-Providerversion 2 müssen Sie keinen neuen Masterverschlüsselungsschlüssel erstellen oder den mit dem Cluster verknüpften Schlüssel ändern. Weitere Informationen zu Kubernetes-KMS-Providern finden Sie unter KMS-Provider für Datenverschlüsselung verwenden in der Kubernetes-Dokumentation.

Die KMS-Providerversion zum Verschlüsseln von Kubernetes-Secret-Objekten hängt von der Kubernetes-Version ab, die auf der Cluster Control Plane ausgeführt wird:

Cluster, die einen Masterverschlüsselungsschlüssel verwenden, den Sie Kubernetes-Versionen vor 1.36.1 verwalten und ausführen, verwenden KMS-Providerversion 1 zum Verschlüsseln von Kubernetes-Secret-Objekten.
Neue Cluster, die mit Kubernetes-Version 1.36.1 oder höher erstellt wurden, und ein von Ihnen verwalteter Masterverschlüsselungsschlüssel verwenden KMS-Providerversion 2 ab dem Zeitpunkt, zu dem das Cluster erstellt wird.
Wenn Sie ein vorhandenes Cluster auf Kubernetes-Version 1.36.1 oder höher upgraden, verwendet Kubernetes Engine die KMS-Providerversion 2. Neue Kubernetes-Secret-Objekte verwenden KMS-Providerversion 2, ebenso wie vorhandene Secret-Objekte, die anschließend aktualisiert werden.

Durch das Upgrade der Cluster Control Plane werden nicht automatisch alle vorhandenen Kubernetes Secret-Objekte neu geschrieben. Secret-Objekte, die vor dem Upgrade mit KMS-Providerversion 1 verschlüsselt wurden, können mit KMS-Providerversion 1 verschlüsselt bleiben, bis Kubernetes sie erneut schreibt.

Kubernetes Engine behält KMS-Providerversion 1 als Lese-Fallback bei, sodass vorhandene Secret-Objekte nach dem Upgrade der Control Plane und während der Migration lesbar bleiben. Sie müssen vorhandene Secret-Objekte nicht sofort migrieren, damit die Anwendungen weiter ausgeführt werden.

Verwenden Sie die Prozedur in diesem Thema, um alle vorhandenen Kubernetes-Secret-Objekte in einem Vorgang neu zu schreiben. Wenn Kubernetes jedes Secret-Objekt neu schreibt, verschlüsselt der Kubernetes-API-Server es mit KMS-Providerversion 2. Nachdem die Migration erfolgreich war, wurden Secret-Objekte, die zuvor mit KMS-Providerversion 1 verschlüsselt wurden, mit KMS-Providerversion 2 neu verschlüsselt.

Beachten Sie Folgendes:

Normalerweise müssen Sie diese Migration nicht für ein neues Cluster ausführen, das mit Kubernetes-Version 1.36.1 oder höher erstellt wurde, da das Cluster KMS-Providerversion 2 ab dem Zeitpunkt der Clustererstellung verwendet.
Sie können die Migration nicht ausführen, während die Cluster Control Plane eine Kubernetes-Version vor 1.36.1 ausführt.
Kubernetes Engine startet keine Massenmigration automatisch, wenn Sie die Cluster Control Plane upgraden. Sie entscheiden, wann die Migration gestartet werden soll.
Eine manuelle Migration ist nur erforderlich, wenn Sie alle vorhandenen, unveränderten Kubernetes-Secret-Objekte in einem Vorgang erneut verschlüsseln möchten.

Hinweis

Diese Prozedur gilt nur für Cluster, die einen Masterverschlüsselungsschlüssel verwenden, den Sie zur Verschlüsselung von Kubernetes-Secret-Objekten im Ruhezustand in etcd verwalten. Sie gilt nicht für Cluster, die nur die Standardverschlüsselung der Blockspeicher-Volumes verwenden, die etcd enthalten.

Bevor Sie beginnen

Vor der Migration von Kubernetes-Secret-Objekten zu KMS-Providerversion 2:

Stellen Sie sicher, dass das Cluster einen Masterverschlüsselungsschlüssel im Oracle Cloud Infrastructure Vault-Service verwendet, den Sie verwalten, um Kubernetes-Secrets im Ruhezustand zu verschlüsseln. Siehe Kubernetes-Secrets-at-Rest in usw. verschlüsseln.
Führen Sie ein Upgrade der Cluster Control Plane auf Kubernetes Version 1.36.1 oder höher durch. Siehe Kubernetes-Version auf Control-Plane‑Knoten in einem Cluster upgraden.
Konfigurieren Sie kubectl für den Zugriff auf das Cluster. Siehe Clusterzugriff einrichten.
Stellen Sie sicher, dass Ihre Kubernetes-Identität die Berechtigung zum Erstellen, Abrufen, Überwachen und Löschen der clusterbezogenen storageversionmigrations.storagemigration.k8s.io-Ressource hat. Ein Clusteradministrator verfügt in der Regel über diese Berechtigungen.
Wenn Sie eine Backuplösung wie Velero verwenden, erstellen Sie ein aktuelles Backup, das alle Kubernetes-Secret-Objekte enthält, und bestätigen Sie, dass das Backup erfolgreich abgeschlossen wurde. Schützen Sie das Backup entsprechend den Sicherheitsanforderungen Ihres Unternehmens, da es vertrauliche Daten enthält.
Planen Sie, die Migration zu überwachen, bis sie erfolgreich ist. Die Migration liest und schreibt jedes Kubernetes-Secret-Objekt im Cluster neu und kann zusätzliche Kubernetes-API-Aktivitäten generieren. Die Migration größerer Cluster kann länger dauern.

Prüfen, ob das Cluster bereit ist

Sie können die interne KMS-Providerkonfiguration der Kubernetes Engine nicht anzeigen. Verwenden Sie stattdessen die Kubernetes-Control-Plane-Version und die Kubernetes-API-Discovery, um zu bestätigen, dass das Cluster für die Migration bereit ist:

Prüfen Sie die Kubernetes-Client- und -Serverversionen, indem Sie Folgendes eingeben:
```
kubectl version
```
Stellen Sie sicher, dass Server Version v1.36.1 oder höher ist.

Die Serverversion ist die Kubernetes-Version, die auf der Cluster Control Plane ausgeführt wird. Die Kubernetes-Versionen, die auf Worker-Knoten ausgeführt werden, bestimmen nicht, ob die Migration von KMS-Providerversion 2 verfügbar ist.

Prüfen Sie, ob die API für die Speicherversionsmigration verfügbar ist, indem Sie Folgendes eingeben:

kubectl api-resources --api-group=storagemigration.k8s.io

Stellen Sie sicher, dass die Ausgabe die Ressource storageversionmigrations enthält, wie die folgenden:


NAME                         SHORTNAMES   APIVERSION                         NAMESPACED   KIND
storageversionmigrations                  storagemigration.k8s.io/v1beta1    false        StorageVersionMigration

Bestätigen Sie, dass Ihre Kubernetes-Identität eine Migration erstellen, überwachen und löschen kann, indem Sie Folgendes eingeben:
```
kubectl auth can-i create storageversionmigrations.storagemigration.k8s.io
```
```
kubectl auth can-i get storageversionmigrations.storagemigration.k8s.io
```
```
kubectl auth can-i watch storageversionmigrations.storagemigration.k8s.io
```
```
kubectl auth can-i delete storageversionmigrations.storagemigration.k8s.io
```
Jeder Befehl muss yes zurückgeben.

Wenn ein Befehl no zurückgibt, bitten Sie einen Clusteradministrator, die Migration auszuführen, oder erteilen Sie ihm die erforderlichen Kubernetes-RBAC-Berechtigungen.

Sie können die Migration starten, wenn alle der folgenden Bedingungen wahr sind:

Das Cluster verwendet einen Masterverschlüsselungsschlüssel, den Sie zur Verschlüsselung von Kubernetes-Secret-Objekten verwalten.
Auf der Cluster Control Plane wird Kubernetes-Version 1.36.1 oder höher ausgeführt.
Die API für die Speicherversionsmigration ist verfügbar.
Ihre Kubernetes-Identität verfügt über die erforderlichen Berechtigungen.

Wenn die API für die Speicherversionsmigration nicht verfügbar ist, versuchen Sie nicht, eine andere Bulk-Rewrite-Prozedur zu verwenden. Stellen Sie sicher, dass kubectl mit dem gewünschten Cluster verbunden ist und dass das Upgrade der Control Plane abgeschlossen ist. Wenn die API weiterhin nicht verfügbar ist, wenden Sie sich an Oracle Support.

Vorhandene Kubernetes-Secret-Objekte migrieren

Weitere Informationen zur Verwendung der Kubernetes Storage-Versionsmigrations-API zum Migrieren gespeicherter Objekte finden Sie unter Kubernetes-Objekte mit Storage-Versionsmigration migrieren in der Kubernetes-Dokumentation.

So verschlüsseln Sie alle vorhandenen Kubernetes-Secret-Objekte mit KMS-Providerversion 2 erneut:

Erstellen Sie eine Datei namens migrate-secrets-to-kms-v2.yaml mit dem folgenden Inhalt:
```
apiVersion: storagemigration.k8s.io/v1beta1
kind: StorageVersionMigration
metadata:
  name: migrate-secrets-to-kms-v2
spec:
  resource:
    group: ""
    resource: secrets
```
Der leere Wert group gibt die Kubernetes-Core-API-Gruppe an. Der Wert resource: secrets begrenzt die Migration zu Kubernetes-Secret-Objekten.

Eine StorageVersionMigration-Ressource ist clusterbezogen. Die Migration umfasst daher Kubernetes-Secret-Objekte in allen Namespaces.
Migration erstellen:
```
kubectl create -f migrate-secrets-to-kms-v2.yaml
```
Beim Erstellen der Ressource wird der Kubernetes-Speicherversionsmigrator angewiesen, die Kubernetes-Secret-Objekte zu lesen und neu zu schreiben. Der Vorgang ändert nicht absichtlich geheime Werte. Wenn jedes Objekt geschrieben wird, verschlüsselt der Kubernetes-API-Server es mit der Konfiguration der aktiven KMS-Providerversion 2.
Überwachen Sie die Migration, und warten Sie, bis sie erfolgreich ist:
```
kubectl wait \
  --for=condition=Succeeded \
  storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2 \
  --timeout=24h
```
Ein erfolgreicher Befehl gibt eine Ausgabe ähnlich der folgenden zurück:
```
storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2 condition met
```
Der Timeout steuert, wie lange kubectl auf die Bedingung wartet. Wenn Sie den Timeout erreichen, wird eine Migration, die noch ausgeführt wird, nicht abgebrochen.

Migration überprüfen

So bestätigen Sie, dass die Migration erfolgreich abgeschlossen wurde:

Migrationsstatus abrufen:

kubectl get \
  storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2 \
  -o yaml

Stellen Sie in der Liste status.conditions sicher, dass die Succeeded-Bedingung den Wert True hat, ähnlich dem Folgenden:
```
status:
  conditions:
  - type: Succeeded
    status: "True"
    reason: StorageVersionMigrationSucceeded
```

Der Status "Erfolgreich" bestätigt, dass Kubernetes die Secret-Objekte neu geschrieben hat. Bei einem Cluster, das einen von Ihnen verwalteten Masterverschlüsselungsschlüssel verwendet und Kubernetes-Version 1.36.1 oder höher ausführt, werden die umgeschriebenen Objekte mit KMS-Providerversion 2 verschlüsselt.

Nachdem Sie bestätigt haben, dass die Migration erfolgreich war, können Sie die abgeschlossene Migrationsressource löschen:

kubectl delete \
  storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2

Sie können auch die lokale Datei migrate-secrets-to-kms-v2.yaml löschen.

Durch das Löschen der Ressource StorageVersionMigration wird die Migration nicht rückgängig gemacht, und es werden keine Kubernetes-Secret-Objekte gelöscht.

Fehlerbehebung bei KMS v2-Migration

Die API zur Speicherversionsmigration ist nicht aufgeführt

Wenn der Befehl kubectl api-resources die Ressource storageversionmigrations nicht auflistet, bestätigen Sie Folgendes:

kubectl verwendet den Kontext für das beabsichtigte Cluster.
Die von kubectl version gemeldete Server Version ist v1.36.1 oder höher.
Das Upgrade der Control Plane wurde erfolgreich abgeschlossen.

Die auf Worker-Knoten ausgeführten Kubernetes-Versionen bestimmen nicht, ob die Migrations-API verfügbar ist.

Wenn alle diese Bedingungen erfüllt sind und die API weiterhin nicht verfügbar ist, wenden Sie sich an Oracle Support. Versuchen Sie nicht, eine andere Bulk-Rewrite-Prozedur zu verwenden.

Die Migration kann nicht erstellt werden

Wenn der Befehl kubectl create einen Forbidden-Fehler zurückgibt, prüfen Sie, ob Ihre Kubernetes-Identität die Migrationsressource erstellen kann:

kubectl auth can-i create storageversionmigrations.storagemigration.k8s.io

Wenn der Befehl no zurückgibt, bitten Sie einen Clusteradministrator, die Migration auszuführen, oder erteilen Sie ihm die erforderlichen Kubernetes-RBAC-Berechtigungen.

Wenn der Befehl kubectl create einen AlreadyExists-Fehler zurückgibt, prüfen Sie die vorhandene Migration:

kubectl get \
  storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2 \
  -o yaml

Wenn die vorhandene Migration erfolgreich abgeschlossen wurde und Sie eine neue Migration ausführen möchten, löschen Sie die abgeschlossene Ressource StorageVersionMigration, bevor Sie sie erneut erstellen.

Die Migration ist nicht erfolgreich

Prüfen Sie den Migrationsstatus und die zugehörigen Ereignisse:

kubectl describe \
  storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2

Wenn die Failed-Bedingung True lautet oder die Migration unvollständig bleibt, behalten Sie die Befehlsausgabe bei, und wenden Sie sich an Oracle Support.

Nicht umgeschriebene Kubernetes-Secret-Objekte bleiben mit dem Fallback des KMS-Providers Version 1 lesbar. Neue Secret-Objekte und vorhandene Secret-Objekte, die über normale Kubernetes-Vorgänge aktualisiert wurden, werden weiterhin mit KMS-Providerversion 2 verschlüsselt.

Oracle Cloud Infrastructure - Dokumentation