etcd- und Bootlaufwerke der Steuerungsebene verschlüsseln

Autopilot Standard

Hinweis: In diesem Dokument wird ein Feature mit allgemeiner Verfügbarkeit namens GKE Control Plane Authority verwendet, das nur für berechtigte Google Cloud Kunden verfügbar ist. Wenn Sie Zugriff auf dieses Feature anfordern möchten, wenden Sie sich an Ihr Google Cloud Account-Management-Team.

In diesem Dokument erfahren Sie, wie Sie Daten verschlüsseln, die in der Steuerungsebene von Google Kubernetes Engine (GKE) gespeichert sind. Dazu verwenden Sie Schlüssel, die Sie in Cloud Key Management Service (Cloud KMS) verwalten. Sie sollten bereits mit Konzepten wie etcd, der GKE-Clusterarchitektur, und Cloud KMS vertraut sein.

Auf dieser Seite wird ein Teil einer Reihe optionaler Features der Steuerungsebene in GKE beschrieben, mit denen Sie Aufgaben wie das Überprüfen der Sicherheitskonfiguration Ihrer Steuerungsebene oder das Konfigurieren der Verschlüsselung und der Signierung von Anmeldedaten in der Steuerungsebene mit von Ihnen verwalteten Schlüsseln ausführen können. Weitere Informationen finden Sie unter Informationen zu GKE Control Plane Authority.

Standardmäßig Google Cloud wendet verschiedene Sicherheitsmaßnahmen auf die verwaltete Steuerungsebene an. Auf dieser Seite werden optionale Funktionen beschrieben, die Ihnen mehr Einblick in die GKE-Steuerungsebene oder mehr Kontrolle über sie geben.

Informationen zur Verschlüsselung von Bootlaufwerken und etcd der Steuerungsebene

Standardmäßig verschlüsselt GKE das Bootlaufwerk eines Steuerungsebenenknotens, das Laufwerk, auf dem Daten in etcd gespeichert sind, und die Google Cloud interne betriebliche Sicherung von etcd mit Verschlüsselungsschlüsseln, die Google Cloud verwaltet. Weitere Informationen zur Standardverschlüsselung finden Sie unter Verschlüsselung ruhender Daten. Sie können optional Ihre eigenen Verschlüsselungsschlüssel verwenden, die Sie mit Cloud KMS verwalten, um diese Ressourcen zu verschlüsseln. Weitere Informationen finden Sie unter Verschlüsselung von Bootlaufwerken und etcd der Steuerungsebene.

Sie erstellen in Cloud KMS Schlüssel, mit denen GKE Ihre Ressourcen der Steuerungsebene verschlüsselt. Beachten Sie beim Erstellen dieser Ressourcen Folgendes:

• Sie können einen Schlüsselbund für alle Schlüssel in einem Cluster verwenden, unabhängig vom Zweck der einzelnen Schlüssel. Wenn Sie einen vorhandenen Schlüsselbund haben, den Sie für einen anderen Zweck verwendet haben, z. B. zum Einrichten eigener Zertifizierungsstellen, können Sie diesen Schlüsselbund für diese Anleitung verwenden.
• Sie sollten die Schlüssel am selben Google Cloud Standort wie Ihrem Cluster erstellen, um die Latenz zu verbessern.
• In den meisten Anwendungsfällen können Sie die Cloud KMS-Schlüsselschutzstufe Software verwenden. Sie können auch Hardwareschlüssel mit Cloud HSM verwenden.
• Sie müssen das Flag --purpose mit dem Wert encryption angeben, da diese Schlüssel für die symmetrische Verschlüsselung verwendet werden.
• Sie sollten die Standarddauer für die Schlüsselzerstörung nicht ändern.

Verwendung mit anderen GKE Control Plane Authority-Features

GKE Control Plane Authority bietet die folgenden Features im Zusammenhang mit selbstverwalteten Schlüsseln, die Sie gleichzeitig beim Erstellen eines Clusters aktivieren müssen:

• Komponenten der Steuerungsebene verschlüsseln (dieses Dokument)
• Eigene Zertifizierungsstellen und Schlüssel ausführen

Sie können diese Features nur aktivieren, wenn Sie einen neuen GKE-Cluster erstellen. Sie können vorhandene Cluster nicht aktualisieren, um diese Features zu verwenden. Wenn Sie beide Features im selben Cluster verwenden möchten, führen Sie alle Konfigurationsverfahren für Schlüssel und Zertifizierungsstellen in beiden Anleitungen aus und führen Sie dann den Befehl zum Erstellen des Clusters aus, mit dem beide Feature-Sets aktiviert werden, wie im Abschnitt Cluster erstellen beschrieben.

Hinweis

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, installieren und dann initialisieren Sie die gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem gcloud components update Befehl ab. Ältere Versionen der gcloud CLI unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.
  Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das Attribut compute/region fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

• Achten Sie darauf, dass Ihr Schlüsselprojekt einen Cloud KMS-Schlüsselbund für Ihren Cluster hat. Sie können einen beliebigen vorhandenen Schlüsselbund am Standort Ihres Clusters verwenden. Informationen zum Erstellen eines neuen Schlüsselbunds finden Sie unter Schlüsselbund erstellen.

• Aktivieren Sie die Cloud Key Management Service API.

  Rollen, die zum Aktivieren von APIs erforderlich sind

  Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Rolle „Inhaber“ (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. Informationen zum Zuweisen von Rollen.

  API aktivieren

Projekte identifizieren

Wir empfehlen, separate Google Cloud Projekte wie folgt zu verwenden:

• Schlüsselprojekt: enthält alle Schlüssel.
• Clusterprojekt: enthält Ihre GKE-Cluster.

Sie können optional dasselbe Projekt für Ihre Schlüssel und GKE-Cluster verwenden. Wir empfehlen jedoch, separate Projekte zu verwenden, damit die Teams, die Ihre Schlüssel und kryptografischen Vorgänge verwalten, von den Teams getrennt sind, die Ihre Cluster verwalten.

Erforderliche Rollen und Berechtigungen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Ausführen Ihrer eigenen Verschlüsselungsschlüssel benötigen:

• Cloud KMS-Schlüssel erstellen: Cloud KMS-Administrator (roles/cloudkms.admin) für Ihr Schlüsselprojekt
• GKE-Cluster erstellen: Kubernetes Engine-Clusteradministrator (roles/container.clusterAdmin) für Ihr Clusterprojekt

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Voraussetzungen

Für die Verschlüsselung von Laufwerken der Steuerungsebene mit eigenen Schlüsseln gelten die folgenden Anforderungen:

• Ihr Cluster muss GKE-Version 1.31.1-gke.1846000 oder höher ausführen.

• Sie müssen Ihren Cluster in einer der folgenden Regionen erstellen:

  • asia-east1
  • asia-northeast1
  • asia-southeast1
  • europe-west1
  • europe-west4
  • us-central1
  • us-central2
  • us-east1
  • us-east4
  • us-east5
  • us-south1
  • us-west1
  • us-west3
  • us-west4
  Hinweis: Unabhängig von GKE Control Plane Authority können Sie den Modus „ Vertraulich“ für Hyperdisk Balanced für Ihre Knotenlaufwerke verwenden. Wenn Sie den Modus „Vertraulich“ für Hyperdisk Balanced für Ihre Knoten verwenden möchten und zusätzlich Ihre Laufwerke der Steuerungsebene mit eigenen Schlüsseln verschlüsseln möchten, müssen Sie den Cluster in einer Region erstellen, die den Modus „Vertraulich“ für Hyperdisk Balanced unterstützt. Wenn Sie den Cluster in einer anderen Region erstellen, können Sie den Modus „Vertraulich“ für Hyperdisk Balanced für Ihre Knoten nicht verwenden.

Beschränkungen

• Sie können die Verschlüsselungsschlüssel für Bootlaufwerke und etcd nur während der Clustererstellung konfigurieren.

• Für regionale Cluster im Standardmodus und für Autopilot-Cluster muss die Region, in der Sie einen Cluster erstellen, Kapazität für den Modus „Vertraulich“ für Hyperdisk Balanced in mindestens drei Zonen in dieser Region haben.

  Für zonale Cluster im Standardmodus muss die Clusterzone Hyperdisk Balanced-Kapazität haben. Wenn Sie Hilfe bei der Kapazität benötigen, wenden Sie sich an Cloud Customer Care.

• 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.

• Cloud External Key Manager-Schlüssel (Cloud EKM) werden nicht unterstützt.

• Sie können nicht auf die Google Cloud internen betrieblichen Sicherungen von etcd zugreifen oder mit ihnen interagieren. Sie sind nur für die Notfallwiederherstellung vorgesehen.

• Multiregionale Schlüsselbunde werden nicht unterstützt. Sie müssen einen regionalen Schlüsselbund verwenden.

Schlüssel erstellen

In diesem Abschnitt erstellen Sie einen Verschlüsselungsschlüssel für die Bootlaufwerke und etcd-Laufwerke in Ihrer Steuerungsebene und einen separaten Verschlüsselungsschlüssel für die Google Cloud interne betriebliche Sicherung von etcd. Sie können einen Schlüsselbund verwenden, um alle diese Schlüssel und alle anderen Schlüssel für den Cluster zu speichern.

Warnung: Aktivieren Sie die automatische Schlüsselrotation nicht mit Cloud KMS. Für die Rotation Ihrer Verschlüsselungsschlüssel sind zusätzliche Schritte erforderlich, um sicherzustellen, dass Ihre Ressourcen der Steuerungsebene mit neuen Schlüsselversionen neu verschlüsselt werden, bevor die ursprünglichen Schlüsselversionen gelöscht werden.

1. Erstellen Sie den Verschlüsselungsschlüssel für die Bootlaufwerke und etcd-Laufwerke Ihrer Steuerungsebene:

   gcloud kms keys create KCP_DISK_KEY_NAME \
       --keyring=KEYRING_NAME \
       --location=LOCATION \
       --purpose="encryption" \
       --protection-level=PROTECTION_LEVEL \
       --project=KEY_PROJECT_ID
   

   Ersetzen Sie Folgendes:

   • KCP_DISK_KEY_NAME: der Name für den Verschlüsselungsschlüssel für die Bootlaufwerke und etcd-Laufwerke Ihrer Steuerungsebene.
   • KEYRING_NAME: der Name des Schlüsselbunds, in dem Ihre Verschlüsselungsschlüssel für den Cluster gespeichert werden sollen.
   • LOCATION: der Google Cloud Standort für den Schlüsselbund. Dieser muss mit dem Standort Ihres Clusters übereinstimmen. Eine Liste der Regionen finden Sie in der Tabelle Cloud KMS-Standorte. Filtern Sie nach "Region".
   • PROTECTION_LEVEL: die Schutzstufe für den Schlüssel, z. B. software oder hsm.
   • KEY_PROJECT_ID: die Projekt-ID Ihres Schlüsselprojekts.

2. Erstellen Sie den Verschlüsselungsschlüssel für die interne Sicherung von etcd:

   gcloud kms keys create ETCD_BACKUP_KEY_NAME \
       --keyring=KEYRING_NAME \
       --location=LOCATION \
       --purpose="encryption" \
       --protection-level=PROTECTION_LEVEL \
       --project=KEY_PROJECT_ID
   

   Ersetzen Sie ETCD_BACKUP_KEY_NAME durch einen Namen für den Verschlüsselungsschlüssel für die interne Sicherung von etcd.

IAM-Rollen für den GKE-Dienst-Agent gewähren

In diesem Abschnitt gewähren Sie dem GKE-Dienst-Agent im Clusterprojekt IAM-Rollen für die von Ihnen erstellten Schlüssel. Der GKE-Dienst-Agent benötigt diese Rollen, um diese Schlüssel zum Verschlüsseln der entsprechenden Ressourcen der Steuerungsebene zu verwenden.

1. Suchen Sie die Projektnummer Ihres Clusterprojekts:

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

   Ersetzen Sie CLUSTER_PROJECT_ID durch die Projekt-ID Ihres GKE-Clusterprojekts.

   Die Ausgabe sieht etwa so aus:

   1234567890
   

2. Gewähren Sie dem GKE-Dienst-Agent im Clusterprojekt die Rolle „Cloud KMS CryptoKey-Verschlüsseler/Entschlüsseler“ (roles/cloudkms.cryptoKeyEncrypterDecrypter) für den Verschlüsselungsschlüssel für Bootlaufwerke und etcd-Laufwerke:

   gcloud kms keys add-iam-policy-binding KCP_DISK_KEY_NAME \
       --location=LOCATION \
       --keyring=KEYRING_NAME \
       --member="serviceAccount:[e-mail]" \
       --role=roles/cloudkms.cryptoKeyEncrypterDecrypter \
       --project=KEY_PROJECT_ID
   

   Ersetzen Sie Folgendes:

   • KCP_DISK_KEY_NAME: der Name des Schlüssels zur Laufwerksverschlüsselung.
   • LOCATION: der Google Cloud Standort für den Schlüssel.
   • KEYRING_NAME: der Name des Schlüsselbunds, der den Verschlüsselungsschlüssel enthält.
   • CLUSTER_PROJECT_NUMBER: die numerische Projektnummer des Clusterprojekts, die Sie im vorherigen Schritt ermittelt haben.
   • KEY_PROJECT_ID: die Projekt-ID Ihres Schlüsselprojekts.

3. Gewähren Sie dem GKE-Dienst-Agent im Clusterprojekt die Cloud KMS CryptoKey-Verschlüsseler/Entschlüsseler über Delegation (roles/cloudkms.cryptoKeyEncrypterDecrypterViaDelegation) Rolle für den Verschlüsselungsschlüssel für Bootlaufwerke und etcd-Laufwerke:

   gcloud kms keys add-iam-policy-binding KCP_DISK_KEY_NAME \
       --location=LOCATION \
       --keyring=KEYRING_NAME \
       --member="serviceAccount:[e-mail]" \
       --role=roles/cloudkms.cryptoKeyEncrypterDecrypterViaDelegation \
       --project=KEY_PROJECT_ID
   

4. Gewähren Sie dem GKE-Dienst-Agent im Clusterprojekt die Rolle „Cloud KMS-Schlüsselnutzer“ für die Verschlüsselungsschlüssel für Bootlaufwerke und etcd-Laufwerke für die Schlüsselrotation:

   gcloud kms keys add-iam-policy-binding KCP_DISK_KEY_NAME \
       --location=LOCATION \
       --keyring=KEYRING_NAME \
       --member="serviceAccount:[e-mail]" \
       --role=roles/container.cloudKmsKeyUser \
       --project=KEY_PROJECT_ID
   

5. Gewähren Sie dem GKE-Dienst-Agent im Cluster Projekt die Rolle „ Cloud KMS CryptoKey-Verschlüsseler (roles/cloudkms.cryptoKeyEncrypter)“ für den Verschlüsselungsschlüssel für die interne Sicherung von etcd:

   gcloud kms keys add-iam-policy-binding ETCD_BACKUP_KEY_NAME \
       --location=LOCATION \
       --keyring=KEYRING_NAME \
       --member="serviceAccount:[e-mail]" \
       --role=roles/cloudkms.cryptoKeyEncrypter \
       --project=KEY_PROJECT_ID
   

   Ersetzen Sie ETCD_BACKUP_KEY_NAME durch den Namen des Verschlüsselungsschlüssels für die betriebliche Sicherung von etcd.

   Wenn Sie die Rolle roles/cloudkms.cryptoKeyEncrypter gewähren, kann GKE keine Datenbankwiederherstellungen in Ihrem Namen ausführen. Außerdem verlängert sich die Zeit, die zum Wiederherstellen der Funktionalität benötigt wird, wenn ein Datenbankproblem auftritt, erheblich. Wenn GKE Wiederherstellungen für Sie ausführen soll, gewähren Sie stattdessen die Rolle roles/cloudkms.cryptoKeyEncrypterDecrypter.

Verschlüsselungsschlüssel in einem Cluster verwenden

In diesem Abschnitt erfahren Sie, wie Sie die Pfade zu Ihren Verschlüsselungsschlüsseln ermitteln.

1. Ermitteln Sie den Pfad zu Ihrem Schlüssel zur Laufwerksverschlüsselung:

   gcloud kms keys describe KCP_DISK_KEY_NAME \
       --keyring=KEYRING_NAME \
       --location=LOCATION \
       --project=KEY_PROJECT_ID \
       --format="value(name)"
   

   Ersetzen Sie Folgendes:

   • KCP_DISK_KEY_NAME: der Name des Verschlüsselungsschlüssels für die Bootlaufwerke und etcd-Laufwerke der Steuerungsebene.
   • KEYRING_NAME: der Name des Schlüsselbunds, der den Schlüssel enthält.
   • LOCATION: der Google Cloud Standort des Schlüssels.
   • KEY_PROJECT_ID: die Projekt-ID Ihres Schlüsselprojekts.

   Die Ausgabe sieht etwa so aus:

   projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEYRING_NAME/cryptoKeys/disk-encryption-key
   

2. Ermitteln Sie den Pfad zu Ihrem Verschlüsselungsschlüssel für die interne Sicherung von etcd:

   gcloud kms keys describe ETCD_BACKUP_KEY_NAME \
       --keyring=KEYRING_NAME \
       --location=LOCATION \
       --project=KEY_PROJECT_ID \
       --format="value(name)"
   

   Ersetzen Sie ETCD_BACKUP_KEY_NAME durch den Namen des Verschlüsselungsschlüssels für die betriebliche Sicherung von etcd.

   Die Ausgabe sieht etwa so aus:

   projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEYRING_NAME/cryptoKeys/etcd-backup-encryption-key
   

Cluster erstellen

Warnung: Wenn Sie die Cloud KMS-Schlüssel, die Sie für die Verschlüsselung verwendet haben, widerrufen oder löschen, besteht für Ihren Cluster das Risiko eines irreparablen Datenverlusts.

In diesem Abschnitt erstellen Sie einen Cluster mit verschiedenen Optionen, je nachdem, welche GKE Control Plane Authority-Features Sie konfigurieren möchten. Sie können diese Features nur während der Clustererstellung konfigurieren. Mit den folgenden Befehlen werden Cluster im Standardmodus erstellt. Wenn Sie stattdållen Cluster im Autopilot-Modus erstellen möchten, verwenden Sie dieselben Flags mit dem gcloud container clusters create-auto Befehl.

• So erstellen Sie einen Cluster, in dem die Laufwerksverschlüsselung konfiguriert wird und Ihre eigenen Zertifizierungsstellen und Signaturschlüssel für Dienstkonten ausgeführt werden:

  1. Führen Sie alle Konfigurationsschritte für Schlüssel und Zertifizierungsstellen unter Eigene Zertifizierungsstellen und Schlüssel ausführen aus.
  2. Ermitteln Sie die Pfade zu den einzelnen Dienstkontoschlüsseln und Zertifizierungsstellen. Folgen Sie dazu der Anleitung unter Zertifizierungsstellen und Schlüssel in einem neuen Cluster einrichten.

  3. Erstellen Sie einen Cluster:

     gcloud container clusters create CLUSTER_NAME \
         --location=LOCATION \
         --project=CLUSTER_PROJECT_ID \
         --control-plane-disk-encryption-key=PATH_TO_DISK_KEY \
         --gkeops-etcd-backup-encryption-key=PATH_TO_ETCD_BACKUP_KEY \
         --service-account-signing-keys=PATH_TO_SIGNING_KEY_VERSION \
         --service-account-verification-keys=PATH_TO_VERIFICATION_KEY_VERSION \
         --cluster-ca=PATH_TO_CLUSTER_CA \
         --etcd-peer-ca=PATH_TO_ETCD_PEER_CA \
         --etcd-api-ca=PATH_TO_ETCD_API_CA \
         --aggregation-ca=PATH_TO_AGGREGATION_CA
     

     Ersetzen Sie Folgendes:

     • CLUSTER_NAME: der Name Ihres neuen Clusters.
     • LOCATION: der Standort Ihres neuen Clusters.
     • CLUSTER_PROJECT_ID: die Projekt-ID Ihres Clusterprojekts.
     • PATH_TO_DISK_KEY: der Pfad zu Ihrem Schlüssel zur Laufwerksverschlüsselung aus den vorherigen Schritten in diesem Dokument.
     • PATH_TO_ETCD_BACKUP_KEY: der Pfad zu Ihrem Verschlüsselungsschlüssel für die interne Sicherung von etcd aus den vorherigen Schritten in diesem Dokument.
     • PATH_TO_SIGNING_KEY_VERSION: der Pfad zur Signaturschlüsselversion des Kubernetes-Dienstkontos in Cloud KMS.
     • PATH_TO_VERIFICATION_KEY_VERSION: der Pfad zur Überprüfungsschlüsselversion des Kubernetes-Dienstkontos in Cloud KMS.
     • PATH_TO_CLUSTER_CA: der Pfad zum Cluster-CA-Pool.
     • PATH_TO_ETCD_PEER_CA: der Pfad zum etcd-Peer-CA-Pool.
     • PATH_TO_ETCD_API_CA: der Pfad zum etcd-API-CA-Pool.
     • PATH_TO_AGGREGATION_CA: der Pfad zum Aggregations-CA-Pool.

• Wenn Sie einen Cluster erstellen möchten, in dem nur die Laufwerksverschlüsselung mit den in dieser Anleitung erstellten Schlüsseln konfiguriert wird, führen Sie den folgenden Befehl aus:

  gcloud container clusters create CLUSTER_NAME \
      --location=LOCATION \
      --project=CLUSTER_PROJECT_ID \
      --control-plane-disk-encryption-key=PATH_TO_DISK_KEY \
      --gkeops-etcd-backup-encryption-key=PATH_TO_ETCD_BACKUP_KEY
  

  Ersetzen Sie Folgendes:

  • CLUSTER_NAME: der Name Ihres neuen Clusters.
  • LOCATION: der Standort Ihres neuen Clusters.
  • CLUSTER_PROJECT_ID: die Projekt-ID Ihres Clusterprojekts.
  • PATH_TO_DISK_KEY: der Pfad zu Ihrem Schlüssel zur Laufwerksverschlüsselung aus den vorherigen Schritten.
  • PATH_TO_ETCD_BACKUP_KEY: der Pfad zu Ihrem Verschlüsselungsschlüssel für die interne Sicherung von etcd aus den vorherigen Schritten.

Sie können alle diese Flags auch angeben, wenn Sie einen neuen Cluster im Standardmodus erstellen.

Status des Verschlüsselungsschlüssels prüfen

In diesem Abschnitt erfahren Sie, wie Sie den Verschlüsselungsschlüssel prüfen, der während der Clustererstellung verwendet wurde. Sie können diese Prüfung mit Cloud Logging oder mit der Google Cloud CLI durchführen.

Schlüssel mit Logging prüfen

So prüfen Sie die Schlüssel mit Logging:

1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf:

   Zum Log-Explorer

2. Rufen Sie das Clustererstellungsprotokoll ab, indem Sie die folgende Abfrage angeben:

   resource.type="gke_cluster"
   resource.labels.cluster_name="CLUSTER_NAME"
   resource.labels.location="CLUSTER_LOCATION"
   protoPayload.serviceName="container.googleapis.com"
   protoPayload.methodName=~"google.container.v(1|1alpha1|1beta1).ClusterManager.CreateCluster"
   protoPayload.request.cluster.userManagedKeysConfig:*
   

3. Klicken Sie auf Abfrage ausführen.

Prüfen Sie in der Ausgabe, ob die Parameter für die Clustererstellung einen Schlüsselpfad enthalten, der dem in Cloud KMS eingerichteten Schlüssel entspricht, wie im folgenden Beispiel:

# lines omitted for clarity
userManagedKeysConfig: {
  controlPlaneDiskEncryptionKey: "projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/KCP_DISK_KEY_NAME"
  gkeopsEtcdBackupEncryptionKey: "projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/ETCD_BACKUP_KEY_NAME"
}

Schlüssel mit der gcloud CLI prüfen

So prüfen Sie den Verschlüsselungsschlüssel mit der gcloud CLI:

1. Führen Sie für den Schlüssel zur Laufwerksverschlüsselung den folgenden Befehl aus:

   gcloud container clusters describe CLUSTER_NAME \
       --location=LOCATION \
       --format="value(userManagedKeysConfig.controlPlaneDiskEncryptionKey)"
   

2. Führen Sie für den Verschlüsselungsschlüssel für die interne Sicherung von etcd den folgenden Befehl aus:

   gcloud container clusters describe CLUSTER_NAME \
       --location=LOCATION \
       --format="value(userManagedKeysConfig.gkeopsEtcdBackupEncryptionKey)"
   

Verschlüsselungsschlüssel für etcd und Laufwerke der Steuerungsebene rotieren

Die von Ihnen erstellten Verschlüsselungsschlüssel laufen nicht ab. Um Ihre Sicherheitskonfiguration zu verbessern, sollten Sie diese Schlüssel regelmäßig rotieren und Ihre Ressourcen mit neuen Schlüsselversionen neu verschlüsseln. Weitere Informationen finden Sie unter Verschlüsselungsschlüssel für etcd und Bootlaufwerke der Steuerungsebene rotieren.

Nächste Schritte

• Weitere Informationen zu den Elementen, die Sie in der Steuerungsebene aufrufen können
• Eigene Zertifizierungsstellen und Schlüssel in GKE ausführen
• Integrität der VM der Steuerungsebene prüfen