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

Durch die Integration von Secret Manager und der 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 in einem neuen oder vorhandenen GKE-Cluster.
2. Konfigurieren Sie Anwendungen so, dass sie sich bei der Secret Manager API authentifizieren.
3. Definieren Sie mit einer SecretProviderClass-YAML-Datei, welche Secrets auf Kubernetes-Pods bereitgestellt werden sollen.
4. Erstellen Sie ein Volume, auf dem die Secrets bereitgestellt werden. Nachdem das Volume bereitgestellt 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 Secrets Store und dem Google Secret Manager-Anbieter. Wenn Sie den Open-Source-CSI-Treiber „Secrets Store“ für den Zugriff auf Secrets verwenden, können Sie zum Secret Manager-Add-on migrieren. Weitere Informationen finden Sie unter Vom vorhandenen CSI-Treiber für Secrets Store migrieren.

Wichtig :In diesem Dokument bezieht sich der Begriff Secret auf vertrauliche Daten, die in Secret Manager gespeichert sind, und nicht auf das Secret-Objekt in der GKE API.

Vorteile

Das Secret Manager-Add-on bietet folgende Vorteile:

• Sie können eine vollständig verwaltete und unterstützte Lösung verwenden, um ohne zusätzlichen Aufwand von GKE aus auf Secret Manager-Secrets 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 sowie Kubernetes-Funktionen wie das Übergeben von Secrets an Container in Form von bereitgestellten Volumes verwenden.
• Das Secret Manager-Add-on wird sowohl in Standard- als auch in Autopilot-Clustern unterstützt.
• Das Secret Manager-Add-on unterstützt Knoten, die Container-Optimized OS- oder Ubuntu-Knoten-Images verwenden.

Beschränkungen

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

• Das Secret Manager-Add-on unterstützt die folgenden Funktionen nicht, die im Open-Source-Secrets Store CSI-Treiber verfügbar sind:

  • Automatische Secret-Rotation
  • Als Kubernetes-Secret synchronisieren

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

Hinweise

• Enable the Secret Manager and Google Kubernetes Engine APIs.

  Enable the APIs

• 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 Google Cloud Console einrichten.

  Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region, --location] must be supplied: Please specify location vermeiden.

• 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 die Identitätsföderation von Arbeitslasten für 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 eines Clusters:

Console

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

   Zur Seite "Google Kubernetes Engine"

2. Klicken Sie auf Erstellen.

3. Klicken Sie im Dialogfeld Cluster erstellen auf Konfigurieren.

4. Klicken Sie im Navigationsmenü im Bereich Cluster auf Sicherheit.

5. Klicken Sie das Kästchen Secret Manager aktivieren an.

6. Klicken Sie das Kästchen Workload Identity aktivieren an.

7. Fahren Sie mit der Konfiguration des Clusters fort und klicken Sie dann auf Erstellen.

gcloud

{ Standard cluster}

Führen Sie den folgenden Befehl aus, um das Secret Manager-Add-on in einem neuen Standardcluster zu aktivieren:

Ersetzen Sie folgende Werte, bevor sie einen der Befehlsdaten verwenden:

• CLUSTER_NAME: Der Name Ihres Clusters.
• LOCATION: die Compute Engine-Region für den Cluster, z. B. us-central1.
• VERSION: die GKE-Version, die Sie verwenden möchten. Achten Sie darauf, dass in Ihrem Cluster die GKE-Version 1.27.14-gke.1042001 oder höher ausgeführt wird. Wenn diese Version nicht im Standard-Release-Kanal enthalten ist, verwenden Sie das Flag --release-channel, um einen Release-Kanal auszuwählen, der diese Version enthält.
• PROJECT_ID ist die ID Ihres Google Cloud-Projekts.

Führen Sie folgenden Befehl aus:

Linux, macOS oder Cloud Shell

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

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

Windows (PowerShell)

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

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

Windows (cmd.exe)

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

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

{Autopilot-Cluster}

Führen Sie den folgenden Befehl aus, um das Secret Manager-Add-on in einem neuen Autopilot-Cluster zu aktivieren:

Ersetzen Sie folgende Werte, bevor sie einen der Befehlsdaten verwenden:

• CLUSTER_NAME: Der Name Ihres Clusters.
• VERSION: die GKE-Version, die Sie verwenden möchten. Achten Sie darauf, dass in Ihrem Cluster die GKE-Version 1.27.14-gke.1042001 oder höher ausgeführt wird. Informationen zum Festlegen einer bestimmten Version finden Sie unter Version und Release-Version eines neuen Autopilot-Clusters festlegen.
• LOCATION: die Compute Engine-Region für den Cluster, z. B. us-central1.

Führen Sie folgenden Befehl aus:

Linux, macOS oder Cloud Shell

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

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

Windows (PowerShell)

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

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

Windows (cmd.exe)

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

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 CSI-Treiber für Secrets Store in Kubernetes-Volumes mit dem Namen des Treibers und des Bereitstellers verwenden: secrets-store-gke.csi.k8s.io.

Secret Manager-Add-on für einen vorhandenen GKE-Cluster aktivieren

So aktivieren Sie das Secret Manager-Add-on in einem vorhandenen Cluster:

Console

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

   Zur Seite "Google Kubernetes Engine"

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

3. Klicken Sie auf der Seite mit den Clusterdetails im Abschnitt Sicherheit auf Secret Manager.

4. Klicken Sie im Dialogfeld Secret Manager bearbeiten das Kästchen Secret Manager aktivieren an.

5. Klicken Sie auf Änderungen speichern.

gcloud

Ersetzen Sie folgende Werte, bevor sie einen der Befehlsdaten verwenden:

• CLUSTER_NAME: der Name Ihres Clusters
• LOCATION: die Compute Engine-Region für den Cluster, z. B. us-central1

Führen Sie folgenden Befehl aus:

Linux, macOS oder Cloud Shell

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

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

Windows (PowerShell)

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

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

Windows (cmd.exe)

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

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 auf dem Kubernetes-Cluster installiert ist:

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

Ersetzen Sie Folgendes:

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

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

Der Google Secret Manager-Anbieter verwendet die Workload Identity des Pods, auf dem ein Secret bereitgestellt wird, um sich bei der Secret Manager API zu authentifizieren. So können Sie Ihre Anwendungen mit Workload Identity Federation for GKE bei der Secret Manager API authentifizieren:

• Erstellen Sie ein neues Kubernetes-Dienstkonto oder verwenden Sie ein vorhandenes Kubernetes-Dienstkonto im selben Namespace wie der Pod, auf dem Sie das Secret bereitstellen möchten.

• Erstellen Sie eine IAM-Zulassungsrichtlinie (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 Principal-ID des IAM authentifiziert, die dem Kubernetes-Dienstkonto entspricht.

Neues 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 zum Zugriff auf das Geheimnis:

   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.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 Google Cloud-Projektnummer
   • PROJECT_ID: die Projekt-ID des Google Cloud-Projekts, das Ihren GKE-Cluster enthält
   • NAMESPACE: Der Name des Kubernetes-Namespace für das ServiceAccount.
   • KSA_NAME: Der Name Ihres vorhandenen Kubernetes-Dienstkontos.

Vorhandenes Kubernetes-Dienstkonto verwenden

Erstellen Sie eine IAM-Zulassungsrichtlinie, die auf das vorhandene Kubernetes-ServiceAccount verweist, und gewähren Sie ihm die Berechtigung zum 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.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 Google Cloud-Projektnummer
• PROJECT_ID: die Projekt-ID des Google Cloud-Projekts, das Ihren GKE-Cluster enthält
• NAMESPACE: Der Name des Kubernetes-Namespace für das ServiceAccount.
• KSA_NAME: Der Name Ihres vorhandenen Kubernetes-Dienstkontos.

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 zu bereitstellenden Secrets und den Dateinamen auf, 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 Ihres SecretProviderClass-Objekts.
   • PROJECT_ID: Ihre Projekt-ID.
   • SECRET_NAME: den Namen des Secrets.
   • SECRET_VERSION: die Secret-Version.
   • FILENAME.txt: der Dateiname, unter dem der geheime Wert bereitgestellt wird. Mit den Variablen resourceName und path können Sie mehrere Dateien erstellen.

2. Wenden Sie das Manifest an:

   kubectl apply -f app-secrets.yaml
   

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

   kubectl get SecretProviderClasses
   

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 bereitgestellt wird
   • 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 des SecretProviderClass-Objekts

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 CSI-Treiber für Secrets-Speicher migrieren

Wenn Sie von Ihrer vorhandenen Installation des CSI-Treibers für Secrets-Speicher zum Secret Manager-Add-on migrieren, aktualisieren Sie Ihr Pod-Manifest so:

1. Aktualisieren Sie den Namen Ihrer SecretProviderClass und die provider wie im folgenden Manifest beschrieben:

   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: app-secrets-gke
   spec:
     provider: gke
     parameters:
       secrets: |
         - resourceName: "projects/<project_id>/secrets/<secret_name>/versions/<secret_version>"
           path: "good1.txt"
   

2. Aktualisieren Sie die driver und die secretProviderClass für Ihr Kubernetes-Volume wie im folgenden Manifest beschrieben:

   volumes:
     - name: mysecret
       csi:
         driver: secrets-store-gke.csi.k8s.io
         readOnly: true
         volumeAttributes:
           secretProviderClass: "app-secrets-gke"
   

Secret Manager-Add-on deaktivieren

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

Console

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

   Zur Seite "Google Kubernetes Engine"

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

3. Klicken Sie auf der Seite mit den Clusterdetails im Abschnitt Sicherheit auf Secret Manager.

4. Entfernen Sie im Dialogfeld Secret Manager bearbeiten das Häkchen aus dem Kästchen Secret Manager aktivieren.

5. Klicken Sie auf Änderungen speichern.

gcloud

Ersetzen Sie folgende Werte, bevor sie einen der Befehlsdaten verwenden:

• CLUSTER_NAME: der Name Ihres Clusters
• REGION: die Compute Engine-Region für den Cluster, z. B. us-central1

Führen Sie folgenden Befehl aus:

Linux, macOS oder Cloud Shell

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

gcloud container clusters update CLUSTER_NAME \
    --no-enable-secret-manager \
    --region=REGION \

Windows (PowerShell)

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

gcloud container clusters update CLUSTER_NAME `
    --no-enable-secret-manager `
    --region=REGION `

Windows (cmd.exe)

Hinweis: Prüfen Sie, ob die Google Cloud CLI mit Authentifizierung und einem Projekt initialisiert wurde. Führen Sie dazu gcloud init oder gcloud auth login und gcloud config set project aus.

gcloud container clusters update CLUSTER_NAME ^
    --no-enable-secret-manager ^
    --region=REGION ^