Utiliser WIF avec AWS

Les charges de travail AWS peuvent s'authentifier auprès de l'API Claude sans clés API statiques en échangeant un jeton d'identité OIDC signé par AWS. La méthode recommandée consiste à appeler l'API AWS STS GetWebIdentityToken, qui fonctionne partout où la charge de travail dispose d'identifiants AWS : Lambda, EC2, ECS et EKS. Les charges de travail EKS peuvent également utiliser la méthode du jeton projeté Kubernetes, qui nécessite moins d'étapes de configuration mais ne fonctionne qu'à l'intérieur d'un pod.

Ce guide présente les deux méthodes. Pour les concepts sous-jacents (comptes de service, émetteurs de fédération et règles de fédération), consultez Workload Identity Federation.

Prérequis

• Connaissance des concepts WIF : comptes de service, émetteurs de fédération et règles de fédération.
• Une charge de travail AWS (pod EKS, tâche ECS, fonction Lambda ou instance EC2) avec un rôle IAM attaché.
• La CLI aws ou un SDK AWS disponible dans la charge de travail.
• L'autorisation de créer des comptes de service, des émetteurs de fédération et des règles de fédération dans la Claude Console pour votre organisation Anthropic.

Utiliser les jetons d'identité web STS (recommandé)

L'API AWS STS GetWebIdentityToken renvoie un jeton OIDC signé par AWS qui atteste de l'identité IAM de l'appelant. Comme elle utilise les identifiants AWS ambiants de la charge de travail, la même intégration couvre Lambda, EC2, ECS et EKS.

Configurer AWS

Configurer Anthropic

Suivez le guide de configuration pour enregistrer un émetteur de fédération, créer un compte de service Anthropic et créer une règle de fédération dans la Claude Console. Utilisez ces valeurs spécifiques à STS.

Émetteur de fédération : Enregistrez l'URL de l'émetteur STS propre au compte que vous avez copiée à l'étape précédente. Elle expose un point de terminaison JWKS public, utilisez donc le mode découverte.

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

Règle de fédération : Faites correspondre l'audience que vous passez à GetWebIdentityToken et l'ARN du rôle IAM appelant dans la revendication sub. La valeur sub est l'ARN du rôle IAM de la charge de travail qui a appelé l'API, sous la forme arn:aws:iam::<account>:role/<role-name>. Le jeton contient également une revendication https://sts.amazonaws.com/ avec aws_account, org_id, principal_id et tous les request_tags que vous avez passés ; vous pouvez faire correspondre ces éléments avec la map claims de la règle ou une condition CEL pour un contrôle plus fin.

{
  "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
}

Soyez aussi spécifique que la charge de travail le permet. Faites correspondre l'ARN exact du rôle, et n'élargissez subject_prefix (par exemple, à arn:aws:iam::123456789012:role/*) que si plusieurs rôles IAM doivent correspondre au même compte de service Anthropic.

Acquérir et utiliser le jeton

Appelez GetWebIdentityToken avec https://api.anthropic.com comme audience, puis passez le résultat aux identifiants de fédération du SDK. Le fournisseur de jeton est un callable, de sorte que le SDK réinvoque STS à chaque actualisation.

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-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from AWS"}],
)
print(message.content[0].text)

Vérifier la configuration

Depuis l'intérieur de la charge de travail, échangez directement un jeton émis par STS et inspectez la réponse :

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

Un échange réussi renvoie un access_token commençant par sk-ant-oat01- et une valeur expires_in en secondes. En cas de 400 invalid_grant, consultez Dépanner un échange échoué ; la cause la plus courante côté AWS est une incompatibilité de iss (l'URL de l'émetteur STS propre au compte doit correspondre exactement à l'issuer_url enregistrée).

Utiliser les jetons de compte de service projetés EKS

Si votre charge de travail s'exécute dans un pod EKS, vous pouvez ignorer l'appel STS et lire directement depuis le disque un jeton de compte de service projeté par Kubernetes. Kubernetes projette nativement un jeton compatible OIDC dans le pod, et le SDK peut le lire à partir d'un chemin de fichier, donc aucun callable fournisseur de jeton n'est requis. Cette méthode comporte deux étapes de configuration AWS de moins que la méthode STS, mais ne fonctionne qu'à l'intérieur d'un pod ; le mécanisme sous-jacent est le même que celui de l'intégration Kubernetes générique.

Cette méthode nécessite en outre un cluster EKS avec un fournisseur OIDC IAM activé et un accès kubectl au cluster.

Configurer votre cluster EKS

Configurer Anthropic

Suivez le guide de configuration pour enregistrer un émetteur de fédération, créer un compte de service Anthropic et créer une règle de fédération dans la Claude Console. Utilisez ces valeurs spécifiques à EKS.

Émetteur de fédération : Les émetteurs EKS exposent un point de terminaison JWKS public, utilisez donc le mode découverte. L'URL de l'émetteur doit correspondre exactement à la revendication iss du jeton. Enregistrez un émetteur par cluster.

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

Règle de fédération : Faites correspondre la revendication Kubernetes sub et l'audience Anthropic https://api.anthropic.com. (Projetez un jeton de compte de service dédié avec cette audience ; ne réutilisez pas le jeton IRSA par défaut 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
}

Soyez aussi spécifique que la charge de travail le permet. N'assouplissez subject_prefix à system:serviceaccount:inference:* (le * final en fait une correspondance de préfixe) que si chaque compte de service du namespace doit correspondre au même compte de service Anthropic.

Acquérir et utiliser le jeton

À l'intérieur du pod, le jeton projeté se trouve à /var/run/secrets/anthropic.com/token (exposé sous ANTHROPIC_IDENTITY_TOKEN_FILE dans la spécification du Pod). Passez ce fichier aux identifiants de fédération du SDK et le SDK gère l'échange et l'actualisation.

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-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from EKS"}],
)
print(message.content[0].text)

Vérifier la configuration

Depuis l'intérieur du pod, échangez directement le jeton projeté et inspectez la réponse :

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

Un échange réussi renvoie un access_token commençant par sk-ant-oat01- et une valeur expires_in en secondes. En cas de 400 invalid_grant, consultez Dépanner un échange échoué ; la cause la plus courante côté EKS est que l'aud du jeton projeté ne correspond pas à la règle (projetez un jeton avec audience: https://api.anthropic.com, et non le sts.amazonaws.com par défaut d'IRSA).

Délimiter votre règle

Verrouillez le bloc match de la règle à la portée la plus étroite qui convient à votre cas d'usage :

• Fixez l'ARN complet du rôle : Utilisez subject_prefix: "arn:aws:iam::<account>:role/<role-name>" sans * final afin que les autres rôles du compte ne correspondent pas.
• Fixez l'ID du compte : Faites correspondre le champ aws_account de la revendication https://sts.amazonaws.com/ du jeton via la map claims ou une condition CEL comme vérification de défense en profondeur contre un préfixe mal configuré.
• Fixez le namespace et le compte de service sur EKS : Utilisez la valeur exacte system:serviceaccount:<namespace>:<name> sans * après le préfixe system:serviceaccount:.
• Utilisez une règle distincte par environnement : Créez des règles distinctes pour les charges de travail de production, de staging et de développement plutôt que d'élargir un seul préfixe pour les couvrir toutes.

Étapes suivantes

• Consultez la référence WIF pour la référence complète sur la précédence des identifiants, la configuration des profils et la correspondance des règles.
• Pour les clusters Kubernetes autogérés qui ne sont pas sur EKS, consultez Utiliser WIF avec Kubernetes.