External Secrets Operator: Die Referenz-Architektur für hybrides Secrets Management

TL;DR

Geheimnisse (API-Keys, Datenbank-Passwörter) gehören nicht in den Git-Code, aber ihre Bereitstellung zur Laufzeit ist oft komplex. Wer den AWS Secrets Manager direkt in seine Applikation integriert (via SDK), erzeugt harten Vendor Lock-in im Source Code. Der External Secrets Operator (ESO) löst dieses Dilemma. Er fungiert als Brücke, die Geheimnisse aus externen Quellen (AWS, Azure, Vault) synchronisiert und als native Kubernetes Secrets bereitstellt. Das Ergebnis: Die Applikation bleibt cloud-agnostisch und sauber.

1. Das Architektur-Prinzip: Entkopplung von Code und Config

In der Cloud-Native-Entwicklung gilt das Prinzip der “Twelve-Factor App”: Konfiguration (und damit Geheimnisse) sollen strikt vom Code getrennt und über Umgebungsvariablen injiziert werden.

Häufig verletzen Entwickler dieses Prinzip, indem sie Cloud-SDKs (z.B. boto3 für AWS) direkt in die Applikation einbauen, um Geheimnisse zur Laufzeit abzurufen.

• Das Problem: Der Code „weiß", dass er auf AWS läuft. Er ist nicht mehr portabel.
• Die Lösung (ESO): Der External Secrets Operator läuft im Cluster und übernimmt die Arbeit. Er pollt die externe API (z.B. AWS Secrets Manager), holt das Geheimnis und legt es als Standard Kubernetes Secret ab. Die Applikation liest einfach eine Umgebungsvariable – sie weiß nicht, woher das Geheimnis ursprünglich kam.

2. Kern-Feature: Multi-Provider Support und Templating

ESO ist das “Schweizer Taschenmesser” für Geheimnisse. Es unterstützt nahezu jeden relevanten Backend-Provider: AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, Google Secret Manager, GitLab CI Variables und viele mehr.

Besonders mächtig ist die Templating-Engine:

Oft liefert ein externer Provider ein JSON-Blob (z.B. {“username”: “admin”, “password”: “xyz”}). Die Applikation erwartet aber zwei getrennte Umgebungsvariablen. ESO kann die Daten während der Synchronisation parsen, umformatieren und in das exakte Format bringen, das die Applikation benötigt. Das erspart komplexe Wrapper-Skripte im Container -Startvorgang.

3. Sicherheit und RBAC

Ein häufiger Einwand ist: “Sind Kubernetes Secrets sicher?”

Ja, in modernen Clustern (wie im ayedo Stack) sind sie es.

• Encryption at Rest: Die Secrets werden in der etcd-Datenbank verschlüsselt gespeichert.
• Granulares RBAC: Dank Kubernetes RBAC kann exakt gesteuert werden, welcher Pod welches Secret lesen darf.
• Minimale Rechte: Nur der ESO-Controller benötigt Zugriff auf die externe AWS-API. Die hunderten Applikations-Pods benötigen keine IAM-Berechtigungen mehr, um AWS Secrets Manager aufzurufen. Das reduziert die Angriffsfläche drastisch.

4. Betriebsmodelle im Vergleich: AWS SDK / CSI Driver vs. ayedo Managed ESO

Hier entscheidet sich, ob Ihre Applikations-Entwickler Cloud-Experten sein müssen oder ob sie sich auf Code konzentrieren können.

Szenario A: Native Integration oder CSI Driver (Der Code-Lock-in)

Viele Teams nutzen den AWS Secrets and Configuration Provider (ASCP) oder binden das AWS SDK direkt ein.

• Code-Abhängigkeit: Der Entwickler muss AWS-Logik in den Microservice bauen. Ein Wechsel zu Azure bedeutet: Code umschreiben.
• Filesystem-Zwang (CSI): Der AWS CSI-Treiber mountet Secrets als Dateien. Viele Applikationen erwarten aber Umgebungsvariablen. Dies erfordert Workarounds.
• Keine Cross-Cloud-Logik: Wenn Sie einen Teil der Apps On-Premise haben, funktioniert die AWS-Methode dort oft nicht oder nur über komplexe IAM-User-Konstrukte.

Szenario B: External Secrets Operator mit Managed Kubernetes von ayedo

Im ayedo App-Katalog ist ESO die Standard-Komponente für das Secrets-Management.

• Write Once, Run Anywhere: Die Applikation erwartet einfach ein Secret namens db-pass. Ob dieses Secret im Hintergrund aus AWS, Azure oder einem lokalen Vault kommt, definiert allein der Platform Engineer via CRD (ExternalSecret). Der App-Code bleibt 100% portabel.
• Zentrale Governance: Sie können genau steuern, welche Namespaces auf welche externen Stores zugreifen dürfen (ClusterSecretStore vs. SecretStore).
• Automatische Rotation: Ändert sich das Geheimnis in AWS, synchronisiert ESO es (konfigurierbar) automatisch in den Cluster. Ein Neustart der Pods (via Reloader) sorgt dafür, dass die Änderung live geht.

Technischer Vergleich der Betriebsmodelle

FAQ: ESO & Security Strategy

Sind Kubernetes Secrets nicht unsicher (Base64)?

Das ist ein altes Missverständnis. Base64 ist nur die Kodierung für die Anzeige. Entscheidend ist, wie sie gespeichert sind. In professionellen Clustern (wie bei ayedo) ist Encryption at Rest aktiviert. Das bedeutet, selbst wenn jemand physischen Zugriff auf die Server-Festplatte hat, kann er die Secrets nicht lesen. Zudem verhindert RBAC, dass unbefugte User im Cluster die Secrets sehen.

Was passiert, wenn die AWS API ausfällt?

Das ist ein großer Vorteil von ESO gegenüber der direkten SDK-Integration. Da ESO die Secrets in Kubernetes-Secrets synchronisiert, stehen diese auch dann zur Verfügung, wenn die Verbindung zu AWS kurzzeitig unterbrochen ist. Die Applikation startet weiterhin, da sie die lokale Kopie (den Cache) im Cluster nutzt. Bei direkter Integration würde die App abstürzen.

Kann ESO auch Secrets schreiben (Push)?

Ja, ESO hat ein Feature namens PushSecret. Damit können Sie ein Secret im Kubernetes-Cluster erstellen (z.B. generiert von einem anderen Tool) und es zurück in den AWS Secrets Manager oder Vault schreiben. Das ist nützlich, um Zertifikate oder generierte Passwörter zentral zu sichern.

Wie funktioniert die Rotation von Passwörtern?

ESO pollt das externe Backend in einem definierten Intervall (z.B. alle 10 Minuten). Wenn Sie das Datenbank-Passwort in AWS rotieren, aktualisiert ESO das Kubernetes-Secret. In Kombination mit einem Tool wie Reloader (ebenfalls oft im ayedo Stack) können dann automatisch alle Pods neu gestartet werden, um das neue Passwort zu laden – ganz ohne Downtime.

Fazit

Geheimnisse sind kritisch, aber ihre Verwaltung sollte die Entwicklung nicht bremsen. Wer AWS-spezifische Logik in seine Applikationen baut, kettet seinen Code an die Plattform. Der External Secrets Operator durchbricht diese Abhängigkeit. Er ermöglicht es, mächtige Cloud-Backends wie AWS Secrets Manager zu nutzen, ohne die Portabilität der Anwendungen zu opfern. Mit dem ayedo Managed Stack erhalten Teams eine robuste, provider-unabhängige Pipeline für Geheimnisse, die Sicherheit und Developer Experience vereint.