Lösung des Problems der unkontrollierten Ausbreitung von Secrets in Kubernetes-Umgebungen mit mehreren Konten mithilfe des External Secrets Operator

Die Automatisierung der Infrastruktur in Kubernetes ist weitgehend gelöst – bis die Verwaltung von Secrets ins Spiel kommt. Mit zunehmender Skalierung der Umgebungen wird die Verteilung und Rotation von Secrets über mehrere isolierte Cluster hinweg schnell zu einer großen betrieblichen Herausforderung.

Unser Team stand kürzlich genau vor diesem Problem, als es eine skalierbare Kubernetes-Plattform für einen Kunden entwickelte, die auf EKS läuft. Das Kernproblem war nicht auf einen bestimmten Cloud-Anbieter oder gar auf die Cloud-Infrastruktur an sich beschränkt. Die gleichen Herausforderungen treten in Azure, Google Cloud, Multi-Cloud-Umgebungen, On-Premise-Umgebungen und sogar in lokalen Entwicklungsworkflows mit Tools wie KIND oder Minikube auf.

Der gemeinsame Nenner ist die Isolation. Jede Umgebung – Entwicklungs-, Staging- und Produktionsumgebung – befindet sich in einem eigenen Konto, Namensraum oder Cluster. Diese Trennung ist zwar für die Sicherheit und die Begrenzung des Schadensumfangs unerlässlich, erschwert jedoch die Verwaltung gemeinsamer Geheimnisse und macht sie fehleranfällig.

In diesem Artikel wird erläutert, wie wir die Synchronisierung von Kubernetes-Secrets über mehrere Konten hinweg mithilfe des External Secrets Operator (ESO) und Bitwarden Secrets Managergelöst haben, wodurch eine zentralisierte Steuerung mit automatisierter Verteilung ermöglicht wird.

Die Herausforderung: Heimliche Ausbreitung in abgelegenen Gebieten

Unser Kunde betreibt zwei Anwendungen, die in hohem Maße auf Integrationen von Drittanbietern angewiesen sind. Bei der Automatisierung der Bereitstellung neuer Umgebungen traten sofort Probleme auf:

Gemeinsam genutzte Anmeldedaten in der Testumgebung

In der Entwicklungs- und Staging-Umgebung nutzten die Anwendungen dieselben Sandbox-Anmeldedaten für externe Dienste. Jede Umgebung benötigte identische Werte, die jedoch separat gespeichert wurden.

Fragmentierte geheime Speicherung

Jeder Kubernetes-Cluster befand sich in einem eigenen Konto. Da pro Konto ein eigener Secrets-Dienst verwendet wurde, mussten bei der Rotation eines einzelnen API-Schlüssels eines Drittanbieters überall manuelle Aktualisierungen vorgenommen werden.

Manuelle Rotation und operationelles Risiko

Das Fehlen einer zentralen Steuerung führte zu Rotationsermüdung und erhöhten Risiken. Die Anforderung war klar:
Ein Geheimnis sollte nur einmal aktualisiert werden und sich dann automatisch auf alle Cluster übertragen.

Die wichtigste architektonische Entscheidung bestand darin, die Speicherung von Geheimnissen von deren Nutzung zu trennen.

Die Lösung: Der „External Secrets Operator“ als Integrationsschicht

Um externe Secret-Speicher mit Kubernetes-nativen Secrets zu verbinden, haben wir uns für den External Secrets Operator (ESO) entschieden. ESO synchronisiert Secrets aus einem externen Backend mithilfe einer deklarativen Konfiguration in Kubernetes Secrets.

Als Backend-Speicher haben wir uns für den Bitwarden Secrets Manager entschieden. Diese Entscheidung war pragmatisch begründet: Der Kunde setzte Bitwarden bereits unternehmensweit ein, sodass wir die bestehenden Zugriffskontrollen und Governance-Maßnahmen weiterverwenden konnten.

Auch wenn Bitwarden als Anbieter ausgewählt wurde, ist diese Architektur anbieterunabhängig. Das gleiche Muster funktioniert auch mit Alternativen wie HashiCorp Vault. Das wichtige Prinzip bleibt dasselbe:

Speichern Sie Geheimnisse zentral und lassen Sie ESO diese automatisch in jeden Kubernetes-Cluster synchronisieren.

Einführungsleitfaden

Die folgenden Schritte beschreiben die genaue Konfiguration, die in unserer Kubernetes-Umgebung verwendet wird. Obwohl alle Ressourcen mit Terraform automatisiert wurden, werden hier der Übersichtlichkeit halber direkte Befehle angezeigt.
(Den vollständigen Automatisierungscode finden Sie im verlinkten GitHub-Repository.)

Voraussetzungen:

• Ein Kubernetes-Cluster (EKS, AKS, GKE oder ein gleichwertiges System)
• kubectl und Helm sind lokal installiert
• Ein Bitwarden-Konto

Schritt 1: Sichere Kommunikation zwischen ESO und dem Bitwarden-SDK

Die ESO-Bitwarden-Integration erfordert eine sichere HTTPS-Kommunikation. Um Zertifikate innerhalb des Clusters dynamisch zu verwalten, installieren wir zunächst Cert Manager.

helm repo add jetstack https://charts.jetstack.io 
helm repo update 

helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --set installCRDs=true

Einen selbstsignierten ClusterIssuer erstellen

cat <<EOF | kubectl apply -f -
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: bitwarden-bootstrap-issuer
spec:
  selfSigned: {}
EOF

Erstellen Sie den Namespace für externe Geheimnisse und das Stamm-CA-Zertifikat

kubectl create namespace external-secrets

cat <<EOF | kubectl apply -f -
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: bitwarden-bootstrap-certificate
  namespace: external-secrets
spec:
  commonName: bitwarden-tls-ca
  isCA: true
  secretName: bitwarden-ca-certs
  issuerRef:
    name: bitwarden-bootstrap-issuer
    kind: ClusterIssuer
EOF

Erstellen Sie den Zertifikatsaussteller und das TLS-Zertifikat für den SDK-Server

cat <<EOF | kubectl apply -f -
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: bitwarden-certificate-issuer
  namespace: external-secrets
spec:
  ca:
    secretName: bitwarden-ca-certs
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: bitwarden-tls-certs
  namespace: external-secrets
spec:
  secretName: bitwarden-tls-certs
  dnsNames:
    - bitwarden-sdk-server.external-secrets.svc.cluster.local
    - external-secrets-bitwarden-sdk-server.external-secrets.svc.cluster.local
    - localhost
  issuerRef:
    name: bitwarden-certificate-issuer
    kind: Issuer
EOF

Schritt 2: Installieren Sie den „External Secrets Operator“ mit Bitwarden-Unterstützung

ESO muss mit aktivierter Bitwarden-SDK-Unterstützung installiert werden, wodurch der interne Dienst bereitgestellt wird, der für die Kommunikation mit der Bitwarden-API verwendet wird.

helm repo add external-secrets https://charts.external-secrets.io 

helm install external-secrets external-secrets/external-secrets \
  --namespace external-secrets \
  --set installCRDs=true \
  --set "bitwarden-sdk-server.enabled=true"

Schritt 3: Authentifizierung

Erstellen Sie ein Zugriffstoken für das Maschinenkonto im Bitwarden-Portal. Dieser Token gewährt Lesezugriff auf das Projekt, das Ihre Geheimnisse enthält.

Speichern Sie das Token als Kubernetes-Secret:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: bitwarden-access-token
  namespace: external-secrets
type: Opaque
stringData:
  token: <YOUR_BITWARDEN_ACCESS_TOKEN>
EOF

Hinweis: Dem Token kann auch Schreibzugriff gewährt werden, wenn Sie vorhaben, die PushSecret-API von ESO zu verwenden, um Geheimnisse in Bitwarden zu erstellen.

Schritt 4: Erstellen eines ClusterSecretStore

Ein ClusterSecretStore ermöglicht es allen Namespaces, auf ein einziges globales Backend zu verweisen, ohne dass die Authentifizierungskonfiguration dupliziert werden muss.

cat <<EOF | kubectl apply -f -
apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
  name: bitwarden-global-store
spec:
  provider:
    bitwardensecretsmanager:
      apiURL: https://vault.bitwarden.eu./api
      identityURL: https://vault.bitwarden.eu./identity
      auth:
        secretRef:
          credentials:
            key: token
            name: bitwarden-access-token
            namespace: external-secrets
      bitwardenServerSDKURL: https://bitwarden-sdk-server.external-secrets.svc.cluster.local:9998
      caProvider:
        type: Secret
        name: bitwarden-ca-certs
        key: ca.crt
        namespace: external-secrets
      organizationID: <YOUR_ORGANIZATION_ID>
      projectID: <YOUR_PROJECT_ID>
EOF

Schritt 5: Geheimnisse mit „ExternalSecret“ synchronisieren

Die Ressource „ExternalSecret“ legt fest, wie Geheimnisse abgerufen und als Kubernetes-Secrets implementiert werden.

cat <<EOF | kubectl apply -f -
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: app-payment-creds
  namespace: app-backend
spec:
  refreshInterval: 15m
  secretStoreRef:
    name: bitwarden-global-store
    kind: ClusterSecretStore
  target:
    name: payment-creds
    creationPolicy: Owner
  data:
  - secretKey: api_key
    remoteRef:
      key: "<YOUR_NAME_OR_ID_SECRET_HERE"
EOF

Das Ergebnis: Zentralisierte Schlüsselverwaltung in großem Maßstab

Dieser Ansatz trennt die Verwaltung des Lebenszyklus von Geheimnissen vollständig von der Bereitstellung der Infrastruktur.

Wenn eine neue Umgebung erstellt wird – sei es in einem bestehenden Konto oder in einem brandneuen –, muss lediglich ESO installiert und auf den vorhandenen ClusterSecretStore verwiesen werden. Die Geheimnisse werden automatisch abgerufen.

Wenn ein Geheimnis rotiert wird, wird es einmalig in Bitwarden aktualisiert und innerhalb weniger Minuten an alle Cluster weitergeleitet.

Ob nun zwei Cluster oder zweihundert verwaltet werden – das Ergebnis ist dasselbe: weniger Engpässe bei der Bereitstellung, weniger menschliche Fehler und ein deutlich übersichtlicheres Betriebsmodell. Da ESO als universelle Brücke fungiert, wird die Verwaltung von Geheimnissen zu einer unsichtbaren Infrastruktur – sicher, zentralisiert und automatisch.

Lesen Sie hier den vollständigen Blogbeitrag .