Sicherheit zentral gedacht
HashiCorp Vault als Rückgrat für Cloud-native Plattformen
Ein Gespräch mit Jakob Beckmann und Zak Cook über den produktiven Einsatz von HashiCorp Vault in komplexen IT-Landschaften – und darüber, wie Unternehmen damit Zero-Trust-Architekturen realisieren, Secrets sicher automatisieren und Sicherheitsrichtlinien konsistent durchsetzen können.
Jakob Beckmann und Zak Cook über den produktiven Einsatz von HashiCorp Vault in komplexen IT-Landschaften | 17.6.2025
Könnt ihr euch kurz vorstellen? Welche Rolle habt ihr bei ipt und worauf liegt euer technischer Fokus?
Jakob Beckmann (JBE): Ich bin Principal Architect bei ipt mit einem Schwerpunkt auf Cloud-native Security. HashiCorp Vault ist in meinen Projekten oft ein zentrales Element, weil es operative Sicherheit standardisiert und automatisiert.
Zak Cook (ZCO): Ich bin Senior Consultant bei ipt. Mein Fokus liegt auf Platform Engineering. Vault ist immer ein Thema in meinen Projekten, vor allem wenn es um die Absicherung von Workloads in Kubernetes geht – sei es durch Secrets Injection, Public Key Infrastructure (PKI) oder dynamische Credentials.
Welche Rolle spielt HashiCorp Vault in modernen Platform-Engineering-Ansätzen?
ZCO: Eine zentrale. Sobald du mehr als ein Dev-Team hast, brauchst du Standards und Automatisierung für alles, was mit Secrets und Zugängen zu tun hat. HashiCorp Vault bringt Struktur, Kontrolle und Transparenz – und das auf eine Art, die sich mit Infrastructure-as-Code und CI/CD gut verbinden lässt.
JBE: Ich stimme Zak absolut zu. Vault ist eine Plattformkomponente. Es verlagert Security dorthin, wo sie hingehört: weg von Menschen, hin zu Systemen (shift-down). Und es schafft einen zentralen Ort, um Sicherheitsrichtlinien durchzusetzen. Gerade im Platform Engineering ist das ein Gamechanger.
Ab wann lohnt es sich für Unternehmen, über den Einsatz von HashiCorp Vault nachzudenken?
JBE: Eine Credential-Management-Lösung lohnt sich eigentlich immer. Credentials manuell zu verwalten ist sehr gefährlich und fehleranfällig. HashiCorp Vault spezifisch lohnt sich eher bei etwas grösseren Lösungen. Aber es lohnt sich, mit Vault schlank und früh zu starten. Viele beginnen mit einem kleinen Cluster und wachsen dann schrittweise.
ZCO: Ich bin mit Jakob einverstanden. Einen einfachen Vault zu erstellen, ist nicht schwer, besonders wenn man bereits ein Kubernetes-Cluster nutzt. Es gibt eine benutzerfreundliche UI, das heisst, man kann schnell mit Vault starten, Secrets erstellen und anfangen, Best Practices zu lernen.
Ist HashiCorp Vault vor allem für Cloud-Umgebungen relevant – oder spielt es auch on-prem eine Rolle?
ZCO: HashiCorp Vault ist komplett cloud-unabhängig. Es läuft genauso gut on-prem wie in der Cloud oder in hybriden Szenarien. Diese Flexibilität ist ein klarer Vorteil gegenüber Cloud-Anbieter Secret-Managern.
JBE: Ich würde behaupten, dass es gerade bei on-prem-Umgebungen eine noch grössere Rolle spielt. Hyperscaler bieten ihre eigenen Credential-Management-Lösungen an, die zumindest für simple Use Cases ebenfalls recht gut geeignet sind. On-prem gibt es aber fast keine Alternativen zu Vault, zumindest wenn man moderne Plattformen betreibt.
Was sind Funktionen in HashiCorp Vault, die aus eurer Sicht noch viel zu wenig genutzt werden?
JBE: Die Public Key Infrastructure (PKI)-Funktion, ganz klar. Viele wissen gar nicht, dass HashiCorp Vault komplette Certificate Authorities ersetzen kann – inklusive automatischer Ausstellung und Rotation. Das senkt den manuellen Aufwand enorm, reduziert Fehlerquellen und erhöht die Konsistenz in dynamischen Umgebungen.
Ich habe leider noch nie ein Unternehmen gesehen, wo Zertifikat-Management korrekt und automatisiert gelöst ist. Somit sind leider oft auch noch gewisse interne Netzwerkverbindungen unverschlüsselt. Vault löst das ohne grossen Aufwand.
ZCO: Ich sehe oft, dass statische Secrets gepflegt werden, was okay ist. Aber dynamische Credentials sind deutlich sicherer. Sie leben nur ein paar Minuten und machen gestohlene Zugangsdaten praktisch wertlos.
Man sollte immer prüfen, ob es für den jeweiligen Use Case bereits eine geeignete dynamische Secrets Engine gibt.
Gibt es Einsatzszenarien, in denen HashiCorp Vault aus eurer Sicht nicht die richtige Wahl ist?
ZCO: Die Integration von HashiCorp Vault kann bei Legacy-Anwendungen, die auf älteren Infrastrukturen wie virtuellen Maschinen (VMs) laufen, unter Umständen weniger reibungslos sein. Es ist aber dennoch machbar.
In solchen Fällen würde ich zunächst den Fokus darauf legen, die Workloads auf eine containerisierte Cloud-Infrastruktur wie Kubernetes zu migrieren, da dies eine deutlich nahtlosere Integration mit Vault ermöglicht.
JBE: Wenn man bei einem Hyperscaler ist und nur sehr einfache Use Cases hat, steht der Aufwand und die Komplexität, die mit Vault einhergeht, oft nicht im Verhältnis zum Nutzen.
Gleichzeitig sehen wir bei unseren Kunden häufig den Bedarf für deutlich komplexere Anwendungsfälle. Diese werden jedoch leider oft nicht umgesetzt, weil es an Engineering-Power und dem nötigen Know-how fehlt.
Was sind aus eurer Erfahrung häufige Fehler bei der Einführung und dem Betrieb von HashiCorp Vault?
ZCO: HashiCorp Vault zuerst manuell zu konfigurieren und dann nachträglich auf IaC umzusteigen ist mühsam. Lieber von Anfang an deklarativ arbeiten.
Und Policies nicht pro Rolle bauen, sondern nach Funktion strukturieren. Das spart nicht nur Aufwand, sondern sorgt für mehr Transparenz und Wiederverwendbarkeit im Berechtigungskonzept.
JBE: Vault bringt eine gewisse Komplexität mit sich, die man nicht unterschätzen sollte. Anders als bei vielen anderen Tools ist ein schrittweises Herantasten über «Learning by Doing» nur bedingt zielführend.
Einige Grundentscheidungen – etwa zur Struktur der Credentials und dessen Access Policies – haben langfristige Auswirkungen. Deshalb lohnt es sich, am Anfang gezielt Zeit einzuplanen, um die Prinzipien hinter Vault gut zu verstehen.
Wenn intern noch wenig Erfahrung vorhanden ist, kann der Austausch mit Personen, die Vault bereits in der Praxis eingeführt haben, helfen, typische Hürden früh zu erkennen und tragfähige Lösungen zu entwickeln.
Welche Alternativen zu HashiCorp Vault seht ihr – und wann wären diese sinnvoll?
JBE: Es gibt Cloud-spezifische Produkte wie AWS Secrets Manager oder Azure Key Vault. Sie sind einfacher zu starten, aber auch limitierter, wie etwa beim Thema dynamische Secrets oder PKI. Zudem versuchen viele andere Produkte, gewisse Features von Vault zu integrieren und eine stärkere Adoption in der Cloud-native Welt zu erreichen.
Zum Beispiel CyberArk mit Conjur oder der Delinea Secret Server. Sie sind aber weiterhin in den meisten Use Cases von Vault noch stark hinterher.
ZCO: Ich würde grundsätzlich die von den Cloud-Anbietern entwickelten Alternativen empfehlen: Sie sind gut integriert, solide und in vielen Fällen völlig ausreichend.
Wenn jedoch nur wenige Secrets im Einsatz sind und es noch keine zentrale Verwaltung gibt, können Tools wie Sealed Secrets oder SOPS eine pragmatische Zwischenlösung darstellen, um Secrets versionskontrolliert in Git zu verwalten.
Sobald es jedoch um zentrale Authentifizierung, dynamische Secrets, PKI oder eine fein abgestimmte Zugriffskontrolle über komplexe Umgebungen hinweg geht, spielt Vault seine Stärken aus. Genau für solche anspruchsvolleren Anforderungen ist es gemacht
Welche Bedeutung hat HashiCorp Vault im Kontext von zugriffsbasierter Sicherheit, wie sie heute unter dem Begriff Identity-First Security diskutiert wird – gerade in dynamischen Cloud-Umgebungen?
JBE: Identity-First Security heisst: Jede Entscheidung basiert auf Identitäten und nicht auf IPs oder Netzgrenzen. HashiCorp Vault baut hier drauf auf. Jede Request zu Vault wird authentisiert, basierend auf externen Identitäten (z. B. via Kubernetes oder Identity Providern). Basierend darauf entscheidet Vault, worauf man berechtigt ist.
Das ist ein zentraler Baustein von Zero-Trust-Architekturen, in denen keinem System und keiner Verbindung per se vertraut wird, sondern jede Aktion geprüft werden muss. Vault spielt hier eine recht zentrale Rolle.
In einer idealen Welt ist jedes System mit jedem möglichen Identity Provider integriert, und man muss keine Credentials mehr managen. Die reale Welt sieht leider sehr anders aus. Hier kommt dann Vault ins Spiel, um für Identitäten temporäre Credentials zu erstellen, damit kein Trust zwischen Systemen existieren muss.
ZCO: Und das funktioniert auch für Services, Jobs oder temporäre Deployments. Vault integriert Identitäten auf allen Ebenen und ersetzt veraltete Zugriffsmuster durch sichere, auditierbare Prozesse.
Damit unterstützt Vault Zero Trust nicht nur konzeptionell, sondern ganz konkret in der technischen Umsetzung, wie beispielsweise durch feingranulare Policies, temporäre Zugriffstokens oder die Trennung von Rollen und Berechtigungen.
Vielen Dank für eure Einblicke!
Das Gespräch führte Monika Spisak, ipt Marketing
Über mich
Als Senior Consultant entwickle ich Cloud-native Plattformlösungen, die durch Integration, Automatisierung und Skalierbarkeit nachhaltigen Mehrwert für Unternehmen schaffen.
Über mich
Als Principal Architect bei ipt liegt mein technischer Schwerpunkt bei Cloud-native Technologien, Kubernetes sowie Cloud-native Security.