Vom Kunden verwaltete CAs und Schlüssel der Steuerungsebene rotieren

.

Auf dieser Seite wird Clusteradministratoren und Sicherheitsexperten gezeigt, wie sie die Zertifizierungsstellen (Certificate Authorities, CAs) und Dienstkonto-Signaturschlüssel rotieren, die Sie für die GKE-Steuerungsebene konfiguriert haben.

Sie sollten mit den folgenden Konzepten vertraut sein:

Rotation von Anmeldedaten planen

Auf dieser Seite wird beschrieben, wie Sie die folgenden Anmeldedatenkomponenten in Ihrer Steuerungsebene rotieren:

  • Die Stammzertifizierungsstelle des Clusters, die Stammzertifizierungsstelle für die Aggregation, die Stammzertifizierungsstelle für die etcd-API und die Stammzertifizierungsstelle für die etcd-Peers.
  • Die Signatur- und Bestätigungsschlüssel des Kubernetes-ServiceAccount.

Sie können auch die vom Kunden verwalteten Verschlüsselungsschlüssel rotieren, die Sie zum Verschlüsseln der Bootlaufwerke der Steuerungsebene, der etcd-Laufwerke und des internen etcd-Back-ups verwendet haben, das Google Cloud für die Notfallwiederherstellung verwendet. Weitere Informationen finden Sie unter Verschlüsselungsschlüssel für etcd- und Steuerungsebenen-Bootlaufwerke rotieren.

Rotieren Sie Ihre Anmeldedaten, um den Ablauf von Zertifizierungsstellen zu vermeiden, um das Risiko von manipulierten Schlüsselversionen zu verringern und als Teil der Sicherheitspraktiken Ihrer Organisation. Berücksichtigen Sie Folgendes, um zu planen, wie oft Sie bestimmte GKE Control Plane Authority-Ressourcen rotieren:

  • Standardmäßig laufen GKE-Zertifikate, die von den Stammzertifizierungsstellen im Certificate Authority Service (CA Service) signiert wurden, ein Jahr nach dem Erstellungsdatum ab.
  • Schlüssel im Cloud Key Management Service (Cloud KMS) laufen nicht ab. Führen Sie eine manuelle Schlüsselrotation nur durch, wenn Ihre Organisation Anforderungen an die Schlüsselrotation hat. Um Unterbrechungen laufender Arbeitslasten zu minimieren, sollten Sie für diese Schlüssel keine automatische Schlüsselrotation konfigurieren.

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 diesen Task 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.

  • Sie haben einen vorhandenen Cluster, in dem selbstverwaltete Zertifizierungsstellen und Dienstkontoschlüssel verwendet werden.

  • Ermitteln Sie die Projekt-IDs der folgenden Google Cloud Projekte:

    • Schlüsselprojekt: Das Projekt, das Ihre Cloud KMS- und CA Service-Ressourcen enthält.
    • Clusterprojekt: Das Projekt, das Ihren GKE-Cluster enthält.

  • Damit Sie die Validierungsaufgaben auf dieser Seite ausführen können, müssen die folgenden Audit-Logs zum Datenzugriff aktiviert sein:

    • Cloud Key Management Service (KMS) API: DATA_READ
    • Certificate Authority Service: ADMIN_READ

    Informationen zum Aktivieren dieser Logtypen finden Sie unter Audit-Logs zum Datenzugriff aktivieren.

Erforderliche Rollen und Berechtigungen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Rotieren Ihrer vom Kunden verwalteten CAs und Schlüssel benötigen:

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.

Beschränkungen

Die asymmetrischen Cloud KMS-Schlüssel, die Sie zum Signieren und Überprüfen von Dienstkonten verwenden, unterstützen keine automatische Schlüsselrotation.

Signatur- und Bestätigungsschlüssel für Dienstkonten rotieren

Wenn Sie die GKE-Steuerungsebene einrichten, fügen Sie Ihrem Cluster einen Dienstkonto-Signaturschlüssel und Dienstkonto-Bestätigungsschlüssel hinzu. GKE verwendet diese Schlüssel zum Signieren und Validieren von Inhabertokens für Kubernetes-Dienstkonten. Bei einer Rotation fügen Sie den neuen Schlüssel der Liste der Bestätigungsschlüssel für Dienstkonten hinzu, warten, bis die Änderungen übernommen wurden, und ersetzen dann den Signaturschlüssel für das Dienstkonto durch den neuen Schlüssel.

So rotieren Sie die Dienstkontoschlüssel:

  1. Rufen Sie den vollständigen Ressourcennamen der ursprünglichen Schlüsselversion des Signaturschlüssels des Dienstkontos ab:

    gcloud container clusters describe CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --format="value(userManagedKeysConfig.serviceAccountSigningKeys)"

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • CONTROL_PLANE_LOCATION: Der Standort des Clusters.
    • CLUSTER_PROJECT_ID: die Projekt-ID des Clusterprojekts.

    Die Ausgabe sieht etwa so aus:

    projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/SIGNING_KEY_NAME/cryptoKeyVersions/ORIGINAL_SIGNING_KEY_VERSION

    In dieser Ausgabe ist SIGNING_KEY_NAME der Name des Schlüssels und ORIGINAL_SIGNING_KEY_VERSION die Nummer der ursprünglichen Signaturschlüsselversion.

  2. Erstellen Sie eine neue Schlüsselversion für den Signaturschlüssel des Dienstkontos:

    gcloud kms keys versions create \
    --key=SIGNING_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

    Ersetzen Sie Folgendes:

    • SIGNING_KEY_NAME: der Name des Signaturschlüssels für das Dienstkonto.
    • KEYRING_NAME: der Name des Schlüsselbunds, der den Schlüssel enthält.
    • CONTROL_PLANE_LOCATION: der Google Cloud Speicherort des Schlüsselbunds.
    • KEY_PROJECT_ID: Die Projekt-ID Ihres Schlüsselprojekts.

  3. Rufen Sie den vollständigen Ressourcennamen der neuen Schlüsselversion ab:

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

    Die Ausgabe sieht etwa so aus:

    projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/SIGNING_KEY_NAME/cryptoKeyVersions/NEW_SIGNING_KEY_VERSION

    In dieser Ausgabe ist SIGNING_KEY_NAME der Name des Schlüssels und NEW_SIGNING_KEY_VERSION die Nummer der neuen Signaturschlüsselversion.

  4. Fügen Sie die neue Schlüsselversion dem Satz von Dienstkonto-Bestätigungsschlüsseln für den Cluster hinzu:

    gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --service-account-verification-keys=ORIGINAL_KEY_VERSION_PATH,NEW_KEY_VERSION_PATH

    Ersetzen Sie Folgendes:

    • ORIGINAL_KEY_VERSION_PATH: der vollständige Ressourcenname der ursprünglichen Signaturschlüsselversion aus der Ausgabe des ersten Schritts in diesem Abschnitt. Beispiel: projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/1
    • NEW_KEY_VERSION_PATH: Der vollständige Ressourcenname der neuen Signaturschlüsselversion aus der Ausgabe des vorherigen Schritts. Beispiel: projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/2

    Nach Abschluss des Cluster-Updates kann es bis zu 10 Minuten dauern, bis der neue Schlüsselversionspfad an den Kubernetes API-Server und jeden GKE API-Endpunkt weitergegeben wird.

  5. So prüfen Sie, ob der neue Schlüsselversionspfad vollständig übernommen wurde:

    1. Rufen Sie die öffentliche Komponente der Clustersignaturschlüssel über die GKE API als JSON Web Key Set (JWKS) ab:

      curl https://container.googleapis.com/v1/projects/CLUSTER_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/clusters/CLUSTER_NAME/jwks

      Die Ausgabe sieht etwa so aus:

      {
  "keys": [
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY1_ID",
      "n": "KEY1_MODULUS",
      "e": "KEY1_EXPONENT"
    },
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY2_ID",
      "n": "KEY2_MODULUS",
      "e": "KEY2_EXPONENT"
    }
  ]
}

      Diese Ausgabe muss zwei Schlüssel-Einträge enthalten, was darauf hinweist, dass beide Schlüsselversionen in der GKE API verfügbar sind. Wenn Sie nur einen Schlüssel sehen, warten Sie 10 Minuten und versuchen Sie es noch einmal.

    2. Stellen Sie eine Verbindung zum Cluster her, damit Sie kubectl-Befehle ausführen können:

      gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

    3. Rufen Sie die öffentliche Komponente der Clustersignaturschlüssel vom Kubernetes API-Server als JWKS ab:

      kubectl get --raw /openid/v1/jwks | jq

      Die Ausgabe sieht etwa so aus:

      {
  "keys": [
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY1_ID",
      "n": "KEY1_MODULUS",
      "e": "KEY1_EXPONENT"
    },
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY2_ID",
      "n": "KEY2_MODULUS",
      "e": "KEY2_EXPONENT"
    }
  ]
}

      Diese Ausgabe muss zwei Schlüssel-Einträge enthalten, was darauf hinweist, dass beide Schlüsselversionen im Kubernetes API-Server verfügbar sind. Wenn Sie nur einen Schlüssel sehen, warten Sie 10 Minuten und versuchen Sie es noch einmal.

  6. Aktualisieren Sie den Cluster, damit die neue Schlüsselversion als Signaturschlüssel für das Dienstkonto verwendet wird:

    gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --service-account-signing-key=NEW_KEY_VERSION_PATH

  7. Prüfen Sie, ob für neue Dienstkontotokens die neue Schlüsselversion verwendet wird:

    1. Dienstkonto erstellen:

      kubectl create serviceaccount test-sa-1

    2. Erstellen Sie ein Token für das Dienstkonto:

      kubectl create token test-sa-1

    3. Extrahieren Sie einen kürzlich signierten Digest aus Logging:

      export SIGNED_DIGEST=$(gcloud logging read \
    'resource.type="gke_cluster" '\
    'AND resource.labels.cluster_name="' CLUSTER_NAME '" '\
    'AND protoPayload.methodName="google.cloud.gkeauth.v1.Auth.SignServiceAccountJWT" '\
    'AND protoPayload.metadata.subject="system:serviceaccount:default:test-sa-1"' \
    --freshness=1h \
    --bucket=_Required \
    --location=global \
    --view=_AllLogs \
    --order=DESC \
    --limit=1 \
    --format="value(protoPayload.metadata.toBeSignedDigest)")
      1. Prüfen Sie, ob die neue Version des Signaturschlüssels verwendet wird:
        gcloud logging read \
      'resource.type="cloudkms_cryptokeyversion" '\
      'AND protoPayload.methodName="AsymmetricSign" '\
      'AND protoPayload.request.digest.sha256="'${SIGNED_DIGEST}'"' \
      --freshness=1h \
      --bucket=_Default \
      --location=global \
      --view=_AllLogs \
      --order=DESC \
      --limit=1 \
      --format="value(protoPayload.resourceName)"
  ```
The output is the resource path of the new signing key version.

  8. Warten Sie, bis alle Tokens im Cluster, die die ursprüngliche Signaturschlüsselversion des Dienstkontos verwenden, abgelaufen sind. Standardmäßig beträgt die Tokenlebensdauer eine Stunde, mit einem konfigurierbaren Maximum von 24 Stunden. Führen Sie den folgenden Befehl aus, um die konfigurierte Token-Lebensdauer in Ihrem Cluster zu prüfen:

    kubectl get pods -A -o json | jq -r '.items[]?.spec?.volumes[]?.projected?.sources[]?.serviceAccountToken?.expirationSeconds | select(. != null)' | sort -nr | head -n 1

  9. Warten Sie, bis die konfigurierte Token-Lebensdauer aus der Ausgabe des vorherigen Schritts abgelaufen ist. Nach Ablauf dieses Zeitraums verwenden alle gebundenen Tokens in Ihrem Cluster die neue Version des Signaturschlüssels für das Dienstkonto.

  10. Entfernen Sie die ursprüngliche Schlüsselversion aus der Liste der Bestätigungsschlüssel für den Cluster:

    gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --service-account-verification-keys=NEW_KEY_VERSION_PATH

  11. Optional: Deaktivieren Sie die ursprüngliche Schlüsselversion. Nachdem Sie bestätigt haben, dass die ursprüngliche Schlüsselversion nicht verwendet wird und der Cluster fehlerfrei ist, löschen Sie die Schlüsselversion.

    Wenn Sie die Schlüssel nicht als Reaktion auf ein kritisches Ereignis rotieren, empfehlen wir, einige Tage zu warten, bevor Sie die ursprüngliche Schlüsselversion löschen. Weitere Informationen finden Sie unter Schlüsselversionen löschen und wiederherstellen.

Nachdem Sie diese Schritte ausgeführt haben, wird jedes neue und vorhandene Dienstkonto-Token in Ihrem Cluster mit der neuen Schlüsselversion signiert. Der API-Server lehnt alle Anfragen ab, die ein Bearer-Token mit der ursprünglichen Schlüsselversion verwenden, da die ursprüngliche Schlüsselversion nicht in der Clusterkonfiguration vorhanden ist.

CA-Zertifikate der GKE Control Plane Authority rotieren

In den folgenden Abschnitten wird beschrieben, wie Sie die Stammzertifizierungsstellen rotieren, die der Cluster für die GKE-Steuerungsebene verwendet.

Neue Schlüsselversionen für die CAs erstellen

  1. Erstellen Sie eine neue Schlüsselversion für den Cluster-Root-CA-Schlüssel:

    gcloud kms keys versions create \
    --key=CLUSTER_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

    Ersetzen Sie Folgendes:

    • CLUSTER_CA_KEY_NAME: Der Name des Schlüssel der Cluster-Root-CA für den Cluster.
    • KEYRING_NAME: der Name des Schlüsselbunds, der den Schlüssel enthält.
    • CONTROL_PLANE_LOCATION: der Google Cloud Speicherort des Schlüsselbunds. Dieser entspricht dem Standort Ihres Clusters.
    • KEY_PROJECT_ID: Die Projekt-ID Ihres Schlüsselprojekts.

  2. Erstellen Sie eine neue Schlüsselversion für den Aggregations-Stamm-CA-Schlüssel:

    gcloud kms keys versions create \
    --key=AGGREGATION_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

    Ersetzen Sie AGGREGATION_CA_KEY_NAME durch den Namen des Aggregations-Stammzertifizierungsstellenschlüssels für den Cluster.

  3. Erstellen Sie eine neue Schlüsselversion für den etcd-API-Root-CA-Schlüssel:

    gcloud kms keys versions create \
    --key=ETCD_API_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

    Ersetzen Sie ETCD_API_CA_KEY_NAME durch den Namen des etcd-API-Stammzertifizierungsstellenschlüssels für den Cluster.

  4. Erstellen Sie eine neue Schlüsselversion für den Stamm-CA-Schlüssel des etcd-Peers:

    gcloud kms keys versions create \
    --key=ETCD_PEER_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

    Ersetzen Sie ETCD_PEER_CA_KEY_NAME durch den Namen des etcd-Peer-Stammzertifizierungsstellenschlüssels für den Cluster.

Neue Stamm-CAs erstellen

  1. Rufen Sie den vollständigen Ressourcennamen der neuen Version des Cluster-Root-CA-Schlüssels ab:

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

    Die Ausgabe sieht etwa so aus:

    projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/CLUSTER_CA_KEY_NAME/cryptoKeyVersions/VERSION

    In dieser Ausgabe ist VERSION die Nummer der neuen Schlüsselversion.

  2. Erstellen Sie eine neue Cluster-Root-CA im Cluster-CA-Pool:

    gcloud privateca roots create CLUSTER_ROOT_CA_NAME \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=CLUSTER_CA_KEY_PATH \
    --subject="CN=cluster-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID

    Ersetzen Sie Folgendes:

    • CLUSTER_ROOT_CA_NAME: Ein Name für Ihre neue Stammzertifizierungsstelle.
    • CLUSTER_CA_POOL_NAME: Der Name des Cluster-CA-Pools.
    • CLUSTER_CA_KEY_PATH: der vollständige Ressourcenname der neuen Schlüsselversion aus der Ausgabe des vorherigen Schritts.
    • ORGANIZATION: Der Name Ihrer Organisation.

  3. Rufen Sie den vollständigen Ressourcennamen der neuen CA-Schlüsselversion für den Aggregationsstamm ab:

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

    Die Ausgabe sieht etwa so aus:

    projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/AGGREGATION_CA_KEY_NAME/cryptoKeyVersions/VERSION

  4. Erstellen Sie eine neue Stamm-CA für die Zusammenfassung im CA-Pool für die Zusammenfassung:

    gcloud privateca roots create AGGREGATION_ROOT_CA_NAME \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=AGGREGATION_CA_KEY_PATH \
    --subject="CN=aggregation-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID

    Ersetzen Sie Folgendes:

    • AGGREGATION_ROOT_CA_NAME: ein Name für die neue aggregierte Stammzertifizierungsstelle.
    • AGGREGATION_CA_POOL_NAME: der Name des CA-Pools für die Aggregation.
    • AGGREGATION_CA_KEY_PATH: der vollständige Ressourcenname der neuen Schlüsselversion aus der Ausgabe des vorherigen Schritts.

  5. Rufen Sie den vollständigen Ressourcennamen der neuen etcd-API-Root-CA-Schlüsselversion ab:

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

    Die Ausgabe sieht etwa so aus:

    projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/ETCD_API_CA_KEY_NAME/cryptoKeyVersions/VERSION

  6. Erstellen Sie eine neue Stamm-CA für die etcd-API im CA-Pool für die etcd-API:

    gcloud privateca roots create ETCD_API_ROOT_CA_NAME \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=ETCD_API_CA_KEY_PATH \
    --subject="CN=etcd-api-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID

    Ersetzen Sie Folgendes:

    • ETCD_API_ROOT_CA_NAME: Ein Name für die neue Stammzertifizierungsstelle der etcd-API.
    • ETCD_API_CA_POOL_NAME: Der Name des CA-Pools für die etcd-API.
    • ETCD_API_CA_KEY_PATH: der vollständige Ressourcenname der neuen Schlüsselversion aus der Ausgabe des vorherigen Schritts.

  7. Rufen Sie den vollständigen Ressourcennamen der neuen etcd-Peer-Stamm-CA-Schlüsselversion ab:

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

    Die Ausgabe sieht etwa so aus:

    projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/ETCD_PEER_CA_KEY_NAME/cryptoKeyVersions/VERSION

  8. Erstellen Sie eine neue Stamm-CA für etcd-Peers im CA-Pool für etcd-Peers:

    gcloud privateca roots create ETCD_PEER_ROOT_CA_NAME \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=ETCD_PEER_CA_KEY_PATH \
    --subject="CN=etcd-peer-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID

    Ersetzen Sie Folgendes:

    • ETCD_PEER_ROOT_CA_NAME: Ein Name für die neue Stammzertifizierungsstelle für etcd-Peers.
    • ETCD_PEER_CA_POOL_NAME: der Name des etcd-Peer-CA-Pools.
    • ETCD_PEER_CA_KEY_PATH: der vollständige Ressourcenname der neuen Schlüsselversion aus der Ausgabe des vorherigen Schritts.

  9. Bevor Sie fortfahren, übertragen Sie die Änderungen der Stamm-CA in das Cluster-Vertrauensbündel. Folgen Sie dazu der Anleitung im Abschnitt Steuerungsebene und Knoten neu starten.

Ersetzen Sie die ursprünglichen Stammzertifizierungsstellen durch die neuen.

Nachdem Sie die Steuerungsebene und die Knoten neu gestartet haben, gehen Sie so vor:

  1. Aktivieren Sie die neue Cluster-Stamm-CA:

    gcloud privateca roots enable CLUSTER_ROOT_CA_NAME \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

  2. Aktivieren Sie die neue Stamm-CA für die Zusammenfassung:

    gcloud privateca roots enable AGGREGATION_ROOT_CA_NAME \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

  3. Aktivieren Sie die neue Stamm-CA für die etcd API:

    gcloud privateca roots enable ETCD_API_ROOT_CA_NAME \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

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

    gcloud privateca roots enable ETCD_PEER_ROOT_CA_NAME \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

  5. Deaktivieren Sie die ursprüngliche Cluster-Stamm-CA:

    gcloud privateca roots disable ORIGINAL_CLUSTER_ROOT_CA \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

    Ersetzen Sie ORIGINAL_CLUSTER_ROOT_CA durch den Namen der ursprünglichen Cluster-Stammzertifizierungsstelle, die Sie rotieren.

  6. Deaktivieren Sie die ursprüngliche Stamm-CA für die Aggregation:

    gcloud privateca roots disable ORIGINAL_AGGREGATION_ROOT_CA \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

    Ersetzen Sie ORIGINAL_AGGREGATION_ROOT_CA durch den Namen der ursprünglichen Aggregations-Stammzertifizierungsstelle, die Sie rotieren.

  7. Deaktivieren Sie die ursprüngliche Stamm-CA der etcd-API:

    gcloud privateca roots disable ORIGINAL_ETCD_API_ROOT_CA \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

    Ersetzen Sie ORIGINAL_ETCD_API_ROOT_CA durch den Namen der ursprünglichen etcd-API-Stammzertifizierungsstelle, die Sie rotieren.

  8. Deaktivieren Sie die ursprüngliche Stamm-CA des etcd-Peers:

    gcloud privateca roots disable ORIGINAL_ETCD_PEER_ROOT_CA \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

    Ersetzen Sie ORIGINAL_ETCD_PEER_ROOT_CA durch den Namen der ursprünglichen etcd-Peer-Stammzertifizierungsstelle, die Sie rotieren.

  9. An diesem Punkt stellen die neuen Stamm-CAs alle neuen Zertifikate im Cluster aus. Um neue Zertifikate für die kubelet auf jedem Knoten auszustellen, starten Sie die Steuerungsebene und die Knoten neu. Dieser Schritt ist erforderlich, da kubelet-Zertifikate eine lange Lebensdauer haben.

Nachdem der Cluster mehrere Tage lang in einem fehlerfreien Zustand war, können Sie die ursprünglichen Root-Zertifizierungsstellen löschen, wie im nächsten Abschnitt beschrieben.

Ursprüngliche Stammzertifizierungsstellen löschen

In diesem Abschnitt erfahren Sie, wie Sie Ihre ursprünglichen Stammzertifizierungsstellen löschen. Bevor Sie diese Schritte ausführen, prüfen Sie Folgendes:

  • Der Cluster blieb mehrere Tage lang in einem fehlerfreien Zustand, nachdem Sie die ursprünglichen Stamm-Zertifizierungsstellen durch die neuen Stamm-Zertifizierungsstellen ersetzt hatten.
  • Sie haben alle von den ursprünglichen Root-CAs ausgestellten Zertifikate durch neue Zertifikate ersetzt.

Verwenden Sie den Befehl gcloud privateca roots delete, um die ursprünglichen Root-Zertifizierungsstellen zu löschen, wie in den folgenden Schritten beschrieben. In diesen Befehlen wird mit dem Flag --ignore-active-certificates die CA nach einer Kulanzfrist gelöscht, auch wenn die CA nicht widerrufene oder nicht abgelaufene Zertifikate hat.

  1. Löschen Sie die ursprüngliche Stammzertifizierungsstelle des Clusters:

    gcloud privateca roots delete ORIGINAL_CLUSTER_ROOT_CA \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

    Ersetzen Sie ORIGINAL_CLUSTER_ROOT_CA durch den Namen der ursprünglichen Cluster-Stammzertifizierungsstelle, die Sie rotieren.

  2. Löschen Sie die ursprüngliche Aggregations-Stammzertifizierungsstelle:

    gcloud privateca roots delete ORIGINAL_AGGREGATION_ROOT_CA \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

    Ersetzen Sie ORIGINAL_AGGREGATION_ROOT_CA durch den Namen der ursprünglichen Aggregations-Stammzertifizierungsstelle, die Sie rotieren.

  3. Löschen Sie die ursprüngliche Stammzertifizierungsstelle der etcd-API:

    gcloud privateca roots delete ORIGINAL_ETCD_API_ROOT_CA \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

    Ersetzen Sie ORIGINAL_ETCD_API_ROOT_CA durch den Namen der ursprünglichen etcd-API-Stammzertifizierungsstelle, die Sie rotieren.

  4. Löschen Sie die ursprüngliche Stammzertifizierungsstelle für etcd-Peers:

    gcloud privateca roots delete ORIGINAL_ETCD_PEER_ROOT_CA \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

    Ersetzen Sie ORIGINAL_ETCD_PEER_ROOT_CA durch den Namen der ursprünglichen etcd-Peer-Stammzertifizierungsstelle, die Sie rotieren.

  5. Optional: Übertragen Sie die Änderungen an den Root-CAs auf das Cluster-Trust-Bundle. Eine Anleitung finden Sie im Abschnitt Steuerungsebene und Knoten neu starten. Wenn Sie diesen Schritt überspringen, werden die ursprünglichen Stammzertifizierungsstellen beim nächsten Upgrade der Steuerungsebene und der Knotenversion entfernt.

Steuerungsebene und Knoten neu starten

Wenn Sie Änderungen an der Root-CA-Konfiguration Ihres Clusters vornehmen, z. B. Root-CAs aktivieren oder deaktivieren oder Zertifikate widerrufen, müssen Sie diese Änderungen an das Trust-Bundle des Clusters weitergeben. Damit Änderungen am Trust-Bundle für den Cluster übernommen werden, starten Sie die Steuerungsebene und (in einigen Szenarien) die Knoten neu.

  1. Führen Sie ein Upgrade der Cluster-Steuerungsebene auf dieselbe Version durch, die bereits verwendet wird.

    1. Suchen Sie nach der GKE-Version, die bereits von der Steuerungsebene verwendet wird:

      gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --format="value(currentMasterVersion)"

      Ersetzen Sie Folgendes:

      • CLUSTER_NAME: Name Ihres GKE-Clusters.
      • CLUSTER_VERSION: die GKE-Version, die auf dem Cluster bereits ausgeführt wird.
      • CLUSTER_PROJECT_ID: die Projekt-ID Ihres Clusterprojekts.

    2. Upgrade der Steuerungsebene durchführen:

      gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=CLUSTER_VERSION \
    --project=CLUSTER_PROJECT_ID

  2. Wenn Sie Zertifikate manuell mit Kubernetes-CertificateSigningRequests generieren, stellen Sie alle diese Zertifikate neu aus und stellen Sie die neuen Zertifikate API-Clients zur Verfügung.

  3. Wenn Sie nur die Cluster-Stamm-CA rotieren möchten, lösen Sie die Knotenneuerstellung aus, indem Sie für jeden Ihrer Knotenpools ein Upgrade auf die bereits verwendete Version durchführen.

    1. So finden Sie die GKE-Version, die der Knotenpool verwendet:

      gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --format="value(version)"

      Ersetzen Sie NODE_POOL_NAME durch den Namen des Knotenpools, der aktualisiert werden soll.

    2. Knotenpool aktualisieren:

      gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=NODE_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=CLUSTER_VERSION \
    --project=CLUSTER_PROJECT_ID

Wenn Sie die Schritte in diesem Abschnitt während einer CA-Rotation ausgeführt haben, fahren Sie mit der nächsten Phase der Rotation fort. Das ist einer der folgenden Abschnitte auf dieser Seite:

Nächste Schritte