Auf Secrets außerhalb von GKE-Clustern mit Clientbibliotheken zugreifen

Autopilot Standard

In dieser Anleitung erfahren Sie, wie Sie die von Ihren GKE-Clustern (Google Kubernetes Engine) verwendeten sensiblen Daten in Secret Manager speichern. Sie erfahren, wie Sie mit der Identitätsföderation von Arbeitslasten für GKE und denGoogle Cloud -Clientbibliotheken sicherer auf die Daten aus Ihren Pods zugreifen.

Das Speichern sensibler Daten außerhalb des Clusterspeichers reduziert das Risiko eines nicht autorisierten Zugriffs auf die Daten, wenn ein Angriff stattfindet. Wenn Sie für den Zugriff auf die Daten Workload Identity-Föderation für GKE verwenden, können Sie die Risiken vermeiden, die mit der Verwaltung langlebiger Dienstkontoschlüssel verbunden sind. Außerdem können Sie den Zugriff auf Ihre Secrets mithilfe von Identity and Access Management (IAM) anstelle von clusterinternen RBAC-Regeln steuern. Sie können einen beliebigen externen Secret-Speicheranbieter wie Secret Manager oder HashiCorp Vault verwenden.

Diese Seite richtet sich an Sicherheitsexperten, die sensible Daten aus dem Clusterspeicher verschieben möchten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

In dieser Anleitung wird ein GKE Autopilot-Cluster verwendet. Um die Schritte mit GKE Standard auszuführen, müssen Sie die Identitätsföderation von Arbeitslasten für GKE manuell aktivieren.

Sie können die Identitätsföderation von Arbeitslasten für GKE verwenden, um über GKE-Arbeitslasten auf alle Google Cloud APIs zuzugreifen, ohne weniger sichere Ansätze wie statische Dienstkonto-Schlüsseldateien verwenden zu müssen. In dieser Anleitung wird Secret Manager als Beispiel verwendet. Sie können aber dieselben Schritte ausführen, um auf andere Google CloudAPIs zuzugreifen. Weitere Informationen finden Sie unter Identitätsföderation von Arbeitslasten für GKE.

Ziele

• Erstellen Sie ein Secret in Google Cloud Secret Manager.
• GKE Autopilot-Cluster, Kubernetes-Namespaces und Kubernetes-Dienstkonten erstellen.
• Erstellen Sie IAM-Zulassungsrichtlinien, um Ihren Kubernetes-Dienstkonten Zugriff auf das Secret zu gewähren.
• Testanwendungen verwenden, um den Zugriff auf Dienstkonten zu prüfen.
• Beispielanwendung ausführen, die über die Secret Manager API auf das Secret zugreift.

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

• GKE Autopilot
• Secret Manager

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.

Neuen Nutzern von Google Cloud steht möglicherweise ein kostenloser Testzeitraum zur Verfügung.

Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Hinweise

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

Install the Google Cloud CLI.

Wenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.

Führen Sie den folgenden Befehl aus, um die gcloud CLI zu initialisieren:

gcloud init

Create or select a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

• Create a Google Cloud project:

  gcloud projects create PROJECT_ID

  Replace PROJECT_ID with a name for the Google Cloud project you are creating.

• Select the Google Cloud project that you created:

  gcloud config set project PROJECT_ID

  Replace PROJECT_ID with your Google Cloud project name.

Verify that billing is enabled for your Google Cloud project.

Enable the Kubernetes Engine and Secret Manager APIs:

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

gcloud services enable container.googleapis.com secretmanager.googleapis.com

Install the Google Cloud CLI.

Wenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.

Führen Sie den folgenden Befehl aus, um die gcloud CLI zu initialisieren:

gcloud init

Create or select a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

• Create a Google Cloud project:

  gcloud projects create PROJECT_ID

  Replace PROJECT_ID with a name for the Google Cloud project you are creating.

• Select the Google Cloud project that you created:

  gcloud config set project PROJECT_ID

  Replace PROJECT_ID with your Google Cloud project name.

Verify that billing is enabled for your Google Cloud project.

Enable the Kubernetes Engine and Secret Manager APIs:

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

gcloud services enable container.googleapis.com secretmanager.googleapis.com

1. Grant roles to your user account. Run the following command once for each of the following IAM roles: roles/secretmanager.admin, roles/container.clusterAdmin

   gcloud projects add-iam-policy-binding PROJECT_ID --member="user:USER_IDENTIFIER" --role=ROLE

   Replace the following:

   • PROJECT_ID: Your project ID.
   • USER_IDENTIFIER: The identifier for your user account. For example, [e-mail].
   • ROLE: The IAM role that you grant to your user account.

Umgebung vorbereiten

Klonen Sie das GitHub-Repository, das die Beispieldateien für diese Anleitung enthält:

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
cd ~/kubernetes-engine-samples/security/wi-secrets

Secret in Secret Manager erstellen

1. Im folgenden Beispiel sehen Sie die Daten, die Sie zum Erstellen eines Secrets verwenden:

   key=my-api-key

2. Erstellen Sie ein Secret zum Speichern der Beispieldaten:

   gcloud secrets create bq-readonly-key \
       --data-file=manifests/bq-readonly-key \
       --ttl=3600s
   

   Mit diesem Befehl wird Folgendes ausgeführt:

   • Erstellt ein neues Secret Manager-Secret mit dem Beispielschlüssel in der Region us-central1 Google Cloud .
   • Legt fest, dass das Secret eine Stunde nach Ausführung des Befehls abläuft.

Cluster und Kubernetes-Ressourcen erstellen

GKE-Cluster, Kubernetes-Namespaces und Kubernetes-Dienstkonten erstellen. Sie erstellen zwei Namespaces, einen für den Lesezugriff und einen für den Lese-/Schreibzugriff auf das Secret. Außerdem erstellen Sie in jedem Namespace ein Kubernetes-Dienstkonto für die Verwendung mit der Workload Identity-Föderation für GKE.

1. Erstellen Sie einen GKE Autopilot-Cluster:

   gcloud container clusters create-auto secret-cluster \
       --location=us-central1
   

   Die Bereitstellung des Clusters kann etwa fünf Minuten dauern. Für Autopilot-Cluster ist die Identitätsförderung von Arbeitslasten für GKE immer aktiviert. Wenn Sie stattdessen einen GKE Standard-Cluster verwenden möchten, müssen Sie die Identitätsföderation von Arbeitslasten für GKE manuell aktivieren, bevor Sie fortfahren.

2. Erstellen Sie einen readonly-ns- und einen admin-ns-Namespace:

   kubectl create namespace readonly-ns
   kubectl create namespace admin-ns
   

3. Erstellen Sie ein Kubernetes-Dienstkonto readonly-sa und ein Kubernetes-Dienstkonto admin-sa:

   kubectl create serviceaccount readonly-sa --namespace=readonly-ns
   kubectl create serviceaccount admin-sa --namespace=admin-ns
   

IAM-Zulassungsrichtlinien erstellen

1. Gewähren Sie dem Dienstkonto readonly-sa Lesezugriff auf das Secret:

   gcloud secrets add-iam-policy-binding bq-readonly-key \
       --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/readonly-ns/sa/readonly-sa \
       --role='roles/secretmanager.secretAccessor' \
       --condition=None
   

   Ersetzen Sie Folgendes:

   • PROJECT_NUMBER: Ihre numerische Google CloudProjektnummer.
   • PROJECT_ID: Projekt-ID in Google Cloud .

2. Gewähren Sie dem Dienstkonto admin-sa Lese- und Schreibzugriff auf das Secret:

   gcloud secrets add-iam-policy-binding bq-readonly-key \
       --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/admin-ns/sa/admin-sa \
       --role='roles/secretmanager.secretAccessor' \
       --condition=None
   gcloud secrets add-iam-policy-binding bq-readonly-key \
       --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/admin-ns/sa/admin-sa \
       --role='roles/secretmanager.secretVersionAdder' \
       --condition=None
   

Secret-Zugriff prüfen

Stellen Sie Test-Pods in jedem Namespace bereit, um den Lesezugriff und den Lese-/Schreibzugriff zu überprüfen.

1. Prüfen Sie das schreibgeschützte Pod-Manifest:

   # Copyright 2022 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #     http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   apiVersion: v1
   kind: Pod
   metadata:
     name: readonly-test
     namespace: readonly-ns
   spec:
     containers:
     - image: google/cloud-sdk:slim
       name: workload-identity-test
       command: ["sleep","infinity"]
       resources:
         requests:
           cpu: "150m"
           memory: "150Mi"
     serviceAccountName: readonly-sa

   Dieser Pod verwendet das Dienstkonto readonly-sa im Namespace readonly-ns.

2. Prüfen Sie das Pod-Manifest mit Lese-/Schreibzugriff:

   # Copyright 2022 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #     http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   apiVersion: v1
   kind: Pod
   metadata:
     name: admin-test
     namespace: admin-ns
   spec:
     containers:
     - image: google/cloud-sdk:slim
       name: workload-identity-test
       command: ["sleep","infinity"]
       resources:
         requests:
           cpu: "150m"
           memory: "150Mi"
     serviceAccountName: admin-sa

   Dieser Pod verwendet das Dienstkonto admin-sa im Namespace admin-ns.

3. Stellen Sie die Test-Pods bereit:

   kubectl apply -f manifests/admin-pod.yaml
   kubectl apply -f manifests/readonly-pod.yaml
   

   Es kann einige Minuten dauern, bis die Pods ausgeführt werden. Führen Sie den folgenden Befehl aus, um den Fortschritt zu überwachen:

   watch kubectl get pods -n readonly-ns
   

   Wenn sich der Pod-Status in RUNNING ändert, drücken Sie Ctrl+C, um zur Befehlszeile zurückzukehren.

Lesezugriff testen

1. Öffnen Sie eine Shell im readonly-test-Pod:

   kubectl exec -it readonly-test --namespace=readonly-ns -- /bin/bash
   

2. Versuchen Sie, das Secret zu lesen:

   gcloud secrets versions access 1 --secret=bq-readonly-key
   

   Die Ausgabe lautet key=my-api-key.

3. Versuchen Sie, neue Daten in das Secret zu schreiben:

   printf "my-second-api-key" | gcloud secrets versions add bq-readonly-key --data-file=-
   

   Die Ausgabe sieht etwa so aus:

   ERROR: (gcloud.secrets.versions.add) PERMISSION_DENIED: Permission 'secretmanager.versions.add' denied for resource 'projects/PROJECT_ID/secrets/bq-readonly-key' (or it may not exist).
   

   Der Pod, der das schreibgeschützte Dienstkonto verwendet, kann nur das Secret lesen und keine neuen Daten schreiben.

4. Beenden Sie den Pod:

   exit
   

Lese-/Schreibzugriff testen

1. Öffnen Sie eine Shell im admin-test-Pod:

   kubectl exec -it admin-test --namespace=admin-ns -- /bin/bash
   

2. Versuchen Sie, das Secret zu lesen:

   gcloud secrets versions access 1 --secret=bq-readonly-key
   

   Die Ausgabe lautet key=my-api-key.

3. Versuchen Sie, neue Daten in das Secret zu schreiben:

   printf "my-second-api-key" | gcloud secrets versions add bq-readonly-key --data-file=-
   

   Die Ausgabe sieht etwa so aus:

   Created version [2] of the secret [bq-readonly-key].
   

4. Lesen Sie die neue Secret-Version:

   gcloud secrets versions access 2 --secret=bq-readonly-key
   

   Die Ausgabe lautet my-second-api-key.

5. Beenden Sie den Pod:

   exit
   

Die Pods erhalten nur die Zugriffsebene, die Sie dem im Pod-Manifest verwendeten Kubernetes-Dienstkonto gewährt haben. Alle Pods, die das Kubernetes-Konto admin-sa im Namespace admin-ns verwenden, können neue Versionen des Secrets schreiben, aber alle Pods im Namespace readonly-ns, die das Dienstkonto readonly-sa von Kubernetes verwenden, können das Secret nur lesen.

Über Ihren Code auf Secrets zugreifen

In diesem Abschnitt tun Sie Folgendes:

1. Stellen Sie mithilfe von Clientbibliotheken eine Beispielanwendung bereit, die Ihr Secret in Secret Manager liest.

2. Prüfen Sie, ob die Anwendung auf Ihr Secret zugreifen kann.

Sie sollten nach Möglichkeit immer mithilfe der Secret Manager API über Ihren Anwendungscode auf Secret Manager-Secrets zugreifen.

1. Sehen Sie sich den Quellcode der Beispielanwendung an:

   // Copyright 2022 Google LLC
   //
   // Licensed under the Apache License, Version 2.0 (the "License");
   // you may not use this file except in compliance with the License.
   // You may obtain a copy of the License at
   //
   //     http://www.apache.org/licenses/LICENSE-2.0
   //
   // Unless required by applicable law or agreed to in writing, software
   // distributed under the License is distributed on an "AS IS" BASIS,
   // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   // See the License for the specific language governing permissions and
   // limitations under the License.
   
   package main
   
   import (
   	"context"
   	"fmt"
   	"log"
   	"os"
   
   	secretmanager "cloud.google.com/go/secretmanager/apiv1"
   	secretmanagerpb "google.golang.org/genproto/googleapis/cloud/secretmanager/v1"
   )
   
   func main() {
   
           // Get environment variables from Pod spec.
           projectID := os.Getenv("PROJECT_ID")
           secretId := os.Getenv("SECRET_ID")
           secretVersion := os.Getenv("SECRET_VERSION")
   
           // Create the Secret Manager client.
           ctx := context.Background()
           client, err := secretmanager.NewClient(ctx)
           if err != nil {
                   log.Fatalf("failed to setup client: %v", err)
           }
           defer client.Close()
   
           // Create the request to access the secret.
           accessSecretReq := &secretmanagerpb.AccessSecretVersionRequest{
                   Name: fmt.Sprintf("projects/%s/secrets/%s/versions/%s", projectID, secretId, secretVersion),
           }
   
           secret, err := client.AccessSecretVersion(ctx, accessSecretReq)
           if err != nil {
                   log.Fatalf("failed to access secret: %v", err)
           }
   
           // Print the secret payload.
           //
           // WARNING: Do not print the secret in a production environment - this
           // snippet is showing how to access the secret material.
           log.Printf("Welcome to the key store, here's your key:\nKey: %s", secret.Payload.Data)
   }
   

   Diese Anwendung ruft die Secret Manager API auf, um zu versuchen, das Secret zu lesen.

2. Prüfen Sie das Pod-Manifest der Beispielanwendung:

   # Copyright 2022 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #     http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   apiVersion: v1
   kind: Pod
   metadata:
     name: readonly-secret-test
     namespace: readonly-ns
   spec:
     containers:
     - image: us-docker.pkg.dev/google-samples/containers/gke/wi-secret-store:latest
       name: secret-app
       env:
         - name: PROJECT_ID
           value: "YOUR_PROJECT_ID"
         - name: SECRET_ID
           value: "bq-readonly-key"
         - name: SECRET_VERSION
           value: "latest"
       resources:
         requests:
           cpu: "125m"
           memory: "64Mi"
     serviceAccountName: readonly-sa

   Das Manifest tut Folgendes:

   • Erstellt einen Pod im Namespace readonly-ns, der das Dienstkonto readonly-sa verwendet.
   • Ruft eine Beispielanwendung aus einer Google Image Registry ab. Diese Anwendung ruft die Secret Manager API mithilfe derGoogle Cloud -Clientbibliotheken auf. Sie können sich den Anwendungscode im Repository in /main.go ansehen.
   • Legt Umgebungsvariablen für die zu verwendende Beispielanwendung fest.

3. Ersetzen Sie Umgebungsvariablen in der Beispielanwendung:

   sed -i "s/YOUR_PROJECT_ID/PROJECT_ID/g" "manifests/secret-app.yaml"
   

4. Stellen Sie die Beispiel-App bereit:

   kubectl apply -f manifests/secret-app.yaml
   

   Es kann einige Minuten dauern, bis der Pod funktioniert. Wenn der Pod einen neuen Knoten in Ihrem Cluster benötigt, bemerken Sie möglicherweise Ereignisse vom Typ CrashLoopBackOff, während GKE den Knoten bereitstellt. Die Abstürze enden, wenn der Knoten erfolgreich bereitgestellt wurde.

5. Prüfen Sie den Secret-Zugriff:

   kubectl logs readonly-secret-test -n readonly-ns
   

   Die Ausgabe lautet my-second-api-key. Wenn die Ausgabe leer ist, wird der Pod möglicherweise noch nicht ausgeführt. Warten Sie ein paar Minuten und versuchen Sie es noch einmal.

Alternative Ansätze

Wenn Sie Ihre sensiblen Daten in Ihre Pods einbinden müssen, verwenden Sie das Secret Manager-Add-on für GKE. Mit diesem Add-on wird der Google Cloud Secret Manager-Anbieter für den CSI-Treiber für Kubernetes Secret Store in Ihren GKE-Clustern bereitgestellt und verwaltet. Eine Anleitung finden Sie unter Secret Manager-Add-on mit GKE verwenden.

Die Bereitstellung von Secrets als bereitgestellte Volumes birgt die folgenden Risiken:

1. Bereitgestellte Volumes sind anfällig für Directory-Traversal-Angriffe.
2. Umgebungsvariablen können aufgrund von Fehlkonfigurationen wie dem Öffnen eines Debugging-Endpunkts manipuliert werden.

Wann immer möglich, empfehlen wir den programmatischen Zugriff auf Secrets über die Secret Manager API. Eine Anleitung dazu erhalten Sie anhand der Beispielanwendung in diesem Tutorial oder unter Secret Manager-Clientbibliotheken.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

Einzelne Ressourcen löschen

1. Löschen Sie den Cluster:

   gcloud container clusters delete secret-cluster \
       --location=us-central1
   

2. Optional: Secret in Secret Manager löschen:

   gcloud secrets delete bq-readonly-key
   

   Wenn Sie diesen Schritt nicht ausführen, läuft das Secret automatisch ab, da Sie bei der Erstellung das --ttl-Flag gesetzt haben.

Projekt löschen

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, zum Beispiel eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, anstatt das gesamte Projekt.

Wenn Sie weitere Architekturen, Tutorials oder Kurzanleitungen nutzen möchten, können Sie vorhandene Projekte wiederverwenden und somit vermeiden, dass Projektkontingente überschritten werden.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Nächste Schritte

• Weitere Informationen zur Funktionsweise der Workload Identity Federation for GKE
• Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center