Aplikacja ChatGPT na komputery jest dostępna w Amazon Bedrock w środowisku AWS GovCloud (US), a wnioskowanie modelu jest kierowane przez Responses API w Amazon Bedrock. Opublikowana instrukcja dotyczy kontrolowanego lokalnego wdrożenia Codex, w którym żądania modelu przechodzą przez Amazon Bedrock Mantle w regionie us-gov-west-1 z użyciem tożsamości, punktów końcowych i kontroli regionalnych AWS GovCloud (US).

Takie wdrożenie nie sprowadza się do wyboru adresu usługi. Łączy logowanie w trybie API, zasady zarządzanego urządzenia, nazwany profil AWS, reguły narzucone przez administratora, ustawienia operacyjne i ograniczenia sieciowe. W kontrolowanym układzie sieć zezwala wyłącznie na zatwierdzony punkt końcowy Amazon Bedrock. Pozostałe połączenia zewnętrzne i funkcje korzystające z sieci są wyłączone.

Wymagania wstępne i role plików

Przed rozpoczęciem potrzebna jest zgodna wersja aplikacji ChatGPT na komputery oraz zatwierdzone konto AWS GovCloud (US). Wymagane są także autoryzowana tożsamość IAM i dane uwierzytelniające, dostęp do zatwierdzonego modelu, regionu i punktu końcowego, a także pliki requirements.toml i config.toml.

Pliki pełnią odmienne funkcje. requirements.toml to kontrolowany przez administratora zbiór reguł nakładający ograniczenia bezpieczeństwa, których użytkownik nie może zastąpić. config.toml określa ustawienia operacyjne, w tym dostawcę amazon-bedrock, model, uprawnienia i limity kontekstu. Rozdzielenie tych zadań pozwala odróżnić obowiązkowe granice od parametrów opisujących działanie aplikacji w ich obrębie.

Trzy etapy wdrożenia

Konfiguracja obejmuje trzy główne etapy: skonfigurowanie uwierzytelniania, utworzenie plików konfiguracyjnych aplikacji ChatGPT oraz uruchomienie, zainicjowanie i zweryfikowanie wdrożenia. Kolejność ma znaczenie, ponieważ oba pliki TOML muszą zostać zainstalowane przed uruchomieniem aplikacji. Dzięki temu aplikacja rozpoczyna pracę z przygotowanymi wcześniej regułami i ustawieniami.

1. Wybór uwierzytelniania

Aplikacja obsługuje uwierzytelnianie Amazon Bedrock za pomocą klucza API Amazon Bedrock albo standardowego łańcucha danych uwierzytelniających AWS SDK. AWS IAM Identity Center SSO jest obsługiwane przez ścieżkę łańcucha poświadczeń. Wybrana metoda określa, gdzie aplikacja szuka danych i z których istniejących źródeł AWS może korzystać.

Weryfikacja musi uwzględniać kolejność pierwszeństwa. Aplikacja najpierw sprawdza AWS_BEARER_TOKEN_BEDROCK. Token bearer zapisany w pliku .codex/.env właściwym dla danej platformy ma pierwszeństwo przed uwierzytelnianiem opartym na profilu. Sama obecność nazwanego profilu AWS nie dowodzi więc, że jest on aktywnym źródłem, jeśli dostępny jest token o wyższym priorytecie.

Jeżeli token bearer nie jest dostępny, aplikacja przechodzi do standardowego łańcucha danych uwierzytelniających AWS SDK. Może on korzystać z plików poświadczeń i konfiguracji AWS, profili SSO oraz zapisanych sesji SSO. Kontrola wdrożenia powinna zatem obejmować źródła rzeczywiście dostępne według tej kolejności, a nie tylko profil wskazany jako zamierzony.

2. Zastosowanie reguł i ustawień

Po przygotowaniu uwierzytelniania dwa pliki konfiguracyjne definiują kontrolowane środowisko. Reguły administratora ograniczają zmiany dostępne użytkownikom, natomiast konfiguracja operacyjna wybiera Amazon Bedrock oraz ustala model, uprawnienia i limity kontekstu. Zasady sieciowe dopuszczają zatwierdzony punkt końcowy Amazon Bedrock, wyłączając inne połączenia zewnętrzne i funkcje sieciowe.

Elementy te odpowiadają na różne pytania kontrolne. Uwierzytelnianie wyjaśnia, jak aplikacja uzyskuje uprawnienia do wysłania żądania. requirements.toml wyznacza lokalne granice, których nie można zastąpić. config.toml określa dostawcę i parametry działania, a ograniczenia sieciowe wskazują jedyny zatwierdzony cel zewnętrzny.

3. Uruchomienie i potwierdzenie

Po zainstalowaniu obu plików można uruchomić i zainicjować aplikację. Pomyślną konfigurację sprawdza się, potwierdzając, że amazon-bedrock widnieje jako dostawca modelu w widoku stanu Codex CLI albo w ustawieniach aplikacji ChatGPT na komputery. Kontrola zestawia przygotowaną konfigurację z dostawcą wskazywanym przez działającą aplikację.

Postępowanie po nieudanej walidacji

Jeżeli walidacja nie powiedzie się, wdrażanie należy zatrzymać. Urządzenia objęte zmianą powinny wrócić do wcześniej zatwierdzonych zasad i ustawień dostawcy. Tymczasowe dane uwierzytelniające AWS lub klucze API należy unieważnić, a następnie potwierdzić utratę łączności z Amazon Bedrock. Przed kolejną próbą trzeba udokumentować niepowodzenie, aby nie rozpoczynać jej z niejasnego, częściowo zmienionego stanu.

Konfiguracja techniczna nie jest autoryzacją

Korzystanie z AWS GovCloud (US) ani wykonanie instrukcji nie autoryzuje samo w sobie obciążenia. Organizacja nadal odpowiada za ocenę wdrożenia zgodnie z własnym planem bezpieczeństwa i procesem autoryzacji. Potwierdzenie dostawcy, ścieżki poświadczeń, plików konfiguracyjnych i ograniczonej łączności jest krokiem walidacji technicznej, a nie zamiennikiem wewnętrznej oceny lub zatwierdzenia.