Passwörter und Geheimnisse begegnen dem Administrator längst nicht nur bei Benutzerzugängen und ihrem Zugriff auf Dienste und Plattformen. Sie sind stattdessen ständige Begleiter des Alltags: Dienste benötigen für die Kommunikation untereinander Passwörter oder andere Token, der automatisierte Zugriff auf Services etwa im Rahmen von CI/CD-Pipelines verlangt ebenfalls eine Authentifizierung und auch Datenbanken geben ihren Inhalt erst nach erfolgreicher Kombination aus Login und Passwort frei.

Ein anderer Trend ist jener hin zur Automatisierung. Doch besonders gut harmonieren Authentifizierung und Automatisierung nicht miteinander: Sicher- heitsexperten stellen sich die Nackenhaare bei der Vorstellung auf, dass Passwörter im Klartext beispielsweise Bestandteil eines Git-Verzeichnisses sind, nur um zur Verfügung zu stehen, wenn aus einem Verzeichnis heraus automatisiert eine CI/CD-Pipeline gefüttert werden soll. Doch die flinke Welt der IT reagiert zügig auf neue Anforderungen mit Tools und Werkzeugen, die das Verwalten von Passwörtern in automatisierter, sicherer und maschinell lesbarer Art und Weise ermöglichen. Zur Riege dieser Werkzeuge gehört Hashicorps Vault. Ursprünglich als digitaler Passwortspeicher mit API gestartet, beherrscht die Anwendung heute eine Vielzahl von Funktionen, um alle Arten von Geheimnissen digital zu verwalten und zu speichern, zu verwalten und zu teilen.

Die meisten Admins kennen Vault bereits, haben von seinen Fähigkeiten allerdings kaum eine realistische Vorstellung. Gerade im Kontext der Automa- tisierung entfaltet die Software ihre volle Schlagkraft. Grund genug, genauer hinzusehen: Wie funktioniert Vault unter der Haube, wie lassen sich seine Fähigkeiten im Kontext des Speicherns von Passwörtern nutzen, wie wird das Tool zur ausgefeilten SSL-CA?

Bevor wir in medias res gehen, steht ein kleiner Abschnitt Theorie in Sachen Authentifizierung auf dem Plan. Denn sonst ist ein umfassendes Verständnis der Möglichkeiten von Vault in Sachen Automatisierung kaum möglich. Ursprünglich konzipiert war Vault eigentlich als Passwortmanager für digitale Umgebungen. Damit hat das Werkzeug im Kern Ähnlichkeiten mit Ansible Vault, mit dem es trotz der Namensgleichheit aber keinesfalls zu verwechseln oder zu vergleichen ist. Ansible Vault ermöglicht, Passwörter in einer verschlüsselten Datei in einem Git- oder lokalen Verzeichnis so abzuspeichern, dass Ansible sie direkt lesen und nutzen kann.

Der Zugriff auf die verschlüsselte Datei setzt allerdings voraus, dass der Ansible-Admin dabei auch das zugehörige Passwort eingibt. Alternativ wäre es zwar möglich, das Passwort auch über die Kommandozeile als Parameter beim Aufruf zu übergeben, das aber bringt früher oder später wieder das Problem mit sich, dass der Aufruf samt Passwort in Logdateien oder einem Git-Verzeichnis im Klartext landet. So gesehen wäre durch den Einsatz von Ansible Vault in Umgebungen mit hohem Grad an Automatisierung also im Grunde nichts gewonnen.

Hashicorp Vault [1] leistet deutlich mehr und will eine zentrale Komponente im Authentifizierungsverfahren sein. Das galt schon ganz am Anfang, als Vault "nur" ein Key-Value-Speicher für Passwörter war. Die Idee dahinter ist, dass IT-Verantwortliche, statt Passwörter irgendwo im Klartext zu hinterlegen, diese in einem sicheren Tresor (englisch Vault) ablegen und den Zugriff auf diesen mittels verschiedener Methoden einschränken. Dies umfasst einerseits eine Authentifizierung bei der Anmeldung an Vault selbst, andererseits aber auch eine Rollenverwaltung in dem Tool, die nicht jedem Nutzer automatisch den Zugriff auf alle hinterlegten Geheimnisse ermöglicht. Eine große Rolle spielt zudem der Augenblick, da ein Dienst von extern Zugangsdaten aus Vault ausliest: Das geschieht nämlich nicht mehr mittels Login und Passwort, sondern im Regelfall über einen eigens hierfür ausgestellten Token.

Ein Token ist üblicherweise ein Zugangsschlüssel zu einem Dienst, der zeitlich begrenzt gültig ist und regelmäßig erneuert werden muss. Er ersetzt in den meisten Szenarien die klassische Kombination aus Benutzernamen und Passwort. Um einen Token zu bekommen, meldet sich ein Benutzer zunächst API-basiert bei einem Dienst wie Vault unter Verwendung seiner Credentials an. Vault stellt dann einen Token aus, den der Client erhält. Der Token ist dabei zweckgebunden. Er ermöglicht im Normalfall das Verwenden eines spezifischen Diensts, ohne sich bei diesem nochmals mittels Passwort und Benutzername einzuloggen. Es gibt verschiedene Varianten und viele Dienste, etwa jene der Cloudplattform OpenStack, weisen einem Token auch einen "Scope" zu, der es Anwendungen ermöglicht, Art und Umfang der erteilten Rechte selbst zu interpretieren.

Viel wichtiger ist bei Token aber die Möglichkeit, diese mit einem Ablaufdatum zu versehen und ad hoc zu revidieren. Weil der Geltungsbereich eines Tokens obendrein eingeschränkt ist, lässt er sich mit deutlich weniger Gefahren weitergeben, etwa im Quelltext einer Automationsumgebung. Hat ein Dienst oder eine Software eine native Anbindung an Vault, lässt sich das Passwort sogar direkt in diesem abspeichern und landet dann im Regelfall verschlüsselt auf einem Datenträger, taucht also gar nicht mehr im Klartext auf.

Der eigentliche Mehrwert von Vault besteht also in seiner Stellung als zentraler Tresor für Zugangsdaten. Diese lassen sich auf der API-Ebene automatisiert abfragen und ermöglichen es anderen Anwendungen, die Zugangsdaten zu einem bestimmten Dienst dynamisch und während der Laufzeit anzufordern, statt sie im Klartext zu hinterlegen. Maßgeblich verantwortlich für diesen Arbeitsablauf ist in Vault heute der "KVV2", oder "Key Value v2"-Speicher, der zuständig für das Speichern von Geheimnissen aller Art ist.

KVV2 ist ein komplexes Biest, weil seine Entwickler anders als beim Vorgänger hier Themen wie Hochverfügbarkeit und verteilte Installationen eingebaut haben. Entsprechend braucht Vault für KVV2 einen Konsensalgorithmus im Hintergrund, ab Werk nutzt die Software dafür das weitgehend wartungsfreie Raft-Protokoll. Alternativ lässt sich Hashicorp Consul [2] einsetzen. Zwar gibt es noch weitere Backends, doch diese sind ohne praktische Relevanz, zumal Hashicorp kommerziellen Support nur für Raft und Consul leistet und Raft dabei präferiert. Wer Vault dann in den nötigen drei Instanzen betreibt, schaltet idealerweise noch einen Loadbalancer vor.

Auch wenn in diesem Artikel vorrangig von Passwörtern die Rede ist, versteht sich Vault eher als allgemeiner Speicher für Geheimnisse aller Art. Dieser Grundsatz hilft dabei, gedanklich nicht auf die schiefe Bahn zu geraten und das Tool vorrangig als Ersatz für Apps wie KeePassX oder 1Password zu betrachten. Auch die speichern längst nicht mehr nur Passwörter, sondern beliebige Informationen, sind aber auf den Einsatz auf Desktops und portablen Geräten getrimmt. Vault versteht sich stattdessen als verschlüsselter Speicher für Key-Value-Wertepaare, in dem sich beliebige Informationen sicher und zugangsbeschränkt ablegen lassen.

Vault lässt sich in mehreren Varianten betreiben. Der Hersteller bietet dafür seine Hashicorp Cloud Platform (HCP), die mannigfaltige Verwaltungswerkzeuge bereitstellt, um diverse Vault-Installationen parallel zu verwalten. So kompliziert (und kostenpflichtig) muss es aber nicht sein, denn die Software läuft auch problemlos lokal. Steht das Setup aus drei Vault-Knoten und Loadbalancer, geht es das Einrichten der Umgebung. Nach dem Erstellen eines Administrators hat dieser die Möglichkeit, in Vault verschiedene Benutzer ebenso wie verschiedene Richtlinien für das Speichern und Verwenden von Passwörtern zu hinterlegen. Es sei an dieser Stelle auf die offizielle Dokumentation [3] verwiesen, die eine Vielzahl möglicher "First Steps" aufzeigt und ihre jeweiligen Auswirkungen erläutert. Dabei kommt vor allem das Vault-CLI zum Einsatz, das letztlich aber auch nur mit der API im Hintergrund kommuniziert. Weil dies mittels HTTPS und ReST geschieht, erklärt sich auch, wieso für einen verteilten Vault-Cluster ein Loadbalancer zwar nicht zwingend nötig, wohl aber sehr sinnvoll ist.

Vault kommt mit einer großen Anzahl von Funktionen, die den Zugriff auf Zugangsdaten steuern. So bietet das Werkzeug etwa eine ACL-Funktion, die den Zugriff auf die "Secrets Engine" regelt, den eigentlichen Tresor in Vault.

Control Groups bieten eine weitere Möglichkeit, zusätzliche Authentifizierungswege vorzuschreiben, etwa via Zweifaktor-Authentifizierung (2FA). Besonders ausgefuchst ist das Sentinel-Modul, mit dem sich Role Governing Policies (RGP) und Endpoint Governing Policies (EGP) definieren lassen. Diese Richtlinien definieren bis auf kleinste Parameter hinunter die Bedingungen für das Ausstellen von Policies ebenso wie deren zeitliche Beschränkung, erlaubte Nutzer und so weiter. Wer sich mit Vault noch gar nicht befasst hat, erlebt hier allerdings eine recht steile Lernkurve.

Es überrascht nicht, dass es aus der Open-Source-Community heraus diverse Ansätze und Bestrebungen gibt, die eigene Software mit Vault kompatibel zu machen. Gerade Werkzeuge für Automation und Orchestrierung profitieren von einer solchen Verbindung. Ein hervorragendes Beispiel dafür ist Ansible. Wie beschrieben kommt Ansible eigentlich mit einem eigenen Passworttresor, der aber nicht annähernd so mächtig ist wie Hashicorp Vault. Entsprechend hoher Beliebtheit erfreut sich das aktuell vor allem von der Community entwickelte "vault"-Modul für Ansible. Es beherrscht eine große Menge Features und kann Benutzer in Vault anlegen oder löschen, Policies definieren, Einträge in Vault hinterlegen oder diese mittels "hashi_vault_lookup" abfragen. Wer also ein wichtiges Passwort für die eigene Infrastruktur in Vault ablegt, greift auf dieses aus Ansible heraus nahtlos zu, ohne es im Klartext irgendwo zu hinterlegen.

Andere Automatisierer stehen dem Prinzip in nichts nach. Für Puppet etwa gibt das "vault_lookup::lookup"-Modul. Dieses leistet Vergleichbares wie "hasi_vault_lookup" in Ansible. Integrationen existieren obendrein für Saltstack oder Chef. Wer sich in die Welt der Orchestrierer vorwagt, findet auch hier umfassenden Vault-Support an verschiedenen Stellen: Dass Terraform etwa nahtlos kooperiert, wundert nicht, schließlich stammt es vom selben Hersteller. Ebenso nahtlos lässt Vault sich aber auch mit AWS CloudFormation oder Azure integrieren.

Wer ein Interesse an einheitlicher Benutzerverwaltung und Authentifizierung hat, kommt bei Vault ebenfalls auf seine Kosten. Denn die Software lässt sich an Google Cloud Auth, AWS IAM oder Azure Auth anschließen und behandelt diese dann als "Trusted Party". Im Klartext: Nutzer, die sich bei einem der genannten Dienste anmelden können, dürfen sich auch in Vault anmelden. Wer ohnehin einen dieser Dienste nutzt, etabliert so eine nahtlose Zugriffskontrolle für alle in Vault hinterlegten Daten, weil der Tresor praktisch keine eigene Benutzerverwaltung mehr benötigt.

Und im Kontext der Hyperscaler lässt sich das Spiel noch eine Stufe eskalieren: Vault bietet für Cloudanbieter dynamische Credentials. Sind beispielsweise AWS IAM und Vault integriert, können hierzu auf der Vault-Ebene (etwa durch Policy oder ACL) berechtigte Nutzer Zugangsdaten für AWS dynamisch beantragen. Vault erstellt diese dann in IAM automatisiert auf Grundlage der vorgegebenen Richtlinien. Sehen diese etwa vor, dass Passwörter eine beschränkte Gültigkeit haben, legt das Tresor-Tool dies in AWS IAM an. Im Anschluss händigt es die IAM-Zugangsdaten an den Client aus, sodass dieser damit auf AWS zuzugreifen kann.

Von zentraler Bedeutung für moderne Automation per CI/CD ist die Integration von Vault in ebensolche Systeme. Hier ist insbesondere das seitens der Community entwickelte Plug-in [4] für Jenkins ein echtes Highlight. Ist das Modul in Jenkins aktiviert, lässt sich durch den Administrator unmittelbar eine Verbindung zu Vault herstellen und Jenkins erhält Zugriff auf die darin abgelegten Credentials.

Das Jenkins-Plug-in sorgt im Gegenzug dafür, dass bei etwaigen Ausgaben von CI/CD-Pipelines Passwörter so markiert sind, dass sie nicht versehentlich beispielsweise in Logs auftauchen. In einer Pipeline kann der Entwickler dann einfach auf Zugangsdaten in Vault referenzieren, ohne diese explizit zu benennen. Vergleichbare Integrationen existieren für andere Anwendungen, etwa für GitLab oder ArgoCD. Verwiesen sei an dieser Stelle zudem auf die Liste der Vault-Integrationen auf der Website des Herstellers [5]. Dort erfahren Sie auch, dass sich Vault beispielsweise aus Kubernetes heraus nahtlos nutzen lässt.

Unterstützung in Sachen Automation bietet Vault auch noch in eine andere Richtung. Beinahe jedes Unternehmen, dass intern mit SSL arbeitet, benötigt dafür früher oder später eine lokale SSL Certificate Authority (SSL-CA). Das hat durchaus Vorteile: Beim Verteilen des eigenen CA-Zertifikats auf alle Maschinen einer Installation lassen sich lokal beliebige SSL-Zertifikate ausstellen, denen die jeweiligen Systeme dann vorbehaltlos vertrauen. Und das Ausrollen der SSL-CA stellt bei gängigen Automationstools wie Ansible oder Puppet heute keine Herausforderung mehr dar. Das Problem liegt eher in Betrieb und Pflege einer lokalen SSL-CA, denn diese sind aufwendig, zumal eine sinnvolle Toolchain hierfür kaum existiert. Viele Unternehmen werkeln mit Behelfslösungen wie TinyCA herum, auch diese sind aber eher nicht zufriedenstellend.

Wer ohnehin Vault im Unternehmen einsetzt, kann stattdessen effizient und leicht auf dessen CA zugreifen und die Verwaltung der eigenen SSL-CA auf diese Weise weitgehend automatisieren. Hierzu bringt unser Tool eine eigene "PKI Engine" mit, deren Verwendung relativ simpel ist. Stellen Sie sicher, dass Sie als Benutzer mit hinreichenden Rechten auf Vault zugreifen, idealerweise mit einer zugewiesenen Administratorenrolle. Für die nötigen Schritte nutzen Sie das Vault-CLI, dieses sollte also über die Umgebungsvariablen "VAULT_ADDR", "VAULT_TOKEN" und "VAULT_NAMESPACE=admin" so eingerichtet sein, dass "vault status" den Zustand des Vaults ausgibt, in dem Sie die CA einrichten wollen. Dann genügen drei Befehle, um die CA aufzusetzen und nutzbar zu machen:

Bei "common_name" setzen Sie idealerweise den Domänennamen der Firma oder Organisation, für die Sie Vault als SSL-CA aufsetzen. Schon hier wird deutlich, wie mächtig Vault im Einsatz als SSL-CA ist, denn mit anderen Werkzeugen dauert allein das Aufsetzen des Root-CA-Zertifikats deutlich länger. Allerdings sind Sie mit dem Setup an dieser Stelle noch nicht ganz fertig, denn Vault setzt auch voraus, dass Sie eine Intermediate-CA einrichten, mit der Sie dann später die "CSR" (Certificate Signing Requests) der eigentlichen Endanwendungen gegenzeichnen – wobei sich auch dieser Teil mittels CLI gut automatisieren lässt. Ein passendes Zertifikat erhalten Sie nämlich einfach mittels

Die Ausgabe des Befehls enthält dann das eigentliche Zertifikat, das CA- samt Intermediate-Zertifikat sowie den dazugehörenden privaten Schlüssel.

Darüber hinaus lässt sich Vault in seiner Rolle als SSL-CA hervorragend automatisieren. Um etwa in einer lokalen Umgebung automatisiert SSL-Zertifikate für Dienste auszustellen, erledigen Sie das beispielsweise mittels curl-Befehl auf der Kommandozeile. Dafür müssen die Variablen "VAULT_TOKEN" und "VAULT_ NAMESPACE" einmal mehr gesetzt sein, dann liefert folgender Befehl die bereits beschriebenen Artefakte:

Unser Workshop demonstriert eindrucksvoll, dass Vault weit mehr ist als das, was heute allgemein unter einem Passwortmanager verstanden wird. Die Software lässt sich nahtlos und sicher in die Automatisierung einbinden. Dabei ist das Tool so beliebt, dass praktisch alle Automatisierungswerkzeuge von Bedeutung ein Plug-in oder ein Modul für eine nahtlose Integration vorhalten. Und als wäre das alles nicht schon genug, ist via Vault auch eine PKI einfach aus dem Hut gezaubert, sprich schnell und unkompliziert eingerichtet. Dabei muss es zudem nicht die nunmehr kostenpflichtige Variante sein, denn mit OpenBao stehen IT-Verantwortlichen alle in diesem Workshop aufgezeigten Funktionen frei zur Verfügung.