OpenBao Implementation and Operation

Das Problem

Secrets Management ist jener Teil der Plattforminfrastruktur, von dem alle abhängen und den niemand verantworten möchte. Am Ende steht eine Mischung aus CI-Variablen, in Eile committeten Kubernetes Secrets, einer Tabelle, die angeblich nur vorübergehend existiert, und einer Vault-Instanz, die jemand installiert hat, der das Unternehmen inzwischen verlassen hat.

Zwei Entwicklungen haben die Lage zuletzt verschärft. Der Wechsel von HashiCorps Vault zur Business Source License hat die Bedingungen verändert, unter denen viele Organisationen ihre Secrets-Plattform betrieben haben, und eine Neubewertung angestoßen, die die meisten Teams nicht abschließen konnten. Zugleich haben NIS2 und DORA aus dem Umgang mit Zugangsdaten, der Schlüsselhoheit und der Nachvollziehbarkeit von Zugriffen Fragen gemacht, die Sie mit Nachweisen statt mit Absichten beantworten müssen.

OpenBao ist die Open-Source-Antwort auf das erste Problem: ein Projekt der Linux Foundation, API-kompatibel zu den Vault-Versionen, die die meisten Organisationen einsetzen, und echtes Open Source – Sie können es einsehen, überall betreiben und wieder verlassen. Was es nicht mitbringt, ist eine Implementierung.

Was wir bauen

Eine produktionsreife Secrets-Plattform, keinen Proof of Concept.

• OpenBao hochverfügbar ausgerollt, mit dem Storage-Backend Ihrer Wahl, Auto-Unseal und einem getesteten Wiederherstellungspfad

• Authentifizierungsmethoden, die zur Arbeitsweise Ihrer Organisation passen: OIDC für Menschen, Kubernetes Service Accounts für Workloads, AppRole oder JWT für Pipelines

• Secret Engines für Ihre tatsächlichen Anwendungsfälle: statische Key-Value-Secrets, dynamische Datenbank-Zugangsdaten, PKI für interne Zertifikate, Transit-Verschlüsselung dort, wo Anwendungen nie einen Schlüssel halten sollten

• Policies als Code, in Ihren Repositories, wie jede andere Änderung reviewt – Zugriff wird zum Pull Request statt zum Ticket

• Workload-Integration: das Secrets-Operator- oder Agent-Injector-Muster, das zu Ihrer Plattform passt, sodass Anwendungen Secrets erhalten, ohne dass Entwickler je eines in der Hand halten

• Audit Devices konfiguriert und an Ihren bestehenden Logging-Stack angebunden, mit einer Aufbewahrung, die Ihren Pflichten entspricht

• Schlüsselhoheit und Break-Glass bewusst geregelt, dokumentiert und geprobt statt vorausgesetzt

Wenn Sie von Vault migrieren

Wir inventarisieren Ihren heutigen Bestand, bilden Engines, Policies und Consumer ab und planen eine Migration, die Consumer in Wellen überführt statt einen Stichtagswechsel zu versuchen. Wo ein Vault-Enterprise-Feature kein OpenBao-Äquivalent hat, sagen wir es Ihnen vorher und nicht hinterher.

Ablauf

Optional: Wir betreiben es

Secrets Management ist ein Dienst, der um drei Uhr nachts verfügbar sein muss und in der Woche gepatcht wird, in der ein CVE erscheint. Wenn Sie diese Rufbereitschaft nicht selbst besetzen möchten, betreiben wir den Dienst mit vereinbartem Service Level: Upgrades, Security Response, Zertifikats- und Schlüsselrotation, Verfügbarkeitsüberwachung und Incident Response – bei vollem Zugriff Ihres Teams und der Möglichkeit, den Betrieb jederzeit zurückzuholen.

Das ist optional und wird separat kalkuliert. Die Implementierung steht für sich und ist so ausgelegt, dass Ihr Team sie ab der Übergabe selbst betreiben kann.

Für wen es gedacht ist

Für Organisationen, die einen ungesteuerten Secrets-Bestand ablösen, ihre Position nach der Vault-Lizenzänderung neu bewerten oder Secrets Management im Rahmen eines Plattformaufbaus erstmals sauber aufsetzen. Besonders wertvoll dort, wo der Umgang mit Zugangsdaten von einer Engineering- zu einer Audit-Frage geworden ist.

Wie es weitergeht

Die meisten Kunden schließen eine Open-Source-Assurance-Vereinbarung an, die OpenBao und die übrigen Komponenten ihres kritischen Pfads abdeckt, oder übergeben uns den Day-2-Betrieb, während sich ihr Plattformteam auf Developer Experience konzentriert.