Secret Manager-Add-on mit der Google Kubernetes Engine verwenden

Durch die Integration von Secret Manager und Google Kubernetes Engine (GKE) können Sie sensible Daten wie Passwörter und Zertifikate, die von GKE-Clustern verwendet werden, als Secrets in Secret Manager speichern.

Auf dieser Seite wird erläutert, wie Sie mit dem Secret Manager-Add-on auf die in Secret Manager gespeicherten Secrets als Volumes zugreifen, die in Kubernetes-Pods bereitgestellt sind.

Dieser Vorgang umfasst folgende Schritte:

1. Aktivieren Sie das Secret Manager-Add-on für einen neuen oder vorhandenen GKE-Cluster.
2. Anwendungen für die Authentifizierung bei der Secret Manager API konfigurieren
3. Definieren Sie mit einer SecretProviderClass-YAML-Datei, welche Secrets in Kubernetes-Pods eingebunden werden sollen. Das Secret Manager-Add-on unterstützt sowohl globale als auch regionale Secrets.
4. Erstellen Sie ein Volume, in dem die Secrets bereitgestellt werden. Nachdem das Volume angehängt wurde, können Anwendungen im Container auf die Daten im Containerdateisystem zugreifen.

Das Secret Manager-Add-on basiert auf dem Open-Source-CSI-Treiber für Kubernetes Secret Store und dem Google Secret Manager-Anbieter. Wenn Sie den Open-Source-CSI-Treiber für Secrets Store verwenden, um auf Secrets zuzugreifen, können Sie zum Secret Manager-Add-on migrieren. Weitere Informationen finden Sie unter Von vorhandenem CSI-Treiber für Secrets-Speicher migrieren.

Vorteile

Das Secret Manager-Add-on bietet folgende Vorteile:

• Sie können eine vollständig verwaltete und unterstützte Lösung verwenden, um ohne Betriebsaufwand auf Secret Manager-Secrets in GKE zuzugreifen.
• Sie müssen keinen benutzerdefinierten Code schreiben, um auf in Secret Manager gespeicherte Secrets zuzugreifen.
• Sie können alle Ihre Secrets zentral in Secret Manager speichern und verwalten und mit dem Secret Manager-Add-on selektiv auf Secrets aus GKE-Pods zugreifen. So können Sie Funktionen von Secret Manager wie CMEK-Verschlüsselung, detaillierte Zugriffssteuerung, verwaltete Rotation, Lebenszyklusverwaltung und Audit-Logs nutzen und gleichzeitig Kubernetes-Funktionen wie das Übergeben von Secrets an Container in Form von eingebundenen Volumes verwenden.
• Das Secret Manager-Add-on wird sowohl in Standard-Clustern als auch in Autopilot-Clustern unterstützt.
• Das Secret Manager-Add-on unterstützt Knoten, die Knoten-Images für Container-Optimized OS oder Ubuntu verwenden.

Beschränkungen

Für das Secret Manager-Add-on gelten die folgenden Einschränkungen:

• Das Secret Manager-Add-on unterstützt die Funktion Als Kubernetes-Secret synchronisieren nicht, die im Open-Source-Secrets Store CSI-Treiber verfügbar ist. Wenn Sie in Secret Manager gespeicherte Secrets mit Kubernetes-Secrets synchronisieren möchten, verwenden Sie die integrierte Secret-Synchronisierungsfunktion von Secret Manager. Weitere Informationen finden Sie unter Secrets mit Kubernetes Secrets synchronisieren.

• Das Secret Manager-Add-on unterstützt keine Windows Server-Knoten.

Hinweis

• Aktivieren Sie die Secret Manager API und die Google Kubernetes Engine API, falls sie noch nicht aktiviert sind.

  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

  APIs aktivieren

• Wenn Sie die Google Cloud CLI für diese Aufgabe 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 dem Befehl gcloud components update ab.

  Sie können das Secret Manager-Add-on nicht manuell mit dem Google Cloud SDK oder der Cloud de Confiance -Konsole einrichten.

• Achten Sie darauf, dass in Ihrem Cluster die GKE-Version 1.27.14-gke.1042001 oder höher mit einem Linux-Knoten-Image ausgeführt wird.

• Wenn Sie einen GKE Standard-Cluster verwenden, muss Workload Identity Federation for GKE für Ihren Cluster aktiviert sein. Die Workload Identity-Föderation für GKE ist in einem Autopilot-Cluster standardmäßig aktiviert. Kubernetes-Pods verwenden die Workload Identity-Föderation für GKE, um sich bei der Secret Manager API zu authentifizieren.

Secret Manager-Add-on aktivieren

Sie können das Secret Manager-Add-on sowohl für Standard- als auch für Autopilot-Cluster aktivieren.

Secret Manager-Add-on in einem neuen GKE-Cluster aktivieren

So aktivieren Sie das Secret Manager-Add-on beim Erstellen des Clusters:

gcloud container clusters create CLUSTER_NAME \
    --enable-secret-manager \
    --location=LOCATION \
    --cluster-version=VERSION \
    --workload-pool=PROJECT_ID.s3ns.svc.id.goog

gcloud container clusters create CLUSTER_NAME `
    --enable-secret-manager `
    --location=LOCATION `
    --cluster-version=VERSION `
    --workload-pool=PROJECT_ID.s3ns.svc.id.goog

gcloud container clusters create CLUSTER_NAME ^
    --enable-secret-manager ^
    --location=LOCATION ^
    --cluster-version=VERSION ^
    --workload-pool=PROJECT_ID.s3ns.svc.id.goog

gcloud container clusters create-auto CLUSTER_NAME \
    --enable-secret-manager \
    --cluster-version=VERSION \
    --location=LOCATION

gcloud container clusters create-auto CLUSTER_NAME `
    --enable-secret-manager `
    --cluster-version=VERSION `
    --location=LOCATION

gcloud container clusters create-auto CLUSTER_NAME ^
    --enable-secret-manager ^
    --cluster-version=VERSION ^
    --location=LOCATION

Nachdem Sie das Secret Manager-Add-on aktiviert haben, können Sie den Secrets Store CSI-Treiber in Kubernetes-Volumes mit dem Namen des Treibers und des Bereitstellers verwenden: secrets-store-gke.csi.k8s.io.

Secret Manager-Add-on in einem vorhandenen GKE-Cluster aktivieren

So aktivieren Sie das Secret Manager-Add-on für einen vorhandenen Cluster:

gcloud container clusters update CLUSTER_NAME \
    --enable-secret-manager \
    --location=LOCATION

gcloud container clusters update CLUSTER_NAME `
    --enable-secret-manager `
    --location=LOCATION

gcloud container clusters update CLUSTER_NAME ^
    --enable-secret-manager ^
    --location=LOCATION

Installation des Secret Manager-Add-ons prüfen

Führen Sie den folgenden Befehl aus, um zu prüfen, ob das Secret Manager-Add-on im Kubernetes-Cluster installiert ist:

  gcloud container clusters describe CLUSTER_NAME --location LOCATION | grep secretManagerConfig -A 4

Ersetzen Sie Folgendes:

• CLUSTER_NAME ist der Name des Clusters.
• LOCATION: Der Standort Ihres Clusters, z. B. us-central1

Automatische Rotation von Secrets konfigurieren

Sie können das Secret Manager-Add-on so konfigurieren, dass Secrets automatisch rotiert werden. Secrets, die nach der ersten Bereitstellung des Pods in Secret Manager aktualisiert werden, werden dann automatisch und regelmäßig an den Pod übertragen. Durch die automatische Rotation von eingebundenen Secrets erhalten Anwendungen automatisch aktualisierte Secrets, ohne dass ein Neustart oder manueller Eingriff erforderlich ist. Diese Funktion sorgt dafür, dass Anwendungen immer die aktuellsten Secrets verwenden.

Beachten Sie beim Konfigurieren der automatischen Rotation von Secrets Folgendes:

• Die automatische Rotation von Secrets ist eine optionale Konfiguration.
• Sie können diese Funktion beim Erstellen eines neuen Clusters oder beim Aktualisieren eines vorhandenen Clusters konfigurieren.
• Sie können die Häufigkeit der automatischen Rotation konfigurieren, indem Sie das Rotationsintervall und die Rotationsintervalleinheit angeben.
• Die automatische Rotation von Secrets wird in GKE-Version 1.32.2-gke.1059000 oder höher unterstützt.

Wenn Sie die automatische Rotation von Secrets konfigurieren möchten, müssen Sie die Funktion enable-secret-manager-rotation aktivieren und das Rotationsintervall durch Festlegen von secret-manager-rotation-interval konfigurieren.

Automatische Rotation von Secrets in einem neuen GKE-Cluster konfigurieren

So konfigurieren Sie die automatische Rotation von Secrets beim Erstellen des Clusters:

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --location=LOCATION \
    --enable-secret-manager \
    --enable-secret-manager-rotation \
    --secret-manager-rotation-interval=ROTATION_INTERVAL
    

gcloud container clusters create CLUSTER_NAME `
    --cluster-version=VERSION `
    --location=LOCATION `
    --enable-secret-manager `
    --enable-secret-manager-rotation `
    --secret-manager-rotation-interval=ROTATION_INTERVAL
    

gcloud container clusters create CLUSTER_NAME ^
    --cluster-version=VERSION ^
    --location=LOCATION ^
    --enable-secret-manager ^
    --enable-secret-manager-rotation ^
    --secret-manager-rotation-interval=ROTATION_INTERVAL
    

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --cluster-version=VERSION \
    --workload-pool=PROJECT_ID.s3ns.svc.id.goog \
    --enable-secret-manager \
    --enable-secret-manager-rotation \
    --secret-manager-rotation-interval=ROTATION_INTERVAL
    

gcloud container clusters create CLUSTER_NAME `
    --location=LOCATION `
    --cluster-version=VERSION `
    --workload-pool=PROJECT_ID.s3ns.svc.id.goog `
    --enable-secret-manager `
    --enable-secret-manager-rotation `
    --secret-manager-rotation-interval=ROTATION_INTERVAL
    

gcloud container clusters create CLUSTER_NAME ^
    --location=LOCATION ^
    --cluster-version=VERSION ^
    --workload-pool=PROJECT_ID.s3ns.svc.id.goog ^
    --enable-secret-manager ^
    --enable-secret-manager-rotation ^
    --secret-manager-rotation-interval=ROTATION_INTERVAL
    

Automatische Rotation von Secrets in einem vorhandenen GKE-Cluster konfigurieren

So konfigurieren Sie die automatische Rotation von Secrets in einem vorhandenen GKE-Cluster:

gcloud container clusters update CLUSTER_NAME \
    --enable-secret-manager \
    --location=LOCATION \
    --enable-secret-manager-rotation \
    --secret-manager-rotation-interval=ROTATION_INTERVAL

gcloud container clusters update CLUSTER_NAME `
    --enable-secret-manager `
    --location=LOCATION `
    --enable-secret-manager-rotation `
    --secret-manager-rotation-interval=ROTATION_INTERVAL

gcloud container clusters update CLUSTER_NAME ^
    --enable-secret-manager ^
    --location=LOCATION ^
    --enable-secret-manager-rotation ^
    --secret-manager-rotation-interval=ROTATION_INTERVAL

Anwendungen für die Authentifizierung bei der Secret Manager API konfigurieren

Der Google Secret Manager-Anbieter verwendet die Arbeitslastidentität des Pods, in den ein Secret eingebunden ist, wenn er sich bei der Secret Manager API authentifiziert. So ermöglichen Sie es Ihren Anwendungen, sich mit Workload Identity Federation for GKE bei der Secret Manager API zu authentifizieren:

• Erstellen Sie ein Kubernetes-ServiceAccount oder verwenden Sie ein vorhandenes Kubernetes-ServiceAccount im selben Namespace wie der Pod, in den Sie das Secret einbinden möchten.

• Erstellen Sie eine IAM-Richtlinie (Identity and Access Management) für das Secret in Secret Manager.

Pods, die das konfigurierte Kubernetes-Dienstkonto verwenden, werden beim Zugriff auf die Secret Manager API automatisch als die IAM-Haupt-ID authentifiziert, die dem Kubernetes-Dienstkonto entspricht.

Kubernetes-Dienstkonto erstellen

1. Speichern Sie das folgende Manifest als service-account.yaml:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: KSA_NAME
     namespace: NAMESPACE
   

   Ersetzen Sie Folgendes:

   • KSA_NAME: der Name des neuen Kubernetes-ServiceAccount
   • NAMESPACE: der Name des Kubernetes-Namespace für das ServiceAccount

2. Wenden Sie das Manifest an:

   kubectl apply -f service-account.yaml
   

3. Erstellen Sie eine IAM-Zulassungsrichtlinie, die auf das neue Kubernetes-ServiceAccount verweist, und gewähren Sie ihm die Berechtigung für den Zugriff auf das Secret:

   gcloud secrets add-iam-policy-binding SECRET_NAME \
       --role=roles/secretmanager.secretAccessor \
       --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.s3ns.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME
   

   Ersetzen Sie Folgendes:

   • SECRET_NAME: Der Name des Secrets im Secret Manager
   • PROJECT_NUMBER: Ihre numerische Cloud de Confiance Projektnummer
   • PROJECT_ID: Die Projekt-ID des Cloud de Confiance by S3NS -Projekts, das Ihren GKE-Cluster enthält.
   • NAMESPACE: der Name des Kubernetes-Namespace für das ServiceAccount
   • KSA_NAME: der Name Ihres vorhandenen Kubernetes-ServiceAccount

Vorhandenes Kubernetes-ServiceAccount verwenden

Erstellen Sie eine IAM-Zulassungsrichtlinie, die auf das vorhandene Kubernetes-ServiceAccount verweist, und gewähren Sie ihm die Berechtigung für den Zugriff auf das Secret:

gcloud secrets add-iam-policy-binding SECRET_NAME \
    --role=roles/secretmanager.secretAccessor \
    --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.s3ns.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME

Ersetzen Sie Folgendes:

• SECRET_NAME: Der Name des Secrets im Secret Manager
• PROJECT_NUMBER: Ihre numerische Cloud de Confiance Projektnummer
• PROJECT_ID: Die Projekt-ID des Cloud de Confiance by S3NS -Projekts, das Ihren GKE-Cluster enthält.
• NAMESPACE: der Name des Kubernetes-Namespace für das ServiceAccount
• KSA_NAME: der Name Ihres vorhandenen Kubernetes-ServiceAccount

Festlegen, welche Secrets bereitgestellt werden sollen

Wenn Sie angeben möchten, welche Secrets als Dateien im Kubernetes-Pod bereitgestellt werden sollen, erstellen Sie ein SecretProviderClass-YAML-Manifest und listen Sie die Secrets auf, die bereitgestellt werden sollen, sowie den Dateinamen, unter dem sie bereitgestellt werden sollen. Gehen Sie so vor:

1. Speichern Sie das folgende Manifest als app-secrets.yaml:

   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: SECRET_PROVIDER_CLASS_NAME
   spec:
     provider: gke
     parameters:
       secrets: |
         - resourceName: "projects/PROJECT_ID/secrets/SECRET_NAME/versions/SECRET_VERSION"
           path: "FILENAME.txt"
   

   Ersetzen Sie Folgendes:

   • SECRET_PROVIDER_CLASS_NAME: der Name für Ihr SecretProviderClass-Objekt.
   • PROJECT_ID: Ihre Projekt-ID.
   • SECRET_NAME: der Secret-Name.
   • SECRET_VERSION: die Secret-Version. Die Secret-Version muss sich in derselben Region wie der Cluster befinden.
   • FILENAME.txt: Der Dateiname, in dem der Secret-Wert bereitgestellt wird. Sie können mehrere Dateien mit den Variablen resourceName und path erstellen.

   Bei einem regionalen Secret ist resourceName der vollständige Pfad zur Secret-Ressource, der den Speicherort des regionalen Secrets enthält. Beispiel: „projects/PROJECT_ID/locations/LOCATION/secrets/SECRET_NAME/versions/SECRET_VERSION“

2. Wenden Sie das Manifest an:

   kubectl apply -f app-secrets.yaml -n NAMESPACE
   

   Ersetzen Sie NAMESPACE durch den Namen des Kubernetes-Namespace für das Dienstkonto.

3. Prüfen Sie, ob das SecretProviderClass-Objekt erstellt wurde:

   kubectl get SecretProviderClasses -n NAMESPACE
   

Volume konfigurieren, in dem die Secrets bereitgestellt werden

1. Speichern Sie die folgende Konfiguration als my-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: POD_NAME
     namespace: NAMESPACE
   spec:
     serviceAccountName: KSA_NAME
     containers:
     - image: IMAGE_NAME
       imagePullPolicy: IfNotPresent
       name: POD_NAME
       resources:
         requests:
           cpu: 100m
       stdin: true
       stdinOnce: true
       terminationMessagePath: /dev/termination-log
       terminationMessagePolicy: File
       tty: true
       volumeMounts:
         - mountPath: "/var/secrets"
           name: mysecret
     volumes:
     - name: mysecret
       csi:
         driver: secrets-store-gke.csi.k8s.io
         readOnly: true
         volumeAttributes:
           secretProviderClass: SECRET_PROVIDER_CLASS_NAME
   

   Ersetzen Sie Folgendes:

   • POD_NAME: der Name des Kubernetes-Pods, in dem das Secret eingebunden ist
   • NAMESPACE: der Name des Kubernetes-Namespace für das ServiceAccount
   • KSA_NAME: Das Kubernetes-Dienstkonto, das Sie im Schritt Anwendungen für die Authentifizierung bei der Secret Manager API konfigurieren eingerichtet haben.
   • IMAGE_NAME ist der Name des Container-Images.
   • SECRET_PROVIDER_CLASS_NAME: der Name für Ihr SecretProviderClass-Objekt

2. Nur in Standardclustern: Fügen Sie dem Feld template.spec Folgendes hinzu, um die Pods in Knotenpools zu platzieren, die Workload Identity Federation for GKE verwenden.

   In Autopilot-Clustern wird dieser Schritt übersprungen, sodass dieser nodeSelector abgelehnt wird, da jeder Knoten Workload Identity Federation for GKE verwendet.

   spec:
     nodeSelector:
       iam.gke.io/gke-metadata-server-enabled: "true"
   

3. Wenden Sie die Konfiguration auf Ihren Cluster an.

   kubectl apply -f my-pod.yaml
   

In diesem Schritt wird ein Volume mysecret unter /var/secrets mit dem CSI-Treiber (secrets-store-gke.csi.k8s.io) bereitgestellt. Dieses Volume verweist auf das SecretProviderClass-Objekt, das als Anbieter fungiert.

Vom vorhandenen Open-Source-CSI-Treiber für Kubernetes Secrets Store migrieren

Wenn Sie den Open-Source-CSI-Treiber für Kubernetes Secret Store und den Google Secret Manager-Anbieter verwenden, können Sie Ihre Arbeitslasten zum verwalteten Secret Manager-Add-on migrieren.

Das verwaltete Add-on und der Open-Source-Treiber können gleichzeitig im selben Cluster ausgeführt werden. So können Sie einzelne Anwendungen und Namespaces inkrementell migrieren, ohne dass es zu Cluster-Ausfallzeiten kommt.

So migrieren Sie zum Secret Manager-Add-on:

1. Secret Manager-Add-on für Ihren Cluster aktivieren
2. SecretProviderClass-Manifeste erstellen
3. Arbeitslastmanifeste aktualisieren
4. Migration überprüfen
5. Alte Open-Source-Ressourcen bereinigen

Schritt 1: Secret Manager-Add-on für Ihren Cluster aktivieren

Aktivieren Sie das Secret Manager-Add-on in Ihrem vorhandenen GKE-Cluster:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --enable-secret-manager \
    [--enable-secret-manager-rotation \
     --secret-manager-rotation-interval=ROTATION_INTERVAL]

Ersetzen Sie Folgendes:

• CLUSTER_NAME: der Name Ihres Clusters
• LOCATION: Der Standort Ihres Clusters, z. B. us-central1.
• (Optional) ROTATION_INTERVAL: Die Häufigkeit, mit der eingebundene Secrets automatisch aktualisiert werden, z. B. 120s oder 3600s. Der zulässige Mindestwert ist 60s und der Standardwert ist 120s.

Schritt 2: SecretProviderClass-Manifeste erstellen

Erstellen Sie für jede Anwendung ein SecretProviderClass-Manifest mit provider: gke. Wir empfehlen, dem Ressourcennamen -gke anzuhängen, damit die alten und neuen SecretProviderClass-Ressourcen während der laufenden Updates nebeneinander existieren können.

1. Speichern Sie das folgende Manifest als secret-provider-class-gke.yaml:

   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: SECRET_PROVIDER_CLASS_NAME-gke # Append -gke to coexist with existing SPC
     namespace: NAMESPACE
   spec:
     provider: gke # Changed from 'gcp'
     parameters:
       secrets: |
         - resourceName: "projects/PROJECT_ID/secrets/SECRET_NAME/versions/SECRET_VERSION"
           path: "FILENAME.txt"
   

   Ersetzen Sie Folgendes:

   • SECRET_PROVIDER_CLASS_NAME-gke: der Name der neuen SecretProviderClass-Ressource
   • NAMESPACE: der Kubernetes-Namespace, in dem Ihre Arbeitslast ausgeführt wird
   • PROJECT_ID: Ihre Cloud de Confiance by S3NS Projekt-ID
   • SECRET_NAME: Der Name des Secrets im Secret Manager.
   • SECRET_VERSION: die Secret-Version, z. B. latest oder 1
   • FILENAME.txt: der Dateiname, in dem der Secret-Wert bereitgestellt wird

   Geben Sie für regionale Secrets den vollständigen Ressourcenpfad einschließlich des Standorts an: "projects/PROJECT_ID/locations/LOCATION/secrets/SECRET_NAME/versions/SECRET_VERSION"

2. Wenden Sie das neue SecretProviderClass-Manifest an:

   kubectl apply -f secret-provider-class-gke.yaml
   

Schritt 3: Arbeitslastmanifeste aktualisieren

Aktualisieren Sie Ihre Pod- oder Deployment-Manifeste, damit der verwaltete Treiber (secrets-store-gke.csi.k8s.io) verwendet wird und auf den neuen Namen SecretProviderClass verwiesen wird.

1. Aktualisieren Sie den Abschnitt volumes Ihres Arbeitslastmanifests (z. B. deployment.yaml):

   spec:
     containers:
     - name: CONTAINER_NAME
       image: IMAGE_NAME
       volumeMounts:
       - name: secrets-volume
         mountPath: "/var/secrets"
         readOnly: true
     volumes:
     - name: secrets-volume
       csi:
         driver: secrets-store-gke.csi.k8s.io # Changed from 'secrets-store.csi.k8s.io'
         readOnly: true
         volumeAttributes:
           secretProviderClass: SECRET_PROVIDER_CLASS_NAME-gke # Reference new SPC name
   

   Ersetzen Sie Folgendes:

   • CONTAINER_NAME: der Name des Containers in Ihrer Arbeitslast
   • IMAGE_NAME: der Name Ihres Container-Images
   • SECRET_PROVIDER_CLASS_NAME-gke: der Name der neuen SecretProviderClass-Ressource

2. Wenden Sie das aktualisierte Arbeitslastmanifest an, um ein Rolling Deployment auszulösen:

   kubectl apply -f deployment.yaml
   

Schritt 4: Migration überprüfen

Prüfen Sie, ob Ihre Arbeitslasten das verwaltete Add-on erfolgreich verwenden:

1. Prüfen Sie, ob Ihre Pods bereitgestellt wurden und den Status Running erreicht haben:

   kubectl get pods -n NAMESPACE
   

   Ersetzen Sie NAMESPACE durch den Kubernetes-Namespace, in dem Ihre Arbeitslast ausgeführt wird.

2. Prüfen Sie, ob Secrets korrekt bereitgestellt wurden und im Container darauf zugegriffen werden kann:

   kubectl exec -it POD_NAME -n NAMESPACE -- cat /var/secrets/FILENAME.txt
   

   Ersetzen Sie Folgendes:

   • POD_NAME: der Name Ihres Kubernetes-Pods
   • NAMESPACE: der Kubernetes-Namespace, in dem Ihre Arbeitslast ausgeführt wird
   • FILENAME.txt: der Name der eingebundenen Secret-Datei, die in Ihrer SecretProviderClass konfiguriert ist

3. Optional: Wenn Sie die automatische Rotation aktiviert haben, prüfen Sie die Secret-Aktualisierungen:

   1. Fügen Sie in Secret Manager eine neue Version des Secrets hinzu.
   2. Warten Sie das konfigurierte Rotationsintervall ab, z. B. 120 Sekunden.

   3. Sehen Sie sich die eingebundene Secret-Datei noch einmal im Pod an, um zu prüfen, ob der Inhalt aktualisiert wurde, ohne dass der Pod neu gestartet wurde:

      kubectl exec -it POD_NAME -n NAMESPACE -- cat /var/secrets/FILENAME.txt
      

Schritt 5: Alte Open-Source-Ressourcen bereinigen

1. Löschen Sie die alten SecretProviderClass-Ressourcen:

   kubectl delete secretproviderclass OLD_SECRET_PROVIDER_CLASS_NAME -n NAMESPACE
   

   Ersetzen Sie Folgendes:

   • OLD_SECRET_PROVIDER_CLASS_NAME: Der Name Ihrer Legacy-SecretProviderClass-Ressource, z. B. my-app-secrets.
   • NAMESPACE: der Kubernetes-Namespace, in dem Ihre Arbeitslast ausgeführt wird

2. Wenn Sie das Open-Source-Plugin für den Google Secret Manager-Anbieter mit einem Manifest bereitgestellt haben, löschen Sie das DaemonSet:

   kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/secrets-store-csi-driver-provider-gcp/main/deploy/provider-gcp-plugin.yaml
   

3. Wenn Sie den Open-Source-CSI-Treiber für Secrets-Speicher mit Helm installiert haben, deinstallieren Sie die Helm-Version:

   helm uninstall csi-secrets-store -n kube-system
   

Secret Manager-Add-on deaktivieren

Führen Sie den folgenden Befehl aus, um das Secret Manager-Add-on in einem vorhandenen Standard-Cluster oder in einem Autopilot-Cluster zu deaktivieren:

gcloud container clusters update CLUSTER_NAME \
    --no-enable-secret-manager \
    --location=LOCATION

gcloud container clusters update CLUSTER_NAME `
    --no-enable-secret-manager `
    --location=LOCATION

gcloud container clusters update CLUSTER_NAME ^
    --no-enable-secret-manager ^
    --location=LOCATION

Nächste Schritte

• Versionshinweise zur Secret Manager-GKE-Integration lesen