OpenBao skaliert die Secrets-Verwaltung waagerecht Lesende Standby-Knoten entlasten den aktiven Server

Von Thomas Joos 2 min Lesedauer

Anbieter zum Thema

Passwörter, API-Token und Zertifikate gehören nicht in Konfigurationsdateien. OpenBao verwaltet solche Geheimnisse zentral. Die Lösung geht aus einem Fork von HashiCorp Vault hervor. Die neueren Versionen lösen eine alte Grenze der Architektur und verteilen Lesezugriffe auf mehrere Knoten im Cluster.

OpenBao: skaliert die Secrets-Verwaltung waagerecht(Bild:  Thomas Joos)
OpenBao: skaliert die Secrets-Verwaltung waagerecht
(Bild: Thomas Joos)

OpenBao speichert und verteilt sensible Daten wie Datenbank-Zugänge, kryptografische Schlüssel und Zertifikate und vergibt kurzlebige, dynamische Geheimnisse mit Leasing und Rücknahme. Das Projekt entstand 2023 aus dem letzten unter der MPL 2.0 stehenden Stand von HashiCorp Vault, nachdem der Hersteller Vault auf eine restriktive Lizenz umgestellt hatte. Administratoren binden OpenBao in Automatisierung und CI/CD-Pipelines ein, damit Dienste ihre Zugangsdaten zur Laufzeit abrufen und nicht dauerhaft in Dateien ablegen. Heute läuft OpenBao unter dem Dach der Linux Foundation und als Sandbox-Projekt der OpenSSF, gesteuert von einem technischen Komitee mit Vertretern von SAP, GitLab und weiteren Firmen.

Von Vault zur Community-Version

Die API-Kompatibilität zu Vault bleibt weit erhalten, sodass bestehende Integrationen und Clients ohne großen Umbau weiterarbeiten. Zugleich öffnet das Projekt Funktionen, die bei Vault der kostenpflichtigen Enterprise-Version vorbehalten waren. Dazu gehören Namespaces für die mandantenfähige Trennung, eine transaktionale Speicherung sowie Bausteine für Transit-Verschlüsselung, einen KMIP-Server und PKCS#11. Der offene Governance-Ansatz nimmt Anwendern das Risiko einer erneuten Lizenzänderung durch einen einzelnen Hersteller.

Lesende Standby-Knoten verteilen die Last

Von Vault erbte OpenBao eine hochverfügbare, aber nicht waagerecht skalierbare Architektur. Nur ein aktiver Knoten führte Schreibvorgänge aus, die Standby-Knoten blieben kalt und reichten jede Anfrage an den aktiven Knoten weiter. Der aktive Knoten wird damit zur Grenze für den Durchsatz, sobald viele Clients gleichzeitig Geheimnisse abrufen.

Die neueren Versionen führen lesefähige Standby-Knoten ein. Ein Standby beantwortet Lesezugriffe ohne Schreibvorgang, darunter Lesezugriffe auf den KV-Speicher und Teile der Zertifikatsausstellung, nun lokal und leitet nur schreibende Vorgänge an den aktiven Knoten weiter. Beim Raft-Backend sorgt der Write-Ahead-Log für eine asynchrone Invalidierung der Caches entlang der Speicherpfade, damit die verteilten Knoten konsistente Daten liefern. In der Praxis teilen sich mehrere Knoten die Leselast, was den Durchsatz erhöht und die Latenz senkt. Für das PostgreSQL-Backend kündigt das Projekt eine vergleichbare Verteilung über einen gRPC-Stream an, und für Schreibvorgänge steht eine Skalierung je Namespace auf der Roadmap.

Fazit

OpenBao bietet Rechenzentren eine herstellerneutrale Verwaltung für Geheimnisse mit breiter Vault-Kompatibilität. Die lesefähigen Standby-Knoten heben eine langjährige Grenze der Architektur auf und verteilen Lesezugriffe über den Cluster. Für Umgebungen mit vielen Clients und hoher Frequenz an Abrufen wächst die Verwaltung damit über einen einzelnen aktiven Knoten hinaus.

(ID:50909652)

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu RZ- und Server-Technik

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung