Secrets auf Anwendungsebene verschlüsseln

Autopilot Standard

---

Erfahren Sie, wie Sie Kubernetes-Secrets auf Anwendungsebene mit einem Schlüssel verschlüsseln, den Sie in Cloud Key Management Service (Cloud KMS) verwalten. Da dieses Feature auf Cloud KMS-Funktionen basiert, sollten Sie sich mit der Schlüsselrotation und der Umschlagverschlüsselung vertraut machen.

---

Klicken Sie auf Anleitung, um eine detaillierte Anleitung für diese Aufgabe direkt in der Google Cloud Console aufzurufen.

Anleitung

---

Übersicht

Google Kubernetes Engine (GKE) verschlüsselt standardmäßig inaktive Kundendaten, einschließlich Secrets. GKE verarbeitet und verwaltet diese Standardverschlüsselung, sodass von Ihrer Seite keine weiteren Maßnahmen erforderlich sind.

Die Secret-Verschlüsselung auf Anwendungsebene erhöht die Sicherheit der in etcd gespeicherten sensiblen Daten, wie etwa Secrets. Sie verwenden einen mit Cloud KMS verwalteten Schlüssel, um inaktive Daten auf Anwendungsebene zu verschlüsseln. Diese Verschlüsselung schützt vor Angreifern, die Zugriff auf eine Offline-Kopie von etcd haben.

Sie müssen zuerst einen Cloud KMS-Schlüssel erstellen und dem GKE-Dienstkonto Zugriff auf den Schlüssel gewähren, um die Verschlüsselung von Secrets auf Anwendungsebene verwenden zu können. Sie können einen Schlüssel mit einer beliebigen von Cloud KMS unterstützten Schutzstufe verwenden.

Achten Sie darauf, dass sich der Schlüssel am selben Speicherort wie der Cluster befindet, um die Latenz zu verringern und um Situationen zu vermeiden, bei denen Ressourcen von Diensten abhängen, die über mehrere fehlerhafte Domains verteilt sind. Nach dem Erstellen eines Schlüssels können Sie das Feature auf einem neuen oder vorhandenen Cluster aktivieren. Dazu geben Sie den Schlüssel an, den Sie verwenden möchten. Wenn Sie dieses Feature aktivieren, verschlüsselt GKE alle neuen und vorhandenen Secrets mit Ihrem Verschlüsselungsschlüssel.

Hinweis: Wenn Sie CMEK in GKE verwenden, können Ihre Projekte Kontingente für kryptografische Anfragen verbrauchen. GKE kann diese Kontingente beispielsweise nutzen, wenn ein Schlüsselverschlüsselungsschlüssel aus Cloud KMS verwendet wird, um einen Datenverschlüsselungsschlüssel in GKE zu verschlüsseln oder zu entschlüsseln. Ver- und Entschlüsselungsvorgänge über CMEK-Schlüssel wirken sich nur dann auf Cloud KMS-Kontingente aus, wenn Sie Hardware- (Cloud HSM) oder externe Schlüssel (Cloud EKM) verwenden. Weitere Informationen finden Sie unter Cloud KMS-Kontingente.

Umschlagverschlüsselung

Kubernetes bietet eine Umschlagverschlüsselung von Secrets durch einen KMS-Anbieter. Dies bedeutet, dass zur Verschlüsselung der Secrets ein lokaler Schlüssel verwendet wird. Dieser wird im Allgemeinen als Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) bezeichnet. Der DEK selbst wird durch einen anderen Schlüssel, den Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK), verschlüsselt. Kubernetes speichert den KEK nicht.

Die Umschlagverschlüsselung bietet folgende Vorteile:

• Verbesserte Leistung im Vergleich zur Verschlüsselung mit einem öffentlichen Schlüssel: GKE verwendet die Cloud KMS API nur zum Verschlüsseln neuer DEKs mit dem KEK oder zum Entschlüsseln eines DEK, wenn der lokale Cache leer ist.
• Bessere Verwaltung von Schlüsseln in großem Maßstab: Ein einzelner KEK kann mehrere DEKs verschlüsseln. Die Anzahl der Schlüssel, die Sie im Cloud KMS-Dienst speichern müssen, ist weitaus geringer als die Anzahl der Schlüssel, die Ihre Daten verschlüsseln.
• Möglichkeit, einen zentralen Root of Trust zu verwenden: Secrets, die in Kubernetes gespeichert sind, können sich auf einen externen Root of Trust verlassen. Dies bedeutet, dass Sie einen zentralen Root of Trust, z. B. ein Hardwaresicherheitsmodul, für alle Ihre Secrets verwenden können. Ein Angreifer, der offline auf Ihre Container zugreift, kann Ihre Secrets nicht abrufen.

Mit Verschlüsselung von Secrets auf Anwendungsebene in GKE verschlüsselt GKE Ihre Secrets mit lokalen DEKs und dem AES-CBC. GKE verschlüsselt die DEKs mit einem KEK, den Sie in Cloud KMS verwalten.

Weitere Informationen zur Umschlagverschlüsselung finden Sie unter Umschlagverschlüsselung.

Was geschieht, wenn Sie ein Secret erstellen?

Wenn Sie ein neues Secret erstellen, geschieht Folgendes:

1. Der Kubernetes API-Server generiert mit einem Zufallszahlengenerator einen eindeutigen DEK für das Secret.

2. Der Kubernetes API-Server verwendet den DEK lokal, um das Secret zu verschlüsseln.

3. Das KMS-Plug-in sendet den DEK zur Verschlüsselung an Cloud KMS. Das KMS-Plug-in authentifiziert sich über das GKE-Dienstkonto Ihres Projekts bei Cloud KMS.

4. Cloud KMS verschlüsselt den DEK mit dem KEK und sendet ihn an das KMS-Plug-in zurück.

5. Der Kubernetes API-Server speichert das verschlüsselte Secret und den verschlüsselten DEK. Der Klartext-DEK wird nicht auf einem Laufwerk, sondern nur im Arbeitsspeicher des API-Servers gespeichert.

6. Der Kubernetes API-Server erstellt einen Cache-Eintrag, der den verschlüsselten DEK dem speicherinternen Klartext-DEK zuordnet. Dadurch kann der API-Server das Secret entschlüsseln, ohne Cloud KMS zu verwenden.

Wenn ein Client ein Secret vom Kubernetes API-Server anfordert, passiert Folgendes:

1. Der Kubernetes API-Server ruft das verschlüsselte Secret und den verschlüsselten DEK ab.

2. Der Kubernetes API-Server prüft den Cache auf einen vorhandenen Zuordnungseintrag und entschlüsselt das Secret, ohne Cloud KMS zu verwenden.

3. Wenn kein Cache-Eintrag gefunden wird, sendet das KMS-Plug-in den DEK zur Entschlüsselung mithilfe des KEK an Cloud KMS. Der entschlüsselte DEK wird dann zur Entschlüsselung des Secrets verwendet.

4. Der Kubernetes API-Server gibt das entschlüsselte Secret an den Client zurück.

Was geschieht, wenn Sie einen Schlüssel löschen?

Warnung: Das Löschen eines Schlüssels ist nicht umkehrbar – Daten, die mit der gelöschten Version verschlüsselt wurden, können nicht wiederhergestellt werden.

Wenn Sie in Cloud KMS einen KEK löschen, der ein Secret in GKE verschlüsselt hat, ist das Secret nicht mehr verfügbar, es sei denn, Sie aktualisieren den Cluster, um zuerst einen neuen KEK zu verwenden.

Wenn Sie eine alte KEK-Version nach einer Schlüsselrotation löschen möchten, sollten Sie zuerst die neue KEK-Version zum neu Verschlüsselndes Secrets verwenden. Sie können optional die vorherige KEK-Version beibehalten, um eine Neuverschlüsselung von Secrets zu vermeiden. Ihnen werden jedoch weiterhin alle aktiven KEKs in Cloud KMS in Rechnung gestellt. Weitere Informationen zur Preisgestaltung finden Sie unter Cloud KMS – Preise.

Hinweis: Löschen Sie nur frühere KEK-Versionen, wenn Sie sicher sind, dass keine Daten in Ihrem Cluster mit der vorherigen Version verschlüsselt wurden. Bevor Sie einen KEK löschen, sollten Sie prüfen, ob der Schlüssel verwendet wird. Weitere Informationen finden Sie unter Schlüsselversionen löschen und wiederherstellen.

Sofern keine Volume-Projektion für Dienstkontotoken verwendet wird, nutzen Dienstkonten von Arbeitslasten in GKE ebenfalls Secrets. Diese sind nach dem Löschen eines Schlüssels nicht mehr verfügbar. Ohne Zugriff auf die Secrets schlagen die Arbeitslasten fehl.

Es gelten folgende Ausnahmen:

• Pods mit vorhandenem Zugriff auf Secrets als bereitgestellte Volumes oder Umgebungsvariablen behalten den Zugriff.

• Nachdem Sie den KEK gelöscht haben, kann der Kubernetes API-Server weiterhin Cache-KMS-Zuordnungseinträge zum Entschlüsseln von Secrets verwenden. Auf diese Weise können neu gestartete oder verschobene Pods auf das Secret zugreifen, sofern keine der folgenden Situationen eintritt:

  • Die Steuerungsebene des Clusters neu gestartet wird.
  • Der Kubernetes API-Server-Pod neu gestartet wird.
  • Der DEK-Zuordnungseintrag für das Secret sich nicht im Cache des Kubernetes API-Servers befindet.

Bevor Sie einen KEK löschen, prüfen Sie, ob er von Ihrem Cluster verwendet wird. Sie können auch in Cloud KMS eine Benachrichtigungsrichtlinie erstellen, mit der Schlüssel gelöscht werden können.

Hinweis

• Für die Übungen in diesem Thema benötigen Sie zwei Google Cloud-Projekte:

  • Schlüsselprojekt: Hier erstellen Sie einen KEK.

  • Clusterprojekt: Hier erstellen Sie einen Cluster, der die Verschlüsselung auf Anwendungsebene aktiviert.

  Hinweis: Sie können als Schlüsselprojekt und Clusterprojekt dasselbe Projekt verwenden. Es wird jedoch empfohlen, separate Projekte zu verwenden.

• Stellen Sie in Ihrem Schlüsselprojekt sicher, dass Sie die Cloud KMS API aktiviert haben.

  Cloud KMS API aktivieren

• In Ihrem Schlüsselprojekt benötigt der Nutzer, der Schlüsselbund und Schlüssel erstellt, die folgenden IAM-Berechtigungen:

  • cloudkms.keyRings.getIamPolicy
  • cloudkms.keyRings.setIamPolicy

  Diese und weitere Berechtigungen sind in der vordefinierten roles/cloudkms.adminIAM-Rolle enthalten. Weitere Informationen zum Erteilen von Berechtigungen zur Schlüsselverwaltung finden Sie in der Cloud KMS-Dokumentation.

• Achten Sie darauf, dass in Ihrem Clusterprojekt die Google Kubernetes Engine API aktiviert ist.

  Google Kubernetes Engine API aktivieren

• Prüfen Sie, ob das Google Cloud CLI installiert ist.

• Aktualisieren Sie gcloud auf die neueste Version:

  gcloud components update

Cloud KMS-Schlüssel erstellen

Zum Erstellen eines Cloud KMS-Schlüssels müssen Sie zuerst einen Schlüsselbund erstellen. Schlüssel und Schlüsselbunde sind regionale Ressourcen. Geben Sie beim Erstellen eines Schlüsselbunds einen Speicherort an, der dem Standort Ihres GKE-Clusters entspricht:

• Ein zonaler Cluster sollte einen Schlüsselbund von einem übergeordneten Ort aus verwenden. Ein Cluster in der Zone us-central1-a kann beispielsweise nur einen Schlüssel in der Region us-central1 verwenden.

• Ein regionaler Cluster sollte einen Schlüsselbund am selben Speicherort verwenden. Beispielsweise sollte ein Cluster in der Region asia-northeast1 mit einem Schlüsselbund aus der Region asia-northeast1 geschützt werden.

Hinweis: Die Cloud KMS-Region global wird für die Verwendung mit GKE nicht unterstützt.

Sie können die gcloud CLI oder die Google Cloud Console verwenden.

Console

Erstellen Sie in Ihrem Schlüsselprojekt einen Schlüsselbund:

1. Rufen Sie in der Google Cloud Console die Seite Schlüsselverwaltung auf.

   Key Management aufrufen

2. Klicken Sie auf KeyRing erstellen.

3. Geben Sie im Feld Schlüsselbundname einen Namen für den Schlüsselbund ein.

4. Wählen Sie aus der Drop-down-Liste Location (Speicherort) den Speicherort Ihres Kubernetes-Clusters aus.

5. Klicken Sie auf Erstellen.

Erstellen Sie als Nächstes einen Schlüssel:

1. Rufen Sie in der Google Cloud Console die Seite Schlüsselverwaltung auf.

   Key Management aufrufen

2. Klicken Sie auf den Namen des Schlüsselbunds, für den Sie einen Schlüssel erstellen.

3. Klicken Sie auf Schlüssel erstellen.

4. Geben Sie im Feld Schlüsselname einen Namen für den Schlüssel ein.

5. Akzeptieren Sie die Standardwerte für Rotationszeitraum und Ab dem oder legen Sie einen Schlüsselrotationszeitraum und einen Beginn fest, wenn Sie andere Werte verwenden möchten.

6. [Optional] Klicken Sie im Feld Labels auf Label hinzufügen, wenn Sie Ihren Schlüssel mit Labels versehen möchten.

7. Klicken Sie auf Erstellen.

gcloud

Erstellen Sie in Ihrem Schlüsselprojekt einen Schlüsselbund:

gcloud kms keyrings create RING_NAME \
    --location=LOCATION \
    --project=KEY_PROJECT_ID

Dabei gilt:

• RING_NAME: Name des neuen Schlüsselbunds.
• LOCATION ist der Ort, an dem Sie den Schlüsselbund erstellen möchten.
• KEY_PROJECT_ID: Ihre Schlüsselprojekt-ID.

Schlüssel erstellen:

gcloud kms keys create KEY_NAME \
    --location=LOCATION \
    --keyring=RING_NAME \
    --purpose=encryption \
    --project=KEY_PROJECT_ID

Dabei gilt:

• KEY_NAME: Der Name des neuen Schlüssels.
• LOCATION ist der Cloud KMS-Speicherort, an dem Sie den Schlüsselbund erstellt haben.
• RING_NAME: der Name des Schlüsselbunds.
• KEY_PROJECT_ID: Ihre Schlüsselprojekt-ID.

Verwendung des Schlüssels erlauben

Das GKE-Dienstkonto in Ihrem Clusterprojekt hat folgenden Namen:

[e-mail]

Ersetzen Sie CLUSTER_PROJECT_NUMBER durch die Projektnummer Ihres Clusters. Führen Sie den folgenden Befehl aus, um Ihre Projektnummer mit der gcloud CLI zu ermitteln:

gcloud projects describe CLUSTER_PROJECT_ID \
    --format="value(projectNumber)"

Zur Gewährung des Zugriffs auf das Dienstkonto können Sie die Google Cloud Console oder die gcloud CLI verwenden.

Console

Gewähren Sie Ihrem GKE-Dienstkonto die Cloud KMS-Rolle CryptoKey Encrypter/Decrypter:

1. Öffnen Sie in der Google Cloud Console den Browser für Cloud Key Management Service-Schlüssel.
   Zum Browser für Cloud KMS-Schlüssel

2. Klicken Sie auf den Namen des Schlüsselbunds, der den gewünschten Schlüssel enthält.

3. Klicken Sie das Kästchen für den gewünschten Schlüssel an.

   Der Tab Berechtigungen im rechten Fensterbereich wird verfügbar.

4. Geben Sie im Dialogfeld Mitglieder hinzufügen die E-Mail-Adresse des GKE-Dienstkontos an, auf das Sie Zugriff gewähren.

5. Wählen Sie im Drop-down-Menü Rolle auswählen die Option Cloud KMS CryptoKey-Verschlüsseler/Entschlüsseler aus.

6. Klicken Sie auf Speichern.

gcloud

Gewähren Sie Ihrem GKE-Dienstkonto die Cloud KMS-Rolle CryptoKey Encrypter/Decrypter:

gcloud kms keys add-iam-policy-binding KEY_NAME \
    --location=LOCATION \
    --keyring=RING_NAME \
    --member=serviceAccount:SERVICE_ACCOUNT_NAME \
    --role=roles/cloudkms.cryptoKeyEncrypterDecrypter \
    --project=KEY_PROJECT_ID

Dabei gilt:

• KEY_NAME: der Name des Schlüssels
• LOCATION ist der Cloud KMS-Speicherort, an dem Sie den Schlüsselbund erstellt haben.
• RING_NAME: der Name des Schlüsselbunds.
• SERVICE_ACCOUNT_NAME ist der Name Ihres GKE-Dienstkontos.
• KEY_PROJECT_ID: Ihre Schlüsselprojekt-ID

Sicherstellen, dass ein Cloud HSM-Schlüssel ein ausreichendes Kontingent hat

Wenn Sie einen Cloud HSM-Schlüssel verwenden, wird das Google Cloud-Projekt, das den Schlüssel enthält, durch Ihr Schlüsselkontingent begrenzt. Achten Sie darauf, dass Ihr Kontingent für die Verwendung Ihrer Cloud HSM-Schlüssel mit Verschlüsselung von Secrets auf Anwendungsebene ausreicht. Wenn Ihr Kontingent aufgebraucht ist, können die Knoten die Verbindung zur Clustersteuerungsebene verlieren.

Verschlüsselung von Secrets auf Anwendungsebene aktivieren

Sie können die Verschlüsselung von Secrets auf Anwendungsebene für neue oder vorhandene GKE-Standard- und GKE-Autopilot-Cluster mit der gcloud CLI oder der Google Cloud Console aktivieren.

Nachdem Sie die Verschlüsselung von Secrets auf Anwendungsebene aktiviert haben, empfehlen wir, eine Schlüsselrotation durchzuführen. Sie können die automatische Schlüsselrotation in Cloud KMS konfigurieren. Eine Anleitung finden Sie unter Automatische Rotation konfigurieren.

In einem neuen Cluster

Sie können einen neuen Cluster mit aktivierter Secret-Verschlüsselung auf Anwendungsebene mit der Google Cloud Console oder der gcloud CLI erstellen.

Console – Autopilot

Führen Sie die folgenden Schritte aus, um einen Autopilot-Cluster mit aktivierter Secret-Verschlüsselung auf Anwendungsebene zu erstellen:

1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

   Zur Seite „Google Kubernetes Engine“

2. Klicken Sie auf Erstellen.

3. Klicken Sie im Abschnitt Autopilot auf Konfigurieren.

4. Konfigurieren Sie den Cluster wie gewünscht.

5. Klicken Sie im Navigationsbereich auf Erweiterte Optionen und maximieren Sie den Abschnitt Sicherheit.

6. Klicken Sie das Kästchen Secrets-Verschlüsselung auf Anwendungsebene aktivieren an und wählen Sie den Schlüssel aus, den Sie unter Cloud KMS-Schlüssel erstellen erstellt haben.

7. Klicken Sie auf Erstellen.

Console – Standard

Führen Sie die folgenden Schritte aus, um einen Standardcluster mit aktivierter Secret-Verschlüsselung auf Anwendungsebene zu erstellen:

1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

   Zur Seite „Google Kubernetes Engine“

2. Klicken Sie auf Erstellen.

3. Klicken Sie unter Standard auf Konfigurieren.

4. Konfigurieren Sie den Cluster wie gewünscht.

5. Klicken Sie im Navigationsbereich unter Cluster auf Sicherheit.

6. Klicken Sie das Kästchen Secrets-Verschlüsselung auf Anwendungsebene aktivieren an und wählen Sie den Schlüssel aus, den Sie unter Cloud KMS-Schlüssel erstellen erstellt haben.

7. Klicken Sie auf Erstellen.

gcloud

Geben Sie in Ihrem Befehl zur Erstellung einen Wert für den Parameter --database-encryption-key an, um einen Cluster zu erstellen, der die Secret-Verschlüsselung auf Anwendungsebene unterstützt.

gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=latest \
    --region=COMPUTE_REGION \
    --database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project=CLUSTER_PROJECT_ID

Dabei gilt:

• CLUSTER_NAME ist der von Ihnen für den neuen Cluster ausgewählte Name.
• COMPUTE_REGION: die Computing-Region, in der Sie den Cluster erstellen möchten.
• KEY_PROJECT_ID: Ihre Schlüsselprojekt-ID.
• LOCATION ist der Cloud KMS-Speicherort, an dem Sie den Schlüsselbund erstellt haben.
• RING_NAME: der Name des Schlüsselbunds.
• KEY_NAME: der Name des Schlüssels
• CLUSTER_PROJECT_ID: die Projekt-ID Ihres Clusters.

Sie können die Verschlüsselung von Secrets auf Anwendungsebene für einen neuen Standardcluster mit dem Befehl gcloud container clusters create mit denselben Flags aktivieren.

In einem vorhandenen Cluster

Sie können einen vorhandenen Cluster über die gcloud CLI oder die Google Cloud Console aktualisieren, um die Verschlüsselung von Secrets auf Anwendungsebene zu verwenden. GKE verschlüsselt alle vorhandenen und neuen Secrets mit dem angegebenen Verschlüsselungsschlüssel.

Wichtig: Beim Aktualisieren eines vorhandenen Clusters, um die Secret-Verschlüsselung auf Anwendungsebene zu verwenden, wird die Steuerungsebene des Clusters neu gestartet. Bei zonalen Clustern ist die Steuerungsebene nicht mehr verfügbar.

Console

So aktualisieren Sie einen Cluster für die Secret-Verschlüsselung auf Anwendungsebene:

1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

   Zur Seite "Google Kubernetes Engine"

2. Klicken Sie auf den Namen des Clusters, den Sie ändern möchten.

3. Klicken Sie unter Sicherheit im Feld Secret-Verschlüsselung auf Anwendungsebene auf Secret-Verschlüsselung auf Anwendungsebene bearbeiten.

4. Klicken Sie das Kästchen Secrets-Verschlüsselung auf Anwendungsebene aktivieren an und wählen Sie den Schlüssel aus, den Sie unter Cloud KMS-Schlüssel erstellen erstellt haben.

5. Klicken Sie auf Änderungen speichern.

gcloud

Führen Sie den folgenden Befehl aus, um Secret-Verschlüsselungen auf Anwendungsebene für einen vorhandenen Cluster zu aktivieren:

gcloud container clusters update CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project=CLUSTER_PROJECT_ID

Dabei gilt:

• CLUSTER_NAME: Der Name Ihres Clusters.
• COMPUTE_REGION ist die Compute Engine-Region des Clusters.
• KEY_PROJECT_ID: Ihre Schlüsselprojekt-ID.
• LOCATION ist der Cloud KMS-Speicherort, an dem Sie den Schlüsselbund erstellt haben.
• RING_NAME: der Name des Schlüsselbunds.
• KEY_NAME: der Name des Schlüssels
• CLUSTER_PROJECT_ID: die Projekt-ID Ihres Clusters.

Cloud KMS-Schlüssel aktualisieren

Sie können einen vorhandenen Cluster mit der gcloud CLI oder der Google Cloud Console aktualisieren, um einen neuen Cloud KMS-Schlüssel zu verwenden.

Wichtig: Beim Aktualisieren eines vorhandenen Clusters zur Verwendung eines neuen Cloud KMS-Schlüssels wird die Cluster-Kontrollebene neu gestartet. Bei zonalen Clustern ist die Steuerungsebene nicht mehr verfügbar.

Console

So aktualisieren Sie einen Cluster zur Verwendung eines neuen Cloud KMS-Schlüssels:

1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

   Zur Seite "Google Kubernetes Engine"

2. Klicken Sie auf den Namen des Clusters, den Sie ändern möchten.

3. Klicken Sie unter Sicherheit im Feld Secret-Verschlüsselung auf Anwendungsebene auf Secret-Verschlüsselung auf Anwendungsebene bearbeiten.

4. Wählen Sie den neuen Verschlüsselungsschlüssel aus, den Sie verwenden möchten.

5. Klicken Sie auf Änderungen speichern.

gcloud

Aktualisieren Sie Ihren vorhandenen Cluster, um einen neuen Cloud KMS-Schlüssel zu verwenden:

gcloud container clusters update CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --database-encryption-key=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME \
    --project=CLUSTER_PROJECT_ID

Dabei gilt:

• CLUSTER_NAME: Der Name Ihres Clusters.
• COMPUTE_REGION ist die Compute Engine-Region des Clusters.
• KEY_PROJECT_ID: Ihre Schlüsselprojekt-ID.
• LOCATION ist der Cloud KMS-Speicherort, an dem Sie den Schlüsselbund erstellt haben.
• RING_NAME: der Name des Schlüsselbunds.
• KEY_NAME: der Name des Schlüssels
• CLUSTER_PROJECT_ID: die Projekt-ID Ihres Clusters.

Secret-Verschlüsselung auf Anwendungsebene deaktivieren

Zum Deaktivieren der Verschlüsselung von Secrets auf Anwendungsebene können Sie die gcloud CLI oder die Google Cloud Console verwenden.

Console

1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

   Zur Seite "Google Kubernetes Engine"

2. Klicken Sie auf den Namen des Clusters, den Sie ändern möchten.

3. Klicken Sie unter Sicherheit im Feld Secret-Verschlüsselung auf Anwendungsebene auf Secret-Verschlüsselung auf Anwendungsebene bearbeiten.

4. Entfernen Sie das Häkchen aus dem Kästchen Secret-Verschlüsselung auf Anwendungsebene aktivieren.

5. Klicken Sie auf Änderungen speichern.

gcloud

Führen Sie den folgenden Befehl aus, um die Secret-Verschlüsselung auf Anwendungsebene zu deaktivieren:

gcloud container clusters update CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --disable-database-encryption \
    --project=CLUSTER_PROJECT_ID

Dabei gilt:

• CLUSTER_NAME: Der Name Ihres Clusters.
• COMPUTE_REGION ist die Compute Engine-Region des Clusters.
• CLUSTER_PROJECT_ID: die Projekt-ID Ihres Clusters.

Aktivierung der Secret-Verschlüsselung auf Anwendungsebene prüfen

Sie können mithilfe der Google Cloud Console oder mithilfe der gcloud CLI prüfen, ob ein Cluster die Secret-Verschlüsselung auf Anwendungsebene verwendet.

Console

1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

   Zur Seite "Google Kubernetes Engine"

2. Klicken Sie auf den Namen des Clusters, den Sie ändern möchten.

3. Prüfen Sie unter Sicherheit, ob im Feld Verschlüsselung von Secrets auf Anwendungsebene Enabled und der richtige Schlüssel angezeigt werden.

gcloud

Prüfen Sie, ob ein Cluster Verschlüsselung von Secrets auf Anwendungsebene verwendet:

gcloud container clusters describe CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --format='value(databaseEncryption)' \
    --project=CLUSTER_PROJECT_ID

Dabei gilt:

• CLUSTER_NAME: Der Name Ihres Clusters.
• COMPUTE_REGION ist die Compute Engine-Region des Clusters.
• CLUSTER_PROJECT_ID: die Projekt-ID Ihres Clusters.

Wenn der Cluster die Secret-Verschlüsselung auf Anwendungsebene verwendet, sieht die Ausgabe in etwa so aus:

keyName=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME;state=ENCRYPTED

Schlüssel rotieren

Wir empfehlen, Schlüssel nach einem regelmäßigen Zeitplan zu rotieren, auch nachdem Sie die Verschlüsselung von Secrets auf Anwendungsebene aktiviert haben. Eine Anleitung zum Konfigurieren der automatischen Schlüsselrotation oder zum manuellen Rotieren Ihrer Schlüssel finden Sie unter Schlüssel rotieren.

Bei einer Schlüsselrotation werden Ihre vorhandenen Secrets mit dem vorherigen KEK verschlüsselt. Damit eine neuere KEK-Version ein Secret umschließt, verschlüsseln Sie das Secret nach der Schlüsselrotation neu.

Beispielsweise erstellen und speichern Sie ein Secret, Secret1. Es ist mit DEK1 verschlüsselt, das wiederum mit KEKv1 umschlossen ist.

Nach der Rotation des KEKs verschlüsseln Sie Secret1 noch einmal, damit es von DEK2 umschlossen wird, das wiederum mit KEKv2, dem rotierten KEK, umschlossen ist.

Hinweis: Die Rotation der Schlüsselversion ist ein Vorgang mit Eventual Consistency. Es kann daher zu einer Verzögerung kommen, bevor die neue Schlüsselversion wirksam wird. Es empfiehlt sich, mindestens drei Stunden zu warten, bevor Sie Ihre Secrets nach einer Rotation neu verschlüsseln. Weitere Informationen finden Sie unter Konsistenz der Schlüsselversionen.

Secrets neu verschlüsseln

Nach einer Schlüsselrotation sollten Sie Ihre Secrets neu verschlüsseln, um sie mit der neuen Version des KEK zu verpacken. Sie können zwar keine automatische Neuverschlüsselung mit der gcloud CLI konfigurieren, Sie können aber beispielsweise einen CronJob verwenden, um den Befehl zur Neuverschlüsselung in regelmäßigen Abständen auszuführen.

Um Ihre Secrets nach einer Schlüsselrotation manuell neu zu verschlüsseln, warten Sie mindestens drei Stunden, bis die neue Version konsistent ist. Tippen Sie dann auf jedes Secret, um die Neuverschlüsselung mit einem Befehl wie dem folgenden zu erzwingen:

kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - encryption-key-rotation-time="TIME"

Ersetzen Sie TIME durch einen String, der angibt, wann die Rotation stattfindet (z. B. 20200909-090909).

Hinweis: Die alte Schlüsselversion ist weiterhin vorhanden und verursacht Kosten. Wenn die alte Version nicht mehr verwendet wird, sollten Sie sie löschen. Da die Schlüsselversion endgültig gelöscht wird, müssen Sie die Secrets noch einmal verschlüsseln, bevor Sie das tun.

Beschränkungen

• GKE unterstützt bis zu 30.000 Secrets pro Cluster für die Secret-Verschlüsselung auf Anwendungsebene. Wenn Sie mehr als 30.000 Secrets speichern, wird Ihr Cluster zum Zeitpunkt des Upgrades möglicherweise instabil, was zu einem potenziellen Ausfall Ihrer Arbeitslasten führen kann.
• Achten Sie darauf, dass die durchschnittliche Größe der Metadaten eines Secrets in jedem Namespace unter 5 KiB liegt. Wenn die durchschnittliche Größe der Metadaten über 5 KiB liegt, wechselt der Cluster möglicherweise in einen fehlerhaften Zustand, in dem einige Secrets verschlüsselt sind, während andere nach dem Aktivieren oder dem Deaktivieren des Features entschlüsselt werden.

• Sie müssen einen Schlüssel in derselben Region wie der Cluster auswählen. Beispielsweise kann ein zonaler Cluster in us-central1-a nur einen Schlüssel in der Region us-central1 verwenden. Bei regionalen Clustern müssen sich Schlüssel am selben Speicherort befinden, um die Latenz zu verringern und um Situationen zu vermeiden, bei denen Ressourcen von Diensten abhängen, die über mehrere fehlerhafte Domains verteilt sind.

  Hinweis: Der Schlüssel muss sich nicht im selben Projekt wie der Cluster befinden. Weitere Informationen zu den unterstützten Standorten für Cloud KMS finden Sie unter Cloud-Standorte.

• GKE unterstützt nur Schlüssel aus Cloud KMS. Sie können weder einen anderen KMS-Anbieter von Kubernetes noch einen anderen Verschlüsselungsanbieter verwenden.

Fehlerbehebung

Informationen zur Fehlerbehebung bei der Verschlüsselung von Secrets auf Anwendungsebene, einschließlich der Behebung von Problemen mit fehlgeschlagenen Aktualisierungen der Secret-Verschlüsselung, finden Sie unter Fehlerbehebung bei der Verschlüsselung von Secrets auf Anwendungsebene.

Cloud KMS-Schlüssel ist deaktiviert

Das GKE-Standarddienstkonto kann keinen deaktivierten Cloud KMS-Schlüssel für die Secrets-Verschlüsselung auf Anwendungsebene verwenden.

Informationen zum erneuten Aktivieren eines deaktivierten Schlüssels finden Sie unter Schlüsselversion aktivieren.

Nächste Schritte

• Mehr über Secrets in Kubernetes
• Mehr über Secret Management mit Cloud KMS
• Mehr über die Härtung von Clustern