Secrets Management

Schluss mit Passwörtern in Git, CI-Variablen und Excel-Listen

Ein zentraler Secret Store mit Vault oder OpenBao: hochverfügbar, mit klarem Berechtigungskonzept, angebunden an Kubernetes und CI/CD und vollständig als Code beschrieben. So, wie ich es zuletzt in einer sicherheitssensitiven On-Premises-Umgebung aufgebaut habe.

30 Minuten unverbindlich sprechen Alle Leistungen

Thomas Zachmann · thomas@zachmann.work · thomaszachmann.de/secrets-management-einfuehrung

Für wen

Typische Ausgangslagen

Secrets liegen verstreut

„Wir wissen nicht genau, wo überall Passwörter stehen.“

Zugangsdaten in Repositories, Pipeline-Variablen und Konfigurationsdateien. Wer Zugriff hat, ist kaum nachvollziehbar, Rotation findet nicht statt.

Audit oder neue Vorgaben

„Die Prüfer wollen wissen, wer wann auf welches Secret zugegriffen hat.“

Ohne zentralen Store gibt es keine Protokollierung und keine Nachweise.

Kubernetes wächst

„Jedes Team löst das mit Secrets anders.“

Kubernetes-Secrets im Klartext im Git, selbstgebaute Lösungen pro Team. Es fehlt ein gemeinsames Muster.

Umfang

Was ich aufbaue

Architektur
Hochverfügbarer Betrieb, Storage, Netzwerk und Zugriffswege
Unseal
Auto-Unseal über HSM oder KMS, Konzept für Recovery Keys
Berechtigungskonzept
Auth-Methoden, Policies und Rollen nach Least Privilege
Kubernetes-Anbindung
Kubernetes Auth, Agent Injection oder External Secrets Operator
CI/CD-Anbindung
Pipelines holen Secrets zur Laufzeit statt sie zu speichern
Betrieb
Backup und Restore, Monitoring, Audit-Logs, Upgrade-Pfad
Infrastructure as Code
Alles in Terraform/OpenTofu und Ansible, reproduzierbar und versioniert

Das Ziel ist, dass Ihr Team den Secret Store danach selbst betreibt. Dokumentation und Einweisung sind Teil der Leistung, nicht Folgeangebot.

Ergebnis

Was Sie bekommen

Produktiver Secret Store
Vault oder OpenBao, hochverfügbar und angebunden
Berechtigungskonzept
Dokumentiert und als Code umgesetzt
Muster für Teams
Vorlagen, wie Anwendungen Secrets beziehen
Übergabe
Betriebsdokumentation und Einweisung

Ablauf

1. Konzept
Anforderungen, Architektur, Berechtigungen
3–4 Tage
2. Aufbau
Cluster, Unseal, Auth-Methoden als Code
5–7 Tage
3. Anbindung
Kubernetes, CI/CD, erste Anwendungen
4–6 Tage
4. Übergabe
Dokumentation und Einweisung
1–2 Tage

Ich arbeite remote, auf Wunsch auch vor Ort.

Angebot

Varianten und Angebot

Nach einem kurzen Erstgespräch erhalten Sie ein schriftliches Angebot mit Festpreis für den vereinbarten Umfang.

Starter

  • ein Cluster, eine Umgebung
  • Kubernetes- und CI/CD-Anbindung
  • ca. 4 Wochen

Enterprise

  • mehrere Umgebungen oder Standorte
  • HSM-Integration, Disaster Recovery
  • Anbindung vieler Teams

Die Konzeptphase kann auch einzeln beauftragt werden.

Belege

Warum ich

Praxis
Ich baue und betreibe Vault/OpenBao selbst, zuletzt als zentralen Secret Store einer On-Premises-Kubernetes-Plattform: Berechtigungskonzept, Auto-Unseal über ein Hardware-HSM, Kubernetes Auth, Injection und External Secrets Operator, vollständig als Infrastructure as Code.
Buch
„Vault in Practice“: ein praxisnaher Lab-Guide zu HashiCorp Vault und OpenBao (Leanpub, 581 Seiten).
Plattformen
On-Premises-Kubernetes in regulierten Umfeldern: RKE2 mit automatisiertem Lifecycle, OpenShift auf virtualisierter Infrastruktur, Kyverno-Policies, GitOps mit Argo CD und Flux, Observability mit Prometheus, Grafana, Loki und Tempo.
Zertifikate
CKS, CKA, CKAD

Nächster Schritt

30 Minuten, unverbindlich

Schreiben Sie mir kurz, wo Ihre Secrets heute liegen und welche Plattformen angebunden werden sollen.

Gespräch vereinbaren

Thomas Zachmann · Freiberuflicher Platform Engineer · Hamburg
thomas@zachmann.work · thomaszachmann.de