Run several applications on one EKS cluster and give the worker nodes an IAM role that can call Claude Platform on AWS, and you've quietly granted every pod on those nodes that access — the billing dashboard, the log shipper, the intern's test deployment. IRSA (IAM Roles for Service Accounts) is AWS's fix for Kubernetes: it maps a Kubernetes service account to a specific IAM role, so the identity boundary moves from the node down to the pod.
How IRSA reaches the Anthropic SDK
IRSA is a specialization of web identity federation. A pod annotated with a service account that's mapped to an IAM role receives a projected identity token, and the pod's environment carries two variables: AWS_WEB_IDENTITY_TOKEN_FILE (the token's path) and AWS_ROLE_ARN (the role to assume). That pair is a documented link in the AWS default credential provider chain that the AnthropicAWS client reads — Anthropic's docs list web identity via exactly these variables, naming IRSA as the canonical case. The SDK exchanges the token for short-lived role credentials and SigV4-signs every request, session token included, with no code changes.
Notably, web identity sits above container credentials and instance metadata in the chain — so once IRSA is configured, the pod's own role reliably wins over any node-level role, which is precisely the behavior you want.
The pattern, end to end
The cluster-side prerequisites (associating an OIDC identity provider with the cluster, creating the role with a trust policy pinned to the service account, annotating the service account with the role ARN) are standard EKS configuration — follow the official AWS documentation for the current steps. The Claude-specific parts are the policy and the pod spec:
1. One role per application, scoped to its workspace. Give each service account's role the minimal inference policy on that application's workspace ARN only:
{"Version": "2012-10-17", "Statement": [{
"Sid": "PodScopedInference",
"Effect": "Allow",
"Action": ["aws-external-anthropic:CreateInference",
"aws-external-anthropic:CountTokens",
"aws-external-anthropic:GetModel",
"aws-external-anthropic:ListModels"],
"Resource": "arn:aws:aws-external-anthropic:us-west-2:123456789012:workspace/wrkspc_01AbCdEf23GhIj"
}]}2. Configure the two non-secret values in the pod. Set AWS_REGION (the workspace's region — the client has no default and raises at construction without it) and ANTHROPIC_AWS_WORKSPACE_ID as ordinary environment variables in the deployment manifest. Neither is sensitive, so no Kubernetes Secret is needed for either.
3. Ship credential-free code.
from anthropic import AnthropicAWS
client = AnthropicAWS() # IRSA web-identity creds via the chain
resp = client.messages.create(
model="claude-sonnet-5",
max_tokens=1024,
messages=[{"role": "user", "content": "Classify this ticket: ..."}],
)Troubleshooting the usual suspects
Pod uses the node role instead of the IRSA role. The web-identity env vars aren't present — usually a missing or misspelled service-account annotation, or the pod isn't using the annotated service account. Inspect the pod's environment for AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN.
Chain shadowing. Environment variables sit above web identity in the chain: an AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY pair injected from an old Secret will silently override IRSA. Remove static keys from the manifest entirely — that's the point of the exercise (see the credential chain).
403 after successful auth. The role assumed correctly but the policy lacks a required aws-external-anthropic: action, or the pod's ANTHROPIC_AWS_WORKSPACE_ID points at a workspace the role isn't allowed to touch. Cross-check against the actions reference.
Every request fails with a federation error. "Outbound web identity federation is disabled for your account" is the account-level prerequisite (aws iam enable-outbound-web-identity-federation) — unrelated to IRSA despite the similar name.
Where to go next
The general federation picture (CI systems, external IdPs) is in workload identity federation; simpler compute gets simpler patterns in EC2 instance roles and ECS/Fargate. Policy building blocks are in the IAM policy templates.