Eigene Zertifizierungsstellen und Schlüssel in GKE ausführen

Hinweis:In diesem Dokument wird eine Funktion mit allgemeiner Verfügbarkeit> namens GKE-Steuerungsebenenautorität verwendet, die nur für berechtigte Google Cloud-Kunden verfügbar ist. Wenn Sie Zugriff auf diese Funktion anfordern möchten, wenden Sie sich an Ihr Google Cloud Account-Management-Team

.

Auf dieser Seite wird beschrieben, wie Sie die Steuerungsebene Ihres Google Kubernetes Engine-Clusters (GKE) mit Zertifizierungsstellen (CAs) und Schlüsseln konfigurieren, die Sie verwalten. Diese Anleitung richtet sich an Sicherheitsadministratoren, die bestimmte Compliance- oder Richtlinienanforderungen für die Kontrolle über die Ausstellung und Signierung von Anmeldedaten haben.

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

Standardmäßig wendet Google Cloud verschiedene Sicherheitsmaßnahmen auf die verwaltete Steuerungsebene an. Auf dieser Seite werden optionale Funktionen beschrieben, mit denen Sie mehr Einblick in die GKE-Steuerungsebene erhalten oder mehr Kontrolle darüber haben.

Sie sollten mit den folgenden Konzepten vertraut sein:

• Anfragen zur Zertifikatssignierung (Certificate Signing Requests, CSRs)
• Zertifizierungsstellen
• etcd
• GKE-Clusterarchitektur

Komponenten von Anmeldedaten der Steuerungsebene

In GKE-Clustern werden bestimmte Zertifizierungsstellen und Schlüssel verwendet, um Anmeldedaten im Cluster auszustellen, z. B. X.509-Zertifikate oder Dienstkonto-Tokens. Sie können Schlüssel in Cloud Key Management Service (Cloud KMS) und Zertifizierungsstellen im Certificate Authority Service (CA Service) erstellen und Ihre Cluster so konfigurieren, dass diese Ressourcen anstelle von von Google Cloudverwalteten Zertifizierungsstellen und Schlüsseln verwendet werden.

Weitere Informationen zu den einzelnen Komponenten, die Sie erstellen, finden Sie unter Selbst verwaltete CAs und Schlüssel.

Verwendung mit anderen GKE Control Plane Authority-Funktionen

Die GKE Control Plane Authority bietet die folgenden Funktionen im Zusammenhang mit selbstverwalteten Schlüsseln:

• Eigene Zertifizierungsstellen und Schlüssel verwenden (diese Seite)
• Komponenten der Steuerungsebene verschlüsseln

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

Umgebung vorbereiten

In diesem Abschnitt identifizieren Sie Google Cloud Projekte, die Sie in dieser Anleitung verwenden, und erstellen einen Schlüsselbund in Cloud KMS, der Ihre Schlüssel enthält.

Projekte identifizieren

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

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

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

Schlüsselbund erstellen

Erstellen Sie im Schlüsselprojekt einen Schlüsselbund, der alle Schlüssel für einen bestimmten Cluster enthält. Sie müssen den Schlüsselbund am selben Standort wie Ihren GKE-Cluster erstellen.

Hinweis :Sie können einen Schlüsselbund nach dem Erstellen nicht mehr löschen. Für Schlüsselbunde fallen keine zusätzlichen Kosten an. Wenn Sie jedoch zu viele Schlüsselbunde in einem Projekt haben, kann die Verwaltung Ihrer Ressourcen in Cloud KMS mühsamer werden.

Führen Sie dazu diesen Befehl aus:

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

Ersetzen Sie Folgendes:

• KEY_RING_NAME: Ein Name für Ihren Schlüsselbund.
• KEY_PROJECT_ID: die Projekt-ID Ihres Schlüsselprojekts.
• LOCATION: die Google Cloud Region, in der Sie den Schlüsselbund erstellen möchten. Dies muss dieselbe Region sein, in der sich Ihr GKE-Cluster befindet.

Schlüssel erstellen

Für jede der Anmeldedaten-Autoritäten wie Dienstkontoschlüssel und Zertifizierungsstellen erstellen Sie einen Schlüssel mit Cloud KMS. In diesem Abschnitt wird beschrieben, wie Sie die Schlüssel erstellen, die GKE zum Signieren und Überprüfen von Anmeldedaten im Cluster verwendet. Sie können je nach den Anforderungen Ihrer Organisation eigene Eigenschaften für diese Schlüssel angeben. Weitere Informationen finden Sie auf der Seite Schlüssel erstellen und in der projects.locations.keyRings.cryptoKeys-API-Referenz.

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

Beachten Sie beim Erstellen dieser Ressourcen in Cloud KMS Folgendes:

• Wenn Sie in Ihrem Schlüsselprojekt einen vorhandenen Schlüsselbund haben, können Sie diesen verwenden, um alle Schlüssel zu speichern, die Sie für die Verwendung mit Ihrem Cluster erstellen.
• Der Schlüsselbund muss sich am selben Google Cloud Speicherort wie Ihr Cluster befinden, um die Latenz zu minimieren.
• Für Schlüssel muss asymmetric-signing als Schlüsselzweck angegeben werden.
• Verwenden Sie die folgenden Algorithmen je nach Schlüsseltyp:
  • Signaturschlüssel für Dienstkonten: ein starker RSA-Signatur-PKCS1-Algorithmus wie rsa-sign-pkcs1-4096-sha256 oder rsa-sign-pkcs1-3072-sha256.
  • Schlüssel der Zertifizierungsstelle: ein starker Algorithmus wie ec-sign-p256-sha256.
• Cloud HSM-Hardwareschlüssel werden unterstützt, aber das software-Schutzniveau ist für die meisten Anwendungsfälle ausreichend. Weitere Informationen zu Hardwareschlüsseln finden Sie unter Cloud HSM.
• Ändern Sie nicht die Standarddauer für die Schlüssellöschung.
• GKE verhindert nicht, dass Sie Cloud KMS-Schlüssel, einschließlich CA Service-Schlüssel, löschen, die vom Cluster verwendet werden. Bevor Sie Schlüssel oder Zertifizierungsstellen löschen, müssen Sie sicherstellen, dass die Ressourcen nicht verwendet werden.

Führen Sie die folgenden Befehle aus, um die Schlüssel zu erstellen:

1. Erstellen Sie den Signaturschlüssel für das Kubernetes-Dienstkonto, den Sie auch als Bestätigungsschlüssel für das Dienstkonto beim Erstellen des Clusters angeben:

   gcloud kms keys create sa-signing-key \
       --keyring=KEY_RING_NAME \
       --location=LOCATION \
       --purpose="asymmetric-signing" \
       --protection-level=hsm \
       --default-algorithm=rsa-sign-pkcs1-4096-sha256 \
       --project=KEY_PROJECT_ID
   

   Ersetzen Sie KEY_PROJECT_ID durch die Projekt-ID Ihres dedizierten Schlüsselprojekts.

2. Schlüssel für die Cluster-Stamm-CA erstellen:

   gcloud kms keys create cluster-ca-key \
       --keyring=KEY_RING_NAME \
       --location=LOCATION \
       --purpose="asymmetric-signing" \
       --protection-level=hsm \
       --default-algorithm=ec-sign-p256-sha256 \
       --project=KEY_PROJECT_ID
   

3. Erstellen Sie den etcd-Peer-Stamm-CA-Schlüssel:

   gcloud kms keys create etcd-peer-ca-key \
       --keyring=KEY_RING_NAME \
       --location=LOCATION \
       --purpose="asymmetric-signing" \
       --protection-level=hsm \
       --default-algorithm=ec-sign-p256-sha256 \
       --project=KEY_PROJECT_ID
   

4. Erstellen Sie den etcd-API-Stammzertifizierungsstellenschlüssel:

   gcloud kms keys create etcd-api-ca-key \
       --keyring=KEY_RING_NAME \
       --location=LOCATION \
       --purpose="asymmetric-signing" \
       --protection-level=hsm \
       --default-algorithm=ec-sign-p256-sha256 \
       --project=KEY_PROJECT_ID
   

5. Erstellen Sie den Schlüssel der Aggregations-Stamm-CA:

   gcloud kms keys create aggregation-ca-key \
       --keyring=KEY_RING_NAME \
       --location=LOCATION \
       --purpose="asymmetric-signing" \
       --protection-level=hsm \
       --default-algorithm=ec-sign-p256-sha256 \
       --project=KEY_PROJECT_ID
   

CAs erstellen

Nachdem Sie die Schlüssel für jede der Steuerungsebenenfunktionen erstellt haben, verwenden Sie jeden Schlüssel, um die CA-Pools und die entsprechenden Stamm-CAs mit CA Service zu erstellen:

1. Erstellen Sie den Cluster-CA-Pool:

   gcloud privateca pools create cluster-ca-pool \
       --location=LOCATION \
       --tier=enterprise \
       --project=KEY_PROJECT_ID \
       --no-publish-crl --no-publish-ca-cert
   

   Das Flag --no-publish-crl und das Flag --no-publish-ca-cert sind optional. Wenn Sie diese Flags weglassen, werden Zertifikate in einem Cloud Storage-Bucket veröffentlicht. Weitere Informationen finden Sie unter CA-Zertifikats- und CRL-Veröffentlichung für CAs in einem CA-Pool aktivieren.

2. Erstellen Sie die Stamm-CA des Clusters:

   gcloud privateca roots create cluster-root-ca \
       --pool=cluster-ca-pool \
       --location=LOCATION \
       --kms-key-version=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/cluster-ca-key/cryptoKeyVersions/1 \
       --subject="CN=cluster-ca, O=ORGANIZATION" \
       --project=KEY_PROJECT_ID \
       --auto-enable
   

   Ersetzen Sie ORGANIZATION durch den Namen Ihrer Organisation.

3. Erstellen Sie den etcd-Peer-CA-Pool:

   gcloud privateca pools create etcd-peer-ca-pool \
       --location=LOCATION \
       --tier=enterprise \
       --project=KEY_PROJECT_ID \
       --no-publish-crl --no-publish-ca-cert
   

4. Erstellen Sie die Stamm-CA für etcd-Peers:

   gcloud privateca roots create etcd-peer-root-ca \
       --pool=etcd-peer-ca-pool \
       --location=LOCATION \
       --kms-key-version=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/etcd-peer-ca-key/cryptoKeyVersions/1 \
       --subject="CN=etcd-peer-ca, O=ORGANIZATION" \
       --project=KEY_PROJECT_ID \
       --auto-enable
   

5. Erstellen Sie den etcd-API-CA-Pool:

   gcloud privateca pools create etcd-api-ca-pool \
       --location=LOCATION \
       --tier=enterprise \
       --project=KEY_PROJECT_ID \
       --no-publish-crl --no-publish-ca-cert
   

6. Erstellen Sie die Stamm-CA für die etcd-API:

   gcloud privateca roots create etcd-api-root-ca \
       --pool=etcd-api-ca-pool \
       --location=LOCATION \
       --kms-key-version=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/etcd-api-ca-key/cryptoKeyVersions/1 \
       --subject="CN=etcd-api-ca, O=ORGANIZATION" \
       --project=KEY_PROJECT_ID \
       --auto-enable
   

7. Erstellen Sie den CA-Pool für die Aggregation:

   gcloud privateca pools create aggregation-ca-pool \
       --location=LOCATION \
       --tier=enterprise \
       --project=KEY_PROJECT_ID \
       --no-publish-crl --no-publish-ca-cert
   

8. Erstellen Sie die Aggregationsstamm-CA:

   gcloud privateca roots create aggregation-root-ca \
       --pool=aggregation-ca-pool \
       --location=LOCATION \
       --kms-key-version=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/aggregation-ca-key/cryptoKeyVersions/1 \
       --subject="CN=aggregation-ca, O=ORGANIZATION" \
       --project=KEY_PROJECT_ID \
       --auto-enable
   

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

Der GKE-Dienst-Agent benötigt Zugriff auf die Ressourcen, die Sie in Cloud KMS und im CA-Dienst erstellt haben. Der Dienst-Agent verwendet diese Ressourcen, um Berechtigungsnachweise im Cluster zu signieren, zu prüfen und auszustellen. Sie können die folgenden vordefinierten IAM-Rollen verwenden:

• Kubernetes Engine KMS Crypto Key User (roles/container.cloudKmsKeyUser)
• Zertifikatmanager für CA Service (roles/privateca.certificateManager)

So weisen Sie diese Rollen dem GKE-Dienst-Agent zu:

1. So finden Sie die Projektnummer Ihres Clusterprojekts:

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

   Ersetzen Sie CLUSTER_PROJECT_ID durch die Projekt-ID Ihres Clusterprojekts.

2. Weisen Sie dem Dienstkonto-Signaturschlüssel, den Sie in Schlüssel erstellen erstellt haben, die Rolle „Kubernetes Engine KMS Crypto Key User“ zu:

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

   Ersetzen Sie CLUSTER_PROJECT_NUMBER durch die Projektnummer des Clusterprojekts.

3. Weisen Sie die Rolle „CA Service-Zertifikatsmanager“ für die CA-Pools zu, die Sie unter Zertifizierungsstellen erstellen erstellt haben:

   gcloud privateca pools add-iam-policy-binding cluster-ca-pool \
       --location=LOCATION \
       --member="serviceAccount:[e-mail]" \
       --role=roles/privateca.certificateManager \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools add-iam-policy-binding etcd-peer-ca-pool \
       --location=LOCATION \
       --member="serviceAccount:[e-mail]" \
       --role=roles/privateca.certificateManager \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools add-iam-policy-binding etcd-api-ca-pool \
       --location=LOCATION \
       --member="serviceAccount:[e-mail]" \
       --role=roles/privateca.certificateManager \
       --project=KEY_PROJECT_ID
   
   gcloud privateca pools add-iam-policy-binding aggregation-ca-pool \
       --location=LOCATION \
       --member="serviceAccount:[e-mail]" \
       --role=roles/privateca.certificateManager \
       --project=KEY_PROJECT_ID
   

Zusätzliche Rollen gewähren, wenn die gcloud CLI nicht verwendet wird

In diesem Abschnitt werden zusätzliche Konfigurationsschritte beschrieben, die Sie ausführen müssen, wenn Sie Ihre Zertifizierungsstellen und Schlüssel mit einem Client wie Terraform oder der Google Cloud Console anstelle der gcloud CLI konfigurieren möchten. Wenn Sie die gcloud CLI verwenden, überspringen Sie diesen Abschnitt und fahren Sie mit dem Abschnitt Zertifizierungsstellen und Schlüssel in einem neuen Cluster einrichten fort.

Wenn Sie die gcloud CLI zum Einrichten Ihrer CAs und Schlüssel verwenden, wie auf dieser Seite beschrieben, erstellt und konfiguriert die gcloud CLI automatisch einen Dienst-Agent für CA Service und gewährt dem Dienst-Agent IAM-Rollen. Wenn Sie jedoch einen Client wie Terraform oder die Google Cloud Console verwenden, um Ihre Google Cloud-Umgebung zu konfigurieren, müssen Sie diese Konfigurationsschritte für Ihr Schlüsselprojekt manuell ausführen:

1. Erstellen des Dienst-Agents für den CA Service auslösen.

   Vorschau – triggering service agent creation

   Diese Funktion unterliegt den Bedingungen für Pre‑GA-Angebote im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie gesehen“ verfügbar und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

   gcloud beta services identity create --service=privateca.googleapis.com \
       --project=KEY_PROJECT_ID
   

2. So finden Sie die Projektnummer Ihres Schlüsselprojekts:

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

3. Weisen Sie die Rolle Betrachter (roles/viewer) und die Rolle Cloud KMS CryptoKey-Signer/Verifier (roles/cloudkms.signerVerifier) für alle Root-CA-Schlüssel zu, die Sie im Abschnitt Schlüssel erstellen erstellt haben:

   for key in cluster-ca-key etcd-peer-ca-key etcd-api-ca-key aggregation-ca-key
   do
   gcloud kms keys add-iam-policy-binding $key \
       --keyring=KEY_RING_NAME \
       --location=LOCATION \
       --role=roles/viewer \
       --member="serviceAccount:[e-mail]" \
       --project=KEY_PROJECT_ID
   
   gcloud kms keys add-iam-policy-binding $key \
       --keyring=KEY_RING_NAME \
       --location=LOCATION \
       --role=roles/cloudkms.signerVerifier \
       --member="serviceAccount:[e-mail]" \
       --project=KEY_PROJECT_ID
   done
   

   Ersetzen Sie KEY_PROJECT_NUMBER durch die Schlüsselprojektnummer aus der Ausgabe des vorherigen Schritts.

   Dieser Befehl ist eine for-Schleife, die die Root-CA-Schlüssel durchläuft und dem Dienst-Agenten des CA-Dienstes für jeden Schlüssel die entsprechende Rolle zuweist. Wenn Sie unterschiedliche Namen für die Stamm-CA-Schlüssel verwendet haben, führen Sie diese Befehle für jeden Schlüssel manuell aus.

CAs und Schlüssel auf einem neuen Cluster einrichten

Warnung :Das Löschen von Schlüsseln oder Zertifizierungsstellen, die vom Cluster verwendet werden, kann zu nicht wiederherstellbaren Clustern führen. Bevor Sie Schlüssel oder Zertifizierungsstellen löschen, müssen Sie dafür sorgen, dass Ihr Cluster die Ressourcen nicht mehr verwendet.

Nachdem Sie Schlüssel, CA-Pools und Stamm-CAs erstellt und dem GKE-Dienst-Agent IAM-Rollen zugewiesen haben, erstellen Sie einen neuen Cluster, der diese Ressourcen verwendet.

Für die Flags, die Sie im Befehl zum Erstellen des Clusters angeben, sind die folgenden Ressourcenpfade als Werte erforderlich:

• Pfad zu einer Schlüsselversion in Cloud KMS für den Signaturschlüssel des Dienstkontos, den Sie unter Schlüssel erstellen erstellt haben. Sie geben diesen Pfad für das Flag service-account-signing-keys und für das Flag service-account-verification-keys an.
• Pfad zu den einzelnen CA-Pools, die Sie unter CAs erstellen erstellt haben.

Hinweis :Bevor Sie diese Schritte ausführen, müssen Sie entscheiden, ob Sie auch die Boot-Festplatten der Steuerungsebene und die etcd-Festplatten mit von Ihnen verwalteten Schlüsseln verschlüsseln möchten. Führen Sie in diesem Fall alle Schritte zur Schlüsselkonfiguration unter etcd- und Bootlaufwerke der Steuerungsebene verschlüsseln aus und geben Sie die optionalen Flags an, die im Befehl zum Erstellen des Clusters in diesem Abschnitt beschrieben sind.

So konfigurieren Sie einen neuen Cluster für die Verwendung Ihrer Schlüssel und Zertifizierungsstellen:

1. So finden Sie den Pfad zur neuesten aktivierten Version des Dienstkontosignaturschlüssels:

   gcloud kms keys versions list \
       --key=sa-signing-key \
       --keyring=KEY_RING_NAME \
       --location=LOCATION \
       --project=KEY_PROJECT_ID \
       --filter="STATE=ENABLED" --sort-by=~ --format="value(name)" | sed 1q
   

   Ersetzen Sie KEY_PROJECT_ID durch die Projekt-ID des Schlüsselprojekts.

   Die Ausgabe sieht etwa so aus:

   projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1
   

2. Suchen Sie die Pfade zu den einzelnen CA-Pools, die Sie erstellt haben:

   gcloud privateca pools list --format="get(name)" \
       --project=KEY_PROJECT_ID
   

   Die Ausgabe sieht etwa so aus:

   projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool
   projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool
   projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool
   projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool
   

   Prüfen Sie, ob die Ausgabe alle CA-Pools enthält, die Sie für GKE erstellt haben.

Cluster erstellen

In diesem Abschnitt erstellen Sie einen Cluster mit verschiedenen Optionen, je nachdem, welche GKE-Steuerungsebenen-Autoritätsfunktionen Sie konfigurieren möchten. Sie können diese Funktionen nur beim Erstellen eines Clusters konfigurieren. Mit den folgenden Befehlen werden Cluster im Standardmodus erstellt. Wenn Sie stattdessen Cluster im Autopilot-Modus erstellen möchten, verwenden Sie dieselben Flags mit dem Befehl gcloud container clusters create-auto.

• Führen Sie den folgenden Befehl aus, um nur die in dieser Anleitung erstellten Zertifizierungsstellen und Schlüssel zu konfigurieren:

  gcloud container clusters create example-cluster \
      --location=LOCATION \
      --project=CLUSTER_PROJECT_ID \
      --cluster-version=VERSION \
      --service-account-signing-keys=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
      --service-account-verification-keys=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
      --cluster-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool \
      --etcd-peer-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool \
      --etcd-api-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool \
      --aggregation-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool
  

  Ersetzen Sie Folgendes:

  • CLUSTER_PROJECT_ID: die Projekt-ID des Clusterprojekts.
  • VERSION: Die GKE-Version des Clusters. Muss 1.31.1-gke.1846000 oder höher sein.

• So konfigurieren Sie die Zertifizierungsstellen und Schlüssel sowie die Bootlaufwerkverschlüsselung der Steuerungsebene und die etcd-Verschlüsselung:

  1. Führen Sie alle Schritte zur Schlüsselkonfiguration unter Bootlaufwerke von etcd und der Steuerungsebene verschlüsseln aus.
  2. Die Pfade zu den einzelnen Schlüsseln finden Sie in der Anleitung unter Verschlüsselungsschlüssel in einem Cluster verwenden.

  3. Erstellen Sie einen Cluster.

     gcloud container clusters create example-cluster \
         --location=LOCATION \
         --project=CLUSTER_PROJECT_ID \
         --cluster-version=VERSION \
         --service-account-signing-keys=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
         --service-account-verification-keys=projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1 \
         --cluster-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool \
         --etcd-peer-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool \
         --etcd-api-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool \
         --aggregation-ca=projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool \
         --control-plane-disk-encryption-key=PATH_TO_DISK_KEY \
         --gkeops-etcd-backup-encryption-key=PATH_TO_ETCD_BACKUP_KEY
     

     Ersetzen Sie Folgendes:

     • CLUSTER_PROJECT_ID: die Projekt-ID des Clusterprojekts.
     • VERSION: Die GKE-Version des Clusters. Muss 1.31.1-gke.1846000 oder höher sein.
     • PATH_TO_DISK_KEY: der Pfad zu Ihrem Festplattenverschlüsselungsschlüssel.
     • PATH_TO_ETCD_BACKUP_KEY: der Pfad zu Ihrem internen etcd-Verschlüsselungsschlüssel für Sicherungen.

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

Prüfen, ob der Cluster die angegebenen Schlüssel und Zertifizierungsstellen verwendet

In diesem Abschnitt erfahren Sie, wie Sie die Schlüssel und Zertifizierungsstellen überprüfen, die beim Erstellen des Clusters verwendet wurden. Sie können diese Überprüfung mit Cloud Logging oder mit der Google Cloud CLI durchführen.

Logging verwenden, um Schlüssel und Zertifizierungsstellen zu überprüfen

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

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

   Zum Log-Explorer

2. Geben Sie die folgende Abfrage an:

   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:*
   

   protoPayload.request.cluster.userManagedKeysConfig:* filtert die Ergebnisse nach Logs zur Clustererstellung, die von Ihnen verwaltete Schlüssel und Zertifizierungsstellen enthalten.

3. Klicken Sie auf Abfrage ausführen.

Maximieren Sie in den Ergebnissen das Log zur Clustererstellung. Prüfen Sie, ob die Pfade zu Schlüsseln und Zertifizierungsstellen mit den Pfaden übereinstimmen, die Sie für diesen Cluster erstellt haben, wie im folgenden Beispiel:

# lines omitted for clarity
userManagedKeysConfig: {
  aggregationCa: "projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool"
  clusterCa: "projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool"
  etcdApiCa: "projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool"
  etcdPeerCa: "projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool"
  serviceAccountSigningKeys: [
    0: "projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1"
  ]
  serviceAccountVerificationKeys: [
    0: "projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1"
  ]
}

Schlüssel und Zertifizierungsstellen mit der gcloud CLI prüfen

Führen Sie den folgenden Befehl aus, um zu prüfen, ob der Cluster die von Ihnen erstellten Zertifizierungsstellen und Schlüssel verwendet:

gcloud container clusters describe example-cluster \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID

Die Ausgabe sollte das Feld userManagedKeysConfig wie im folgenden Beispiel enthalten:

# lines omitted for clarity
userManagedKeysConfig:
  sa-signing-key: projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1
  sa-verification-key: projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING_NAME/cryptoKeys/sa-signing-key/cryptoKeyVersions/1
  cluster-ca: projects/KEY_PROJECT_ID/locations/LOCATION/caPools/cluster-ca-pool
  etcd-peer-ca: projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-peer-ca-pool
  etcd-api-ca: projects/KEY_PROJECT_ID/locations/LOCATION/caPools/etcd-api-ca-pool
  aggregation-ca: projects/KEY_PROJECT_ID/locations/LOCATION/caPools/aggregation-ca-pool