Secrets wie ein Profi verwalten: Das Secret Manager Add-on für GKE im Einsatz

Wenn Sie nach einer alternativen, sicheren Methode suchen, um Secrets aus Secret-Management-Diensten direkt in ein Volume zu laden – ohne den Kubernetes Secrets Store CSI Driver zu nutzen – sollten Sie sich das unbedingt ansehen.

Außerdem hat Abdellfetah SGHIOUAR, Dev Advocate bei Google, 2001 einen lesenswerten Artikel verfasst, der weitere Möglichkeiten zur Speicherung von Secrets in GKE behandelt. Sie finden ihn hier.

Zunächst aktivieren wir das Secret Manager Add-on im Cluster. Alternativ lässt sich beim Anlegen eines neuen Clusters direkt das passende Flag setzen. Achten Sie darauf, CLUSTER_NAME und REGION/ZONE entsprechend zu ersetzen.

  gcloud beta container clusters update <CLUSTER_NAME> \
      --enable-secret-manager \
      --location=<ZONE/REGION>

Stellen Sie außerdem sicher, dass Workload Identity Federation in Ihrem Cluster aktiv ist.

Nach Aktivierung des Secret Manager Add-ons stehen zwei neue APIs mit der API-Version secrets-store.csi.x-k8s.io/v1 bereit:

$ kubectl api-resources | grep secrets-store
secretproviderclasses                                 secrets-store.csi.x-k8s.io/v1                true         SecretProviderClass
secretproviderclasspodstatuses                        secrets-store.csi.x-k8s.io/v1                true         SecretProviderClassPodStatus

Damit der Cluster mit dem Secret Manager kommunizieren kann, muss der genutzte Kubernetes-Service-Account die nötigen Berechtigungen erhalten.

Zuerst legen wir Namespace und Service-Account im Cluster an.

kubectl create ns secret-manager-access
kubectl create sa secret-manager-access-sa

Anschließend nutzen wir Workload Identity Federation, um dem K8s-Service-Account die passenden Berechtigungen zuzuweisen. Ersetzen Sie dabei Project ID und Project Number in den Variablen.

PROJECT_NUMBER=<ADD_YOUR_PROJECT_NUMBER>
PROJECT_ID=<ADD_YOUR_PROJECT_ID>
NAMESPACE=secret-manager-access
gcloud projects add-iam-policy-binding projects/star-sorceress \
    --role=roles/secretmanager.secretAccessor \
    --member=principal://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${PROJECT_ID}.svc.id.goog/subject/ns/${NAMESPACE}/sa/secret-manager-access-sa \
    --condition=None

PS: Die Einrichtung von Workload Identity Federation hat sich kürzlich geändert. Wer mehr dazu erfahren möchte, findet in diesem Blogpost eine ausführliche Erklärung von einem Doe'r-Kollegen.

Im nächsten Schritt legen wir unser Super-Secret im Google Secret Manager an und erzeugen die erste Version:

echo "This is my awesome secret, please don't share!" > super-secret.txt
gcloud secrets create super-secret  --replication-policy="automatic" --data-file="super-secret.txt"

Nun erstellen wir die Custom Resource SecretProviderClass, die mit dem zuvor angelegten GCP-Secret verknüpft wird. Vergessen Sie nicht, Ihre Project ID einzutragen.

kubectl apply -f - <<EOF
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: super-secret
spec:
  provider: gke
  parameters:
    secrets: |
      - resourceName: "projects/<PROJECT_ID>/secrets/super-secret/versions/1"
        path: "super-secret.txt"
EOF

Pod-Volume konfigurieren

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: secret-manager-access
spec:
  serviceAccountName: secret-manager-access-sa
  containers:
  - name: test-pod
    image: google/cloud-sdk:slim
    command: ["sleep","infinity"]
    volumeMounts:
      - mountPath: "/var/secrets"
        name: super-secret
  volumes:
  - name: super-secret
    csi:
      driver: secrets-store-gke.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: super-secret
EOF

Prüfen wir nun, ob das Secret tatsächlich vorhanden ist:

kubectl exec -it test-pod -- cat  /var/secrets/super-secret.txt
This is my awesome secret, please don't share

Vorteile des Secret Manager CSI Drivers:

• Mehr Sicherheit: Secrets liegen nie in den Pods selbst – das verkleinert die Angriffsfläche.
• Schlankeres Workload-Management: Workload Identity macht das Verwalten von Anmeldedaten in Pods überflüssig.
• Bessere Konfigurierbarkeit: Granulare Steuerung des Secret-Zugriffs ermöglicht feingliedrige Berechtigungen.
• Zentrales Audit-Logging: Alle Zugriffsversuche auf Secrets werden im Secret Manager protokolliert – ideal fürs Auditing.

Fazit

Mit dem Secret Manager Add-on für GKE setzen Sie auf einen vollständig verwalteten Secret Manager CSI Driver, heben das Sicherheitsniveau Ihres GKE-Clusters spürbar an und vereinfachen das Secret-Management in Ihren Anwendungen. Dank zentraler Steuerung, automatisiertem Mounting und robuster Zugriffskontrolle können Sie sich entspannt auf das Entwickeln und Ausrollen Ihrer Anwendungen konzentrieren.

Referenzen:

https://github.com/kubernetes-sigs/secrets-store-csi-driver

https://github.com/GoogleCloudPlatform/secrets-store-csi-driver-provider-gcp

https://cloud.google.com/secret-manager/docs/secret-manager-managed-csi-component#migrate

https://github.com/external-secrets/external-secrets/issues/478#issuecomment-964413129

https://medium.com/google-cloud/consuming-google-secret-manager-secrets-in-gke-911523207a79

https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity

https://github.com/doitintl/kube-secrets-init

Ich hoffe, dieser Beitrag hat Ihnen weitergeholfen! Bei Fragen freue ich mich über einen Kommentar.

Sie kennen DoiT International noch nicht? Dann werfen Sie unbedingt einen Blick auf uns. Unser Team möchte mehr über Sie und Ihre Anforderungen rund um Cloud Engineering erfahren. Mit ausschließlich erfahrenen Senior Engineers sind wir auf Cloud-Consulting, Architekturdesign und Debugging-Beratung auf hohem Niveau spezialisiert. Kontaktieren Sie uns – sprechen wir!