Was ist OpenBao?
OpenBao ist ein quelloffener Secrets Manager und ein Fork von HashiCorp Vault, betreut unter der OpenSSF der Linux Foundation. Er verwahrt die Zugangsdaten, die deine Systeme brauchen, gibt sie an die richtigen Aufrufer heraus und hält fest, wer was verlangt hat.
Wer weiss, was Vault tut, weiss damit auch, was OpenBao tut, über dieselbe API. Für alle anderen lohnt sich der Einstieg über das Problem.
Das Problem, das ein Secrets Manager löst
Jedes System hält Zugangsdaten: Datenbankpasswörter, API-Schlüssel, Zertifikate, Tokens zwischen Diensten. Irgendwo müssen sie liegen. Die üblichen Orte scheitern alle auf dieselbe Art.
In einer Konfigurationsdatei im Repository. Damit hat jede Person, die es je geklont hat, produktive Zugangsdaten, und jede, die das Repository später bekommt, ebenfalls. Die Datei zu löschen entfernt sie nicht aus der Historie.
In Umgebungsvariablen, die das Deployment setzt. Besser, aber jetzt liegen sie in der Konfiguration des CI-Systems, sichtbar für alle, die eine Pipeline bearbeiten dürfen, und ausgegeben von jedem Prozess, der bei einem Fehler seine Umgebung ausschreibt.
In einer Tabelle, einem Passwortmanager oder im Kopf einer einzelnen Person. Bei fünf Leuten geht das. Bei fünfzig nicht mehr, und einer Revision lässt sich damit gar nichts beantworten.
Allen dreien ist dasselbe gemeinsam: ein Zugangsdatum, das einmal an einem geteilten Ort steht, lässt sich nicht mehr entteilen. Du weisst nicht, wer es hat. Du kannst es nicht rotieren, ohne jede Kopie zu finden. Und wenn jemand geht, rotierst du entweder alles oder du nimmst hin, dass die Person es weiterhin besitzt.
Ein Secrets Manager macht aus Zugangsdaten etwas, das Anwendungen zur Laufzeit abholen, statt etwas, das sie im Voraus mitbekommen. Diese eine Verschiebung ist die Voraussetzung für alles Weitere: Zugriff lässt sich pro Anfrage prüfen, pro Identität vergeben, protokollieren und entziehen.
Was er darüber hinaus leistet
- Dynamische Zugangsdaten. Statt ein Datenbankpasswort zu hinterlegen, erzeugt OpenBao eines, wenn eine Anwendung danach fragt, gültig für ein kurzes Fenster, und räumt es danach wieder ab. Ein Zugangsdatum, das eine Stunde existiert, kann nicht ein Jahr lang lecken.
- Encryption as a Service. Anwendungen schicken Daten zum Verschlüsseln hin und bekommen Chiffrat zurück, ohne den Schlüssel je in der Hand zu halten. Der Schlüssel bleibt dort, wo die Anwendung ihn nicht verlieren kann.
- PKI. Interne Zertifikate ausstellen und erneuern, was sonst eine Tabelle ist und einmal im Jahr ein Ausfall.
- Audit. Jeder Zugriff protokolliert. Das ist meistens der Punkt, an dem aus "wir sollten" ein "wir müssen" wird, weil eine Compliance-Anforderung ihn direkt benennt.
Warum es das Projekt als Fork gibt
Vault war quelloffen unter der MPL. HashiCorp wechselte die Lizenz auf die BSL, die keine Open-Source-Lizenz ist. OpenBao wurde daraufhin von der letzten MPL-Version abgezweigt und liegt heute bei der OpenSSF der Linux Foundation, mit einer Governance aus der Community statt aus einem einzelnen Unternehmen.
Die API-Kompatibilität zu Vault bleibt erhalten, bestehende Integrationen, Werkzeuge und Abläufe funktionieren also weiter.
Für die meisten Organisationen ist die praktische Frage enger als die lizenzphilosophische: ob die Bedingungen von heute noch gelten, wenn die Nutzung wächst, und wer darüber entscheidet. Ein von einer Stiftung getragenes Projekt beantwortet das anders als ein Projekt mit einem einzigen Anbieter dahinter. Welche Antwort dir lieber ist, ist eine echte Wahl, und der Punkt dieses Abschnitts ist, dass es eine Wahl ist: einmal getroffen und später teuer zu revidieren.
Wann du einen brauchst
- Mehr als eine Handvoll Dienste, bei denen Zugangsdaten zwischen Systemen weitergereicht statt von Menschen eingetippt werden.
- Alles, worauf eine Revision schaut. "Wer konnte das Passwort der Produktionsdatenbank lesen, und wann?" ist ohne so ein System keine beantwortbare Frage.
- Kurzlebige Infrastruktur. Container und Autoscaling-Gruppen entstehen und verschwinden; Zugangsdaten ins Image zu backen überlebt das nicht.
- Jemand ist gegangen und ihr musstet alles rotieren. Einmal reicht als Lektion.
Wann noch nicht
Eine einzelne Anwendung mit zwei Zugangsdaten braucht das nicht. Der eingebaute Secret-Speicher deiner Plattform ist ein vernünftiger Anfang, und einen Secrets Manager einzuführen, bevor es Secrets zu verwalten gibt, ist Infrastruktur um ihrer selbst willen.
Wenn niemand den Betrieb übernimmt, wird daraus ein einzelner Ausfallpunkt für jeden Dienst, der daran hängt, und das ist schlimmer als das Problem, das er ersetzt hat.
Was der Betrieb verlangt
Hier trennt sich der Proof of Concept von etwas, worauf du dich verlassen kannst.
- Unsealing. Der Speicher ist im Ruhezustand verschlüsselt und muss nach jedem Neustart entsiegelt werden. Wie das ohne Menschen um drei Uhr nachts geschieht, ist eine Entwurfsentscheidung, und es ist die erste, die aufgeschoben wird. Dazu unten mehr, denn für regulierte Organisationen landet genau hier auch die Hardwarefrage.
- Es wird zu kritischer Infrastruktur. Wenn Anwendungen ihre Zugangsdaten beim Start abholen und der Dienst steht, startet nichts mehr. Hochverfügbarkeit hört in dem Moment auf, optional zu sein, in dem der zweite Dienst angebunden wird.
- Backups, und die Recovery Keys. Die Daten zu sichern genügt nicht; die Wiederherstellung hängt zusätzlich an Schlüsselmaterial, das getrennt, sicher und mehr als einer Person bekannt aufbewahrt wird.
- Policies, die richtig bleiben. Zugriffskontrolle ist nur so gut wie die Policies, und Policies sammeln sich an. Ohne Review driften sie ins Freizügige, und das ist die Richtung, die sich nicht von selbst meldet.
- Das Audit-Log ist ein Beweismittel. Also gehört es an einen Ort, an dem es nicht von denen bearbeitet werden kann, über die es Auskunft gibt.
Wo die Schlüssel wirklich liegen, und HSMs
Für die meisten Organisationen wird die Unsealing-Frage in Software beantwortet, und damit hat es sich. Für regulierte nicht, denn die Revision fragt nicht "ist es verschlüsselt", sondern "wo existiert das Schlüsselmaterial physisch, und wer könnte es herausholen".
Darauf antwortet ein Hardware Security Module. Ein HSM ist eigens dafür gebaute Hardware, die Schlüsselmaterial hält und Operationen damit ausführt, ohne den Schlüssel je wieder herauszugeben. Software kann es bitten, etwas zu entschlüsseln; sie kann es nicht um den Schlüssel bitten.
OpenBao unterstützt das direkt: der PKCS#11-Seal konfiguriert ein HSM als Auto-Unseal-Mechanismus, und die Dokumentation führt Anleitungen je Hersteller, darunter eine für das Securosys Primus HSM. Das ist hier relevant, weil Securosys ein Schweizer Anbieter ist. Wer OpenBao gewählt hat, um Secrets unter Schweizer Jurisdiktion zu halten, kann den Schlüssel, der sie schützt, in Schweizer Hardware legen statt nur in ein Schweizer Rechenzentrum.
Hier zahlt sich der Fork am deutlichsten aus. HashiCorps eigene Dokumentation hält fest, dass Auto-Unseal und Seal Wrapping für PKCS11 Vault Enterprise voraussetzen. In OpenBao ist dieselbe Fähigkeit eine gewöhnliche Seal-Konfiguration, in einem Projekt ganz ohne Lizenzkosten. Wenn ein HSM bei dir eine Compliance-Anforderung ist, ist dieser Unterschied kein Rundungsfehler im Vergleich, sondern für viele Organisationen der ganze Vergleich.
Zwei Unterschiede zu HashiCorp Vault Enterprise gehören vor die Migrationsplanung, und beide sind dokumentiert und nicht zufällig. OpenBao verlangt, dass das Schlüsselmaterial extern erzeugt wird, bevor die Instanz initialisiert wird; es erzeugt keines selbst. Und es unterstützt ausschliesslich AEAD-fähige Algorithmen, keine Encrypt-Then-MAC-Konstruktionen. Keines von beiden ist ein Hindernis, und beide sind die Art von Detail, die einen Nachmittag kostet, wenn man ihr während der Migration begegnet statt davor.
Ob du das alles brauchst, ist eine Compliance-Frage und keine technische. Hat niemand gefragt, wo der Schlüssel liegt, genügt Unsealing in Software, und ein HSM ist Aufwand und Betriebskomplexität, gekauft ohne Anforderung dahinter.
Wo VSHN ins Bild kommt
Wir betreiben OpenBao auf Schweizer Cloud-Infrastruktur, mit beantworteten statt aufgeschobenen Fragen zu Unsealing, Verfügbarkeit, Backup und Audit, und übernehmen die Migration von HashiCorp Vault, falls du von dort wegkommst. Unser Vergleich stellt OpenBao neben Vault und die Alternativen, und die Compliance-Seite ordnet es den CIS Controls zu.
Wenn bei dir noch offen ist, ob du überhaupt einen brauchst, ist das das Gespräch, das zuerst lohnt.