Secret Manager-Add-on mit Google Kubernetes Engine verwenden

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

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

Dieser Vorgang umfasst folgende Schritte:

1. Installieren Sie das Secret Manager-Add-on auf einem 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 auf Kubernetes-Pods bereitgestellt werden sollen.
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 ist vom Open-Source-CSI-Treiber für Kubernetes Secrets Store und vom Google Secret Manager-Anbieter abgeleitet. 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 Vom vorhandenen CSI-Treiber für den Secrets Store migrieren.

Vorteile

Das Add-on für Secret Manager bietet folgende Vorteile:

• Sie können eine vollständig verwaltete und unterstützte Lösung verwenden, um direkt in GKE auf Secret Manager-Secrets ohne operativen Aufwand zuzugreifen.
• Sie müssen keinen benutzerdefinierten Code schreiben, um auf Secrets zuzugreifen, die in Secret Manager gespeichert sind.
• Sie können alle Secrets zentral in Secret Manager speichern und verwalten und mit dem Secret Manager-Add-on selektiv über GKE-Pods auf Secrets zugreifen. Auf diese Weise können Sie Features von Secret Manager wie CMEK-Verschlüsselung, detaillierte Zugriffssteuerung, verwaltete Rotation, Lebenszyklusverwaltung und Audit-Logs sowie Kubernetes-Features wie das Übergeben von Secrets an Container in Form von bereitgestellten Volumes nutzen.
• Das Secret Manager-Add-on wird sowohl für Standardcluster als auch Autopilot-Cluster unterstützt.
• Das Secret Manager-Add-on unterstützt linux/arm64- und linux/amd64-Bereitstellungen.

Beschränkungen

Diese Vorabversion des Secret Manager-Add-ons unterstützt die folgenden Features nicht, die im Open-Source-CSI-Treiber für den Secrets Store verfügbar sind:

• Automatische Secret-Rotation
• Als Kubernetes-Secret synchronisieren

Hinweise

• Secret Manager and Google Kubernetes Engine APIs aktivieren.

  Aktivieren Sie die APIs

• Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialize. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab.

• Achten Sie darauf, dass in Ihrem Cluster GKE-Version 1.29 oder höher mit einem Linux-Knoten-Image ausgeführt wird. Das Add-on Secret Manager unterstützt keine Windows Server-Knoten.

Add-on für Secret Manager installieren

Sie können das Secret Manager-Add-on sowohl auf Standardclustern als auch auf Autopilot-Clustern installieren. Achten Sie darauf, dass die Workload Identity-Föderation für GKE im Standardcluster aktiviert ist. Die Workload Identity-Föderation für GKE ist in einem Autopilot-Cluster standardmäßig aktiviert. Kubernetes-Pods verwenden Workload Identity zur Authentifizierung bei der Secret Manager API.

Add-on für Secret Manager auf einem neuen GKE-Cluster installieren

So installieren Sie das Secret Manager-Add-on bei der Clustererstellung:

Nachdem Sie das Secret Manager-Add-on aktiviert haben, können Sie den CSI-Treiber für den Secrets Store in Kubernetes-Volumes mithilfe des Treiber- und Bereitstellernamens verwenden: secrets-store-gke.csi.k8s.io.

Add-on für Secret Manager auf einem vorhandenen GKE-Cluster installieren

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

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

Ersetzen Sie Folgendes:

• CLUSTER_NAME: der Name Ihres vorhandenen Clusters
• LOCATION: Die Region für Ihren Cluster, z. B. us-central1.

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

Der Google Secret Manager-Anbieter verwendet die Arbeitslastidentität des Pods, auf dem ein Secret bei der Authentifizierung bei der Secret Manager API bereitgestellt wird. Führen Sie die folgenden Schritte aus, damit sich Ihre Anwendungen über die Workload Identity-Föderation für GKE bei der Secret Manager API authentifizieren können:

• Mit einer IAM-Richtlinie (Identity and Access Management) ein IAM-Dienstkonto an ein Kubernetes-Dienstkonto binden Sie können ein neues Kubernetes-Dienstkonto erstellen oder ein vorhandenes Kubernetes-Dienstkonto in einem beliebigen Namespace verwenden, einschließlich des Kubernetes-Standarddienstkontos.
• Verwenden Sie IAM-Bindungen, um dem IAM-Dienstkonto Zugriff auf Secrets in Secret Manager zu gewähren.

Pods, die das konfigurierte Kubernetes-Dienstkonto verwenden, authentifizieren sich beim Zugriff auf die Secret Manager API automatisch als IAM-Dienstkonto.

Kubernetes-Dienstkonto an das IAM-Dienstkonto binden

Erlauben Sie dem Kubernetes-Dienstkonto, die Identität des IAM-Dienstkontos anzunehmen. Fügen Sie dazu eine IAM-Richtlinienbindung zwischen den beiden Dienstkonten hinzu.

Neues Kubernetes-Dienstkonto verwenden

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

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: KSA_NAME
     namespace: NAMESPACE
     annotations:
       iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
   

   Ersetzen Sie Folgendes:

   • KSA_NAME: der Name Ihres neuen Kubernetes-Dienstkontos
   • NAMESPACE: der Name des Kubernetes-Namespace für das Dienstkonto
   • GSA_NAME: der Name des IAM-Dienstkontos
   • PROJECT_ID: die Projekt-ID des Google Cloud-Projekts für Ihr IAM-Dienstkonto

2. Wenden Sie das Manifest an:

   kubectl apply -f service-account.yaml
   

3. Führen Sie den folgenden Befehl aus, um das IAM-Dienstkonto an ein neues Kubernetes-Dienstkonto zu binden:

   gcloud iam service-accounts add-iam-policy-binding \
       --role roles/iam.workloadIdentityUser \
       --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" \
       GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
   

Vorhandenes Kubernetes-Dienstkonto verwenden

Führen Sie den folgenden Befehl aus, um das IAM-Dienstkonto an ein vorhandenes Kubernetes-Dienstkonto zu binden:

gcloud iam service-accounts add-iam-policy-binding \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" \
    GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

Ersetzen Sie Folgendes:

• KSA_NAME: der Name Ihres vorhandenen Kubernetes-Dienstkontos
• NAMESPACE: der Name des Kubernetes-Namespace für das Dienstkonto
• GSA_NAME: der Name des IAM-Dienstkontos
• PROJECT_ID: die Projekt-ID des Google Cloud-Projekts für Ihr IAM-Dienstkonto

Dem IAM-Dienstkonto die Berechtigung für den Zugriff auf das Secret gewähren

Führen Sie den folgenden Befehl aus, um dem Dienstkonto die Berechtigung für den Zugriff auf das Secret zu gewähren:

gcloud secrets add-iam-policy-binding SECRET_NAME \
    --member=serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/secretmanager.secretAccessor

Ersetzen Sie Folgendes:

• SECRET_NAME: der Name des Secrets in Secret Manager
• GSA_NAME: der Name des IAM-Dienstkontos
• PROJECT_ID: die Projekt-ID des Google Cloud-Projekts für Ihr IAM-Dienstkonto

Bereitzustellende Secrets definieren

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 bereitzustellenden Secrets sowie den Dateinamen für die Bereitstellung auf. 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 des SecretProviderClass-Objekts
   • PROJECT_ID: Ihre Projekt-ID.
   • SECRET_NAME: der Secret-Name
   • SECRET_VERSION: die Secret-Version
   • FILENAME.txt: der Dateiname, in dem der Secret-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: default
   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
   • KSA_NAME: das Kubernetes-Dienstkonto, das Sie im Schritt Workload Identity-Dienstkonto einrichten eingerichtet haben
   • IMAGE_NAME ist der Name des Container-Images.
   • SECRET_PROVIDER_CLASS_NAME: der Name des SecretProviderClass-Objekts

2. 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 Objekt SecretProviderClass, das als Anbieter fungiert.

Vom vorhandenen CSI-Treiber für den Secrets Store migrieren

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

1. Aktualisieren Sie den Namen von SecretProviderClass und 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 driver und 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"
   

Add-on für Secret Manager deaktivieren

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

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

Ersetzen Sie Folgendes:

• CLUSTER_NAME: der Name Ihres Clusters
• REGION: Region Ihres Clusters, z. B. us-central1