Secret Manager-Add-on mit Google Kubernetes Engine verwenden

Vorschau

Diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Durch die Einbindung 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 Secrets zugreifen können, die in Secret Manager als in Kubernetes-Pods bereitgestellte Volumes gespeichert sind.

Dieser Vorgang umfasst folgende Schritte:

1. Installieren Sie das Secret Manager-Add-on in einem neuen oder vorhandenen GKE-Cluster.
2. Konfigurieren Sie Anwendungen für die Authentifizierung bei der Secret Manager API.
3. Mit der YAML-Datei SecretProviderClass können Sie festlegen, welche Secrets auf Kubernetes-Pods bereitgestellt werden sollen.
4. Erstellen Sie ein Volume, auf dem die Secrets bereitgestellt werden. Nachdem das Volume angehängt wurde, können Anwendungen im Container auf die Daten im Dateisystem des Containers zugreifen.

Das Secret Manager-Add-on wird vom Open-Source-Kubernetes Secrets Store-CSI-Treiber und dem Google Secret Manager-Anbieter abgeleitet. Wenn Sie den Open-Source-CSI-Treiber für den Secret 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 den Secret-Speicher migrieren.

Wichtig: In diesem Dokument wird der Begriff Secret verwendet, um auf sensible Daten zu verweisen, 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 operativen Aufwand direkt in der GKE 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 aus GKE-Pods auf Secrets zugreifen. Auf diese Weise können Sie die von Secret Manager angebotenen Features wie CMEK-Verschlüsselung, detaillierte Zugriffssteuerung, verwaltete Rotation, Lebenszyklusverwaltung und Audit-Logs nutzen und Kubernetes-Features nutzen, z. B. Secrets in Form von bereitgestellten Volumes an Container übergeben.
• Das Secret Manager-Add-on wird sowohl in Standard- als auch Autopilot-Clustern unterstützt.
• Das Secret Manager-Add-on unterstützt linux/arm64- und linux/amd64-Bereitstellungen.

Beschränkungen

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

• Geheime automatische 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, installieren und initialize Sie dann die gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab.

  Hinweis: Legen Sie bei vorhandenen gcloud CLI-Installationen die Attribute compute/region und compute/zone fest. Durch Festlegen von Standardstandorten können Sie Fehler in der gcloud CLI wie den folgenden vermeiden: One of [--zone, --region, --location] must be supplied: Please specify location.

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

Secret Manager-Add-on installieren

Sie können das Secret Manager-Add-on sowohl in Standard- als auch in Autopilot-Clustern installieren. Achten Sie darauf, dass die Identitätsföderation von Arbeitslasten für GKE im Standardcluster aktiviert ist. Die Identitätsföderation von Arbeitslasten für GKE ist in einem Autopilot-Cluster standardmäßig aktiviert. Kubernetes-Pods authentifizieren sich mithilfe von Workload Identity bei der Secret Manager API.

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

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

Standard-Cluster

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

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

  Ersetzen Sie Folgendes:

  • CLUSTER_NAME: Der Name Ihres Clusters.
  • LOCATION: die Compute Engine-Region oder -Zone für den Cluster.
  • VERSION: Die spezifische GKE-Version, die Sie verwenden möchten. Achten Sie darauf, dass auf Ihrem Cluster GKE-Version 1.29 oder höher ausgeführt wird. Wenn diese Version nicht in der standardmäßigen Release-Version enthalten ist, verwenden Sie das Flag --release-channel, um eine Release-Version auszuwählen, in der diese verfügbar ist.
  • PROJECT_ID ist die ID Ihres Google Cloud-Projekts.

Autopilot-Cluster

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

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

  Ersetzen Sie Folgendes:

  • CLUSTER_NAME: der Name Ihres Clusters
  • VERSION: Die spezifische GKE-Version, die Sie verwenden möchten. Achten Sie darauf, dass auf Ihrem Cluster GKE-Version 1.29 oder höher ausgeführt wird. Wenn diese Version nicht in der standardmäßigen Release-Version enthalten ist, verwenden Sie das Flag --release-channel, um eine Release-Version auszuwählen, in der dies möglich ist.
  • LOCATION: Die Region für Ihren Cluster, z. B. us-central1.

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

Secret Manager-Add-on in 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 den Cluster, z. B. us-central1.

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

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

• Erstellen Sie ein neues Kubernetes-Dienstkonto oder verwenden Sie ein vorhandenes Kubernetes-Dienstkonto in einem beliebigen Namespace, einschließlich des Kubernetes-Standarddienstkontos.

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

Pods, die das konfigurierte Kubernetes-Dienstkonto verwenden, authentifizieren sich beim Zugriff auf die Secret Manager API automatisch als Haupt-ID, 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 Ihres neuen Kubernetes-Dienstkontos
   • NAMESPACE: der Name des Kubernetes-Namespace für das Dienstkonto

2. Wenden Sie das Manifest an:

   kubectl apply -f service-account.yaml
   

3. Erstellen Sie eine IAM-Zulassungsrichtlinie, die auf das neue Kubernetes-Dienstkonto verweist, und gewähren Sie ihm die Berechtigung, auf das Secret zuzugreifen:

   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 in 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 Dienstkonto
   • KSA_NAME: der Name Ihres vorhandenen Kubernetes-Dienstkontos

Vorhandenes Kubernetes-Dienstkonto verwenden

Erstellen Sie eine IAM-Zulassungsrichtlinie, die auf das vorhandene Kubernetes-Dienstkonto verweist, und gewähren Sie ihm die Berechtigung, auf das Secret zuzugreifen:

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 in 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 Dienstkonto
• KSA_NAME: der Name Ihres vorhandenen Kubernetes-Dienstkontos

Definieren Sie die bereitzustellenden Secrets

Wenn Sie angeben möchten, welche Secrets als Dateien im Kubernetes-Pod bereitgestellt werden sollen, erstellen Sie das YAML-Manifest SecretProviderClass und listen Sie die bereitzustellenden Secrets und 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 Name des Secrets
   • SECRET_VERSION: die Secret-Version
   • FILENAME.txt: der Dateiname, in dem der Secret-Wert bereitgestellt wird. Sie können mehrere Dateien mit den Variablen resourceName und path erstellen.

2. Wenden Sie das Manifest an:

   kubectl apply -f app-secrets.yaml
   

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

   kubectl get SecretProviderClasses
   

Volume konfigurieren, auf 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, auf 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 mithilfe des CSI-Treibers (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 Secret Store migrieren

Wenn Sie von Ihrer vorhandenen Installation des CSI-Treibers für den Secret Manager zum Secret Manager-Add-on migrieren, aktualisieren Sie das 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"
   

Secret Manager-Add-on deaktivieren

Führen Sie den folgenden Befehl aus, um das Secret Manager-Add-on in 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: die Region Ihres Clusters, z. B. us-central1