Uwierzytelnianie Claude API: Anthropic, Bedrock, Vertex

Cztery ścieżki uwierzytelniania w Claude API

Uwierzytelnianie w Claude API sprowadza się do jednej decyzji: jakiego poświadczenia użyje klient w przesyłanych danych. Istnieją cztery rozwiązania i nie są one wariantami tego samego mechanizmu. Bezpośrednie API Anthropic wysyła statyczny klucz w nagłówku x-api-key. Amazon Bedrock podpisuje każde żądanie poświadczeniami AWS i w tej konfiguracji klucz Anthropic nie występuje. Google Cloud wysyła krótkotrwały token dostępu Google. Microsoft Foundry wymaga klucza wydanego przez Azure lub tokena Microsoft Entra.

Niniejszy przewodnik dotyczy integracji SDK (software development kit) z usługą działającą na serwerze Linux. Jeśli konfigurujesz narzędzie wiersza poleceń Claude Code, zmienne oraz przebieg procesu są inne: sprawdź skierowanie Claude Code na Bedrock lub Vertex. Jeśli usługa jeszcze nie istnieje, zbuduj ją najpierw zgodnie z pierwsza aplikacja Claude API na VPS, a następnie wróć tutaj, aby skonfigurować poświadczenia.

Wszystkie poniższe informacje zostały zweryfikowane z dokumentacją platformy Anthropic w sierpniu 2026 roku. Identyfikatory modeli, ceny, wersje SDK oraz struktura punktów końcowych ulegają zmianom, dlatego niniejszy przewodnik odsyła do stron dostawców zamiast podawać wartości, które mogą stać się nieaktualne.

Ścieżka 1: klucz API Anthropic

Jest to bezpośrednia metoda i jedyna, w której Anthropic wydaje sekret. Żądania trafiają do endpointu Messages na hoście API Anthropic, a każde żądanie zawiera trzy nagłówki.

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "MODEL_ID", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

Zastąp MODEL_ID aktualnym identyfikatorem z przeglądu modeli Anthropic. Prawidłowa odpowiedź to JSON zawierający tablicę content oraz obiekt usage. Błędny lub wygasły klucz zwraca kod HTTP 401 wraz z authentication_error. Brak nagłówka anthropic-version stanowi odrębny błąd, ponieważ nagłówek ten jest wymagany w każdym żądaniu; SDK ustawiają go automatycznie.

Konstrukcja klienta jest najkrótsza z czterech omawianych, ponieważ nie wymaga żadnej konfiguracji. Każde oficjalne SDK samodzielnie odczytuje ANTHROPIC_API_KEY ze środowiska.

import os
from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment

message = client.messages.create(
    model=os.environ["CLAUDE_MODEL"],
    max_tokens=64,
    messages=[{"role": "user", "content": "Hello"}],
)
print(message.usage)

Warto przechowywać identyfikator modelu w środowisku obok klucza. Nazwy modeli zmieniają się zgodnie z harmonogramem, na który nie masz wpływu, a ponowne wdrażanie kodu w celu edycji jednego ciągu znaków jest zbędnym nakładem pracy.

Klucze tworzy się w konsoli, gdzie podczas tworzenia wybiera się czas wygaśnięcia: ustawienia wstępne 3 godziny, 1 dzień, 7 dni lub 30 dni, czas niestandardowy albo opcję Nigdy. Czas wygaśnięcia jest ustalany w momencie tworzenia i nie można go później zmienić. Anthropic wysyła powiadomienie e-mail do twórcy klucza przed wygaśnięciem klucza długoterminowego, jednak klucz o krótkim czasie ważności wygasa bez żadnego ostrzeżenia. Wygasły klucz zwraca błąd 401 i nie może zostać reaktywowany, więc rozwiązaniem jest zawsze wygenerowanie nowego klucza.

W przypadku bezpośredniego API nie wybiera się regionu, a rachunek trafia bezpośrednio do organizacji Anthropic. Obszary robocze (Workspaces) ograniczają zakres klucza do jednego projektu, co stanowi najbardziej przejrzysty sposób monitorowania wydatków pojedynczej usługi. Obliczenia stojące za tym rachunkiem opisano w sekcji porównanie cen API za token z subskrypcją.

W tym miejscu należy wspomnieć o jeszcze jednej opcji, ponieważ całkowicie eliminuje ona statyczny sekret. Federacja tożsamości obciążeń (Workload Identity Federation) pozwala obciążeniu wymienić token OpenID Connect (OIDC) od zaufanego dostawcy tożsamości na krótkotrwały token Anthropic pod adresem POST /v1/oauth/token, a SDK odświeża ten token przed jego wygaśnięciem. Żaden ciąg znaków sk-ant-api... nie jest nigdzie tworzony ani kopiowany. Rozwiązanie to pasuje do Kubernetes, GitHub Actions oraz maszyn wirtualnych w chmurze, które posiadają już tożsamość platformową. Zwykły VPS zazwyczaj nie posiada takiego wystawcy, więc na takiej maszynie klucz API w pliku jest najbardziej praktycznym rozwiązaniem i tak też traktuje go reszta tego przewodnika.

Ścieżka 2: Poświadczenia AWS w Amazon Bedrock

W przypadku Bedrock nie przechowuje się żadnego klucza Anthropic. SDK podpisuje każde żądanie HTTP przy użyciu AWS Signature Version 4 (SigV4), wykorzystując standardowe poświadczenia AWS, a AWS decyduje, czy dany podmiot może wywołać model.

pip install -U "anthropic[bedrock]"
aws sts get-caller-identity

aws sts get-caller-identity wyświetla numer konta oraz ARN (Amazon Resource Name) tożsamości, do której przypisane są poświadczenia. Uruchom to polecenie przed wykonaniem jakichkolwiek innych działań. Jeśli zakończy się niepowodzeniem, wywołanie Claude również się nie powiedzie, ponieważ SDK podąża tym samym łańcuchem: najpierw argumenty konstruktora, następnie zmienne środowiskowe AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN i AWS_REGION, potem plik konfiguracyjny AWS i reszta standardowego łańcucha (SSO, przyjmowane role, rola zadania ECS, usługa metadanych instancji).

W konstrukcji klienta zmienia się klasa oraz jeden argument.

from anthropic import AnthropicBedrock

client = AnthropicBedrock(aws_region="us-east-1")

Region przestaje być tutaj jedynie dekoracją. Punkty końcowe Bedrock są przypisane do regionów, dostęp do modelu jest przyznawany dla każdego regionu z osobna w konsoli AWS, a region jest częścią podpisu SigV4, więc podpis obliczony dla jednego regionu zostanie odrzucony przez inny. Ustaw AWS_REGION jawnie w środowisku usługi. Anthropic dokumentuje, że klient AnthropicBedrock odczytuje AWS_REGION i korzysta z us-east-1, gdy ta zmienna nie jest ustawiona, oraz że nie odczytuje ~/.aws/config w celu określenia regionu. Dlatego AWS CLI może z powodzeniem wyświetlić listę modeli Claude na tej samej maszynie, na której proces Python kończy się błędem: CLI odczytało plik konfiguracyjny, a klient nie.

Na instancji EC2 przypisuje się rolę IAM (identity and access management) i żaden sekret nie trafia na dysk, ponieważ usługa metadanych instancji przekazuje SDK tymczasowe poświadczenia. Serwer VPS poza AWS nie posiada ani roli instancji, ani usługi metadanych. Wybiera się wtedy między długoterminową parą kluczy dostępu użytkownika IAM przechowywaną na maszynie, co stanowi tę samą klasę sekretu co klucz Anthropic, a federacją: uwierzytelnieniem u dostawcy tożsamości, wywołaniem AWS STS (security token service) i użyciem zwróconych tymczasowych poświadczeń. Bedrock akceptuje również token bearer poprzez AWS_BEARER_TOKEN_BEDROCK, udokumentowany z limitem 12 godzin i opisany przez AWS jako najmniej zalecana ścieżka.

Rachunek trafia na konto AWS, a nie do Anthropic, co zazwyczaj jest głównym powodem wyboru tego rozwiązania. Regionalne punkty końcowe wiążą się z 10% narzutem w stosunku do globalnego punktu końcowego, zgodnie z dokumentacją z sierpnia 2026. Warto rozpoznać jeden błąd Bedrock, ponieważ wygląda on na problem z uprawnieniami, a nim nie jest: Invocation of model ID ... with on-demand throughput isn't supported. Retry your request with the ID or ARN of an inference profile that contains this model.. Jest to błąd routingu modelu i żadna zmiana poświadczeń go nie naprawi.

Ścieżka 3: Poświadczenia Google w Vertex AI

Google Cloud wykorzystuje Application Default Credentials (ADC), czyli ustaloną kolejność wyszukiwania, według której biblioteki uwierzytelniające Google odnajdują poświadczenia bez konieczności ich jawnego wskazywania. ADC sprawdza najpierw GOOGLE_APPLICATION_CREDENTIALS, następnie plik zapisany przez gcloud auth application-default login, a na końcu konto serwisowe przypisane przez serwer metadanych.

pip install -U "anthropic[vertex]"
gcloud auth application-default login

Na stacji roboczej polecenie logowania zapisuje $HOME/.config/gcloud/application_default_credentials.json i proces jest zakończony. Na serwerze jest to niewłaściwe narzędzie, ponieważ przechowywane poświadczenia należą do użytkownika i wygasają wraz z jego kontem. Poza Google Cloud nie ma również serwera metadanych, więc ADC przechodzi do GOOGLE_APPLICATION_CREDENTIALS wskazującego na plik klucza konta serwisowego. Ten plik JSON jest długotrwałym sekretem i wymaga obsługi dokładnie opisanej w dalszej części tego przewodnika. Wewnątrz Google Cloud należy przypisać konto serwisowe do VM, co eliminuje potrzebę ochrony jakiegokolwiek pliku.

from anthropic import AnthropicVertex

client = AnthropicVertex(project_id="my-project", region="global")

Dwie rzeczy ulegają zmianie w przypadku przejścia z SDK na surowe żądania HTTP. Identyfikator modelu zostaje przeniesiony z treści żądania do ścieżki URL, a anthropic_version zostaje przeniesiony z nagłówka do treści, gdzie musi przyjąć wartość vertex-2023-10-16. Poświadczeniem jest standardowy token dostępu Google.

curl https://aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/publishers/anthropic/models/${MODEL_ID}:rawPredict \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -d '{"anthropic_version": "vertex-2023-10-16", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

Region jest argumentem pierwszorzędnym. global kieruje ruch dynamicznie w celu zapewnienia dostępności, us oraz eu to identyfikatory wielu regionów, a nazwa taka jak us-east5 przypina usługę do pojedynczego regionu. Punkty końcowe typu multi-region oraz regionalne są o 10% droższe od globalnych, zgodnie z dokumentacją z sierpnia 2026. Rozliczenia odbywają się w ramach projektu Google Cloud, więc limity oraz faktury są zarządzane przez Google.

Ścieżka 4: Microsoft Foundry to ścieżka Azure

Jeśli poszukiwano Claude w ramach Azure, jest to właściwa sekcja, ponieważ obsługiwana ścieżka istnieje. Claude działa w Microsoft Foundry (wcześniej Azure AI Foundry), a rozliczenia odbywają się poprzez Azure Marketplace w jednostkach Claude Consumption Units. Należy utworzyć zasób Foundry, wdrożyć w nim model Claude i wywołać punkt końcowy hostowany w Azure pod adresem https://{resource}.services.ai.azure.com/anthropic/v1/*.

Działają dwa rodzaje poświadczeń. Pierwszym jest klucz wydany przez Azure, dostępny w zakładce Details wdrożenia w portalu Foundry, przesyłany w nagłówku api-key lub x-api-key. Drugim jest token Microsoft Entra, co stanowi lepszy wybór na serwerze, ponieważ kontrola dostępu oparta na rolach (Azure RBAC) zarządza wówczas uprawnieniami do wywoływania punktu końcowego.

ACCESS_TOKEN=$(az account get-access-token --resource https://ai.azure.com --query accessToken -o tsv)

curl https://${RESOURCE}.services.ai.azure.com/anthropic/v1/messages \
  -H "content-type: application/json" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model": "DEPLOYMENT_NAME", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

Pole model zawiera nazwę wdrożenia, a nie identyfikator modelu. Domyślnie obie wartości są zgodne, jednak przestają być identyczne w momencie nadania własnej nazwy wdrożeniu, co jest najczęstszą przyczyną błędu Deployment not found przy poprawnie sformułowanym żądaniu. Zestawy SDK dla języków Python i TypeScript odczytują ANTHROPIC_FOUNDRY_API_KEY oraz ANTHROPIC_FOUNDRY_RESOURCE ze środowiska. Obsługa Foundry nie jest dostępna w każdym SDK: według stanu na sierpień 2026 obejmuje ona C#, Java, PHP, Python oraz TypeScript, podczas gdy zestawy SDK dla Go i Ruby wymagają użycia ogólnego klienta skierowanego na bazowy adres URL Foundry.

To obejście wiąże się z ryzykiem. Jeśli zmienna ANTHROPIC_API_KEY jest nadal ustawiona w środowisku, ogólny klient pobierze ją i wyśle klucz Anthropic do punktu końcowego Microsoft. Należy usunąć tę zmienną lub wyłączyć domyślne ustawienia środowiskowe w kliencie. Tokeny Entra wygasają po około godzinie, więc procesy działające długotrwale muszą je odświeżać, zamiast pobierać jeden raz podczas uruchamiania.

Jak długo ważne są poświadczenia na serwerze?

[
  {
    "label": "Anthropic key, 30-day preset",
    "max_lifetime_hours": 720
  },
  {
    "label": "Anthropic key, 7-day preset",
    "max_lifetime_hours": 168
  },
  {
    "label": "AWS STS assumed role",
    "max_lifetime_hours": 12
  },
  {
    "label": "Bedrock bearer token",
    "max_lifetime_hours": 12
  },
  {
    "label": "Entra ID access token",
    "max_lifetime_hours": 1
  },
  {
    "label": "Federated Anthropic token",
    "max_lifetime_hours": 1
  }
]

Są to limity i wartości domyślne opublikowane przez poszczególnych dostawców, odczytane w sierpniu 2026 roku, a nie wartości zmierzone. Mają one znaczenie z jednego powodu: określają, jak długo wyciekłe poświadczenie pozostaje aktywne, podczas gdy administrator wciąż ustala fakt wystąpienia wycieku. Tokeny krótkotrwałe znajdujące się na dole zestawienia są ważne przez 1 godzin każdy, a SDK odświeża je automatycznie, więc krótki czas życia nie generuje kosztów operacyjnych. Przyjęta rola (assumed role) jest ważna przez 12 godziny. Klucz utworzony z ustawieniem 30-dniowym pozostaje ważny przez 720 godzin i jest to poświadczenie, które przez miesiąc znajduje się w pliku na serwerze.

Lokalizacja danych uwierzytelniających na serwerze VPS

Umieść sekret w pliku dostępnym tylko dla użytkownika root i pozwól systemd przekazać go do procesu. To rozwiązanie jest niezależne od wersji SDK, dlatego warto wdrożyć je raz i poprawnie.

sudo useradd --system --home /opt/claude-app --shell /usr/sbin/nologin claudeapp
sudo install -d -m 700 -o root -g root /etc/claude-app
sudo install -m 600 -o root -g root /dev/null /etc/claude-app/env
sudoedit /etc/claude-app/env

Plik zawiera zwykłe linie KEY=value. Nie stosuj export, cudzysłowów ani składni powłoki, ponieważ systemd parsuje plik samodzielnie, bez udziału powłoki.

ANTHROPIC_API_KEY=sk-ant-api03-REPLACE-ME
CLAUDE_MODEL=REPLACE-ME

[Unit]
Description=Claude API service
After=network-online.target

[Service]
User=claudeapp
EnvironmentFile=/etc/claude-app/env
ExecStart=/opt/claude-app/venv/bin/python -m claude_app
Restart=on-failure

[Install]
WantedBy=multi-user.target

systemd odczytuje EnvironmentFile= jako root, zanim uprawnienia zostaną obniżone do User=claudeapp, więc konto usługi nie potrzebuje uprawnień do odczytu tego pliku. Wystarczy tryb 600 z właścicielem root, dlatego polecenie install powyżej ustawia takie parametry. Uruchom usługę za pomocą sudo systemctl enable --now claude-app, a następnie potwierdź poleceniem systemctl status claude-app, że jednostka osiągnęła stan active (running), zamiast restartować się w pętli.

Należy unikać czterech poniższych działań, z powodów, które można samodzielnie zweryfikować:

• Nie zapisuj klucza za pomocą Environment= w pliku jednostki. Jednostka w /etc/systemd/system jest dostępna do odczytu dla wszystkich, więc systemctl cat claude-app wyświetli sekret każdemu użytkownikowi lokalnemu.
• Nie dodawaj pliku do repozytorium. .gitignore zapobiega dodaniu nowego pliku do commita, ale nie usuwa plików już zatwierdzonych, ponieważ historia git przechowuje wszystko, co zostało do niej przekazane.
• Nie umieszczaj sekretu w obrazie kontenera. Linie ENV oraz wartości --build-arg są zapisywane w warstwach obrazu, a docker history --no-trunc wyświetla je. Usunięcie pliku w późniejszej warstwie nie usuwa go z warstw wcześniejszych. Przekazuj sekrety w czasie uruchamiania za pomocą --env-file lub zamontowanego pliku.
• Nie traktuj środowiska procesu jako prywatnego względem użytkownika root. sudo tr '\\0' '\\n' < /proc/$(pgrep -u claudeapp -f claude_app | head -1)/environ wyświetla klucz. Celem jest odizolowanie sekretu od wszystkich innych kont w systemie, a nie od roota, który i tak może odczytać wszystko.

Ostatni punkt wyznacza granice skuteczności tego rozwiązania. Zmienna środowiskowa jest odpowiednim kontenerem dla sekretu, gdy dostęp do niej mają tylko usługa i root. Jest to niewłaściwy kontener, gdy proces wykonuje kod, którego nie jesteś autorem, ponieważ wszystko, co proces może wykonać, może również odczytać jego własne środowisko. Ochrona sekretów przed dostępem agenta AI omawia ten przypadek, który stanowi odrębny problem wymagający innego rozwiązania.

Jak przeprowadzić rotację klucza bez przestojów?

Rotacja odbywa się poprzez dodanie nowego klucza, a następnie unieważnienie starego.

1. Utwórz nowy klucz w konsoli, w tym samym obszarze roboczym co stary.
2. Zapisz go w /etc/claude-app/env za pomocą sudoedit.
3. Uruchom sudo systemctl restart claude-app.
4. Potwierdź, że usługa odpowiada na żądania, a następnie unieważnij stary klucz w konsoli.

Plik EnvironmentFile jest odczytywany podczas uruchamiania jednostki, więc działający proces zachowuje wartość przypisaną w momencie startu. Polecenie systemctl daemon-reload ponownie wczytuje pliki jednostek, ale nie zmienia środowiska działającego procesu, dlatego dopiero restart wymusza użycie nowego klucza. Unieważnienie klucza w kroku 1 zamiast w kroku 4 spowoduje przerwę w działaniu usługi, która potrwa do momentu wykonania kroku 3.

Pozostałe trzy metody rotacji zależą od dostawcy. Użytkownik IAM obsługuje jednocześnie dwa aktywne klucze dostępu, więc należy utworzyć drugi, wdrożyć go, a następnie usunąć pierwszy. Klucz konta serwisowego Google rotuje w ten sam sposób. Klucz Foundry jest generowany ponownie w portalu, co natychmiast unieważnia stary, dlatego nową wartość należy zapisać przed kliknięciem. Tokeny Entra oraz federacyjne tokeny Anthropic nie wymagają rotacji, co stanowi najsilniejszy argument za ich stosowaniem, gdy jest to możliwe.

Podczas pracy w konsoli warto ustawić limit wydatków dla obszaru roboczego. Wyciek klucza generuje koszty, zanim jeszcze stanie się problemem bezpieczeństwa, a artykuł ograniczanie wydatków agenta na serwerze VPS zawiera szczegółowy opis dostępnych mechanizmów kontroli.

Dlaczego klient zwraca błąd 401 lub 403?

Błąd 401 z authentication_error w bezpośrednim API. Klucz jest nieprawidłowy, unieważniony lub wygasł. Użytkownicy często pomijają datę wygaśnięcia, ponieważ kod nie uległ zmianie, a żądanie działało poprzedniego dnia. Należy sprawdzić kolumnę wygaśnięcia klucza w konsoli lub odczytać expires_at z Admin API, gdzie wartość null oznacza klucze bez daty wygaśnięcia.

SDK ignoruje konfigurację federacji i używa klucza. ANTHROPIC_API_KEY oraz ANTHROPIC_AUTH_TOKEN znajdują się wyżej w hierarchii ważności poświadczeń niż federacja, więc każdy z nich ją przesłania. W praktyce oznacza to, że zmienna wyeksportowana jako pusty ciąg znaków nadal zajmuje swoje miejsce, przez co ANTHROPIC_API_KEY="" wymusza na SDK uwierzytelnianie pustym kluczem zamiast przejścia do kolejnej metody. Należy użyć unset ANTHROPIC_API_KEY.

Błąd 401 z ogólnym komunikatem Authentication failed przy federacji. Komunikat ten jest celowo identyczny dla każdej możliwej przyczyny, aby osoba wywołująca nie mogła badać konfiguracji reguł poprzez analizę treści błędu. Rzeczywista przyczyna jest rejestrowana na stronie historii uwierzytelniania w konsoli. Należy zacząć od tego miejsca, zamiast zgadywać zawartość JWT.

Błąd 403 w Foundry. Token został uwierzytelniony, ale konto Azure nie posiada roli uprawniającej do wykonania wywołania. Należy przypisać tożsamości wykonującej żądanie rolę Azure RBAC, taką jak Foundry User (dawniej Azure AI User) lub Cognitive Services User.

Jakikolwiek błąd w Bedrock. W pierwszej kolejności należy uruchomić aws sts get-caller-identity jako użytkownik usługi. Pozwala to ustalić, czy serwer posiada w ogóle użyteczne poświadczenia AWS, co pozwala odróżnić problem z poświadczeniami od problemu z dostępem do modelu lub niedopasowaniem regionu. Dostęp do modelu jest przyznawany dla każdego regionu z osobna w konsoli AWS, przez co łatwo włączyć go w jednym regionie, próbując jednocześnie wywołać inny.

FAQ

Czy do korzystania z Claude w ramach Bedrock lub Vertex wymagany jest klucz API Anthropic?

Nie. W Amazon Bedrock zestaw SDK podpisuje każde żądanie przy użyciu poświadczeń AWS za pomocą protokołu SigV4, natomiast w Google Cloud wysyłany jest token dostępu Google pobierany przez Application Default Credentials. W żadnej z tych konfiguracji nie występuje klucz wydany przez Anthropic, a opłaty za użycie są naliczane na konto w chmurze, a nie bezpośrednio w Anthropic. Z tego powodu klucz Anthropic pozostawiony w ANTHROPIC_API_KEY stanowi zagrożenie na tych hostach: ogólny klient skierowany na punkt końcowy chmury wyśle go tam bez ostrzeżenia.

Czy Claude jest dostępny na platformie Azure?

Tak, za pośrednictwem Microsoft Foundry, dawniej Azure AI Foundry. Należy utworzyć zasób Foundry, wdrożyć w nim model Claude i wywołać https://{resource}.services.ai.azure.com/anthropic/v1/messages przy użyciu klucza wydanego przez Azure w nagłówku api-key lub tokena nośnego Microsoft Entra. Opłaty za użycie są naliczane za pośrednictwem Azure Marketplace w jednostkach Claude Consumption Units. Pole model w treści żądania musi zawierać nazwę wdrożenia, która jest identyczna z identyfikatorem modelu tylko do momentu zmiany nazwy wdrożenia.

Gdzie na serwerze z systemem Linux należy przechowywać klucz API Claude?

W pliku należącym do użytkownika root z uprawnieniami 600, wczytywanym przez EnvironmentFile= w jednostce systemd. Systemd odczytuje ten plik jako root przed przełączeniem na użytkownika User= zdefiniowanego w jednostce, dzięki czemu konto usługi nie potrzebuje do niego dostępu. Klucz należy przechowywać poza repozytorium, poza samym plikiem jednostki (który jest czytelny dla wszystkich i wyświetlany przez systemctl cat) oraz poza warstwami obrazu kontenera, ponieważ docker history --no-trunc wyświetla wszystko, co zostało ustawione za pomocą ENV lub --build-arg.

Dlaczego żądanie API Claude zaczęło zwracać błąd 401, mimo że konfiguracja nie uległa zmianie?

Najczęstszą przyczyną jest wygaśnięcie klucza, którego termin ważności został określony w momencie tworzenia. Termin ważności jest ustalany przy tworzeniu, nie można go później edytować, a klucze krótkoterminowe wygasają bez powiadomienia e-mail. Wygasłego klucza nie można reaktywować, dlatego należy utworzyć nowy, zapisać go w pliku środowiskowym, zrestartować usługę, a następnie unieważnić stary klucz. Jeśli klucz jest na pewno aktualny, należy sprawdzić, czy nie jest przesłaniany przez nieaktualne poświadczenie: ANTHROPIC_API_KEY ustawione na pusty ciąg znaków nadal ma pierwszeństwo przed każdym innym źródłem poświadczeń.