Diese Seite wurde von der Cloud Translation API übersetzt.

Secrets mit Kubernetes-Secrets synchronisieren

In diesem Dokument wird beschrieben, wie Sie in Secret Manager gespeicherte Secrets mit Kubernetes-Secrets in Ihren Google Kubernetes Engine-Clustern (GKE) synchronisieren.

Durch den Synchronisierungsprozess können Anwendungen, die in GKE ausgeführt werden, mit Standard-Kubernetes-Methoden wie Umgebungsvariablen oder Volume-Bereitstellungen auf Secrets aus Secret Manager zugreifen. Dies ist nützlich für Anwendungen, die bereits so konzipiert sind, dass sie Secrets aus dem Kubernetes-Secret-Objekt lesen, anstatt aktualisiert werden zu müssen, um direkt auf Secret Manager zuzugreifen.

Empfehlung: Die Funktion zur Synchronisierung von Secrets ist eine Alternative zum Secret Manager-Add-on, mit dem Secrets als In-Memory-Dateien direkt in Ihre Pods eingebunden werden. Verwenden Sie das Secret Manager-Add-on, wann immer Ihre Anwendung es unterstützt, da es eine sicherere Methode ist, um in GKE auf Secrets aus Secret Manager zuzugreifen.

Hinweise

Erfüllen Sie die folgenden Voraussetzungen, bevor Sie Secrets synchronisieren:

Enable the Secret Manager and Google Kubernetes Engine 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.
Enable the APIs
Installieren Sie die gcloud CLI und initialisieren Sie sie. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab.
Prüfen Sie, ob ein GKE-Cluster ausgeführt wird. Für dieses Feature ist die GKE-Version 1.34 oder höher erforderlich.
Achten Sie darauf, dass die Workload Identity-Föderation für GKE in Ihrem GKE-Cluster aktiviert ist. Dies ist für die Authentifizierung erforderlich. Die Workload Identity-Föderation für GKE ist in einem Autopilot-Cluster standardmäßig aktiviert.
Prüfen Sie, ob Sie die erforderlichen IAM-Berechtigungen (Identity and Access Management) zum Verwalten von GKE-Clustern und Secret Manager haben.

Geheimsynchronisierung in einem GKE-Cluster aktivieren

Aktivieren Sie die Funktion zur Synchronisierung von Secrets, wenn Sie einen neuen Cluster erstellen oder einen vorhandenen Cluster aktualisieren. Diese Funktion ist sowohl für Standard- als auch für Autopilot-Cluster verfügbar.

Secret-Synchronisierung für einen neuen Cluster aktivieren

Verwenden Sie einen der folgenden gcloud CLI-Befehle, um einen neuen Cluster mit der Synchronisierung von Secrets zu erstellen:

Standard-Cluster

Um Secret Manager in der Befehlszeile zu verwenden, installieren Sie zuerst die Google Cloud CLI Version 378.0.0 oder höher oder aktualisieren Sie darauf. In Compute Engine oder GKE müssen Sie sich mit dem Bereich cloud-platform authentifizieren.

Aktivieren Sie die Secret-Synchronisierung ohne automatische Rotation.

gcloud beta container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --enable-secret-sync

Secret-Synchronisierung mit automatischer Rotation aktivieren Das Standardintervall beträgt 2 Minuten.

gcloud beta container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --enable-secret-sync \
    --enable-secret-sync-rotation

Aktivieren Sie die Secret-Synchronisierung mit einem benutzerdefinierten Rotationsintervall. Das Mindestintervall beträgt 1 Minute.

gcloud beta container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --enable-secret-sync \
    --enable-secret-sync-rotation \
    --secret-sync-rotation-interval=1m

Ersetzen Sie Folgendes:

CLUSTER_NAME: der Name Ihres GKE-Cluster
CONTROL_PLANE_LOCATION: Die Region oder Zone der Clustersteuerungsebene, z. B. us-central1 oder us-east1-a.
PROJECT_ID: Ihre Google Cloud Projekt-ID

Autopilot-Cluster

Aktivieren Sie die Secret-Synchronisierung ohne automatische Rotation.

gcloud beta container clusters create-auto CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-secret-sync

Secret-Synchronisierung mit automatischer Rotation aktivieren Das Standardintervall beträgt 2 Minuten.

gcloud beta container clusters create-auto CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-secret-sync \
    --enable-secret-sync-rotation

Aktivieren Sie die Secret-Synchronisierung mit einem benutzerdefinierten Rotationsintervall. Das Mindestintervall beträgt 1 Minute.

gcloud beta container clusters create-auto CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-secret-sync \
    --enable-secret-sync-rotation \
    --secret-sync-rotation-interval=1m

Ersetzen Sie Folgendes:

CLUSTER_NAME: der Name Ihres GKE-Cluster
CONTROL_PLANE_LOCATION: Die Region oder Zone der Clustersteuerungsebene, z. B. us-central1 oder us-east1-a.

Geheimsynchronisierung für einen vorhandenen Cluster aktivieren

Verwenden Sie einen der folgenden gcloud CLI-Befehle, um vorhandene Cluster mit der Synchronisierung von Secrets zu aktualisieren:

gcloud

Geheimsynchronisierung für einen vorhandenen Cluster aktivieren

gcloud beta container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-secret-sync

Rotation mit einem benutzerdefinierten Intervall aktivieren

gcloud beta container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-secret-sync-rotation \
    --secret-sync-rotation-interval=5m

Rotation deaktivieren

gcloud beta container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --no-enable-secret-sync-rotation

Ersetzen Sie Folgendes:

CLUSTER_NAME: der Name Ihres GKE-Cluster
CONTROL_PLANE_LOCATION: Die Region oder Zone der Clustersteuerungsebene, z. B. us-central1 oder us-east1-a.

Secret-Synchronisierung konfigurieren

Führen Sie die folgenden Schritte aus, um Secrets zu synchronisieren:

Erstellen Sie mit dem folgenden Befehl ein Kubernetes-ServiceAccount:
```
kubectl create serviceaccount KSA_NAME --namespace NAMESPACE
```
Ersetzen Sie Folgendes:
- KSA_NAME: Der Name des Kubernetes-ServiceAccount.
- NAMESPACE: der Kubernetes-Namespace, in dem Sie das ServiceAccount erstellen möchten.
Erstellen Sie eine IAM-Zulassungsrichtlinie, die auf das neue Kubernetes-ServiceAccount verweist, und gewähren Sie dem ServiceAccount die Berechtigung für den Zugriff auf das Secret:
gcloud

Um Secret Manager in der Befehlszeile zu verwenden, installieren Sie zuerst die Google Cloud CLI Version 378.0.0 oder höher oder aktualisieren Sie darauf. In Compute Engine oder GKE müssen Sie sich mit dem Bereich cloud-platform authentifizieren.
```
gcloud secrets add-iam-policy-binding SECRET_PROJECT_ID \
   --role=roles/secretmanager.secretAccessor \
   --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_IDsvc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME
```
Ersetzen Sie Folgendes:
- SECRET_PROJECT_ID: die ID des Projekts, in dem das Secret gespeichert ist. Dies kann mit dem PROJECT_ID identisch sein, wenn das Secret im selben Projekt wie der GKE-Cluster gespeichert ist.
- PROJECT_NUMBER: Ihre Google Cloud Projektnummer
- PROJECT_ID: Ihre Google Cloud Projekt-ID
- NAMESPACE: der Kubernetes-Namespace
- KSA_NAME: Der Name des Kubernetes-ServiceAccount.
Erstellen Sie eine benutzerdefinierte SecretProviderClass-Ressource mit einem YAML-Manifest. Die SecretProviderClass-Ressource definiert die spezifischen Secrets, die aus Secret Manager abgerufen werden sollen, einschließlich ihrer Ressourcennamen und ‑pfade. Das Secret Manager-Add-on verwendet auch die SecretProviderClass-Ressource, um die zu mountenden Secrets und den Dateinamen anzugeben, unter dem sie gemountet werden sollen.

Erstellen Sie eine spc.yaml-Datei mit folgendem Inhalt:
```
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: SECRET_PROVIDER_CLASS_NAME
  namespace: NAMESPACE
spec:
  provider: gke
  parameters:
    secrets: |
      -   resourceName: "projects/SECRET_PROJECT_ID/secrets/SECRET_NAME/versions/SECRET_VERSION"
          path: "FILENAME.txt"
      -   resourceName: "projects/SECRET_PROJECT_ID/secrets/SECRET_NAME/versions/SECRET_VERSION"
          path: "FILENAME1.txt"
```
Ersetzen Sie Folgendes:
- SECRET_PROVIDER_CLASS_NAME: der Name Ihres SecretProviderClass-Objekts.
- NAMESPACE: der Kubernetes-Namespace, in dem Sie diese Ressource erstellen.
- resourceName: Die vollständige Ressourcen-ID für das Secret im Secret Manager. Dies muss die Projekt-ID, den Secret-Namen und die Version im folgenden Format enthalten: projects/SECRET_PROJECT_ID/secrets/SECRET_NAME/versions/SECRET_VERSION.
  - SECRET_PROJECT_ID: die ID des Google Cloud Projekts, in dem das Secret gespeichert ist. Dies kann dasselbe wie PROJECT_ID sein, wenn das Secret im selben Projekt wie der GKE-Cluster gespeichert ist.
  - SECRET_NAME: der Name des Secrets.
  - SECRET_VERSION: die Secret-Version. Die Secret-Version muss sich in derselben Region wie der Cluster befinden.
- path: Der lokale Dateiname oder Alias, unter dem der Secret-Wert in der Kubernetes-Umgebung verfügbar gemacht wird. Es ist die eindeutige Kennung, die eine bestimmte Secret Manager-Version mit der lokalen Darstellung verknüpft, die vom Cluster verwendet wird. Wenn das Secret mit der SecretSync-Ressource mit einem Kubernetes-Secret synchronisiert wird, wird über diesen Pfad auf das Feld sourcePath verwiesen, um den Secret-Wert für die Synchronisierung zu finden. Sie können mehrere Secrets (definiert durch resourceName) verschiedenen Pfadnamen innerhalb derselben SecretProviderClass zuordnen.
Führen Sie den folgenden Befehl aus, um das Manifest anzuwenden:
```
kubectl apply -f spc.yaml
```
Erstellen Sie eine benutzerdefinierte SecretSync-Ressource mit einem YAML-Manifest. Diese Ressource weist den Synchronisierungscontroller an, ein Kubernetes-Secret basierend auf den in der SecretProviderClass definierten Inhalten zu erstellen oder zu aktualisieren.

Erstellen Sie eine secret-sync.yaml-Datei mit folgendem Inhalt:
```
apiVersion: secret-sync.gke.io/v1
kind: SecretSync
metadata:
  name: KUBERNETES_SECRET_NAME
  namespace: NAMESPACE
spec:
  serviceAccountName: KSA_NAME
  secretProviderClassName: SECRET_PROVIDER_CLASS_NAME
  secretObject:
    type: KUBERNETES_SECRET_TYPE
    data:
      -   sourcePath: "FILENAME.txt"
          targetKey: "TARGET_KEY1"
      -   sourcePath: "FILENAME1.txt"
          targetKey: "TARGET_KEY2"
```
Ersetzen Sie Folgendes:
- KUBERNETES_SECRET_NAME: Der Name, den Sie dem neuen Kubernetes-Secret geben möchten, das von der SecretSync-Ressource erstellt wird.
- NAMESPACE: der Kubernetes-Namespace, in dem die neue Ressource erstellt wird. Er muss mit dem Namespace der SecretProviderClass übereinstimmen.
- KSA_NAME: der Name des Kubernetes-Dienstkontos, das der SecretSync-Controller zum Erstellen und Aktualisieren des Ziel-Kubernetes-Secrets verwendet. Dieses Dienstkonto muss die erforderlichen Berechtigungen für den Zugriff auf externe Secrets aus Secret Manager haben.
- SECRET_PROVIDER_CLASS_NAME: der Name des SecretProviderClass-Objekts, das Sie im vorherigen Schritt erstellt haben. Die SecretSync-Ressource verwendet dies, um die richtige Konfiguration für die Secrets zu finden.
- KUBERNETES_SECRET_TYPE: der Typ des zu erstellenden Kubernetes-Secrets, z. B. Opaque, tls oder docker-registry. Dadurch wird festgelegt, wie Kubernetes die Daten des Secrets verarbeitet.
- sourcePath: Der lokale Dateiname oder Alias (der Wert des Felds path in der SecretProviderClass), der die abzurufenden Secret-Daten identifiziert. Der SecretSync-Controller verwendet diese sourcePath, um den spezifischen Secret-Inhalt anzufordern und in ein neues Kubernetes-Secret zu konvertieren.
- targetKey: Der Schlüssel, der im Abschnitt data des neuen Kubernetes-Secrets verwendet wird. Damit wird definiert, wie der mit sourcePath abgerufene Secret-Inhalt benannt und im endgültigen Kubernetes-Secret-Objekt gespeichert wird. Wenn Sie mehrere Einträge im Datenarray verwenden, können Sie mehrere Schlüssel/Wert-Paare innerhalb desselben Ziel-Secrets definieren.
Führen Sie den folgenden Befehl aus, um das Manifest anzuwenden:
```
kubectl apply -f secret-sync.yaml
```
Der Synchronisierungscontroller erstellt ein Kubernetes Secret im angegebenen Namespace. Dieses Secret enthält die aus Secret Manager zugeordneten Daten.
Prüfen Sie, ob das Kubernetes-Secret erstellt wurde:
```
kubectl get secret KUBERNETES_SECRET_NAME -n NAMESPACE -o yaml
```
Ersetzen Sie Folgendes:
- KUBERNETES_SECRET_NAME: der Name des neuen Kubernetes-Secrets
- NAMESPACE: der Kubernetes-Namespace, in dem das neue Secret erstellt wird
Verwenden Sie den folgenden Befehl, um ein Synchronisierungsproblem zu beheben:
```
kubectl describe secretSync KUBERNETES_SECRET_NAME -n NAMESPACE
```
Ersetzen Sie Folgendes:
- KUBERNETES_SECRET_NAME: der Name des neuen Kubernetes-Secrets
- NAMESPACE: der Kubernetes-Namespace, in dem das neue Secret vorhanden sein soll

Secret-Rotation verwalten

Wenn Sie das --enable-secret-sync-rotation-Flag für Ihren Cluster aktivieren, prüft der Synchronisierungscontroller regelmäßig in Secret Manager nach neuen Versionen der Secrets, die in der SecretProviderClass-Ressource angegeben sind. Das Flag --secret-sync-rotation-interval bestimmt, wie oft der Controller nach Updates sucht.

Wenn der Controller eine neue Secret-Version in Secret Manager erkennt, aktualisiert er das entsprechende Kubernetes-Secret. Der Controller vergleicht Hashes des Secret-Inhalts, um Secrets nur bei Änderungen zu aktualisieren.

Anwendungen, die diese Secrets verwenden, müssen die aktualisierten Secret-Werte aus dem Kubernetes-Secret erkennen und neu laden. Das Design der Anwendung bestimmt, wie dies gehandhabt wird.

Secret-Synchronisierung deaktivieren

Führen Sie den folgenden gcloud CLI-Befehl aus, um die Secret-Synchronisierung zu deaktivieren:

gcloud

gcloud beta container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --no-enable-secret-sync

Ersetzen Sie Folgendes:

CLUSTER_NAME: der Name Ihres GKE-Cluster
CONTROL_PLANE_LOCATION: Die Region oder Zone der Clustersteuerungsebene, z. B. us-central1 oder us-east1-a.

Mit diesem Befehl wird der Synchronisierungscontroller beendet. Es werden keine Kubernetes-Secrets gelöscht, die bereits erstellt wurden. Sie müssen alle synchronisierten Kubernetes-Secrets manuell löschen, wenn Sie sie nicht mehr benötigen.

Synchronisierte Secrets löschen

Wenn Sie ein synchronisiertes Kubernetes-Secret löschen möchten, löschen Sie die SecretSync-Ressource mit dem folgenden Befehl:

    kubectl delete secretsync KUBERNETES_SECRET_NAME --namespace NAMESPACE

Ersetzen Sie Folgendes:

KUBERNETES_SECRET_NAME: der Name des Kubernetes-Secrets
NAMESPACE: der Kubernetes-Namespace, in dem das Secret vorhanden ist

Vom vorhandenen CSI-Treiber für Secrets-Speicher migrieren

Wenn Sie von Ihrer bestehenden Installation des CSI-Treibers für den Secrets-Speicher migrieren, gehen Sie so vor:

Aktualisieren Sie das Feld provider in Ihrer SecretProviderClass von gcp auf gke. Das folgende Beispiel zeigt, wie das Feld provider aktualisiert wird:

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: app-secrets-gke
spec:
  provider: gke
  parameters:
    secrets: |
      -   resourceName: "projects/87654321/secrets/api-key-secret/versions/2"
          path: "good1.txt"

Erstellen Sie eine SecretSync-Ressource. Verwenden Sie die folgende Beispielkonfiguration:

apiVersion: secret-sync.gke.io/v1
kind: SecretSync
metadata:
  name: my-kube-secret
  namespace: NAMESPACE
spec:
  serviceAccountName: KSA_NAME
  secretProviderClassName: my-app-secrets
  secretObject:
    type: Opaque # Or other Kubernetes Secret types
    data:
      -   sourcePath: "my-secret.txt"
          targetKey: "USERNAME"
      -   sourcePath: "another-secret.txt"
          targetKey: "PASSWORD"

Sicherheitsaspekte

Secret Manager bietet Sicherheitsfunktionen wie Zugriffssteuerung mit IAM, vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) und Audit-Logging. Secrets werden in Secret Manager im Ruhezustand und während der Übertragung verschlüsselt. Wenn Sie Secrets mit Kubernetes-Secrets synchronisieren, hängt ihre Sicherheit im Cluster von der Konfiguration Ihres GKE-Cluster ab. Berücksichtige Folgendes:

Speicher: Kubernetes-Secrets werden in etcd gespeichert, dem primären Datenspeicher von GKE. Standardmäßig verschlüsselt GKE inaktive Daten. Für mehr Sicherheit können Sie Kubernetes-Secrets auf Anwendungsebene verschlüsseln, indem Sie einen Schlüssel verwenden, den Sie im Cloud Key Management Service(Cloud KMS) verwalten. Durch die Verschlüsselung von Secrets wird eine zusätzliche Sicherheitsebene für sensible Arbeitslasten geschaffen.
Zugriffssteuerung: GKE unterstützt mehrere Optionen zum Verwalten des Zugriffs auf Ressourcen in Projekten und deren Clustern mithilfe der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC). Zu weit gefasste RBAC-Berechtigungen können dazu führen, dass vertrauliche Informationen für unerwünschte Arbeitslasten oder Nutzer offengelegt werden. Gewähren Sie Zugriff gemäß dem Prinzip der geringsten Berechtigung und prüfen Sie regelmäßig den Zugriff auf Secret Manager und die Kubernetes-Secrets.
Umgebungsvariablen: Um die Sicherheit zu erhöhen, sollten Sie Kubernetes-Secrets als Volumes bereitstellen, anstatt sie als Umgebungsvariablen zu verwenden. Dadurch wird das Risiko einer versehentlichen Protokollierung oder Offenlegung gegenüber anderen Prozessen verringert.

Secrets mit Kubernetes-Secrets synchronisieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Hinweise

Geheimsynchronisierung in einem GKE-Cluster aktivieren

Secret-Synchronisierung für einen neuen Cluster aktivieren

Standard-Cluster

Autopilot-Cluster

Geheimsynchronisierung für einen vorhandenen Cluster aktivieren

gcloud

Secret-Synchronisierung konfigurieren

gcloud

Secret-Rotation verwalten

Secret-Synchronisierung deaktivieren

gcloud

Synchronisierte Secrets löschen

Vom vorhandenen CSI-Treiber für Secrets-Speicher migrieren

Sicherheitsaspekte

Nächste Schritte

Secrets mit Kubernetes-Secrets synchronisieren