Secret Manager-Add-on mit Google Kubernetes Engine verwenden

Einbindung von Secret Manager und Google Kubernetes Engine (GKE) ermöglicht das Speichern sensibler Daten wie Passwörter und Zertifikate, die von der GKE verwendet werden Cluster als Secrets in Secret Manager an.

Auf dieser Seite wird erläutert, wie Sie das Secret Manager-Add-on verwenden können. um auf die in Secret Manager als in Kubernetes-Pods bereitgestellten Volumes zuzugreifen.

Dieser Vorgang umfasst folgende Schritte:

1. Secret Manager-Add-on für einen neuen oder vorhandenen aktivieren 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, Anwendungen im Container können auf die Daten im Containerdateisystem zugreifen.

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

Wichtig :In diesem Dokument wird der Begriff geheim für sensible Daten verwendet. und nicht im Secret-Objekt im GKE API

Vorteile

Das Secret Manager-Add-on bietet folgende Vorteile:

• Sie können eine vollständig verwaltete und unterstützte Lösung für den Zugriff auf Secret Manager verwenden ohne operativen Aufwand direkt aus der GKE herausholen.
• 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. Dadurch stehen Ihnen Funktionen zur Verfügung, wie CMEK-Verschlüsselung, detaillierte Zugriffssteuerung, verwaltete Rotation, Lebenszyklusverwaltung und Audit-Logs sowie Kubernetes-Funktionen wie die Übergabe von Secrets an Container in Form von bereitgestellten Volumes.
• Das Secret Manager-Add-on wird sowohl in Standardclustern als auch Autopilot-Clustern unterstützt.
• Das Secret Manager-Add-on unterstützt Knoten, die Container-Optimized OS verwenden oder Ubuntu-Knoten-Images.

Beschränkungen

Das Secret Manager-Add-on hat die folgenden Einschränkungen:

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

  • Geheime automatische 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, installieren Sie das Programm. und initialisieren Sie dann die gcloud CLI. Wenn Sie zuvor die gcloud CLI installiert haben, rufen Sie die neueste Version ab, indem Sie den den Befehl gcloud components update.

  Sie können das Secret Manager-Add-on nicht manuell mit der Methode Google Cloud SDK oder die Google Cloud Console.

  Hinweis: Bei vorhandenen gcloud CLI-Installationen müssen Sie für vorhandene gcloud CLI-Installationen die Einstellung compute/region- und compute/zone-Properties. Durch Festlegen von Standardstandorten können Sie Fehler in der gcloud CLI vermeiden, z. B. Folgendes: One of [--zone, --region, --location] must be supplied: Please specify location.

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

• Wenn Sie einen GKE Standard-Cluster verwenden, muss die Identitätsföderation von Arbeitslasten für GKE für Ihren Cluster aktiviert sein. Identitätsföderation von Arbeitslasten für GKE wird aktiviert durch Standardeinstellung in einem Autopilot-Cluster. Kubernetes-Pods authentifizieren sich mit der Identitätsföderation von Arbeitslasten für GKE beim Secret Manager API

Secret Manager-Add-on aktivieren

Sie können das Secret Manager-Add-on in beiden Standardclustern aktivieren und Autopilot-Cluster.

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

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

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 auf das Kästchen Secret Manager aktivieren.

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}

So aktivieren Sie das Secret Manager-Add-on auf einem neuen Standardcluster führen Sie den folgenden Befehl aus:

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 spezifische GKE-Version, die die Sie verwenden möchten. Achten Sie darauf, dass Ihr Cluster die GKE-Version ausführt 1.27.14-gke.1042001 oder höher. 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}

So aktivieren Sie das Secret Manager-Add-on für einen neuen Autopilot-Cluster auf, führen Sie den folgenden Befehl aus:

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

• CLUSTER_NAME: Der Name Ihres Clusters.
• VERSION: die spezifische GKE-Version, die die Sie verwenden möchten. Achten Sie darauf, dass Ihr Cluster die GKE-Version ausführt 1.27.14-gke.1042001 oder höher. 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, kann den CSI-Treiber für den Secrets Store in Kubernetes-Volumes mithilfe des Treibers verwenden und Bereitstellername: 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 für einen vorhandenen Cluster: Gehen Sie so vor:

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

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

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

Ersetzen Sie Folgendes:

• CLUSTER_NAME ist der Name des Clusters.
• LOCATION: der 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, Secret Manager API Damit sich Ihre Anwendungen beim Führen Sie die folgenden Schritte aus, um die Secret Manager API mit der Identitätsföderation von Arbeitslasten für GKE zu verwenden:

• 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, authentifizieren sich automatisch als Haupt-ID für IAM, die der Kubernetes-Dienstkonto beim Zugriff auf die Secret Manager API an.

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. IAM-Zulassungsrichtlinie erstellen, die auf das neue Kubernetes verweist Dienstkonto 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

IAM-Zulassungsrichtlinie erstellen, die auf das vorhandene Kubernetes verweist Dienstkonto 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 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 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 sich der Secret-Wert befinden wird montiert sind. Mit resourceName und path können Sie mehrere Dateien erstellen. Variablen.

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: 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 sich das Secret befindet wurde bereitgestellt
   • 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. Fügen Sie nur in Standardclustern Folgendes zur Datei template.spec hinzu: Feld, um die Pods in Knotenpools zu platzieren, die die Identitätsföderation von Arbeitslasten für GKE verwenden.

   Diesen Schritt in Autopilot-Clustern überspringen, da dieser nodeSelector abgelehnt wird da jeder Knoten die Identitätsföderation von Arbeitslasten für 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
   

Mit diesem Schritt wird ein Volume mysecret unter /var/secrets mithilfe des CSI-Treibers bereitgestellt (secrets-store-gke.csi.k8s.io). Dieses Volume verweist auf das Objekt SecretProviderClass die als Anbieter fungiert.

Vom vorhandenen CSI-Treiber für den Secret Store 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 von SecretProviderClass und provider wie beschrieben. im folgenden Manifest:

   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. driver und secretProviderClass für Ihr Kubernetes aktualisieren 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

So deaktivieren Sie das Secret Manager-Add-on für eine vorhandene Standardcluster oder in einem Autopilot-Cluster: Führen Sie folgenden Befehl aus: Befehl:

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 ^