管理IDプロバイダー

AWSでWIFを使用する

Workload Identity FederationとSTS発行のIDトークンを使用して、Lambda、EC2、ECS、またはEKS上のAWSワークロードをClaude APIに対して認証します。

AWSワークロードは、AWSが署名したOIDC IDトークンを交換することで、静的なAPIキーなしでClaude APIに対して認証できます。推奨される方法は、AWS STSのGetWebIdentityToken APIを呼び出すことです。これはワークロードがAWS認証情報を持つあらゆる場所（Lambda、EC2、ECS、EKS）で動作します。EKSワークロードは代わりにKubernetesのprojectedトークンの方法を使用することもできます。こちらは設定手順が少なくなりますが、Pod内でのみ動作します。

このガイドでは両方の方法を説明します。基礎となる概念（サービスアカウント、フェデレーション発行者、フェデレーションルール）については、Workload Identity Federationを参照してください。

前提条件

WIFの概念（サービスアカウント、フェデレーション発行者、フェデレーションルール）に精通していること。
IAMロールがアタッチされたAWSワークロード（EKS Pod、ECSタスク、Lambda関数、またはEC2インスタンス）。
ワークロード内でaws CLIまたはAWS SDKが利用可能であること。
AnthropicのorganizationについてClaude Consoleでサービスアカウント、フェデレーション発行者、フェデレーションルールを作成する権限。

STS Web IDトークンを使用する（推奨）

AWS STSのGetWebIdentityToken APIは、呼び出し元のIAM IDを表明する、AWSが署名したOIDCトークンを返します。ワークロードの環境に備わっているAWS認証情報を使用するため、同じ統合でLambda、EC2、ECS、EKSをカバーできます。

AWSを設定する

1
アカウントでアウトバウンドWeb IDフェデレーションを有効にする
これはアカウントレベルのフラグで、デフォルトではオフです。AWSコンソールでIAMを開き、Account settingsを選択して、Outbound web identity federationを有効にします。プログラムで有効にするには次のようにします。
python3 -c "import boto3; boto3.client('iam').enable_outbound_web_identity_federation()"
これが有効になっていない場合、GetWebIdentityTokenの呼び出しはOutboundWebIdentityFederationDisabledExceptionで失敗します。
2
ワークロードのIAMロールにAPIを呼び出す権限を付与する
Lambda関数、EC2インスタンス、またはECSタスクが実行されるIAMロールに、次のポリシーをアタッチします。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["sts:GetWebIdentityToken"], "Resource": "*" } ] }
3
アカウントのSTS発行者URLを確認する
アウトバウンドフェデレーションを有効にすると、IAM > Account settingsページにGet Token Issuer URLフィールドが表示され、https://<uuid>.tokens.sts.global.api.awsという形式の値が示されます。このURLはAWSアカウントごとに固有です。次のステップのためにコピーしておいてください。プログラムで取得するには次のようにします。
python3 -c "import boto3; print(boto3.client('iam').get_outbound_web_identity_federation_info())"

Anthropicを設定する

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

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

フェデレーション発行者： 前のステップでコピーしたアカウントごとのSTS発行者URLを登録します。これは公開JWKSエンドポイントを公開しているため、ディスカバリーモードを使用します。

{
  "name": "aws-sts",
  "issuer_url": "https://<uuid>.tokens.sts.global.api.aws",
  "jwks": { "type": "discovery" }
}

フェデレーションルール： GetWebIdentityTokenに渡すオーディエンスと、subクレーム内の呼び出し元ロールのIAMロールARNを照合します。subの値はAPIを呼び出したワークロードのIAMロールARNで、arn:aws:iam::<account>:role/<role-name>という形式です。トークンにはaws_account、org_id、principal_id、および渡した任意のrequest_tagsを含むhttps://sts.amazonaws.com/クレームも含まれます。より細かく制御するには、ルールのclaimsマップまたはCELのconditionでこれらを照合できます。

{
  "name": "prod-inference",
  "issuer_id": "fdis_...",
  "match": {
    "subject_prefix": "arn:aws:iam::123456789012:role/inference-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
}

ワークロードが許す限り具体的に指定してください。正確なロールARNを照合し、複数のIAMロールを同じAnthropicサービスアカウントにマッピングする必要がある場合にのみsubject_prefixを広げてください（例：arn:aws:iam::123456789012:role/*）。

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

オーディエンスとしてhttps://api.anthropic.comを指定してGetWebIdentityTokenを呼び出し、その結果をSDKのフェデレーション認証情報に渡します。トークンプロバイダーは呼び出し可能オブジェクトであるため、SDKはリフレッシュのたびにSTSを再度呼び出します。

import os

import anthropic
import boto3
from anthropic import WorkloadIdentityCredentials


def get_sts_web_identity_token() -> str:
    sts = boto3.client("sts", region_name="us-east-1")
    resp = sts.get_web_identity_token(
        Audience=["https://api.anthropic.com"],
        SigningAlgorithm="RS256",
        DurationSeconds=900,
    )
    return resp["WebIdentityToken"]


client = anthropic.Anthropic(
    credentials=WorkloadIdentityCredentials(
        identity_token_provider=get_sts_web_identity_token,
        federation_rule_id=os.environ["ANTHROPIC_FEDERATION_RULE_ID"],
        organization_id=os.environ["ANTHROPIC_ORGANIZATION_ID"],
        service_account_id=os.environ["ANTHROPIC_SERVICE_ACCOUNT_ID"],
        workspace_id=os.environ.get("ANTHROPIC_WORKSPACE_ID"),
    ),
)

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

セットアップを検証する

ワークロード内から、STS発行のトークンを直接交換してレスポンスを確認します。

cURL

JWT=$(aws sts get-web-identity-token \
  --region us-east-1 \
  --audience "https://api.anthropic.com" \
  --signing-algorithm RS256 \
  --duration-seconds 900 \
  --query WebIdentityToken --output text)

curl -sS https://api.anthropic.com/v1/oauth/token \
  -H "content-type: application/json" \
  -d "{
    \"grant_type\": \"urn:ietf:params:oauth:grant-type:jwt-bearer\",
    \"assertion\": \"$JWT\",
    \"federation_rule_id\": \"fdrl_...\",
    \"organization_id\": \"00000000-0000-0000-0000-000000000000\",
    \"service_account_id\": \"svac_...\",
    \"workspace_id\": \"wrkspc_...\"
  }" | jq

交換が成功すると、sk-ant-oat01-で始まるaccess_tokenと、秒単位のexpires_in値が返されます。交換が不透明な401 authentication_errorレスポンス（メッセージAuthentication failed）で失敗した場合は、認証履歴ページで拒否理由を確認し、失敗した交換のトラブルシューティングを参照してください。AWS側で最も一般的な原因はissの不一致です（アカウントごとのSTS発行者URLは登録されたissuer_urlと完全に一致する必要があります）。

EKSのprojectedサービスアカウントトークンを使用する

ワークロードがEKS Pod内で実行されている場合は、STSの呼び出しを省略し、Kubernetesがprojectしたサービスアカウントトークンをディスクから直接読み取ることができます。KubernetesはOIDC互換のトークンをネイティブにPodへprojectし、SDKはそれをファイルパスから読み取れるため、トークンプロバイダーの呼び出し可能オブジェクトは不要です。この方法はSTSの方法よりAWSの設定手順が2つ少なくなりますが、Pod内でのみ動作します。基礎となる仕組みは汎用Kubernetes統合と同じです。

この方法では、さらにIAM OIDCプロバイダーが有効化されたEKSクラスターと、クラスターへのkubectlアクセスが必要です。

EKSクラスターを設定する

1
クラスターのOIDC発行者URLを確認する
各EKSクラスターには固有のOIDC発行者があります。AWS CLIで取得します。
CLI
aws eks describe-cluster \ --name <cluster-name> \ --query "cluster.identity.oidc.issuer" \ --output text
出力はhttps://oidc.eks.us-west-2.amazonaws.com/id/6FA42E7BFDE8549CB...のようになります。次のセクションでこのURLをフェデレーション発行者として登録します。

サービスアカウントを作成し、Anthropicオーディエンスのトークンをprojectする

EKS Pod Identity Webhookはeks.amazonaws.com/role-arnアノテーションを検出し、aud: sts.amazonaws.comを持つトークンを自動的にprojectして、そのパスをAWS_WEB_IDENTITY_TOKEN_FILEとして公開します。そのトークンはAWSロールの引き受け用です。Anthropicの交換用には、audience: https://api.anthropic.comを持つ2つ目のトークンをprojectし、専用のパスにマウントします。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: inference-worker
  namespace: inference
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/inference-worker

apiVersion: v1
kind: Pod
metadata:
  name: inference-worker
  namespace: inference
spec:
  serviceAccountName: inference-worker
  volumes:
    - name: anthropic-token
      projected:
        sources:
          - serviceAccountToken:
              audience: https://api.anthropic.com
              expirationSeconds: 3600
              path: token
  containers:
    - name: app
      image: your-registry/inference-worker:latest
      env:
        - name: ANTHROPIC_IDENTITY_TOKEN_FILE
          value: /var/run/secrets/anthropic.com/token
        - name: ANTHROPIC_FEDERATION_RULE_ID
          value: fdrl_...
        - name: ANTHROPIC_ORGANIZATION_ID
          value: 00000000-0000-0000-0000-000000000000
        - name: ANTHROPIC_SERVICE_ACCOUNT_ID
          value: svac_...
        - name: ANTHROPIC_WORKSPACE_ID  # required when the rule covers multiple workspaces
          value: wrkspc_...
      volumeMounts:
        - name: anthropic-token
          mountPath: /var/run/secrets/anthropic.com
          readOnly: true

3
トークンのクレーム形式を確認する
projectされたトークンは、クラスターのOIDC発行者によって署名されたJSON Web Token（JWT）です。そのsubクレームはKubernetesの慣例system:serviceaccount:<namespace>:<service-account-name>に従います。
{ "iss": "https://oidc.eks.us-west-2.amazonaws.com/id/6FA42E7BFDE8549CB...", "sub": "system:serviceaccount:inference:inference-worker", "aud": ["https://api.anthropic.com"], "kubernetes.io": { "namespace": "inference", "serviceaccount": { "name": "inference-worker", "uid": "..." } }, "exp": 1775527120, "iat": 1775523520 }
serviceAccountTokenのprojectionはaudをhttps://api.anthropic.comに設定します。AWS_WEB_IDENTITY_TOKEN_FILEにある別のIRSA注入トークンはaud: sts.amazonaws.comを持ち、この交換ではなくAWS API呼び出し用です。

Anthropicを設定する

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

フェデレーション発行者： EKSの発行者は公開JWKSエンドポイントを公開しているため、ディスカバリーモードを使用します。発行者URLはトークンのissクレームと完全に一致する必要があります。クラスターごとに1つの発行者を登録します。

{
  "name": "prod-eks-uswest2",
  "issuer_url": "https://oidc.eks.us-west-2.amazonaws.com/id/6FA42E7BFDE8549CB...",
  "jwks": { "type": "discovery" }
}

フェデレーションルール： KubernetesのsubクレームとAnthropicのオーディエンスhttps://api.anthropic.comを照合します。（そのオーディエンスを持つ専用のサービスアカウントトークンをprojectしてください。IRSAデフォルトのsts.amazonaws.comトークンを再利用しないでください。）

{
  "name": "prod-inference",
  "issuer_id": "fdis_...",
  "match": {
    "subject_prefix": "system:serviceaccount:inference:inference-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
}

ワークロードが許す限り具体的に指定してください。名前空間内のすべてのサービスアカウントを同じAnthropicサービスアカウントにマッピングする必要がある場合にのみ、subject_prefixをsystem:serviceaccount:inference:*に緩めてください（末尾の*によりプレフィックス一致になります）。

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

Pod内では、projectされたトークンは/var/run/secrets/anthropic.com/tokenにあります（Pod specでANTHROPIC_IDENTITY_TOKEN_FILEとして公開されています）。そのファイルをSDKのフェデレーション認証情報に渡すと、SDKが交換とリフレッシュを処理します。

import os

import anthropic
from anthropic import IdentityTokenFile, WorkloadIdentityCredentials

client = anthropic.Anthropic(
    credentials=WorkloadIdentityCredentials(
        identity_token_provider=IdentityTokenFile(
            os.environ["ANTHROPIC_IDENTITY_TOKEN_FILE"]
        ),
        federation_rule_id=os.environ["ANTHROPIC_FEDERATION_RULE_ID"],
        organization_id=os.environ["ANTHROPIC_ORGANIZATION_ID"],
        service_account_id=os.environ["ANTHROPIC_SERVICE_ACCOUNT_ID"],
        workspace_id=os.environ.get("ANTHROPIC_WORKSPACE_ID"),
    ),
)

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

セットアップを検証する

Pod内から、projectされたトークンを直接交換してレスポンスを確認します。

cURL

JWT=$(cat "$ANTHROPIC_IDENTITY_TOKEN_FILE")

curl -sS https://api.anthropic.com/v1/oauth/token \
  -H "content-type: application/json" \
  -d "{
    \"grant_type\": \"urn:ietf:params:oauth:grant-type:jwt-bearer\",
    \"assertion\": \"$JWT\",
    \"federation_rule_id\": \"$ANTHROPIC_FEDERATION_RULE_ID\",
    \"organization_id\": \"$ANTHROPIC_ORGANIZATION_ID\",
    \"service_account_id\": \"$ANTHROPIC_SERVICE_ACCOUNT_ID\",
    \"workspace_id\": \"$ANTHROPIC_WORKSPACE_ID\"
  }" | jq

交換が成功すると、sk-ant-oat01-で始まるaccess_tokenと、秒単位のexpires_in値が返されます。交換が不透明な401 authentication_errorレスポンス（メッセージAuthentication failed）で失敗した場合は、認証履歴ページで拒否理由を確認し、失敗した交換のトラブルシューティングを参照してください。EKS側で最も一般的な原因は、projectされたトークンのaudがルールと一致しないことです（IRSAデフォルトのsts.amazonaws.comではなく、audience: https://api.anthropic.comを持つトークンをprojectしてください）。

ルールのスコープを絞る

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

完全なロールARNを固定する： 末尾に*を付けずにsubject_prefix: "arn:aws:iam::<account>:role/<role-name>"を使用し、アカウント内の他のロールが一致しないようにします。
アカウントIDを固定する： プレフィックスの設定ミスに対する多層防御のチェックとして、claimsマップまたはCELのconditionでトークンのhttps://sts.amazonaws.com/クレームのaws_accountフィールドを照合します。
EKSで名前空間とサービスアカウントを固定する： system:serviceaccount:プレフィックスの後に*を付けず、正確なsystem:serviceaccount:<namespace>:<name>の値を使用します。
環境ごとに別のルールを使用する： 1つのプレフィックスを広げてすべてをカバーするのではなく、本番、ステージング、開発のワークロードに対して個別のルールを作成します。

次のステップ

認証情報の優先順位、プロファイル設定、ルール照合の完全なリファレンスについては、WIFリファレンスを確認してください。
EKS上にないセルフマネージドのKubernetesクラスターについては、KubernetesでWIFを使用するを参照してください。

前提条件

STS Web IDトークンを使用する（推奨）

AWSを設定する

アカウントでアウトバウンドWeb IDフェデレーションを有効にする

ワークロードのIAMロールにAPIを呼び出す権限を付与する

アカウントのSTS発行者URLを確認する

Anthropicを設定する

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

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

EKSのprojectedサービスアカウントトークンを使用する

EKSクラスターを設定する

クラスターのOIDC発行者URLを確認する

サービスアカウントを作成し、Anthropicオーディエンスのトークンをprojectする

トークンのクレーム形式を確認する

Anthropicを設定する

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

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

ルールのスコープを絞る

次のステップ

前提条件

STS Web IDトークンを使用する（推奨）

AWSを設定する

Anthropicを設定する

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

セットアップを検証する

EKSのprojectedサービスアカウントトークンを使用する

EKSクラスターを設定する

Anthropicを設定する

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

セットアップを検証する

ルールのスコープを絞る

次のステップ