OpenFGA v1.21.0 to wzorzec dla pytania, na które logowanie nigdy nie odpowiada: czy ten technik może dotknąć obiektu tego klienta?

OpenFGA v1.21.0 to wzorzec dla pytania, na które logowanie nigdy nie odpowiada: czy ten technik może dotknąć obiektu tego klienta?

Rzeczywistość MSP to wiele dzierżaw (tenantów) klientów, technicy z różnymi delegacjami u poszczególnych klientów i integracje maszynowe, które działają samodzielnie. Po uwierzytelnieniu prawdziwe pytanie brzmi: „czy ten podmiot może wykonać tę akcję na tym obiekcie w tej dzierżawie?”. Token, claim grupy czy zdarzenie wylogowania na to nie odpowiadają; odpowiada punkt decyzyjny. Omawiany tu projekt jest wzorcem referencyjnym, a nie rekomendacją: OpenFGA, repozytorium openfga/openfga, Apache-2.0, projekt CNCF Incubating od 28 października 2025 r. (przyjęty 14 września 2022 r.), opisywany przez opiekunów jako wydajny silnik autoryzacji i uprawnień inspirowany Google Zanzibar.

5 października 2026 r. repozytorium na GitHubie miało 5920 gwiazdek, a ostatni push nastąpił 2 października 2026 r. Wydanie v1.21.0, opublikowane 20 września 2026 r., wymienia jedną nowość, Dynamic Conditions, którą projekt oznacza jako eksperymentalną. 6 października 2026 r. pojawiło się nowsze wydanie, v1.22.0. Ten artykuł nie twierdzi, że jakikolwiek produkt Altovar korzysta z OpenFGA.

Dalsza część tekstu omawia, jak autoryzacja oparta na relacjach przekłada się na strukturę dzierżaw MSP, jakie dowody przypięcia wersji i łańcucha dostaw dają wydania, czym OpenFGA nie jest (polityką dopuszczania, nakładką sieciową, skanerami) oraz sześć kontroli dla każdego centralnego punktu decyzyjnego. Logowanie, wylogowanie i ważność tokenu to dane wejściowe; uprawnienie jest decyzją podejmowaną przy każdym żądaniu.

Według opisu i tematów (topics) repozytorium OpenFGA to silnik autoryzacji i uprawnień inspirowany Google Zanzibar. Tematy wymieniają kontrolę dostępu opartą na relacjach obok RBAC, ABAC i dostępu opartego na politykach, a także „entitlements”. Ten artykuł trzyma się tych źródeł: nie podaje macierzy funkcji, danych o przepustowości ani opóźnieniach, ani listy użytkowników.

ReBAC w stylu Zanzibar oznacza, w języku kupującego, że uprawnienia wynikają z relacji między podmiotami i obiektami (kto jest członkiem której dzierżawy, która lokalizacja należy do której dzierżawy, który technik ma delegację do której lokalizacji), a nie z długiej listy ról kopiowanej do każdego tokenu. Decyzja przechodzi po grafie relacji. Nie wkleja katalogu ról do każdego JWT.

Zarządzanie według strony projektu w CNCF odczytanej 5 października 2026 r.: przyjęty do CNCF 14 września 2022 r., Incubating od 28 października 2025 r. Incubating to poziom dojrzałości w procesie fundacji. Nie jest to certyfikacja bezpieczeństwa ani umowa wsparcia. MSP, który traktuje „CNCF Incubating” jak „zaudytowane dla naszych klientów”, czyta etykietę fundacji jako gwarancję dla klienta, której ona nie daje.

5 października 2026 r. repozytorium miało 5920 gwiazdek na GitHubie i 511 forków. Gwiazdki to sygnał popularności, a nie ocena. Strona CNCF pokazuje osobne metryki LFX z inną liczbą gwiazdek; ten artykuł używa liczby z GitHuba i nie miesza tych dwóch źródeł. Licencja zadeklarowana w repozytorium to Apache-2.0.

Ostatnie wydania: v1.22.0 6 października 2026 r., v1.21.0 20 września 2026 r., v1.20.0 8 września 2026 r. i v1.19.0 25 sierpnia 2026 r. Żadne nie jest oznaczone jako wydanie wstępne. Zasada przypinania do powtarzania: uruchamiaj v1.21.0 lub nowszą i nic starszego, przy czym v1.22.0 jest lepszym celem dla nowych wdrożeń, bo zawiera aktualizację bezpieczeństwa jednej z zależności. Nie śledź w środowisku klienta ruchomego obrazu latest bez zgłoszenia zmiany, które wskazuje tag.

Dolna granica to nie po prostu „najnowsza”. v1.20.0 miała sekcję Security: poprawkę CVE w łańcuchu narzędzi, przebudowaną zależność sondy kondycji i poprawkę jednego komunikatu bezpieczeństwa OpenFGA w ścieżce ListUsers. Wszystko starsze niż v1.20.0 nie ma tych poprawek; v1.21.0 je zawiera. v1.22.0 dodaje kolejny wpis Security: zaktualizowaną bibliotekę gRPC, która usuwa GO-2026-6443. Zdanie, które MSP może wpisać do zgłoszenia, brzmi: „v1.20.0 przyniosła poprawki bezpieczeństwa, w tym jeden komunikat OpenFGA w ścieżce ListUsers; uruchamiać ≥ v1.21.0, najlepiej v1.22.0”.

Dynamic Conditions wymaga precyzyjnego sformułowania. Informacje o wydaniu v1.21.0 opisują ją jako „nową funkcję eksperymentalną” (tłumaczenie własne): eksperymentalna, nie ogólnodostępna. Logika uprawnień klientów nie powinna zależeć od funkcji eksperymentalnej, chyba że klient wyraźnie i na piśmie akceptuje to ryzyko.

Dowody wydania, które MSP może dołączyć do zgłoszenia zmiany, zgodnie z tym, co podano przy wydaniach v1.21.0 i v1.22.0: oba są oznaczone jako niezmienne (immutable), a każde zawiera podpisane pliki sum kontrolnych, atestację in-toto i SBOM dla każdego archiwum binarnego. Te dowody potwierdzają, że wdrożony artefakt odpowiada temu, co opublikował projekt, i że masz listę komponentów. Nie są audytem kodu ani twojego modelu autoryzacji.

Pytanie, zapisane raz i używane wielokrotnie: podmiot · akcja · obiekt · dzierżawa. Technik, konto partnera, użytkownik klienta i integracja maszynowa to cztery rodzaje podmiotów. „Odczyt”, „zmiana”, „eksport” i „usunięcie” to różne akcje. Urządzenie, skrzynka pocztowa, zestaw kopii zapasowych to obiekty. Każdy obiekt należy do dokładnie jednej dzierżawy klienta. Na to czteroczęściowe pytanie samo zdarzenie logowania nigdy nie odpowiada.

Relacje zamiast kopiowanych ról: dzierżawa zawiera lokalizacje lub organizacje; zasoby należą do lokalizacji; technik jest powiązany z lokalizacją delegacją, która może być ograniczona w czasie; administrator klienta jest powiązany tylko z własną dzierżawą. Punkt decyzyjny ustala „czy ten technik może zmienić tę skrzynkę pocztową?”, przechodząc po tych relacjach.

Dlaczego to pomaga MSP: uprawnienie opuszcza token i tysiące rozproszonych sprawdzeń if w kodzie aplikacji i staje się jednym miejscem, które można przejrzeć, przetestować i rejestrować. Odebranie technikowi delegacji u jednego klienta to usunięcie jednej relacji, a nie ponowne wydanie tokenów we wszystkich aplikacjach. Zmiana ma właściciela i ślad audytowy w jednym magazynie.

Ramy obronne: domyślna odmowa, najmniejsze uprawnienia i sprawdzenie przy każdym żądaniu (OWASP Authorization Cheat Sheet). Wadliwa kontrola dostępu (broken access control), w tym dostęp do obiektów innej dzierżawy, to klasa błędów, którą ten wzorzec ma ograniczać. Wylogowanie lub sygnał odwołania może wywołać ponowne sprawdzenie; punkt decyzyjny to miejsce, w którym ono następuje. Dlatego samo wylogowanie nie jest też odwołaniem na poziomie dzierżawy.

Gatekeeper i Kyverno to polityki dopuszczania (admission) w Kubernetes dla obiektów infrastruktury. Decydują, czy manifest może trafić do klastra, a nie czy technik może czytać skrzynkę pocztową klienta. Żadne z nich nie zastępuje drugiego. MSP, który myli politykę dopuszczania z uprawnieniami aplikacji, umieści niewłaściwą kontrolę w niewłaściwej warstwie.

OpenZiti to nakładka sieciowa zero trust. Decyduje, które tożsamości mogą dotrzeć do których usług w sieci; nie decyduje o uprawnieniach aplikacji do poszczególnych obiektów. Osiągalność w sieci i uprawnienie do obiektu to różne bramki.

Trivy, Syft i DefectDojo to skanery, generatory SBOM i narzędzia do agregacji wyników. Opisują, co jest w twoim oprogramowaniu i co jest z nim nie tak. Nie autoryzują żądań.

Ten artykuł nie twierdzi, że Auris ani żaden inny produkt Altovar używa, osadza lub integruje OpenFGA. OpenFGA jest przywołany jako otwartoźródłowy wzorzec referencyjny dla scentralizowanej autoryzacji.

Sześć kontroli obronnych dla każdego centralnego punktu decyzyjnego, każda z opisem tego, co jest dowodem, a co nim nie jest.

Po pierwsze, inwentarz: jakie magazyny i modele autoryzacji istnieją, osobne dla klientów czy wspólne, i kto może je zmieniać. Dowodem jest wyeksportowana lista i właściciel każdego modelu. „Używamy ReBAC” nie jest dowodem. Po drugie, przypięcie wersji: ≥ v1.21.0 zapisane w zgłoszeniu zmiany, z dołączonym wynikiem weryfikacji sum kontrolnych i atestacji. Liczba gwiazdek czy tag latest nie są dowodem.

Po trzecie, chroń samo API decyzyjne: tylko uwierzytelnieni wywołujący, dostęp wyłącznie z warstwy aplikacji, operacje administracyjne ograniczone do imiennie wskazanych operatorów z MFA. Po czwarte, zmiany modelu to zmiany kodu: przeglądane, wersjonowane i testowane przed wdrożeniem z jawnymi przypadkami odmowy między dzierżawami. Dowodem jest przebieg testu pokazujący, że dzierżawa B nie może dotrzeć do obiektu dzierżawy A. „Model się kompiluje” nie jest dowodem.

Po piąte, twórz kopie zapasowe danych o relacjach i odtwarzaj je; przećwicz odtwarzanie. Punkt decyzyjny, który utracił relacje, zawodzi w trybie otwartym albo zamkniętym, a oba przypadki to awarie. Po szóste, rejestruj decyzje i zmiany modelu w SIEM jako sygnały operacyjne, np. nieoczekiwane zmiany modelu lub skoki liczby odmów po wydaniu. Na koniec: funkcje eksperymentalne trzymaj z dala od ścieżek uprawnień klientów, dopóki projekt nie zmieni ich statusu.

W skrócie: Apache-2.0; CNCF Incubating od 28 października 2025 r.; 5920 gwiazdek na GitHubie 5 października 2026 r.; minimalna wersja v1.21.0 (20 września 2026 r.), a lepszy cel to v1.22.0 (6 października 2026 r.); pod spodem są poprawki bezpieczeństwa z v1.20.0; Dynamic Conditions jest funkcją eksperymentalną. Gatekeeper, Kyverno, OpenZiti, Trivy, Syft i DefectDojo nie zastępują centralnego punktu decyzyjnego w aplikacji. Logowanie, wylogowanie i ważność tokenu to dane wejściowe; uprawnienie jest decyzją podejmowaną przy każdym żądaniu.

Ten artykuł nie twierdzi, że Auris korzysta z OpenFGA. Wzorzec jest otwartoźródłową architekturą referencyjną dla pytania MSP, na które samo uwierzytelnienie nigdy nie odpowiada.