Case: Secrets Management Platform

Lernziele

Nach dieser Lektion kannst du eine zentrale Secrets-Plattform für 100 Teams designen: Vault als Source of Truth, External Secrets Operator als Brücke nach Kubernetes, dynamische Credentials mit TTL statt Rotation per Kalender. Du kannst die unbequemen Fragen beantworten — was passiert bei Vault-Ausfall, warum landet das Secret am Ende doch in etcd — und du weißt, wie Self-Service für 100 Teams aussieht, ohne dass jedes Team Vault lernen muss.

Das Szenario

„Designe eine zentrale Secrets-Management-Lösung für 100 Teams mit rund 400 Services auf Kubernetes. Compliance verlangt: keine Klartext-Secrets in Git, Rotation mindestens alle 90 Tage, lückenloser Audit-Trail.” Der Case prüft drei Disziplinen gleichzeitig: Security-Architektur (Vertrauensketten, Blast Radius), Plattform-Denken (100 Teams dürfen keine Vault-Experten sein müssen) und Ehrlichkeit — denn jede Secrets-Lösung hat eine Stelle, an der das Geheimnis am Ende doch irgendwo liegt. Wer sie benennt statt versteckt, gewinnt.

Anforderungen klären: Welche Secrets, wessen Secrets, wie schnell weg?

Diese Fragen entscheiden, was du baust:

• „Welche Arten von Secrets — statische API-Keys, Datenbank-Credentials, Zertifikate?” — Angenommen: alles drei. Wichtig, weil die stärkste Antwort für DB-Credentials eine andere ist als für einen statischen Partner-API-Key: dynamisch erzeugen statt rotieren.
• „Was heißt Rotation konkret — neues Secret im Store reicht, oder müssen laufende Pods es übernehmen?” — Angenommen: Workloads müssen das neue Secret binnen Stunden verwenden. Das zieht die Reload-Frage nach sich, die viele Designs vergessen.
• „Was existiert schon?” — Angenommen: AWS, ein HashiCorp Vault ist vorhanden, aber kaum genutzt. Cloud-natives AWS Secrets Manager wäre die Alternative — die Entscheidung gehört explizit gemacht.
• „Wer schreibt Secrets, wer liest sie?” — Angenommen: Teams legen eigene Secrets selbst an (Self-Service), Services lesen nur die eigenen, das Plattform-Team sieht Inhalte gar nicht. Audit: wer hat wann was gelesen.

Eine kurze Abschätzung erdet das Design: 400 Services × 3 Umgebungen × im Schnitt 3–5 Secrets ergibt 4.000–6.000 verwaltete Secrets. Bei einem Sync-Intervall von einer Stunde sind das wenige Anfragen pro Sekunde an Vault — Last ist hier kein Argument, Verfügbarkeit und Berechtigungsmodell sind die Designtreiber.

Architektur: Vault als Quelle, ESO als Brücke, TTL statt Kalender

Das Zielbild in einem Satz: Vault ist die einzige Quelle der Wahrheit, der External Secrets Operator (ESO) synchronisiert daraus Kubernetes-Secrets, und wo immer möglich ersetzen dynamische, kurzlebige Credentials die 90-Tage-Rotation.

Schicht 1 — der Store. Vault läuft als HA-Cluster (Raft-Storage, Auto-Unseal über AWS KMS), betrieben vom Plattform-Team. Pro Team ein eigener Pfad (secret/team-checkout/...) mit Policies, die aus den IdP-Gruppen generiert werden. Begründung gegenüber AWS Secrets Manager: Vault bringt dynamische Secrets-Engines mit und bleibt Cloud-portabel; der Preis ist ein zustandsbehaftetes, kritisches System in Eigenbetrieb. Und weil ESO viele Backends spricht, ist die Store-Entscheidung reversibel — die Teams sehen ExternalSecrets, nicht Vault.

Schicht 2 — die Brücke. Teams schreiben keine Vault-Aufrufe in ihre Apps. Sie legen ein ExternalSecret-Manifest neben ihr Deployment (gerne aus einem Template des Plattform-Charts), das auf einen Pfad im Team-Bereich zeigt. Ein ClusterSecretStore, den das Plattform-Team verwaltet, kapselt die Vault-Verbindung — authentifiziert über die Kubernetes-Auth-Methode: Das ServiceAccount weist sich mit seinem Token aus, Vault mappt das auf Team-Policies. Keine langlebigen Vault-Tokens, nirgends.

Schicht 3 — Rotation. Hier trennt sich Mittelmaß von stark. Für Datenbank-Credentials: Die Vault Database Engine erzeugt frische DB-User mit TTL — „Rotation” passiert nicht alle 90 Tage, sondern implizit alle paar Stunden, und ein geleaktes Credential ist nach Ablauf wertlos. Für statische Secrets: Rotation an der Quelle, ESO zieht den neuen Wert per refreshInterval nach, und ein Reloader-Mechanismus (z. B. Stakater Reloader) startet die betroffenen Deployments rolling neu. Ohne diesen letzten Schritt ist Rotation Theater: Der Store rotiert, der Pod läuft mit dem alten Wert weiter.

Audit: Vault-Audit-Log (jeder Zugriff, mit Identität) zentral ins SIEM. Damit ist die Compliance-Frage „wer hat wann gelesen” eine Abfrage, kein Forensik-Projekt.

Einwände des Interviewers

„Am Ende liegt das Secret doch als Kubernetes-Secret in etcd — base64 ist keine Verschlüsselung. Was hast du gewonnen?” Der wichtigste Einwand, niemals abwiegeln. Ehrliche Antwort: Ja, ESO materialisiert Kubernetes-Secrets. Gewonnen sind zentrale Quelle, Rotation, Audit und „nichts in Git”. Das Restrisiko adressierst du mit etcd-Encryption-at-Rest, striktem RBAC auf Secrets und kurzen TTLs bei dynamischen Credentials. Wer die Materialisierung ganz vermeiden will, nimmt den Vault Agent Injector oder den Secrets-Store-CSI-Driver, der Secrets nur ins Pod-Dateisystem mountet — dafür handelt man sich pro Pod mehr Komplexität ein. Diesen Trade-off explizit zu benennen ist die Antwort.

„Vault fällt aus — was passiert mit den 400 Services?” Differenziert antworten: Laufende Pods behalten ihre Secrets, ESO kann nur nicht mehr refreshen — für statische Secrets ist ein Vault-Ausfall von Stunden unkritisch. Kritisch sind dynamische Credentials mit kurzer TTL: Laufen die Leases aus, während Vault down ist, verlieren Services ihre DB-Verbindung. Konsequenz: TTLs nicht heroisch kurz wählen (eher Stunden als Minuten), Vault als Tier-0-System mit HA und geübtem Restore behandeln.

„Warum nicht einfach Sealed Secrets — verschlüsselt in Git, kein extra System?” Für ein kleines Setup legitim. Bei 100 Teams fehlen drei Dinge: zentraler Audit-Trail, dynamische Secrets, und Rotation heißt bei Sealed Secrets „jedes Secret neu verschlüsseln und committen” — manuell, pro Repo. Außerdem ist der private Schlüssel des Controllers ein Single Point of Trust, dessen Verlust alle Git-Historien-Secrets kompromittiert.

„Wie verhinderst du, dass Team A die Secrets von Team B liest?” Zwei Ebenen: In Vault über Policies pro Team-Pfad, gebunden an die Kubernetes-Auth-Rolle des jeweiligen Namespaces. In Kubernetes über RBAC — ein ExternalSecret kann nur in den eigenen Namespace schreiben, und der ClusterSecretStore erzwingt das Mapping Namespace → Vault-Rolle. Isolation durch Konfiguration, die das Plattform-Team generiert, nicht durch Team-Disziplin.

Praxis

Spiele den Case 40 Minuten am Whiteboard, laut. Pflichtprogramm:

1. Die Klärungsfragen, insbesondere die Unterscheidung statisch vs. dynamisch und die Reload-Frage.
2. Der komplette Lesefluss als Erzählung: Pod-ServiceAccount → Kubernetes-Auth → Vault-Policy → ESO → Kubernetes-Secret → Reload bei Änderung.
3. Die etcd-Frage proaktiv selbst ansprechen, bevor sie kommt.
4. Das Ausfallszenario mit der TTL-Abwägung.

Zusatzrunde nach ein paar Tagen mit verschobener Vorgabe: „Multi-Cloud, AWS und Azure” — und beobachte, wie der Vault-Vorteil (ein Berechtigungsmodell über beide Clouds) plötzlich vom Nice-to-have zum Hauptargument wird.

Typische Stolperfallen

Rotation ohne Reload designen. Das Secret im Store zu rotieren ist die halbe Miete — wenn der Pod den alten Wert im Environment behält, hast du Compliance auf dem Papier und das alte Passwort in Produktion. Refresh-Intervall plus Rolling Restart gehören in jede Rotationsantwort.

Die etcd-Schwachstelle verschweigen. Interviewer kennen sie. Wer sie selbst benennt und Mitigations nennt, wirkt erfahren; wer sie auf Nachfrage nicht kennt, verliert den Case.

Vault-Betrieb unterschätzen. Unseal-Verfahren, Backup/Restore der Raft-Daten, Upgrade-Pfad — ein Satz dazu („Vault ist ein Tier-0-System und braucht denselben Betriebsernst wie die Datenbank”) reicht, aber er muss fallen.

Allen Teams rohes Vault zumuten. 100 Teams mit Vault-CLI und eigenen Policies enden in Wildwuchs. Die Plattform-Antwort: Teams sehen ein ExternalSecret-Template und einen Pfad-Namespace, der Rest ist Plattform-Sache.

Interview-Vorbereitung

Deine Kernbotschaft: Vault als zentrale, auditierbare Quelle mit Team-Pfaden und IdP-gebundenen Policies; ESO als Brücke, die Teams von Vault-Wissen entkoppelt; dynamische Credentials mit TTL als bessere Rotation; und die etcd-Materialisierung als benannter, mitigierter Trade-off.

Rechne mit diesen Follow-ups:

• „ESO oder Vault Agent Sidecar?” — ESO: zentral, einfach, aber materialisiert Kubernetes-Secrets. Sidecar/CSI: Secrets nur im Pod, kein etcd, dafür Komplexität pro Workload. Wahl nach Schutzbedarf, gerne hybrid.
• „Wie kommen Secrets initial in Vault?” — Self-Service über Team-Policies (UI/CLI/Terraform auf den eigenen Pfad), nie über das Plattform-Team als menschliche Durchreiche.
• „Was ist mit Secrets, die die Plattform selbst braucht (z. B. Argo-CD-Credentials)?” — Henne-Ei-Problem benennen: ein kleiner, manuell bootstrapped Kern, alles Weitere wieder über den Standardpfad.
• „90-Tage-Rotation für DB-Passwörter — wie?” — Umdrehen: Mit der Database Engine gibt es kein 90-Tage-Passwort mehr, sondern kurzlebige, dynamisch erzeugte Credentials; die Compliance-Anforderung ist damit übererfüllt.

Zusammenfassung

Der Secrets-Case prüft, ob du Vertrauensketten sauber baust (ServiceAccount → Kubernetes-Auth → Vault-Policy), Teams vom Spezialwissen entkoppelst (ExternalSecret statt Vault-API) und Rotation zu Ende denkst (TTL-Credentials, Refresh plus Reload). Die starken Momente sind die ehrlichen: etcd-Materialisierung, Vault-Ausfall, Bootstrap-Henne-Ei. In der nächsten Lektion baust du die dritte große Shared-Plattform: Observability-as-a-Service für 60 Teams — wo nicht Geheimnisse, sondern Terabytes an Telemetrie das Mengenproblem sind.