Konfiguracja

Płaszczyzna kontrolna to jeden plik binarny Go, olivares, konfigurowany przez mały zbiór flag na podkomendzie serve i garść zmiennych środowiskowych — nie rozległy plik konfiguracji. Domyślne są dobrane, by zamykać się odrzucająco: loopbackowe bindy, TLS włączony, brak dostarczanych poświadczeń. Wszystko poniżej pochodzi z definicji poleceń pliku binarnego i korzenia kompozycji; tam, gdzie ustawienia nie można potwierdzić w źródle, nie jest tu wymienione.

Sekrety, które podłączają prawdziwe źródła i opiekują się prawdziwymi kluczami, pozostają w plikach trzymanych przez operatora lub zamontowanych sekretach odwoływanych przez zmienne środowiskowe — nigdy w magazynie. Dla ścieżki uruchomialnej end-to-end zobacz przewodnik self-host; dla pełnego listingu flag zobacz referencje CLI.

Podkomenda serve

olivares serve uruchamia serwer HTTP REST/web i serwer gRPC w jednym procesie, z konsolą webową serwowaną z tego samego origin co API. Oto typowe wejścia konfiguracyjne.

TLS jest domyślnie włączony. Bez dostarczonych --tls-cert/--tls-key silnik zapewnia samopodpisany certyfikat w katalogu danych raz, z góry, zanim jakikolwiek listener zaakceptuje połączenie — więc zarówno serwer HTTP jak i gRPC używają tego samego certyfikatu i żaden nie wraca do plaintextu. Gdy generuje ten certyfikat, loguje odcisk SHA-256, więc klienci mogą mu zaufać lub go przypiąć.

--insecure to jedyny sposób na serwowanie plaintextu, a ścieżka gRPC zamyka się odrzucając: poza --insecure serwer odmawia konstruowania listenera plaintext zamiast degradować cicho. Używaj go tylko wobec 127.0.0.1 podczas rozwoju lokalnego.

--seed-demo udostępnia demostracyjnego administratora z publicznym hasłem z drzewa źródeł i sfabrykowanymi danymi infrastruktury — tylko dla demo i E2E. Silnik odmawia uruchomienia jeśli któryś listener jest nie-loopbackowy. Użyj jednorazowego katalogu danych.

Drugi poziom flag zarządza rozproszonymi i wzajemno-TLS topologiami — --admin-dsn i --allow-privileged-db-role (Postgres), --grpc-client-ca (wzajemny TLS kolektora) i --region/--known-regions (rezydencja danych). Są opisane poniżej i wymienione w pełni w referencji CLI.

Zmienne środowiskowe

Silnik czyta małą liczbę zmiennych środowiskowych przy uruchomieniu. Te poniżej są potwierdzone w korzeniu kompozycji i podłączaniu.

Katalog danych i źródła

OLIVARES_SOURCES_CONFIG to jedyne wejście, przez które nie-demostracyjne źródła sygnałów i dostawcy rejestrów są rozwiązywani. To konfiguracja operatora zawierająca sekrety i jest celowo trzymana poza magazynem. Silnik czyta ją przy uruchomieniu i rejestruje każde źródło zanim runtime się uruchomi.

Obsługa jest uczciwa zamiast fail-fast. Brakująca zmienna, nieczytelny lub nieprawidłowy-JSON plik, lub skonfigurowana-ale-pusta lista źródeł — wszystko ostrzega i daje pustą konfigurację — silnik nigdy nie przerywa uruchomienia. Nieskonfigurowane źródło ujawnia ostrzeżenie zamiast crashować płaszczyznę lub udawać, że działa: z niczym podłączonym mapa dostępu po prostu pozostaje pusta. Aby ją wypełnić, skonfiguruj co najmniej jedno źródło — zobacz podłącz źródło i, dla ścieżki kooperacyjnej Claude Code, podłącz Claude Code.

Punkt decyzyjny autoryzacji

Natywna kontrola dostępu oparta na atrybutach i rolach zawsze zarządza. Zewnętrzny punkt decyzyjny polityki (PDP), gdy wybrany, jest dodatkową warstwą tylko-ograniczającą, która może tylko zawęzić decyzję, którą wbudowany RBAC już podjął — nigdy jej poszerzyć.

Dwa adaptery siedzą za jednym szwem — wbudowany ewaluator Cedar (ścieżka czystego Go) i adapter OPA-przez-HTTP. Jeśli OLIVARES_PDP_ENGINE wybiera silnik, ale jego konfiguracja jest nieprawidłowa (nieczytelny plik Cedar, zniekształcony cel OPA), silnik wyłącza tylko zewnętrzny PDP, utrzymuje natywny silnik ABAC i RBAC w egzekucji i loguje głośno. Zepsuty plik polityki nigdy nie pozostawia żądań bez zarządzania i nigdy nie crashuje płaszczyzny. Dla modelu domyślnego odrzucania zobacz zarządzanie.

Klucz podpisu audytu

Rejestr audytu jest tylko-do-dopisywania, z łańcuchem haszy i zakotwiczony podpisanymi checkpointami Ed25519. Klucz podpisu per-zdarzenie jest rozwiązywany przy uruchomieniu, zamykający się odrzucająco dla każdego źródła z opieką.

Bez żadnego z nich klucz jest tworzony przy pierwszym uruchomieniu w katalogu danych — uczciwy fallback jednowęzłowy / deweloperski. Dzielenie jednego klucza między replikami (przez wartość env lub zamontowany sekret) jest wymagane dla wysokiej dostępności: w przeciwnym razie każdy węzeł tworzy własny i rejestr rozwidla się przy failover. Podpisywanie per-zdarzenie zawsze pozostaje na maszynce. Opieka owinięta KMS (klucz zarządzany przez klienta) to dodatkowa postawa konfigurowana przez OLIVARES_KEY_WRAP; zobacz referencje CLI.

Wybór magazynu

Silnik wybiera swój magazyn z --engine.

SQLite jest domyślny i nie wymaga zewnętrznej usługi — to magazyn gotowy na air-gap, bez zależności dla topologii jednowęzłowej i ten, na którym działa jednopoleceniowe wdrożenie Docker Compose. Przejdź na Postgres gdy potrzebujesz izolacji wielodzierżawczej lub skali horyzontalnej, nie wcześniej.

Wybranie postgres włącza zabezpieczenie bezpieczeństwa na poziomie wierszy izolujące dzierżawców. Silnik odmawia uruchomienia wobec superusera Postgres lub roli BYPASSRLS — co wyłączałoby to zabezpieczenie — chyba że --allow-privileged-db-role jawnie nadpisuje strażnika (tylko jednoedzierżawczy / jednorazowy). Dla pełnych międzydzierżawczych odczytów System (listing organizacji, pokrycie checkpoint wielodzierżawczy) udostępnij dedykowaną rolę admin NOSUPERUSER BYPASSRLS przez --admin-dsn; bez niej te odczyty działają ograniczone przez RLS i mogą zwracać puste. OLIVARES_DB_MAX_CONNS ogranicza pulę aplikacji per-węzeł.

Wielodzierżawczość i rezydencja

Pojedyncza instancja jest wielodzierżawcza z konstrukcji na Postgres, z bezpieczeństwem na poziomie wierszy izolującym dane każdego dzierżawcy. Rezydencja danych jest nakładana na wierzch przez --region.

• Jednoregionowa (domyślna, bez --region): brak egzekucji rezydencji.
• Ograniczona do regionu (--region eu, --region us, …): instancja obsługuje tylko dzierżawców przypisanych do jej regionu domowego i odrzuca dostęp międzyregionowy zamykając się odrzucająco. --known-regions wymienia kody regionów prawidłowe w całym wdrożeniu; przypisanie dzierżawcy musi być jednym z nich, a zniekształcona konfiguracja regionu uniemożliwia uruchomienie zanim magazyn się otworzy.

Checkpointy audytu

--checkpoint-interval kontroluje jak często podpisany checkpoint jest zapisywany nad łańcuchem każdego dzierżawcy (domyślnie 1h; 0 wyłącza). Finalny checkpoint jest zapisywany przy czystym zamknięciu zanim magazyn się zamknie, więc łańcuch jest zakotwiczony przy zamknięciu również jak na interwale. Zobacz weryfikacja wydania jak podpisany łańcuch jest weryfikowany downstream.

Bezpieczne domyślne

Te postawy obowiązują bez konfiguracji poza serve. Są domyślną postawą produktu, nie opcjonalnym hartowaniem.

Loopbackowe bindy oznaczają, że silnik nie jest osiągalny poza hostem dopóki ich nie zmienisz. Gdy go opublikujesz — powiedzmy mapując port hosta w Docker Compose — TLS jest już włączony, by go chronić; nie łącz opublikowanego bind z --insecure. Na świeżej instalacji silnik drukuje blok FIRST-BOOT SETUP na stdout z jednorazowym tokenem konfiguracji (czytaj z logów kontenera pod Compose); administrator używa go do utworzenia pierwszego użytkownika, następnie uwierzytelnia się.

Co produkt obserwuje, gdzie zarządza i gdzie pokrycie jest warstwowe, przeczytaj uczciwości i ograniczenia.