SPIFFEでWIFを使用する

SPIFFEは、ワークロードにアイデンティティを発行するためのCNCF標準です。SPIREはそのオープンソースのリファレンス実装であり、いくつかの商用製品もSPIFFE準拠のアイデンティティを発行します。Anthropicは、OIDC互換のJWT-SVIDを発行するあらゆるSPIFFE実装とフェデレーションします。実装の最新リストについては、SPIFFEプロジェクトサイトのCommercial software that implements SPIFFEを参照してください。

フェデレーションは、公開HTTPS URLにあるOIDCディスカバリードキュメントを介して行う方法（discoveryモード、URLの制約の対象）と、JWKSを直接登録する方法（inlineモード）のいずれかで機能します。

JWT-SVID仕様ではsubをワークロードのSPIFFE IDとして定義しており、SPIFFE Workload APIでは呼び出し側が取得時にaudを指定する必要があるため、これらのクレームは実装間で共通です。Anthropicはさらにissとiatを必須としていますが、どちらもJWT-SVID仕様では必須とされていないため、両方を設定するように実装を構成してください（SPIREでは、issはサーバー設定のjwt_issuerであり、iatは自動的に設定されます）。これらが整っていれば、このガイドのAnthropicを構成する、トークンを取得して使用する、ルールのスコープを設定するの各セクションは、あらゆるSPIFFE実装に適用できます。

SPIFFEはすべてのワークロードにspiffe://<trust-domain>/<path>という形式の安定したアイデンティティURIを割り当て、SPIREはWorkload APIを通じてそのアイデンティティをJWT-SVIDとしてオンデマンドで発行します。JWT-SVIDは通常の署名付きJWTであり、そのsubクレームはワークロードのSPIFFE IDで、audクレームは取得時にワークロードが指定します。

SPIREトラストドメインから標準OIDCへの橋渡しとなるのがSPIRE OIDC Discovery Providerです。これはスタンドアロンのヘルパーで、トラストドメインのJWT署名鍵のために/.well-known/openid-configurationとJWKSエンドポイントを公開します。ディスカバリープロバイダーが稼働していれば、JWT-SVIDは他のOIDCトークンと同様に検証されます。ディスカバリーURLをフェデレーション発行者として登録し、ワークロードのSPIFFE IDに一致するフェデレーションルールを作成し、ワークロードがそのJWT-SVIDをAnthropicのトークン交換エンドポイントに提示するようにします。

このページの例ではSPIREを使用しており、SPIRE Agentが動作するあらゆる場所（Kubernetesポッド、仮想マシン、ベアメタルホスト）に適用できます。

前提条件

• WIFの概念（サービスアカウント、フェデレーション発行者、フェデレーションルール）に精通していること。
• ワークロードアイデンティティが発行されているSPIFFEデプロイメント（このページの例ではSPIRE ServerとAgentを使用）、およびClaude APIを呼び出す必要があるワークロードの登録エントリ。
• トラストドメイン用のOIDCディスカバリーエンドポイント（SPIREではOIDC Discovery Provider）が公開到達可能なHTTPSエンドポイントで稼働していること、またはinline登録用にエクスポートされたJWKS。
• JWT-SVIDのissクレームを、フェデレーション発行者のissuer_urlとして登録する値に設定するようにSPIFFE発行者が構成されていること。discoveryモードの場合、これはディスカバリーエンドポイントの公開URLです（SPIREではサーバー設定のjwt_issuer）。
• ワークロードがJWT-SVIDを利用できること。WIFはJWT-SVIDのみを受け付け、X.509-SVIDは受け付けません。
• Anthropic組織のClaude Consoleでサービスアカウント、フェデレーション発行者、フェデレーションルールを作成する権限。

JWT-SVIDを取得する際にリクエストするオーディエンス値は常にhttps://api.anthropic.comです。この値をspiffe-helperのjwt_audience、Workload APIのFetchJWTSVID呼び出し、およびフェデレーションルールのaudienceマッチャーで使用してください。

SPIREを構成する

このセクションの手順はSPIRE固有のものです。別のSPIFFE発行者を使用する場合は、そのドキュメントに従ってOIDCディスカバリーエンドポイントとJWT-SVIDの取得を構成し、Anthropicを構成するに進んでください。

すでにOIDC Discovery Providerと共にSPIREを運用している場合、Anthropicとのフェデレーションに必要なSPIRE側の要素は3つです。ディスカバリーURLと一致するjwt_issuer、Claude APIを呼び出すワークロードの登録エントリ、そしてそのワークロードがAnthropicオーディエンスでJWT-SVIDを取得する手段です。以下のサブセクションでそれぞれを順に説明します。構成スニペットはAnthropicフェデレーションに関連する設定のみを示しており、完全なSPIREデプロイメント構成ではありません。

JWT発行者を確認する

Anthropicは、JWT-SVIDのissクレームを登録済みのフェデレーション発行者と照合し、その発行者のディスカバリードキュメントからJWKSを取得することでJWT-SVIDを検証します。2つのSPIRE設定が同じURLで一致している必要があります。SPIRE Serverのjwt_issuer（発行されるすべてのJWT-SVIDのissクレームになります）と、OIDC Discovery Providerのdomainsリスト（ディスカバリードキュメントとJWKSが提供されるホストを決定します）です。この共有URLがAnthropicに登録するものです。

トラストドメインと発行者URLは独立しています。トラストドメイン（spiffe://prod.example.com）はsubクレームのスコープを定めます。発行者URL（https://oidc-discovery.prod.example.com）はAnthropicが署名鍵を取得する場所です。両者がホスト名を共有する必要はありません。

SPIRE Serverの構成でjwt_issuerが設定され、ディスカバリープロバイダーの公開URLを指していることを確認してください。以下の例ではデフォルトのJWT-SVID有効期間も示しています。SPIREの組み込みデフォルトは5分で、継続的なローテーションが必要になるほど短い値です（spiffe-helperを実行するを参照）。Anthropicのトークン交換エンドポイントは、有効期間がフェデレーション発行者に設定された最大値（デフォルトで1時間）を超えるアイデンティティトークンを拒否します（検証ルールを参照）。このチェックはSPIREだけでなくすべてのSPIFFE実装に適用されるため、default_jwt_svid_ttl（またはエントリごとのオーバーライド）をその最大値以下に保ってください。

server {
    trust_domain         = "prod.example.com"
    jwt_issuer           = "https://oidc-discovery.prod.example.com"
    default_jwt_svid_ttl = "5m"
    # ...
}

OIDC Discovery Providerの構成では、同じホスト名がdomainsの下に記載されている必要があり、プロバイダーはSPIRE ServerのAPIソケットに到達できる必要があります。プロバイダーはディスカバリードキュメントとJWKSをHTTPS経由で提供します。組み込みのACMEサポートでTLSを終端するか、TLSを終端するロードバランサーを前段に配置してください。

domains = ["oidc-discovery.prod.example.com"]

server_api {
    address = "unix:///run/spire/sockets/private/api.sock"
}

acme {
    email        = "platform@example.com"
    tos_accepted = true
}

ワークロードを登録する

Claude APIを呼び出す各ワークロードには、ランタイムセレクターをSPIFFE IDにマッピングするSPIRE登録エントリが必要です。ワークロードがすでに登録されている場合は、そのSPIFFE IDを控えておいてください。これはフェデレーションルールのsubject_prefixで使用します。登録されていない場合は登録してください。Kubernetesポッドの場合、セレクターは通常、名前空間とKubernetesサービスアカウントです。

# NODE_UIDをノードのUIDに置き換えてください:
#   kubectl get node <node-name> -o jsonpath='{.metadata.uid}'
spire-server entry create \
    -spiffeID spiffe://prod.example.com/ns/inference/sa/worker \
    -parentID spiffe://prod.example.com/spire/agent/k8s_psat/prod-cluster/NODE_UID \
    -selector k8s:ns:inference \
    -selector k8s:sa:worker

Kubernetes外のワークロードは、unix:uid:1000などのホストレベルのセレクターを使用します（unix:pathも利用可能ですが、エージェントのunixワークロードアテスター構成でdiscover_workload_path = trueが必要です）。spire-controller-managerを実行しているクラスターでは、spire-server entry createを直接呼び出す代わりに、ClusterSPIFFEIDカスタムリソースでエントリを宣言できます。

spiffe-helperを実行する

spiffe-helperは、SPIRE Agentソケットに接続し、指定されたオーディエンスのJWT-SVIDを取得してファイルに書き込み、有効期限前に再取得するサイドカーユーティリティです。ヘルパーはデフォルトでデーモンモードで実行されます。以下の例ではdaemon_mode = trueを明示的に設定しています。

agent_address = "/run/spire/sockets/agent.sock"
# The JWT-SVID file is written under cert_dir
cert_dir      = "/var/run/secrets/anthropic.com"
daemon_mode   = true

jwt_svids = [{
    jwt_audience       = "https://api.anthropic.com"
    jwt_svid_file_name = "token"
}]

Kubernetesでは、spiffe-helperをサイドカーコンテナとして実行し、メモリバックのemptyDirボリューム（medium: Memory）をアプリケーションコンテナと共有して、ベアラーSVIDがノードのディスクに書き込まれないようにします。ホストからSPIRE Agentソケットをサイドカーにマウントし、共有ボリュームを両方のコンテナの/var/run/secrets/anthropic.comにマウントし、アプリケーションコンテナにANTHROPIC_IDENTITY_TOKEN_FILE=/var/run/secrets/anthropic.com/tokenを設定します。VMやベアメタルでは、spiffe-helperをワークロードと並ぶシステムサービスとして実行し、両者を共有ディレクトリに向けてください。

Anthropicを構成する

Claude ConsoleでSettings → Workload identityを開き、Connect workloadをクリックしてCustom OIDCを選択します。ウィザードが発行者の登録、サービスアカウントの作成、フェデレーションルールの作成を順に案内します。

ウィザードがこれらのリソースを作成します。ウィザードに入力する場合でも、Admin APIに送信する場合でも、以下の値を使用してください。

フェデレーション発行者： OIDC Discovery Providerの公開URLをdiscoveryモードで登録します。AnthropicはこのURLから/.well-known/openid-configurationを取得し、返されたjwks_uriをたどってトラストドメインの署名鍵を取得します。

{
  "name": "spire-prod",
  "issuer_url": "https://oidc-discovery.prod.example.com",
  "jwks": { "type": "discovery" }
}

ディスカバリープロバイダーがパブリックインターネットから到達できない場合は、JWKSを自分で取得し（curl https://oidc-discovery.prod.example.com/keys）、返されたkeys配列の内容を使用して"jwks": {"type": "inline", "keys": [...]}で発行者を登録してください。inlineモードでは、issuer_urlはJWT-SVIDのissクレームと比較されるだけです。Anthropicがそこに到達しようとすることはありません。

公開ディスカバリーエンドポイントを公開せずにJWKSの更新を自動化するには、SPIRE ServerのBundlePublisherプラグイン（aws_s3、gcp_cloudstorage、またはk8s_configmap）をformat = "jwks"で構成して、ローテーションのたびにJWT署名鍵を外部ストレージにプッシュし、Admin APIを通じて発行者のインライン鍵を更新してください。

フェデレーションルール： JWT-SVIDのsub（SPIFFE ID）と、spiffe-helperにリクエストするよう構成したaudに一致させます。SPIFFE IDはURI文字列であり、subject_prefixはそれらを不透明なテキストとして照合するため、完全一致の値でも末尾*のプレフィックス一致でも機能します。より複雑なパターンにはCELのconditionを使用してください。

{
  "name": "spire-inference-worker",
  "issuer_id": "fdis_...",
  "match": {
    "subject_prefix": "spiffe://prod.example.com/ns/inference/sa/worker",
    "audience": "https://api.anthropic.com"
  },
  "target": {
    "type": "service_account",
    "service_account_id": "svac_..."
  },
  "workspace_id": "wrkspc_...",
  "oauth_scope": "workspace:developer",
  "token_lifetime_seconds": 600
}

token_lifetime_secondsは、交換によって返されるAnthropicアクセストークンの有効期間であり、JWT-SVIDの有効期間ではありません。SDKはアクセストークンを自動的に更新します。

ワークロードが許す限り具体的にしてください。subject_prefixをspiffe://prod.example.com/ns/inference/*に緩めるのは、そのパス配下に登録されたすべてのワークロードが同じAnthropicサービスアカウントにマッピングされるべき場合のみにしてください。ルールのfdrl_... IDをワークロードのANTHROPIC_FEDERATION_RULE_ID環境変数に追加します。

トークンを取得して使用する

Anthropic SDKは、spiffe-helperが維持するファイルからJWT-SVIDを読み取ることも、トークンプロバイダーのcallableを通じてSPIFFE Workload APIを直接呼び出すこともできます。ファイルパス方式は最もシンプルな統合であり、すべてのSDK言語で機能します。callable方式はサイドカーを不要にしますが、アプリケーションの言語でSPIFFE Workload APIクライアントが必要です。

import anthropic

# spiffe-helperがANTHROPIC_IDENTITY_TOKEN_FILEに書き込むJWT-SVIDを読み取り、
# さらにANTHROPIC_FEDERATION_RULE_ID、
# ANTHROPIC_ORGANIZATION_ID、ANTHROPIC_SERVICE_ACCOUNT_ID、ANTHROPIC_WORKSPACE_IDも読み取ります。
client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
print(next(block.text for block in message.content if block.type == "text"))

セットアップを検証する

SDKを組み込む前に、SPIRE Agentから直接JWT-SVIDを取得し、クレームがフェデレーションルールの期待と一致することを確認してください。別のSPIFFE実装を使用している場合は、そのCLIまたはWorkload APIクライアントでJWT-SVIDを取得し、同じ方法でペイロードをデコードしてください。

spire-agent api fetch jwt \
    -audience https://api.anthropic.com \
    -socketPath /run/spire/sockets/agent.sock \
    -output json \
  | jq -r '.[0].svids[0].svid' \
  | jq -rR 'split(".")[1] | gsub("-";"+") | gsub("_";"/") | @base64d | fromjson'

-output jsonフラグはSVIDレスポンスとバンドルレスポンスを2要素のJSON配列として返すため、jq -r '.[0].svids[0].svid'で生のトークンを抽出できます。-outputのない古いSPIREバージョンでは、コマンドは代わりにラベル付きブロックを出力します。その場合は、デフォルト出力をawk '/^[[:space:]]*eyJ/{print $1; exit}'にパイプしてトークン行を抽出してください。issが登録したOIDC Discovery ProviderのURLであること、subがワークロードのSPIFFE IDであること、audにhttps://api.anthropic.comが含まれていることを確認します。次に、トークンを取得して使用するのcURLの例を実行してください。交換が成功すると、sk-ant-oat01-で始まるaccess_tokenが返されます。交換が不透明な401 authentication_errorレスポンス（メッセージAuthentication failed）で失敗した場合は、認証履歴ページで拒否理由を確認し、失敗した交換のトラブルシューティングを参照してください。SPIRE側で最もよくある原因は、SPIRE Serverのjwt_issuerとフェデレーション発行者として登録されたURLの不一致です。

ルールのスコープを設定する

SPIFFE IDのパス規約は運用者が定義するものであるため、フェデレーションルールのsubject_prefixマッチャーは登録エントリが使用するパススキームを反映する必要があります。一般的なスキームには、spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>（spire-controller-managerのClusterSPIFFEIDリソースがデフォルトで発行する形式）や、VMおよびベアメタルワークロード向けのspiffe://<trust-domain>/host/<hostname>/<service>があります。

ルールのmatchブロックを、ユースケースに適合する最も狭いスコープに固定してください。

• 1つのワークロードに固定する： subject_prefixを末尾の*なしの完全なSPIFFE IDに設定します。
• 常にオーディエンスを設定する： ルールでaudienceを必須とし、spiffe-helper（またはWorkload API呼び出し）を同じ値で構成して、他のリライングパーティ向けに発行されたSVIDが拒否されるようにします。
• パスセグメントでスコープを設定する： spiffe://prod.example.com/ns/inference/*を使用して名前空間配下に登録されたすべてのワークロードに権限を付与し、1つのルールを広げるのではなく、名前空間ごとに別々のルールとAnthropicサービスアカウントを作成します。
• トラストドメインごとに1つの発行者： 各SPIREトラストドメインには独自の署名鍵とOIDC Discovery Providerがあります。それぞれを別々のフェデレーション発行者として登録し、ルールを、そのルールが一致するSPIFFE IDを所有する発行者にバインドしてください。

次のステップ