AWS Secrets Manager vs. External Secrets Operator

Geheimnisse als Cloud-Service oder als Teil der Kubernetes-Plattform

Secrets gehören zu den sensibelsten Bausteinen moderner Anwendungen. Zugangsdaten, API-Keys, Tokens oder Zertifikate entscheiden darüber, ob Systeme sicher miteinander kommunizieren – oder ob Sicherheitsgrenzen faktisch nicht existieren. Entsprechend weitreichend ist die Frage, wo und wie Secrets verwaltet und konsumiert werden.

AWS Secrets Manager und der External Secrets Operator adressieren genau dieses Problem, allerdings aus grundlegend unterschiedlichen Perspektiven. Der eine verankert Secrets in der Cloud-Plattform. Der andere integriert sie bewusst in Kubernetes als zentrale Steuerungsebene. Der Unterschied ist nicht funktional – er ist architektonisch.

AWS Secrets Manager: Secret-Management als Cloud-Service

AWS Secrets Manager ist der verwaltete Dienst von AWS zur Speicherung und Verwaltung sensibler Informationen wie Zugangsdaten, API-Keys oder Zertifikate. Secrets werden verschlüsselt gespeichert, versioniert und lassen sich automatisch rotieren, insbesondere in Kombination mit AWS-Diensten wie RDS oder IAM.

Die Integration in AWS-Services ist tief. Anwendungen greifen über AWS-APIs zu, Berechtigungen folgen IAM-Logik, Audit-Logs laufen über CloudTrail. Der operative Aufwand ist gering, die Abrechnung erfolgt nutzungsbasiert pro Secret und API-Zugriff. Für AWS-zentrierte Architekturen ist das bequem und konsistent.

Diese Stärke ist jedoch zugleich eine strukturelle Begrenzung.

Cloud-Bindung als implizite Architekturentscheidung

Secrets Manager ist an AWS gebunden – technisch wie organisatorisch. Anwendungen müssen AWS-spezifische APIs nutzen, Zugriffsmodelle folgen IAM, Rotationsmechanismen sind auf unterstützte Services zugeschnitten.

In [Kubernetes]-Umgebungen bleibt Secrets Manager damit ein externer Baustein. Pods konsumieren Secrets nicht nativ, sondern indirekt: über Sidecars, SDKs, CSI-Treiber oder Synchronisationsmechanismen. Kubernetes wird zum Ausführungsort, nicht zur Steuerungsebene für Secrets.

Die Plattformlogik von Kubernetes wird damit um eine proprietäre Abhängigkeit ergänzt. Anwendungen wissen implizit, in welcher Cloud sie laufen.

External Secrets Operator: Kubernetes als Secret-Drehscheibe

Der External Secrets Operator setzt genau an dieser Schnittstelle an. Als Open-Source-Komponente für Kubernetes synchronisiert er Secrets aus externen Backends in native Kubernetes-Secrets.

Unterstützt werden unterschiedliche Quellen, darunter AWS Secrets Manager, HashiCorp Vault, Azure Key Vault oder andere kompatible Systeme. Der Operator selbst speichert keine Secrets dauerhaft. Er definiert lediglich, wie Secrets aus einem Backend ins Cluster gelangen – nicht, wo sie erzeugt oder verwaltet werden.

Damit verschiebt sich die Verantwortung bewusst.

Architektur: Nutzung und Verwaltung entkoppeln

Der architektonische Unterschied ist wesentlich. Mit dem External Secrets Operator wird Kubernetes zur zentralen Steuerungsebene für Secret-Nutzung. Anwendungen konsumieren Secrets über standardisierte [Kubernetes]-Mechanismen – unabhängig vom zugrunde liegenden Backend.

Die Konfiguration erfolgt deklarativ, ist versionierbar und GitOps-fähig. Secrets werden über Custom Resources beschrieben, nicht über imperative API-Aufrufe. Ein Wechsel des Backends erfordert keine Anpassung der Workloads, sondern lediglich eine Änderung der Operator-Konfiguration.

Secrets folgen der Plattform – nicht dem Anbieter.

Portabilität als Designziel

Dieser Ansatz passt zu Plattformarchitekturen, die auf Offenheit und Portabilität ausgelegt sind. [Kubernetes]-Cluster können in unterschiedlichen Clouds oder On-Premises betrieben werden, während das Secret-Handling konsistent bleibt.

Sicherheitsmodelle orientieren sich an [Kubernetes]-RBAC, Namespaces und Service Accounts – nicht ausschließlich an IAM-Policies eines einzelnen Providers. Secrets werden dort bereitgestellt, wo sie gebraucht werden, ohne dass die Anwendungslogik Cloud-spezifische Abhängigkeiten kennen muss.

Gerade in Multi-Cluster- oder Hybrid-Szenarien ist das kein Nice-to-have, sondern Voraussetzung für saubere Architektur.

Verantwortung bewusst verteilt

Der zusätzliche Gestaltungsspielraum bringt Verantwortung mit sich. Der External Secrets Operator übernimmt weder Verschlüsselung im Backend noch automatische Rotation. Diese Aufgaben verbleiben bei den jeweiligen Secret-Stores.

Dafür entsteht eine klare Trennung:

• Secret-Erzeugung und -Verwaltung im Backend
• Secret-Nutzung in der [Kubernetes]-Plattform

Genau diese Trennung macht das Modell langfristig stabil. Backends sind austauschbar, Plattformlogik bleibt konstant, Anwendungen bleiben unverändert.

Praktische Konsequenzen in [Kubernetes]-Umgebungen

In [Kubernetes]-zentrierten Umgebungen wird der Unterschied schnell sichtbar. AWS Secrets Manager vereinfacht Secret-Management innerhalb von AWS. Der External Secrets Operator integriert Secrets in die Plattform selbst.

Kubernetes wird nicht nur Laufzeit, sondern Sicherheits- und Steuerungsebene. Workloads bleiben portabel, Deployments reproduzierbar, Abhängigkeiten explizit.

Secrets werden nicht konsumiert – sie werden integriert.

Verdichteter Vergleich

Wann welcher Ansatz sinnvoll ist

AWS Secrets Manager ist sinnvoll für:

• rein AWS-zentrierte Workloads
• enge Integration mit AWS-Services
• geringe Anforderungen an [Kubernetes]-Portabilität
• Fokus auf minimalen Betriebsaufwand

Der External Secrets Operator ist sinnvoll für:

• [Kubernetes]-zentrierte Plattformarchitekturen
• Multi-Cloud- oder Hybrid-Szenarien
• GitOps-basierte Betriebsmodelle
• saubere Trennung von Plattform und Cloud
• langfristige Portabilität und Souveränität

Fazit

Secrets sind kein Implementierungsdetail. Sie definieren, wie eng Anwendungen an ihre Infrastruktur gebunden sind.

AWS Secrets Manager ordnet Secret-Management der Cloud unter. Der External Secrets Operator integriert Secrets in die Plattform selbst.

Der Unterschied ist nicht technisch, sondern strukturell. Wer Secrets als Cloud-Funktion nutzt, akzeptiert Abhängigkeit. Wer sie als Teil der [Kubernetes]-Plattform begreift, hält die Anwendungsarchitektur beweglich – heute und in Zukunft.