HashiCorp Vault + External Secrets Operator: Zero-Trust Secrets Management

TL;DR

• Secrets in Git, klassische Kubernetes-Secrets und manuelle Verfahren reichen für Zero-Trust-Anforderungen und moderne Regulierungen nicht mehr aus.
• HashiCorp Vault liefert mit Secrets Engines, Dynamic Secrets, Encryption as a Service und detaillierten Audit Logs die notwendige technische Grundlage für belastbares, revisionssicheres Secrets Management.
• Der External Secrets Operator (ESO) verbindet Vault und Kubernetes: Er synchronisiert Secrets kontrolliert in Namespaces, sorgt für automatische Rotation und entkoppelt Applikationsteams von der Komplexität des Vault-Backends.
• Ein durchgängiger Workflow Platform Admin → Vault → ESO → Kubernetes → App stellt sicher, dass Credentials für Systeme wie PostgreSQL nie in Git oder unverschlüsselt in Clustern landen.
• ayedo unterstützt Organisationen dabei, Vault und ESO produktiv und compliant zu betreiben – von Architektur und Setup bis zur Integration in bestehende CI/CD- und Governance-Strukturen.

---

Warum modernes Secrets-Management ein Zero-Trust-Kernbaustein ist

Secrets Management ist nicht nur ein Security-Thema, sondern eine Grundvoraussetzung für jede ernstzunehmende Compliance-Strategie. Wer Zugangsdaten, Tokens oder Verschlüsselungs-Keys verliert, verliert im Zweifel auch die Kontrolle über Daten, Systeme und Reputation.

Mit der GDPR (anwendbar seit dem 25.05.2018), der NIS-2-Richtlinie (in Kraft seit dem 16.01.2023, mit Umsetzungsfrist bis zum 17.10.2024) und der DORA-Verordnung (gilt ab dem 17.01.2025) steigt der Druck, Sicherheitsmaßnahmen strukturiert und nachweisbar umzusetzen. Artikel 32 GDPR fordert explizit „geeignete technische und organisatorische Maßnahmen“, insbesondere Verschlüsselung und Zugriffskontrolle.

In modernen, verteilten Infrastrukturen – mit mehreren Kubernetes-Clustern, GitOps, Multi-Cloud und Lieferketten aus Drittanbietern – genügt es nicht mehr, Secrets „irgendwo sicher abzulegen“. Ein zeitgemäßes Konzept muss:

• zentral, aber mandantenfähig sein,
• fein granulierte, nachvollziehbare Zugriffsrichtlinien bieten,
• automatische Rotation und kurzfristige Gültigkeit von Credentials unterstützen,
• revisionssichere Protokollierung und Audit-Möglichkeiten bereitstellen.

HashiCorp Vault in Kombination mit dem External Secrets Operator adressiert genau diese Anforderungen – ohne die Entwicklerproduktivität zu opfern.

---

Optionen im Vergleich: Secrets in Git, Kubernetes Secrets, Vault

Secrets in Git

Secrets direkt im Git-Repository zu speichern, ist aus heutiger Sicht kaum zu rechtfertigen:

• Git ist für Nachvollziehbarkeit optimiert, nicht für Geheimhaltung.
• Ein einmal eingechecktes Secret bleibt in der Historie.
• Replikation in Forks, Clones und Caches macht Löschung praktisch unmöglich.
• Aus Compliance-Perspektive ist das kaum mit Artikel 32 GDPR vereinbar.

Selbst mit Verschlüsselungslösungen rund um Git (z. B. SOPS) bleibt die Herausforderung: Zugriff auf Git bedeutet häufig auch Zugriff auf die verschlüsselten Artefakte und deren Schlüsselmaterial, wenn Governance und Schlüsselmanagement nicht sehr strikt aufgesetzt sind.

Kubernetes Secrets

Kubernetes-Secrets sind ein Fortschritt gegenüber Klartext-Umgebungsvariablen, aber konzeptionell begrenzt:

• Standardmäßig werden sie nur Base64-kodiert im etcd-Backend gespeichert.
• Sie können zwar mit KMS-gestützter Encryption-at-Rest abgesichert werden, bleiben aber clusterlokal.
• Rotation erfordert meist manuelle Prozesse oder individuelle Automatisierung.
• Zugriffskontrolle basiert auf Kubernetes-RBAC – gut, aber nicht auf das Thema Secrets spezialisiert.

Für einfache Szenarien sind Kubernetes Secrets ausreichend. In regulierten Umgebungen mit vielen Anwendungen, Mandanten oder Clustern stoßen sie jedoch an ihre Grenzen.

HashiCorp Vault

Vault bringt einen dedizierten Secret Store mit:

• Zentrale Verwaltung für mehrere Umgebungen und Cluster
• Unterstützung verschiedener Backends (Datenbanken, Cloud-Provider, PKI, Identity-Systeme)
• Feingranulare Policies mit klaren Verantwortlichkeiten
• Integrierte Audit Logs für alle Zugriffe

In einem Zero-Trust-Ansatz wird Vault zur „Source of Truth“ für alle Secrets – Kubernetes ist dann nur noch ein kontrollierter Konsument über ESO.

---

HashiCorp Vault im Detail: Engines, Dynamik und Nachvollziehbarkeit

Secrets Engines und Dynamic Secrets

Vault abstrahiert Secrets über sogenannte Secrets Engines. Wichtige Beispiele:

• Key/Value Engines für klassische statische Secrets (z. B. API-Keys)
• Database Engines für Datenbanken wie PostgreSQL, MySQL oder SQL Server
• Cloud Engines für temporäre IAM-Credentials bei Hyperscalern

Dynamic Secrets sind hier besonders relevant: Für eine PostgreSQL-Datenbank generiert Vault auf Anfrage kurzlebige Zugangsdaten, mit:

• definiertem TTL (Time-to-Live),
• optionaler Maximallebensdauer,
• automatischer Revocation nach Ablauf oder auf Knopfdruck.

Damit werden klassische „Shared Credentials“ durch temporäre, anwendungs- oder dienstspezifische Identitäten ersetzt – ein enormer Sicherheitsgewinn.

Encryption as a Service

Mit der Transit Secrets Engine bietet Vault „Encryption as a Service“:

• Anwendungen schicken Daten an Vault zur Ver- und Entschlüsselung, ohne jemals Keys lokal zu halten.
• Versionierung und Rotation von Keys erfolgt zentral.
• Zugriffe lassen sich per Policy steuern („darf ver- aber nicht entschlüsseln“).

Das erfüllt nicht nur Verschlüsselungsanforderungen aus Artikel 32 GDPR, sondern reduziert auch die Angriffsfläche für Key-Diebstahl signifikant.

Audit Logs und Policies

Jeder Zugriffsversuch auf Vault – erfolgreich oder nicht – kann in Audit-Backends wie Files, Syslog oder SIEM-Systemen protokolliert werden:

• Wer hat wann auf welches Secret zugegriffen?
• Von welcher Rolle oder welchem Service Account aus?
• Welche IP oder welches System war involviert?

Zusammen mit klar definierten Policies entsteht ein nachvollziehbares, revisionsfähiges Kontrollsystem, das auch für NIS‑2- und DORA-Audits belastbare Nachweise liefert.

---

External Secrets Operator: Brücke zwischen Vault und Kubernetes

Der External Secrets Operator (ESO) ist ein Kubernetes Operator, der externe Secret Stores wie Vault mit dem Cluster verbindet:

• Er liest deklarative Ressourcen (ExternalSecret, SecretStore, ClusterSecretStore).
• Er synchronisiert die darin referenzierten Werte in reguläre Kubernetes Secrets.
• Er aktualisiert diese Secrets automatisch, wenn sich Werte oder Versionen im Backend ändern.

Damit müssen Applikationsteams nicht direkt mit Vault-APIs oder -Policies arbeiten. Sie definieren lediglich, welche Secrets sie benötigen, in welchem Namespace, und welches Backend zuständig ist. ESO übernimmt:

• Authentifizierung gegenüber Vault (z. B. via Kubernetes Auth Method),
• regelmäßiges Refreshing und Rotation,
• Fehlerhandling und Statusinformationen innerhalb des Clusters.

Aus Sicht des Pods bleibt alles beim Alten: Er konsumiert ganz normale Kubernetes Secrets. Das komplexe, aber notwendige Sicherheits- und Compliance-Gerüst liegt dahinter.

---

Der Workflow: Platform Admin → Vault → ESO → Kubernetes → App

Ein praxistauglicher Zero-Trust-Workflow könnte wie folgt aussehen:

1. Platform Admin
   Verantwortet zentrale Infrastruktur wie Datenbanken, Vault-Cluster und Kubernetes-Basiskomponenten. Er definiert, welche Systeme über Vault verwaltet werden und legt Policies fest.

2. Vault
   Enthält alle relevanten Credentials, sei es in KV-Stores oder als Dynamic Secrets. Für Datenbanken wie PostgreSQL werden Rollen eingerichtet, die anwendungsspezifische Credentials generieren und rotieren.

3. External Secrets Operator
   Läuft in den jeweiligen Clustern und ist so konfiguriert, dass er auf die passenden Vault-Pfade zugreifen darf – streng begrenzt über Policies und Kubernetes Service Accounts.

4. Kubernetes & GitOps
   Applikationsteams definieren ExternalSecret-Ressourcen in ihren Git-Repositories. GitOps-Werkzeuge wie Argo CD spielen diese ins Cluster ein. ESO erzeugt daraus die konkreten Kubernetes Secrets.

5. Applikation
   Nutzt die bereitgestellten Secrets über Umgebungsvariablen oder Volume Mounts, ohne die Herkunft zu kennen. Rotation wird transparent gehandhabt; im besten Fall erfolgt ein Rolling Restart automatisiert, wenn sich kritische Secrets ändern.

In diesem Modell berühren sensible Informationen weder Git noch CI/CD-Systeme. Sie bleiben in Vault und wandern über ESO kontrolliert in die Laufflächen.

---

Konkretes Szenario: PostgreSQL-Credentials über ExternalSecret

Nehmen wir eine PostgreSQL-Datenbank, die von einem Plattformteam bereitgestellt wird – etwa über CloudNativePG oder einen gemanagten Cloud-Service.

1. Datenbankbereitstellung
   Der Platform Admin erstellt die Datenbank und konfiguriert in Vault eine Database Secrets Engine für PostgreSQL. Dort werden Rollen definiert, die anwendungsspezifische User erzeugen können, mit begrenzten Rechten und klarer TTL.

2. Vault-Konfiguration
   Für jede Anwendung gibt es einen Vault-Pfad (z. B. pro Team oder Service). Policies erlauben ESO nur den Zugriff auf die Pfade, die zum jeweiligen Namespace gehören. Dynamic Secrets sorgen dafür, dass Credentials regelmäßig erneuert werden.

3. ESO-Anbindung
   Im Kubernetes-Cluster ist ESO so konfiguriert, dass er sich gegenüber Vault authentifizieren kann (beispielsweise über die Kubernetes Auth Method). Ein SecretStore-Objekt beschreibt, wo Vault erreichbar ist und wie die Authentifizierung läuft.

4. ExternalSecret durch das App-Team
   Das Applikationsteam beschreibt in seinem Git-Repository ein ExternalSecret, das:

   • auf den richtigen Vault-Pfad zeigt,
   • die benötigten Felder (Benutzername, Passwort, Host, Port, Datenbankname) abbildet,
   • den Namen des Kubernetes Secrets festlegt, das später im Namespace existieren soll.

5. Laufzeitverhalten
   ESO erzeugt das Kubernetes Secret, aktualisiert es bei Rotationen und sorgt dafür, dass die Anwendung stets gültige Credentials erhält. Weder Entwickler noch CI/CD-Pipelines sehen jemals die Klartext-Passwörter.

Dieses Muster lässt sich auf viele andere Systeme übertragen: Message-Broker, externe APIs, Cloud-Ressourcen – überall dort, wo Credentials im Spiel sind.

---

Compliance-Mehrwert: GDPR, NIS‑2 und DORA gezielt adressieren

Ein Vault+ESO-Setup hilft, regulatorische Anforderungen nicht nur „irgendwie“ zu erfüllen, sondern strukturiert nachweisen zu können.

GDPR Art. 32

Artikel 32 GDPR fordert u. a.:

• Pseudonymisierung und Verschlüsselung personenbezogener Daten,
• Sicherstellung von Vertraulichkeit, Integrität und Verfügbarkeit,
• Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit.

Vault adressiert das, indem:

• Kryptografische Schlüssel zentral verwaltet, rotiert und revisionssicher protokolliert werden.
• Zugriff auf Secrets strikt nach dem Least-Privilege-Prinzip erfolgt.
• Alle Zugriffe auditierbar sind, inklusive fehlgeschlagener Zugriffsversuche.

ESO ergänzt dies, indem er sicherstellt, dass Secrets nur kontrolliert in die Kubernetes-Laufzeit gelangen – ohne Streuverluste in Git oder CI/CD-Systemen.

NIS‑2

Die NIS‑2-Richtlinie verlangt von Betreibern kritischer und wichtiger Einrichtungen ein hohes Niveau an Cyber-Sicherheit, inklusive:

• Identity- und Access-Management,
• Risiko- und Vorfallsmanagement,
• Protokollierung und Monitoring.

Vault+ESO unterstützt hier, indem:

• Identitäten (Service Accounts, Rollen, Teams) klar von Berechtigungen und Secrets getrennt sind,
• Secret-Zugriffe zentral geloggt werden,
• Rotation und Revocation-Prozesse etabliert sind, die auch im Incident-Fall schnell greifen.

DORA

DORA fokussiert sich auf die digitale operationelle Resilienz im Finanzsektor. Für Secrets Management relevant sind:

• Schutz kritischer Assets,
• Kontrolle über Drittparteien,
• Nachweisfähigkeit gegenüber Aufsichtsbehörden.

Ein standardisiertes Vault+ESO-Pattern schafft:

• eine wiederverwendbare, prüfbare Blaupause für alle Anwendungen,
• klare Zuständigkeiten (Plattform vs. Fachteam),
• technische Nachweise für Audits (Policies, Audit Logs, Verfahren).

---

Häufige Fragen

Müssen alle Anwendungen direkt mit Vault sprechen?

Nein. Ein zentraler Vorteil des External Secrets Operators ist gerade, dass Anwendungen nicht direkt mit Vault interagieren müssen. Sie konsumieren weiterhin Kubernetes Secrets, während ESO im Hintergrund den sicheren Datenaustausch mit Vault übernimmt.

Für bestimmte High-Security-Szenarien kann ein direkter Vault-Zugriff sinnvoll sein (z. B. bei On-demand-Verschlüsselung über Transit Engines). Für den Großteil der Workloads ist das Muster „Vault → ESO → Kubernetes Secret → App“ jedoch ausreichend und operational deutlich einfacher.

Wie gehe ich mit Legacy-Anwendungen um, die nicht für Rotation gebaut wurden?

Legacy-Anwendungen sind oft nicht in der Lage, Secrets zur Laufzeit neu zu laden. Hier bieten sich pragmatische Schritte an:

• Zunächst die Quelle der Secrets auf Vault umstellen, aber das Konsummuster unverändert lassen.
• Rotation so gestalten, dass sie mit geplanten Rolling Restarts zusammenfällt.
• Langfristig Anwendungen so weiterentwickeln, dass sie z. B. über Sidecars, Config Reloads oder Short-lived Connections besser mit häufigeren Geheimniswechseln umgehen können.

Wichtig ist, dass Sie auch bei Legacy-Systemen zumindest die zentrale Verwaltung und Auditfähigkeit erreichen – ESO hilft, ohne tiefgreifende Codeänderungen erste Verbesserungen umzusetzen.

Wie fügt sich ayedo in dieses Bild ein?

Viele Organisationen unterschätzen den Aufwand für ein robustes Vault+ESO-Setup: Hochverfügbarkeit, Backup-Strategien, Policy-Design, Integration in CI/CD, Schulung von Teams. ayedo bringt hier Plattform- und Compliance-Erfahrung zusammen:

• Referenzarchitekturen für Vault-Cluster und ESO-Deployment in Kubernetes-Umgebungen,
• Best Practices für Policies, Namenskonventionen und Mandantentrennung,
• Begleitung bei der Integration in bestehende Pipelines, Monitoring- und SIEM-Systeme.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

Ein starkes Secrets-Management mit HashiCorp Vault und dem External Secrets Operator ist kein Selbstzweck. Es ist die technische Basis dafür, dass Ihre Plattform resilient, revisionssicher und zukunftsfähig bleibt – insbesondere unter den Rahmenbedingungen von GDPR, NIS‑2 und DORA.

In vielen Organisationen sehen wir ähnliche Muster: Es gibt bereits Kubernetes-Cluster, GitOps ist etabliert, vielleicht existiert sogar ein Vault-PoC. Was fehlt, ist eine konsistente Linie:

• Eine klar definierte Rollenverteilung zwischen Plattform, Security und Applikationsteams.
• Ein standardisiertes Pattern für „Vault → ESO → Kubernetes Secret → App“, das in allen Clustern gleich funktioniert.
• Dokumentierte Prozesse für Rotation, Revocation und Incident Response, die sich sauber in Ihre Compliance- und Audit-Programme einfügen.

Genau hier setzt ayedo an. Wir verstehen Vault und ESO nicht als Insellösungen, sondern als integralen Bestandteil einer Cloud-Native-Plattform: vom sicheren Aufbau und Betrieb der Vault-Infrastruktur über die ESO-Integration in Ihre Cluster bis hin zur Einbettung in CI/CD, Observability und Governance.

Wenn Sie Vault+ESO nicht nur ausprobieren, sondern als dauerhaft tragfähige Basis für Zero-Trust-Secrets-Management etablieren wollen, begleiten wir Sie von der Architektur über das initiale Setup bis hin zur schrittweisen Migration Ihrer Anwendungen – mit einem besonderen Blick auf regulatorische Anforderungen und praktische Umsetzbarkeit im Alltag Ihrer Teams.

Wenn Sie diesen Schritt angehen möchten, starten Sie mit unserem gemeinsamen Vault + ESO Setup.