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:
- Secret Manager-Add-on in einem neuen oder vorhandenen Add-on installieren GKE-Cluster.
- Konfigurieren Sie Anwendungen für die Authentifizierung bei der Secret Manager API.
- Mit der YAML-Datei
SecretProviderClass
können Sie festlegen, welche Secrets auf Kubernetes-Pods bereitgestellt werden sollen. - 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.
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 löschen.
- 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 greifen Sie selektiv aus GKE-Pods mithilfe der Secret Manager-Add-on. Dadurch stehen Ihnen Funktionen zur Verfügung, wie CMEK-Verschlüsselung, detaillierte Zugriffssteuerung, verwaltete Rotation, Lebenszyklusverwaltung und Audit-Logs sowie Kubernetes-Features 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
linux/arm64
- undlinux/amd64
-Bereitstellungen.
Beschränkungen
Diese Vorabversion von Secret Manager das Add-on unterstützt die folgenden in der Open Source verfügbaren Funktionen nicht CSI-Treiber für Secrets Store:
Hinweise
-
Secret Manager and Google Kubernetes Engine APIs aktivieren.
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
.Achten Sie darauf, dass auf Ihrem Cluster GKE-Version 1.29 oder höher mit ein Linux-Knoten-Image. Das Secret Manager-Add-on unterstützt Windows nicht Serverknoten.
Secret Manager-Add-on installieren
Sie können das Secret Manager-Add-on in beiden Standardclustern installieren und Autopilot-Cluster. Achten Sie darauf, dass die Identitätsföderation von Arbeitslasten für GKE im Standardcluster aktiviert ist. Identitätsföderation von Arbeitslasten für GKE ist in einem Autopilot-Cluster standardmäßig aktiviert. Kubernetes-Pods verwenden Workload Identity um sich bei der Secret Manager API zu authentifizieren.
Secret Manager-Add-on in einem neuen GKE-Cluster installieren
So installieren Sie das Secret Manager-Add-on bei der Clustererstellung: führen Sie folgende Schritte aus:
Standard-Cluster
So aktivieren Sie das Secret Manager-Add-on auf einem neuen Standardcluster führen Sie den folgenden Befehl aus:
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 die Sie verwenden möchten. Achten Sie darauf, dass Ihr Cluster die GKE-Version ausführt 1.29 oder höher. Wenn die Standardeinstellung Release-Version enthält diese Version nicht, verwenden Sie das Flag--release-channel
, um eine Version verfügbar ist.PROJECT_ID
ist die ID Ihres Google Cloud-Projekts.
Autopilot-Cluster
So aktivieren Sie das Secret Manager-Add-on für einen neuen Autopilot-Cluster auf, führen Sie den folgenden Befehl aus:
gcloud beta container clusters create-auto CLUSTER_NAME \ --enable-secret-manager \ --cluster-version=VERSION \ --location=LOCATION
Ersetzen Sie Folgendes:
CLUSTER_NAME
: der Name Ihres ClustersVERSION
: die spezifische GKE-Version, die die Sie verwenden möchten. Achten Sie darauf, dass Ihr Cluster die GKE-Version ausführt 1.29 oder höher. Wenn die standardmäßige Release-Version enthält diese Version nicht, verwenden Sie das Flag--release-channel
, um eine Version verfügbar ist.LOCATION
: Die Region für Ihren Cluster, z. B.us-central1
.
Nachdem Sie das Secret Manager-Add-on aktiviert haben,
kann den CSI-Treiber für den Secret Store in Kubernetes-Volumes mithilfe des Treibers verwenden
und Bereitstellername: secrets-store-gke.csi.k8s.io
.
Secret Manager-Add-on in einem vorhandenen GKE-Cluster installieren
So aktivieren Sie das Secret Manager-Add-on für einen vorhandenen Cluster: führen Sie den folgenden Befehl aus:
gcloud beta container clusters update CLUSTER_NAME \
--enable-secret-manager \
--location=LOCATION
Ersetzen Sie Folgendes:
CLUSTER_NAME
: der Name Ihres vorhandenen ClustersLOCATION
: die Region für Ihrem Cluster, 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 ein vorhandenes Kubernetes-Dienstkonto in einem beliebigen Namespace verwenden, einschließlich des Kubernetes-Standarddienstkonto.
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 verwenden.
Neues Kubernetes-Dienstkonto erstellen
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-DienstkontosNAMESPACE
: der Name des Kubernetes-Namespace für das Dienstkonto
Wenden Sie das Manifest an:
kubectl apply -f service-account.yaml
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 ManagerPROJECT_NUMBER
: Ihre numerische Google Cloud-ProjektnummerPROJECT_ID
: die Projekt-ID des Google Cloud-Projekts, das Ihren GKE-Cluster enthältNAMESPACE
: der Name des Kubernetes-Namespace für das DienstkontoKSA_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 ManagerPROJECT_NUMBER
: Ihre numerische Google Cloud-ProjektnummerPROJECT_ID
: die Projekt-ID des Google Cloud-Projekts, das Ihren GKE-Cluster enthältNAMESPACE
: der Name des Kubernetes-Namespace für das DienstkontoKSA_NAME
: der Name Ihres vorhandenen Kubernetes-Dienstkontos
Definieren Sie die bereitzustellenden Secrets
Um anzugeben, welche Secrets als Dateien im Kubernetes-Pod bereitgestellt werden sollen, erstellen Sie einen
SecretProviderClass
YAML-Manifest und listen Sie die bereitzustellenden Secrets und den Dateinamen auf.
wie Sie sie montieren können. Gehen Sie so vor:
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 desSecretProviderClass
-ObjektsPROJECT_ID
: Ihre Projekt-ID.SECRET_NAME
: der Name des SecretsSECRET_VERSION
: die Secret-VersionFILENAME.txt
: der Dateiname, in dem sich der Secret-Wert befinden soll montiert sind. MitresourceName
undpath
können Sie mehrere Dateien erstellen. Variablen.
Wenden Sie das Manifest an:
kubectl apply -f app-secrets.yaml
Prüfen Sie, ob das Objekt
SecretProviderClass
erstellt wurde:kubectl get SecretProviderClasses
Volume konfigurieren, auf dem die Secrets bereitgestellt werden
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, in dem sich das Secret befindet wurde bereitgestelltKSA_NAME
: das von Ihnen eingerichtete Kubernetes-Dienstkonto im Schritt Workload Identity-Dienstkonto einrichtenIMAGE_NAME
ist der Name des Container-Images.SECRET_PROVIDER_CLASS_NAME
: der Name desSecretProviderClass
-Objekts
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 Ihrem Konto zum Secret Manager-Add-on migrieren, vorhandene Installation des CSI-Treibers für den Secret Store, Aktualisieren Sie das Pod-Manifest so:
Aktualisieren Sie den Namen von
SecretProviderClass
undprovider
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"
driver
undsecretProviderClass
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:
gcloud beta container clusters update CLUSTER_NAME \
--no-enable-secret-manager \
--region=REGION
Ersetzen Sie Folgendes:
CLUSTER_NAME
: der Name Ihres ClustersREGION
: die Region Ihres Clusters, z. B.us-central1