Przejdź do treści

Tłumaczenie maszynowe. Wersja angielska jest wiążąca; weryfikacja przez native speakera jeszcze nie nastąpiła.

self-hosted

Samodzielne zarządzanie obok bramy aplikacji Claude: przewodnik po współwdrożeniu

Autor Olivares AI 9 min do przeczytania

Anthropic wysłał bramkę aplikacji Claude pod koniec czerwca 2026 roku. Jest to usługa samodzielnie hostowana, zawarta w pliku wykonywalnym claude (wersja 2.1.195+). Uruchamiasz ją za pomocą claude gateway --config gateway.yaml, tworzysz kopię zapasową za pomocą PostgreSQL, a ona stawia logowanie OIDC przed Twoją flotą Claude Code: sesje korporacyjnego IdP zamiast lokalnie zarządzanych kluczy API. To naprawdę znaczący krok naprzód. Dla zespołów, które uruchamiają Claude Code przeciwko Bedrock, Vertex, Foundry lub bezpośrednio API Anthropic, bramka centralizuje zarządzanie tożsamością, dostępem do modeli i kontrolą wydatków w jednym pliku konfiguracyjnym.

Ten post dotyczy tego, co dzieje się dalej. Twój majątek AI jest prawie na pewno większy niż Claude. Prawdopodobnie uruchamiasz serwery MCP od wielu dostawców. Możesz mieć obciążenia OpenAI lub Gemini, samodzielnie hostowane wnioski przez vLLM lub Ollama, pipeline’y CI, które nigdy nie widzą przeglądarki, oraz frameworki agentów, które delegują zadania między dostawcami. Bramka aplikacji jest tylko dla Claude i tylko dla OIDC. To decyzja dotycząca zakresu, a nie wada — ale oznacza, że pytanie dotyczące zarządzania jest tylko częściowo rozwiązane.

Model wspólnego wdrożenia opisany tutaj umieszcza samodzielnie hostowaną platformę zarządzania obok bramki, czytając zarówno telemetrię bramki, jak i resztę infrastruktury agentów. Komplementarne, a nie konkurencyjne: bramka obsługuje uwierzytelnianie, platforma obsługuje zarządzanie.

Co bramka aplikacji robi dobrze

Bramka rozwiązuje konkretny, ważny problem: zapewnia Claude Code odpowiednią warstwę tożsamości. Zanim istniała, każdy programista posiadał klucz API lub korzystał ze wspólnych poświadczeń, i nie było standardowego sposobu egzekwowania dostępu do modeli, limitów wydatków ani zarządzania ustawieniami na poziomie organizacyjnym.

Po wprowadzeniu bramki:

  • Programiści uwierzytelniają się przez dostawcę tożsamości OIDC (jeden wydawca na instancję bramki).
  • Grupy IdP są mapowane na listy dozwolonych modeli i polityki zarządzanych ustawień w gateway.yaml.
  • Limity wydatków są egzekwowane na użytkownika, grupę lub organizację, za pomocą API administratora limitów wydatków.
  • Telemetria jest rozprowadzana za pośrednictwem OTLP/HTTP, oznaczana user.id, user.email i user.groups.
  • Wydarzenia audytu (11 typów: config.load, session.mint, auth.denied, inference, itd.) są emitowane jako jednolinijkowy JSON na stderr.

Jest to dobrze zaprojektowana infrastruktura dla deklarowanego zakresu. Anthropic publikuje protokół bramki i zachęca do implementacji przez osoby trzecie, co jest niezwykle otwartym podejściem dla dostawcy modelu.

Czego to nie obejmuje

Anthropic dokumentuje następujące decyzje dotyczące zakresu w sposób jasny. Nie są to wady — definiują one, gdzie należy umieścić granicę współwdrożenia:

  • Tylko OIDC. Bez SAML, bez LDAP. Jeśli Twój IdP używa SAML, potrzebujesz mostka OIDC przed bramką.
  • Pojedynczy wydawca. Jeden dostawca OIDC na każdą instancję bramy. Wdrożenia wieloużytkownikowe wymagają oddzielnych instancji.
  • Tylko Claude. Katalog modeli zawiera modele Claude. OpenAI, Gemini, lokalna inferencja oraz inni dostawcy znajdują się poza zakresem bramy.
  • Brak przepływu tokenu usługi. Nieobsługiwane potoki CI/CD nie mają udokumentowanej interaktywnej ścieżki uwierzytelniania przez bramę.
  • Brak UI administratora. Konfiguracja odbywa się w pliku YAML; zmiany wymagają ponownego wdrożenia.
  • Brak wykresu Helm. Brama działa jako standardowe wdrożenie, ale nie ma pakietu wykresu.

Poza tymi udokumentowanymi ograniczeniami istnieją kwestie związane z warstwą zarządzania, których brama nie została zaprojektowana, aby adresować:

  • Inwentaryzacja i stan serwera MCP. Które serery MCP są wdrożone, jakie narzędzia udostępniają i czy ich zadeklarowane możliwości odpowiadają obserwowanemu zachowaniu — to wszystko nie jest zadaniem bramy.
  • Egzekwowanie zasad między dostawcami. Zasada, która mówi „bazy danych produkcyjnych są tylko do odczytu dla wszystkich agentów”, musi obowiązywać w Claude, OpenAI oraz w modelach hostowanych samodzielnie. Brama reguluje dostęp do modelu Claude; nie reguluje zasobów, które te modele wykorzystują, ani tego, jakie inne modele ich używają.
  • Mapowanie dostępu na poziomie sesji. Budowanie grafu, który przedstawia, która sesja agenta uzyskała dostęp do której bazy danych, magazynu obiektów lub punktu końcowego API — oraz czy dostęp był odczytem czy read/write — wymaga korelacji telemetrii, hooków i sygnałów infrastruktury. Brama przekazuje OTLP dosłownie; nie analizuje, co opisuje telemetria.
  • Audyt odporny na manipulacje. Brama emituje zdarzenia audytowe w formacie JSON na stderr. Zdarzenia te muszą znaleźć się w łańcuchu skrótów, w księdze tylko do dopisywania, jeśli mają wspierać pakiety dowodów zgodności.

Model współwdrożenia

Architektura jest celowo prosta: brama i platforma zarządzania działają obok siebie w Twojej infrastrukturze, każdy wykonując to, w czym jest najlepszy.

  Developer workstations                   Your infrastructure
  ┌─────────────────────┐
  │ Claude Code          │
  │ (v2.1.195+)         │
  └──────┬──────────────┘

         │ OIDC device flow
         │ /v1/messages

  ┌──────────────────────────────┐      ┌────────────────────────────────┐
  │ Claude apps gateway          │      │ Olivares AI (self-hosted)      │
  │                              │      │                                │
  │ • OIDC auth (1 issuer)       │      │ • OTLP receiver (gRPC + HTTP)  │
  │ • Model allowlists           │  ──▶ │ • Claude hooks correlation     │
  │ • Spend limits               │ OTLP │ • gateway.yaml posture         │
  │ • Managed settings           │      │ • Audit event ingest           │
  │ • OTLP fan-out               │      │ • Multi-provider governance    │
  │ • JSON audit on stderr       │  ──▶ │ • MCP server inventory         │
  │                              │ logs │ • Access-edge graph (R/RW)     │
  │ Claude models only.          │      │ • Hash-chained audit ledger    │
  │ OIDC only.                   │      │                                │
  └──────────────────────────────┘      │ ALL providers, ALL surfaces.   │
                                        └────────────────────────────────┘

         Other agent traffic ────────────────────────┘
         (OpenAI, Gemini, vLLM, Ollama, MCP servers, CI pipelines)

Dwa strumienie danych łączą bramkę z platformą:

Rozgałęzienie OTLP. Konfiguracja telemetry.forward_to bramki obsługuje już cele OTLP/HTTP. Skieruj jeden z nich na odbiornik Olivares OTLP. Atrybut session.id koreluje telemetry przekazywaną przez bramkę z rekordami czasu pracy sesji z własnego odbiornika hooków konektora Claude. Atrybuty tożsamości (user.id, user.email, user.groups) dodawane przez bramkę podążają za listą dozwolonych atrybutów operatora i stają się etykietami atrybucji na krawędziach sesji i próbkach kosztów — nie jest potrzebny nowy kod odbiornika.

Przetwarzanie zdarzeń audytu. Złącze claude-apps-gateway odczytuje zdarzenia audytu w formacie JSON z bramki. 11 udokumentowanych typów zdarzeń (config.load, session.mint, session.refresh, device.authorize, device.verify, auth.denied, access.denied, inference, managed.serve, spend.blocked, admin.denied) jest mapowanych na obserwacje SDK: odmowy istotne dla bezpieczeństwa stają się ustaleniami, zdarzenia wnioskowania stają się krawędziami dostępu, tworzenie sesji staje się obserwacjami tożsamości, a zdarzenia operacyjne stają się licznikami metryk. Dane PII w surowych zdarzeniach są hashowane przez SHA-256 zanim trafią do jakiejkolwiek obserwacji; adresy e-mail i identyfikatory są pseudonimizowane.

Łącznik claude-apps-gateway również inwentaryzuje sam gateway.yaml: wystawcę OIDC, mapowania grup IdP-do-modelu, dostawców nadrzędnych, miejsca docelowe OTLP oraz postawę administratora wydatków. Ta inwentaryzacja jest metadanymi strukturalnymi — topologią, a nie poświadczeniami.

Wyniki postawy z konfiguracji bramy

Łącznik generuje zestaw wyników postawy pochodzących z konfiguracji bramy. Są to rzeczy, które operator zarządzania musi wiedzieć o wdrożeniu bramy:

WynikPowagaCo wykrywa
Brak skonfigurowanego miejsca docelowego OTLPŚredniaTelemetria nie jest przekazywana; flota jest niewidoczna dla monitoringu
Brak polityki obejmującej wszystkoWysokiUżytkownicy niepasujący do żadnej grupy IdP otrzymują każdy model i brak zarządzanych ustawień
Brak limitów wydatkówŚredniAPI administracyjne wydatków i egzekwowanie nie są skonfigurowane
Sekretne literały w YAMLWysokiclient_secret, jwt_secret lub hasła do bazy danych zapisane jako literały zamiast odniesień ${VAR} lub ${file:...}
Długi czas życia sesji (>12h)ŚredniOpóźnienie deprowizji: sesja cofniętego użytkownika pozostaje ważna
PKCE wyłączonyNiskiPrzepływ OIDC nie używa Proof Key for Code Exchange
Wrażliwe sygnały telemetryczneNiskilogs: true lub traces: true na docelowym urządzeniu — mogą one zawierać pełne polecenia bash i ścieżki plików

Te ustalenia pojawiają się w tym samym widoku postawy co ustalenia z każdego innego łącznika. Łącznik MCP może raportować narzędzie bez piaskownicy. Łącznik Bedrock może oznaczać ograniczenie gap. Łącznik bramki raportuje, że brakuje ogólnej polityki. Jedna powierzchnia, jeden widok.

Jak to wygląda w konfiguracji

Złącze Claude uruchamia odbiornik OTLP na standardowych portach OpenTelemetry oraz punkt końcowy hooks dla PreToolUse/PostToolUse hooks Claude Code. Równolegle z nim, złącze apps-gateway odczytuje konfigurację bramy i strumień audytu. Oba złącza są dostarczane w ramach Apache-2.0 i importują wyłącznie z SDK, nigdy z rdzenia silnika.

# olivares.yaml (w skrócie)
connectors:
  - name: olivares.claude
    config:
      grpc_addr: "127.0.0.1:4317"
      http_addr: "127.0.0.1:4318"
      hook_path: "/hooks"
      enforcement: |
        {"rules":[
          {"tool":"Bash","decision":"ask","reason":"shell access requires confirmation"},
          {"resource_kind":"file","mode":"write","decision":"ask"}
        ]}
      gateway: "direct"
      semconv_opt_in: "gen_ai_latest_experimental"

  - name: olivares.claude-apps-gateway
    config:
      config_path: "/etc/claude-gateway/gateway.yaml"
      audit_log_path: "/var/log/claude-gateway/audit.jsonl"

Pole gateway w złączu Claude oznacza każdą próbkę kosztów powierzchnią wdrożenia (direct, bedrock-mantle, bedrock-legacy, vertex, foundry, claude-platform-aws), dzięki czemu FinOps może dzielić wydatki według ścieżki dostawcy. Pole semconv_opt_in umożliwia neutralny wobec dostawcy profil pobierania GenAI (przypięty do OpenTelemetry semconv v1.41.1), co oznacza, że OpenAI, Gemini lub dowolny agent z instrumentacją OTel korzysta z tej samej mapy dostępu i potoku kosztów — nie tylko Claude Code.

Uczciwe pozycjonowanie

Są rzeczy, o których warto mówić wprost.

To nie jest zamiennik bramy. Proxy inferencyjne Olivares implementuje podzbiór opublikowanego protokołu bramy Anthropic (odkrywanie OAuth, autoryzacja urządzenia RFC 8628, dostarczanie ustawień zarządzanych oraz powierzchnia administracyjna limitów wydatków — przeglądanie, zapisywanie i egzekwowanie na poziomie stanowiska, z odnotowanymi różnicami od protokołu sieciowego). Jest użyteczne, gdy ten podzbiór jest wystarczający. Nie jest pełnym zamiennikiem przepływu przeglądarkowego bramy OIDC, a jego semantyka grupowych wydatków celowo różni się (najbardziej restrykcyjne zasady mają pierwszeństwo, zamiast reguł scalania bramy). Jeśli brama Anthropic spełnia Twoje wymagania dotyczące autoryzacji, użyj jej.

Konektor jest tylko do odczytu. Konektor claude-apps-gateway obserwuje konfigurację bramki i wyjście audytu. Nie modyfikuje gateway.yaml, nie wprowadza polityk ani nie przechwytuje ścieżki /v1/messages. Zapewnia widoczność, a nie kontrolę.

Olivares AI jest wersją przedpremierową. Produkt nie jest certyfikowany według SOC 2, ISO/IEC 27001, unijnego rozporządzenia AI ani żadnego innego standardu, i żaden audyt nie jest w toku. Został zaprojektowany z myślą o celach kontroli, które te standardy badają, więc jest gotowy do audytu, gdy nadejdzie czas.

Wartość tkwi w kombinacji. Zespół, który uruchamia tylko Claude Code przeciwko jednemu dostawcy, z jednym IdP i bez serwerów MCP od innych dostawców, może uznać samą bramę za wystarczającą. Wspólne wdrożenie zyskuje na znaczeniu, gdy zasób jest heterogeniczny: wielu dostawców, serwery MCP od kilku dostawców, modele hostowane samodzielnie, potoki CI, wymagania zgodności obejmujące całą powierzchnię agentów. Właśnie tutaj „autoryzacja Claude” i „zarządzanie zasobami” są naprawdę różnymi problemami.

FAQ

Czy Olivares AI zastępuje bramę aplikacji Claude?

Nie. Doktryna to „i, a nie lub”. Brama Anthropic posiada sesję uwierzytelniania Claude Code, routowanie dostępu do modeli oraz selekcję upstream. Olivares AI sprawia, że to wdrożenie jest zarządzaną powierzchnią w szerszej płaszczyźnie sterowania, która obejmuje również dostawców innych niż Claude, serwery MCP, modele hostowane samodzielnie oraz resztę twojego środowiska agentów. Jeśli już używasz bramy, zachowaj ją.

Czy mogę uruchomić Olivares AI bez bramy aplikacji Claude?

Tak. Złącze claude-apps-gateway jest opcjonalne. Główne złącze Claude (connectors/claude) pobiera dane telemetryczne OTLP i łączy się bezpośrednio z sesjami Claude Code, z bramą lub bez. Jeśli nie używasz bramy Anthropic, tracisz jej ścieżkę uwierzytelniania sesji OIDC, ale zachowujesz pełne zarządzanie: inwentaryzację sesji, mapowanie dostępu na krawędzi, przypisywanie kosztów, egzekwowanie hooków, postawę MCP oraz widok multi-dostawców.


Szczegółową topologię wdrożenia znajdziesz w /architecture. W kwestii zarządzania serwerem MCP w różnych dostawcach zobacz /product/mcp. Pełny zakres produktu znajdziesz w /product.

Powiązane artykuły

Najczęstsze pytania

Czy Olivares AI zastępuje bramę aplikacji Claude?

Nie. Doktryna brzmi: 'i, nie lub'. Brama Anthropic zarządza sesją uwierzytelniania Claude Code, kierowaniem dostępu do modeli i wyborem źródeł danych. Olivares AI czyni to wdrożenie powierzchnią zarządzaną w ramach szerszej płaszczyzny kontrolnej, która obejmuje również dostawców spoza Claude, serwery MCP, modele samodzielnie hostowane i resztę twojej infrastruktury agentów. Jeśli już używasz bramy, zachowaj ją.

Czy mogę uruchomić Olivares AI bez bramy aplikacji Claude?

Tak. Złącze claude-apps-gateway jest opcjonalne. Podstawowe złącze Claude (connectors/claude) pobiera telemetrię OTLP i haki bezpośrednio z sesji Claude Code, zarówno z bramą z przodu, jak i bez niej. Jeśli nie użyjesz bramy Anthropic, tracisz jej ścieżkę uwierzytelniania sesji OIDC, ale zachowujesz pełne zarządzanie: inwentarz sesji, mapowanie dostępu-edge, przypisanie kosztów, wymuszanie haków, postawę MCP oraz widok multi-dostawcy.

Sprawdź dostęp Twoich agentów

Olivares AI to otwarta platforma w modelu hostowanym samodzielnie dla całego środowiska AI w organizacji. Wdrożenie na własnej infrastrukturze zapewnia mapę dostępu, o którą od dawna proszą zespoły bezpieczeństwa i platformowe.