Diese Seite wurde von der Cloud Translation API übersetzt.

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

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 jedoch dieselben Schritte ausführen, um auf andere Google CloudAPIs zuzugreifen. Weitere Informationen finden Sie unter Identitätsföderation von Arbeitslasten für GKE.

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

Im folgenden Beispiel sehen Sie die Daten, die Sie zum Erstellen eines Secrets verwenden:
```
key=my-api-key
```
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.

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.

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

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

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

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 .

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.

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.

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.

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

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

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

Versuchen Sie, das Secret zu lesen:
```
gcloud secrets versions access 1 --secret=bq-readonly-key
```
Die Ausgabe lautet key=my-api-key.

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.

Beenden Sie den Pod:
```
exit
```

Lese-/Schreibzugriff testen

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

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

Versuchen Sie, das Secret zu lesen:
```
gcloud secrets versions access 1 --secret=bq-readonly-key
```
Die Ausgabe lautet key=my-api-key.

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].

Lesen Sie die neue Secret-Version:
```
gcloud secrets versions access 2 --secret=bq-readonly-key
```
Die Ausgabe lautet my-second-api-key.
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:

Stellen Sie mithilfe von Clientbibliotheken eine Beispielanwendung bereit, die Ihr Secret in Secret Manager liest.
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.

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.

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.

Ersetzen Sie Umgebungsvariablen in der Beispielanwendung:

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

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.
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:

Bereitgestellte Volumes sind anfällig für Directory-Traversal-Angriffe.
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.

Auf Secrets außerhalb von GKE-Clustern mit Clientbibliotheken zugreifen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.