OpenBao, fork Vaulta i licencja MPL 2.0

OpenBao, fork Vaulta i licencja MPL 2.0

OpenBao to rozwidlenie HashiCorp Vaulta wykonane kilka commitów po wydaniu 1.14.8, czyli tuż zanim gałąź konserwacyjna Vaulta przeszła na Business Source License. Bieżące wydanie to 2.6.2 z 18 sierpnia 2026 roku, plik licencyjny nazywa się po prostu LICENSE i wciąż otwiera się notą Copyright (c) 2015 HashiCorp, Inc.. Ta nota nie jest przeoczeniem.

Skąd wziął się OpenBao

Punkt rozwidlenia jest udokumentowany co do commita, i to w miejscu, którego łatwo nie znaleźć: w pliku website/src/components/FAQSection/index.tsx, czyli w kodzie strony projektu, a nie w dokumentacji. Odpowiedź na pytanie o wersję Vaulta, z której powstał fork, mówi, że OpenBao został odgałęziony przed ostatnim commitem poprzedzającym BUSL, o skrócie 8993802, i że odpowiada to kilku commitom za wydaniem 1.14.8, ale przed wycięciem 1.14.9.

Ten opis da się sprawdzić niezależnie i wychodzi zgodnie. Plik LICENSE w repozytorium hashicorp/vault pod tagiem v1.14.8 zaczyna się od noty Copyright (c) 2015 HashiCorp, Inc. i zawiera Mozilla Public License w wersji 2.0. Ten sam plik pod tagiem v1.14.9 zaczyna się od noty o prawach MariaDB Corporation Ab do tekstu Business Source License. Vault 1.14.8 wyszedł 6 grudnia 2023 roku, a 1.14.9 dopiero 31 stycznia 2024 roku. OpenBao złapał więc ostatnie wydanie na licencji otwartej i odgałęził się z kodu tuż za nim.

Kolejność zdarzeń nie jest liniowa i to bywa źródłem nieporozumień. Vault 1.15.0 ukazał się 27 września 2023 roku i był już na BSL. Gałąź 1.14.x jeszcze przez cztery miesiące dostawała wydania na MPL, a przełączenie licencji dosięgło jej z opóźnieniem, przy 1.14.9. Ten sam zabieg objął starsze gałęzie: plik licencyjny pod tagiem v1.13.13 też jest już tekstem BSL. Ostatnim wydaniem Vaulta na licencji otwartej pozostaje więc 1.14.8, wydanie, które od dawna nie dostaje poprawek bezpieczeństwa.

Zarząd nad projektem zmieniał się dwa razy. OpenBao startował pod LF Edge, a 17 czerwca 2025 roku został przyjęty jako projekt piaskownicy do OpenSSF. Stopka strony projektu wciąż podpisuje się jako "OpenBao a Series of LF Projects, LLC", więc formalnie mamy do czynienia z projektem Linux Foundation prowadzonym dziś przez OpenSSF, a nie z osobną fundacją. Pierwsze wydanie ogólnie dostępne, 2.0.0, nosi na stronie wydania GitHuba datę 17 lipca 2024 roku, natomiast wpis ogłaszający je na blogu projektu jest datowany na 25 lipca 2024 roku. Rozbieżność ośmiu dni bierze się z tego, że tag został przepchnięty ponownie, o czym mówi sama notka wydania: pierwotny commit 7e0e830 zastąpiono commitem 700fe3f bez zmian w kodzie.

Skala projektu w dniu pisania: repozytorium openbao/openbao ma około 7,1 tysiąca gwiazdek, 544 rozgałęzienia, 244 otwarte zgłoszenia i 70 otwartych żądań scalenia.

Licencja OpenBao z trzech źródeł

Pierwsze źródło to plik w repozytorium. Pod tagiem v2.6.2 w katalogu głównym istnieje dokładnie jeden plik licencyjny, LICENSE, o rozmiarze 15958 bajtów i 365 wierszy. Warianty LICENSE.md, LICENSE.txt, license.md, COPYING, NOTICE i LICENSING.md zwracają 404. Katalogi api/ i sdk/, które są osobnymi modułami Go, nie mają własnych plików licencyjnych. Zawartość to nota autorska HashiCorp z 2015 roku, po niej pełny tekst Mozilla Public License w wersji 2.0, aż po Załącznik A i Załącznik B. Nagłówki plików źródłowych, na przykład w sdk/logical/storage.go i version/version_base.go, niosą dwie linie: // Copyright (c) HashiCorp, Inc. oraz // SPDX-License-Identifier: MPL-2.0.

Zachowanie noty poprzednika nie jest niedopatrzeniem, tylko wymogiem samej licencji: MPL 2.0 nakazuje utrzymanie istniejących not autorskich w kodzie objętym licencją. Ten sam ruch wykonał Valkey, zostawiając w pliku COPYING notę Redis Ltd. Praktyczny wniosek jest identyczny w obu przypadkach: obecność cudzej noty autorskiej w forku nie mówi nic o tym, kto dziś prowadzi projekt.

Druga rzecz warta uwagi w tym pliku to Załącznik B. MPL 2.0 przewiduje możliwość oznaczenia kodu jako "Incompatible With Secondary Licenses", co odcina łączenie go z kodem na GPL, LGPL i AGPL. W repozytorium OpenBao ten załącznik występuje wyłącznie jako część standardowego tekstu licencji, a nigdzie nie jest dołączony jako nota do kodu. Kod jest więc zwykłym MPL 2.0, zgodnym z licencjami wtórnymi.

Drugie źródło to rejestr pakietów, i tu robi się nietypowo. OpenBao jest projektem w Go, więc rejestrem jest proxy modułów. Modułów jest kilka, a ich ścieżki się rozjeżdżają. Główny moduł serwera to nadal github.com/openbao/openbao, bez przyrostka /v2, mimo że wydania noszą numery 2.x. Konsekwencja jest taka, że proxy w ogóle nie potrafi wydać wersji 2.6.2 dla tego modułu i zwraca komunikat o niepoprawnej wersji, bo go.mod ma ścieżkę bez /v2. Zapytanie o wersję najnowszą zwraca pseudowersję v0.0.0-20260714213526-4771dc118499. Biblioteki klienckie mają już poprawne ścieżki: github.com/openbao/openbao/api/v2 w wersji 2.6.0 z 22 czerwca 2026 roku oraz github.com/openbao/openbao/sdk/v2 w wersji 2.6.2 z 22 lipca 2026 roku. Numeracja trzech modułów nie idzie równo z numeracją serwera.

W tym samym rejestrze wiszą wersje wycofane, i to całą listą. Plik go.mod zawiera dyrektywę retract [v0.1.0, v1.17.0], która unieważnia wszystkie numery odziedziczone po Vaulcie. Pamięć podręczna proxy nadal wypisuje te wersje, od v0.1.0 po v1.15.5, choć odpowiadające im tagi zostały z repozytorium usunięte i pobranie którejkolwiek kończy się błędem o nieznanej rewizji. Warto to sprawdzić przed audytem zależności, bo lista wersji modułu wygląda tak, jakby OpenBao wydał kiedyś wersję 1.15.5, czego nigdy nie zrobił.

Pole license w tym rejestrze po prostu nie istnieje: format go.mod nie ma takiego pola. Narzędzie zbierające metadane musi więc sięgnąć do pliku, a nie do rejestru.

Trzecie źródło to zawartość opublikowanej paczki. Archiwum modułu github.com/openbao/openbao/api/v2 w wersji 2.6.0 pobrane z proxy zawiera 70 plików, w tym 57 plików .go i łącznie 423762 bajty rozpakowanej treści, więc kod tam jest, a nie sam opis. W archiwum leży plik LICENSE o rozmiarze 15958 bajtów, czyli dokładnie takim samym jak plik w katalogu głównym repozytorium, i z taką samą treścią, od noty HashiCorp po tekst MPL 2.0. Sam katalog api/ w repozytorium tego pliku nie ma, więc trafia on do archiwum przez mechanizm modułów Go, który dokłada najbliższy nadrzędny plik licencyjny.

# trzecie zrodlo: co naprawde jest w opublikowanej paczce
curl -sO https://proxy.golang.org/github.com/openbao/openbao/api/v2/@v/v2.6.0.zip
unzip -l v2.6.0.zip | grep -i license
unzip -p v2.6.0.zip 'github.com/openbao/openbao/api/v2@v2.6.0/LICENSE' | head -3

Co z tego wynika dla firmy. MPL 2.0 to copyleft na poziomie pliku. Możesz uruchamiać OpenBao w produkcji, oferować go klientom jako usługę hostowaną, konkurować z kimkolwiek, sprzedawać wsparcie i zamykać własny kod, który z nim rozmawia. Jeśli zmodyfikujesz pliki objęte licencją, te pliki musisz udostępnić na MPL 2.0. Nie ma progu liczby użytkowników, progu przychodu, daty przekształcenia ani zgody dostawcy. Sekcja odpowiedzi na stronie projektu mówi wprost, że nie ma planów zmiany licencji kodu źródłowego, i wskazuje klauzulę patentową MPL 2.0 jako powód wyboru tej licencji.

Osobna rzecz, którą trzeba znać przed pierwszym żądaniem scalenia. Plik CONTRIBUTING.md zawiera sekcję o polityce wobec kodu na licencjach źródłowo dostępnych: zabrania kopiowania z jakiegokolwiek źródła objętego licencją źródłowo dostępną, w tym Business Source License 1.1, i wymienia z nazwy wszystkie repozytoria w organizacji HashiCorp na GitHubie. Praca nad parytetem funkcji ma się odbywać metodą czystego pokoju. Do tego dochodzi obowiązkowy podpis DCO oraz ostrzeżenie, żeby na czas pracy nad OpenBao wyłączyć wszystkie generatywne narzędzia wspomagające pisanie kodu.

Co stało się z Vaultem

Vault jest dziś na Business Source License 1.1 i wygląda to inaczej, niż w innych projektach z tej licencji. Przy SurrealDB parametry BSL są ustalane osobno dla każdej wersji. Tutaj jest jeden wpis zbiorczy.

Rozbieżność w wierszu Licensor jest realna i sprawdzalna: plik licencyjny pod tagiem ostatniego wydania wskazuje HashiCorp, a plik na gałęzi głównej wskazuje IBM. Podmiana nazwy licencjodawcy weszła do gałęzi po wycięciu tagu 2.0.4. Jeśli w firmie prowadzisz rejestr licencji zależności, wpisz tam wersję z tagu, którego faktycznie używasz.

Pole Licensed Work brzmi "Vault Version 1.15.0 or later", więc obejmuje wszystko od 1.15.0 wzwyż jednym zdaniem, bez osobnych parametrów na wydanie. Change Date jest sformułowana jako reguła, a nie data: cztery lata od publikacji danej wersji. Każde wydanie przechodzi więc na MPL 2.0 w swoją własną rocznicę. Vault 1.15.0 ukazał się 27 września 2023 roku, więc stanie się kodem na MPL 2.0 27 września 2027 roku, czyli za nieco ponad rok licząc od dziś. Wydanie 2.0.4, opublikowane 4 sierpnia 2026 roku, przejdzie na MPL dopiero w sierpniu 2030 roku.

Additional Use Grant jest tym parametrem, który realnie rozstrzyga, czy wolno Ci używać Vaulta. Zezwala na użycie produkcyjne pod warunkiem, że nie oferujesz Licensed Work osobom trzecim na zasadzie hostowanej lub osadzonej w sposób konkurujący z płatnymi wersjami Vaulta. Tekst licencji sam definiuje pojęcia, których używa. Oferta konkurencyjna to produkt sprzedawany osobom trzecim odpłatnie, w tym w formie płatnych umów wsparcia, którego możliwości istotnie pokrywają się z możliwościami płatnych wersji Vaulta. Jest klauzula ochronna: jeśli Twój produkt nie był ofertą konkurencyjną w chwili udostępnienia, nie staje się nią później tylko dlatego, że do Vaulta dołożono nowe funkcje. Produkty nieodpłatne nie są konkurencyjne z definicji. Osadzenie oznacza włączenie kodu źródłowego albo wykonywalnego do oferty konkurencyjnej, a także takie jej spakowanie, że Vault musi zostać pobrany, żeby ta oferta działała. Hostowanie i używanie Vaulta na własne potrzeby wewnątrz organizacji nie jest ofertą konkurencyjną, a za organizację uważa się także wszystkie podmioty powiązane pod wspólną kontrolą.

Nie ma tu progu liczby użytkowników ani progu przychodu. Granicą jest rodzaj użycia, nie skala. Bank z dwudziestoma tysiącami pracowników może trzymać Vaulta wewnętrznie bez żadnego licencjonowania. Dwuosobowa firma, która sprzedaje hostowanego Vaulta z płatnym wsparciem, tego zrobić nie może. Sama licencja odsyła po wiążącą wykładnię do strony z odpowiedziami dostawcy, więc w przypadkach granicznych to nie jest lektura na własną rękę.

Poza Additional Use Grant zostają ogólne warunki BSL 1.1: wolno kopiować, modyfikować, tworzyć dzieła zależne, redystrybuować i używać nieprodukcyjnie. Użycie produkcyjne bierze się wyłącznie z tego jednego akapitu.

Zgodność polityk, klientów i danych

Projekt ma spisaną politykę zgodności, ratyfikowaną 8 lutego 2024 roku, która rozbija problem na trzy warstwy. To jest lepszy punkt wyjścia niż pytanie "czy da się przesiąść".

Warstwy układają się hierarchicznie: zgodność pieczęci implikuje zgodność magazynu, a ta implikuje zgodność API. Notka wydania 2.0.0 mówi, że OpenBao jest w pełni zgodny z API Vaulta 1.14.9 i zgodny na poziomie pieczęci dla tych wtyczek, które projekt wspiera. Polityki dostępu pozostają tym samym formatem opartym na ścieżkach, więc pliki polityk przenoszą się bez przepisywania.

Klienty to inna sprawa i tu jest pierwsza pułapka. Zmienne środowiskowe zostały przemianowane z przedrostka VAULT_ na BAO_. W pliku api/client.go w wersji 2.6.0 nie ma ani jednego odwołania do zmiennej z przedrostkiem VAULT_, a dokumentacja poleceń wymienia wyłącznie warianty BAO_. Ciekawostka dla czytających kod: identyfikatory w Go nadal nazywają się EnvVaultAddress, EnvVaultToken i tak dalej, zmieniły się tylko wartości.

# konfiguracja klienta przechodzi na przedrostek BAO_
export BAO_ADDR=https://bao.example.com:8200
export BAO_TOKEN=s.xxxxxxxxxxxxxxxx
export BAO_NAMESPACE=zespol-platformy
export BAO_CACERT=/etc/openbao/ca.pem
export BAO_CLIENT_TIMEOUT=60s
bao status

Import biblioteki w Go zmienia się razem ze ścieżką modułu: zamiast github.com/hashicorp/vault/api bierzesz github.com/openbao/openbao/api/v2. To znaczy, że własne integracje wymagają rekompilacji, a nie tylko podmiany adresu.

Dane i sama instalacja to warstwa najbardziej wymagająca. Projekt publikuje przewodnik migracji w miejscu i wprost podaje, w jakich warunkach był testowany: Vault w wersji 1.14.1 w wydaniu społecznościowym, OpenBao 2.2.0, magazyn Raft i pieczęć Shamira, czyli bez automatycznego odpieczętowania. Ograniczenia są wyliczone bez owijania. Jeśli Twój Vault jest starszy niż 1.14.1, najpierw podnieś go do 1.14.1. Jeśli jest w wersji 1.15.0 lub nowszej, ten przewodnik nie zadziała. Jeśli Vault został zainicjowany na wersji starszej niż 1.3, prawdopodobnie trzeba przekluczyć instancję, bo tamta implementacja podziału sekretu Shamira została z OpenBao usunięta.

Do tego dochodzą dwie zmiany, które trzeba zaplanować przed przełączeniem. Format tokenów jest inny: OpenBao wystawia tokeny w postaci [sbr].<losowe>, a Vault używa dłuższych o przedrostkach hvs, hvb i hvr. Stare tokeny są honorowane do końca swojego czasu życia, ale nowe mają już inny kształt, więc konsumenci, którzy walidują format tokena wyrażeniem regularnym, popsują się po cichu. Druga zmiana to disable_mlock: OpenBao nie używa mlock od wersji 2.0.0, a pozostawiona opcja w konfiguracji jest błędem. Jeśli używasz pliku dziennika audytu, po zatrzymaniu Vaulta trzeba przekazać ten plik użytkownikowi, na którym działa OpenBao.

# migracja klastra Raft: najpierw wszystkie repliki, na koncu lider
systemctl stop vault && systemctl start openbao
bao operator raft join https://vault-03.example.com:8200
bao operator unseal
bao operator raft list-peers   # czekaj az kolumna Voter pokaze true

Wtyczki wbudowane i zewnętrzne

Największa różnica funkcjonalna nie leży w rdzeniu, tylko w tym, co jest w binarce. Plik helper/builtinplugins/registry.go w Vaulcie 1.14.8 wymienia 55 nazw wtyczek, przy czym część z nich figuruje tam ze statusem przestarzałej lub usuniętej. Ten sam plik w OpenBao 2.6.2 wymienia 25 nazw.

Zwróć uwagę na jeden wpis, którego w Vaulcie nie ma: valkey-database-plugin. OpenBao ma osobne wtyczki dla Redisa i dla Valkeya, co po historii z tamtym rozwidleniem brzmi znajomo. Wsparcie dla PostgreSQL zostało w binarce, i to zarówno jako silnik poświadczeń dynamicznych, jak i jako backend magazynu.

To, co wypadło z binarki, nie zniknęło z projektu. Repozytorium openbao/openbao-plugins dostarcza wtyczki zewnętrzne uruchamiane jako osobne procesy komunikujące się przez gRPC: uwierzytelnianie przez AWS, Azure, GCP i GitHub, silniki sekretów AWS, Azure, GCP, GCPKMS, Nomad i Consul, sterownik bazodanowy MongoDB oraz sześć wtyczek automatycznego odpieczętowania, w tym AliCloud KMS, AWS KMS, Azure Key Vault, Google Cloud KMS, OCI KMS i OVHcloud KMS. System wtyczek rozróżnia cztery typy: secret, auth, database i kms. Wtyczki deklaratywne rejestruje się w pliku konfiguracyjnym serwera i mogą być pobierane z rejestru OCI, a katalog wtyczek dostępny przez API obsługuje wszystkie typy poza kms, bo ten jest potrzebny przed odpieczętowaniem.

Cena tego układu jest oczywista: to, co u Vaulta było jednym poleceniem secrets enable aws, tutaj jest zadaniem dla osoby utrzymującej wdrożenie. Zysk też jest oczywisty: binarka jest mniejsza, a cykl wydawniczy wtyczek odłączony od cyklu serwera.

Co OpenBao dołożył po rozwidleniu

Wydanie 2.0.0 nie wniosło wielkich nowości, bo służyło ustabilizowaniu forka, zmniejszeniu binarki i wystawieniu podpisów artefaktów. Nie miało nawet interfejsu graficznego, który wrócił dopiero później. Jedyną większą funkcją były listy stronicowane: żądania LIST przyjmują opcjonalne parametry after i limit, co ogranicza rozmiar odpowiedzi przy dużych zbiorach kluczy.

Później tempo wzrosło. Z rzeczy, które są w gałęzi 2.x i których w Vaulcie 1.14 nie było: magazyn transakcyjny w Raft, przestrzenie nazw, rekurencyjne listowanie, konfiguracja deklaratywna, klucze XChaCha20-Poly1305 w silniku transit, miękkie usuwanie kluczy w transit, wybór formatu eksportu kluczy przez format=der albo format=pem, parametr token_strictly_bind_ip wiążący token ze źródłowym adresem żądania oraz usunięcie mlock z rdzenia.

Wydanie 2.6.0 z 14 lipca 2026 roku dołożyło cztery rzeczy warte nazwania. Pieczętowanie przestrzeni nazw pozwala przy tworzeniu przestrzeni zbudować dodatkową pieczęć Shamira i osobny pęk kluczy bariery, dzięki czemu najemca może odciąć operatorowi instancji dostęp do swojej przestrzeni przez zapieczętowanie, nie ruszając pozostałych. Nowy typ wtyczki kms w pliku konfiguracyjnym wypycha mechanizmy automatycznego odpieczętowania do binariów zewnętrznych. Przepływy pod sys/workflows pozwalają operatorowi złożyć wieloetapowe żądania łączące różne wtyczki. Doszedł też wariant obrazu kontenera oparty na distroless, w którym jedynym plikiem wykonywalnym jest sam OpenBao, oraz uwierzytelnione punkty sys/generate-root-token zastępujące dawne nieuwierzytelnione. Projekt podaje, że w to wydanie wkład wniosło 42 nowych współtwórców.

Zapowiedzi na 2.7.0 obejmują grupy kontrolne z udziałem człowieka w zatwierdzaniu operacji, klucze zewnętrzne jako przeprojektowanie enterprise'owych kluczy zarządzanych oraz skalowanie poziome na PostgreSQL. To są zapowiedzi, nie wydany kod.

Skąd wziąć OpenBao

Binarka nazywa się bao, a na Windows bao.exe, i jest jedynym plikiem potrzebnym do uruchomienia serwera. Instalacja przez menedżery pakietów obsługuje Homebrew na macOS, pkg na FreeBSD, pacman w Arch Linux razem z osobnymi pakietami wtyczek, oraz EPEL dla Fedory i RHEL. Projekt utrzymuje też pakiety dla Amazon Linux, Debiana, Fedory, RHEL i Ubuntu, dostępne przez własne repozytoria i do bezpośredniego pobrania.

# Arch Linux, razem z lista dostepnych wtyczek
pacman -Sy openbao
pacman -Ss ^openbao-plugin

# Fedora i RHEL przez EPEL
dnf install -y epel-release
dnf install -y openbao

# obraz kontenera, trzy rejestry do wyboru
podman pull ghcr.io/openbao/openbao
podman pull quay.io/openbao/openbao
podman pull docker.io/openbao/openbao

Obrazy kontenerów są publikowane w trzech rejestrach naraz, co jest wygodne, jeśli Twoja polityka wewnętrzna wyklucza któryś z nich. Podstawowy wariant bazuje na Alpine Linux, wariant openbao-ubi na RHEL UBI, a od 2.6.0 doszedł wariant distroless. Dla Kubernetes jest wykres Helm.

Strony pobierania i ekosystemu na witrynie projektu nie renderują się bez JavaScriptu: surowy HTML zawiera tylko komunikat o pobieraniu informacji o wydaniach z GitHuba, więc listy plików i wdrożeń nie da się z nich odczytać poleceniem wiersza poleceń. Z potwierdzonych wdrożeń produkcyjnych blog projektu wymienia przyjęcie OpenBao jako magazynu sekretów przez EdgeX Foundry oraz prelekcję o użyciu w GitLabie. Nie udało się potwierdzić, żeby którykolwiek z dużych dostawców chmurowych oferował zarządzaną usługę OpenBao, więc traktuj to jako lukę, a nie jako fakt w którąkolwiek stronę.

Jeśli składasz platformę samodzielnie, OpenBao siada obok reszty warstwy operacyjnej bez niespodzianek: terminacja TLS przez Traefika albo Caddy'ego, a wstrzykiwanie sekretów do aplikacji uruchamianych przez Coolify wymaga własnego kroku, bo takie panele nie mają natywnej integracji z OpenBao.

Typowe błędy

Pierwszy: założenie, że VAULT_ADDR i VAULT_TOKEN będą działać. Nie będą. Klient bao czyta wyłącznie zmienne z przedrostkiem BAO_, więc skrypty operacyjne wymagają przejrzenia przed migracją, a nie po.

Drugi: planowanie migracji przy założeniu, że silniki aws, azure czy gcp są w binarce. Nie ma ich tam. Trzeba je zarejestrować jako wtyczki zewnętrzne, co oznacza dodatkowe binaria do dystrybucji i dodatkowy krok w konfiguracji serwera.

Trzeci: próba migracji w miejscu z Vaulta 1.15.0 lub nowszego. Dokumentacja mówi wprost, że przewodnik tego nie obsługuje. Realną drogą zostaje przeniesienie sekretów przez API albo pozostanie przy Vaulcie.

Czwarty: zostawienie disable_mlock w pliku konfiguracyjnym. OpenBao nie używa mlock od 2.0.0 i ta opcja jest błędem konfiguracji, a nie ignorowanym reliktem.

Piąty: go get github.com/openbao/openbao w nadziei na wersję 2.6.2. Główny moduł serwera nie ma przyrostka /v2, więc proxy odmawia i zwraca pseudowersję. Biblioteki kliente bierze się ze ścieżek api/v2 i sdk/v2.

Szósty: przekonanie, że można zostać na Vaulcie 1.14.8, bo to ostatnie wydanie na MPL. Formalnie tak, praktycznie nie: to wydanie z grudnia 2023 roku bez dalszych poprawek bezpieczeństwa, a menedżer sekretów jest ostatnim komponentem, w którym opłaca się siedzieć na kodzie sprzed dwóch lat.

Siódmy: czytanie BSL jako zakazu użycia komercyjnego. Additional Use Grant Vaulta pozwala na użycie produkcyjne i wewnątrzfirmowe bez opłat. Granica biegnie przy sprzedawaniu Vaulta osobom trzecim jako oferty hostowanej lub osadzonej.

Kiedy OpenBao się nie opłaca

Jeśli Twoje wdrożenie stoi na funkcjach Vault Enterprise, OpenBao ich nie odtworzy. Notka wydania 2.0.0 mówi to wprost, a polityka zgodności wskazuje, dlaczego: replikacja, opakowywanie pieczęci i część funkcji silników są niedostępne do odtworzenia bez inżynierii wstecznej, której projekt sobie zabronił własną polityką czystego pokoju.

Jeśli potrzebujesz umowy wsparcia z egzekwowalnym czasem reakcji, projekt piaskownicy OpenSSF jej nie da. Model finansowania to praca społeczności i firm członkowskich, nie kontrakt.

Jeśli Twoje narzędzia wokół sekretów zakładają Vaulta z nazwy, przygotuj się na tarcie. Część operatorów Kubernetes, wtyczek do systemów ciągłego dostarczania i modułów infrastruktury jako kodu odwołuje się do adresów, zmiennych i nazw wtyczek Vaulta. Zgodność API pomaga, ale nie zdejmuje pracy z przejrzenia integracji jedna po drugiej.

I na koniec rzecz, o której łatwo zapomnieć przy porównywaniu funkcji: baza wdrożeń produkcyjnych OpenBao jest wciąż mniejsza niż Vaulta, a materiałów, wpisów o awariach i gotowych odpowiedzi na nietypowe problemy jest odpowiednio mniej. Przy komponencie, który potrafi zatrzymać całą platformę, to jest realny koszt.

FAQ

Czy OpenBao jest darmowy do zastosowań komercyjnych?

Tak, bez zastrzeżeń. MPL 2.0 nie ma progu liczby użytkowników, progu przychodu, daty przekształcenia ani klauzuli o ofertach konkurencyjnych. Możesz sprzedawać hostowanego OpenBao. Jedyny obowiązek pojawia się, gdy modyfikujesz pliki objęte licencją: te pliki udostępniasz na MPL 2.0.

Z której wersji Vaulta powstał OpenBao?

Z kodu kilka commitów za wydaniem 1.14.8, przed wycięciem 1.14.9, przy commicie o skrócie 8993802. To ostatni stan przed przełączeniem gałęzi 1.14.x na BSL. Sprawdzisz to, porównując plik LICENSE w repozytorium hashicorp/vault pod tagami v1.14.8 i v1.14.9.

Czy moje polityki i klienty Vaulta zadziałają bez zmian?

Polityki tak, są tym samym formatem opartym na ścieżkach. Klienty nie do końca: zmienne środowiskowe mają przedrostek BAO_ zamiast VAULT_, a biblioteka Go ma inną ścieżkę importu. Samo wywoływanie API jest zgodne na poziomie deklarowanym dla Vaulta 1.14.9.

Czy da się zmigrować istniejący klaster bez przenoszenia sekretów ręcznie?

Da się, ale w wąskim zakresie: przewodnik migracji w miejscu był testowany na Vaulcie 1.14.1 z magazynem Raft i pieczęcią Shamira, a dla Vaulta 1.15.0 i nowszego wprost nie obowiązuje. Poza tym oknem zostaje przeniesienie sekretów przez API.

Kiedy Vault stanie się znowu kodem na licencji otwartej?

Każda wersja osobno, cztery lata od swojej publikacji, i wtedy przechodzi na MPL 2.0. Vault 1.15.0 z 27 września 2023 roku przejdzie na MPL 27 września 2027 roku. Wydanie 2.0.4 z sierpnia 2026 roku dopiero w sierpniu 2030 roku.

Czy OpenBao ma wszystkie wtyczki, które ma Vault?

Nie. W binarce jest 25 nazw wtyczek wobec 55 w Vaulcie 1.14.8. Silniki chmurowe, consul, nomad i większość sterowników bazodanowych trzeba doinstalować jako wtyczki zewnętrzne z repozytorium openbao/openbao-plugins.