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 프로젝션 토큰 경로를 사용할 수 있으며, 이 경로는 구성 단계가 더 적지만 파드 내부에서만 작동합니다.
이 가이드는 두 경로를 모두 보여줍니다. 기본 개념(서비스 계정, 페더레이션 발급자, 페더레이션 규칙)에 대해서는 Workload Identity Federation을 참조하세요.
사전 요구 사항
- WIF 개념에 대한 이해: 서비스 계정, 페더레이션 발급자, 페더레이션 규칙.
- IAM 역할이 연결된 AWS 워크로드(EKS 파드, ECS 태스크, Lambda 함수 또는 EC2 인스턴스).
- 워크로드에서 사용 가능한
awsCLI 또는 AWS SDK. - Anthropic 조직에 대해 Claude Console에서 서비스 계정, 페더레이션 발급자, 페더레이션 규칙을 생성할 수 있는 권한.
STS 웹 ID 토큰 사용(권장)
AWS STS GetWebIdentityToken API는 호출자의 IAM ID를 증명하는, AWS가 서명한 OIDC 토큰을 반환합니다. 워크로드의 주변(ambient) AWS 자격 증명을 사용하기 때문에 동일한 통합으로 Lambda, EC2, ECS, EKS를 모두 지원합니다.
AWS 구성
계정에 대해 아웃바운드 웹 ID 페더레이션 활성화
이는 계정 수준 플래그이며 기본적으로 꺼져 있습니다. AWS 콘솔에서 IAM을 열고 Account settings를 선택한 다음 Outbound web identity federation을 활성화하세요. 프로그래밍 방식으로 활성화하려면:
python3 -c "import boto3; boto3.client('iam').enable_outbound_web_identity_federation()"이 기능이 활성화되어 있지 않으면
GetWebIdentityToken호출이OutboundWebIdentityFederationDisabledException으로 실패합니다.워크로드의 IAM 역할에 API 호출 권한 부여
Lambda 함수, EC2 인스턴스 또는 ECS 태스크가 실행되는 IAM 역할에 다음 정책을 연결하세요:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["sts:GetWebIdentityToken"], "Resource": "*" } ] }계정의 STS 발급자 URL 찾기
아웃바운드 페더레이션을 활성화하면 IAM > Account settings 페이지에
https://<uuid>.tokens.sts.global.api.aws형식의 값을 가진 Get Token Issuer URL 필드가 표시됩니다. 이 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에 전달하는 audience와 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을 audience로 하여 GetWebIdentityToken을 호출한 다음, 결과를 SDK의 페더레이션 자격 증명에 전달하세요. 토큰 제공자는 호출 가능한 객체(callable)이므로 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 발급 토큰을 직접 교환하고 응답을 확인하세요:
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 프로젝션 서비스 계정 토큰 사용
워크로드가 EKS 파드에서 실행되는 경우 STS 호출을 건너뛰고 Kubernetes가 프로젝션한 서비스 계정 토큰을 디스크에서 직접 읽을 수 있습니다. Kubernetes는 기본적으로 OIDC 호환 토큰을 파드에 프로젝션하며, SDK는 파일 경로에서 이를 읽을 수 있으므로 토큰 제공자 callable이 필요하지 않습니다. 이 경로는 STS 경로보다 AWS 구성 단계가 두 개 적지만 파드 내부에서만 작동합니다. 기본 메커니즘은 일반 Kubernetes 통합과 동일합니다.
이 경로에는 추가로 IAM OIDC 제공자가 활성화된 EKS 클러스터와 클러스터에 대한 kubectl 액세스가 필요합니다.
EKS 클러스터 구성
클러스터의 OIDC 발급자 URL 찾기
각 EKS 클러스터에는 고유한 OIDC 발급자가 있습니다. AWS CLI로 가져오세요:
CLIaws 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 audience 토큰 프로젝션
EKS 파드 ID 웹훅은
eks.amazonaws.com/role-arn어노테이션을 감지하고aud: sts.amazonaws.com을 가진 토큰을 자동으로 프로젝션하며, 그 경로를AWS_WEB_IDENTITY_TOKEN_FILE로 노출합니다. 해당 토큰은 AWS 역할 수임용입니다. Anthropic 교환을 위해서는audience: https://api.anthropic.com으로 두 번째 토큰을 프로젝션하고 전용 경로에 마운트하세요.apiVersion: v1 kind: ServiceAccount metadata: name: inference-worker namespace: inference annotations: eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/inference-workerapiVersion: 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토큰의 클레임 형태 확인
프로젝션된 토큰은 클러스터의 OIDC 발급자가 서명한 "JSON Web Token"(JSON 웹 토큰), 즉 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프로젝션은aud를https://api.anthropic.com으로 설정합니다.AWS_WEB_IDENTITY_TOKEN_FILE에 있는 별도의 IRSA 주입 토큰은aud: sts.amazonaws.com을 가지며 이 교환이 아닌 AWS API 호출용입니다.
Anthropic 구성
Claude Console에서 Settings → Workload identity를 열고 Connect workload를 클릭한 다음 AWS 타일을 선택하세요. 마법사가 발급자 등록, 서비스 계정 생성, 페더레이션 규칙 생성 과정을 안내합니다.
마법사가 이러한 리소스를 대신 생성해 줍니다. 마법사에 입력하든 Admin API로 전송하든 다음 값을 사용하세요:
페더레이션 발급자: EKS 발급자는 공개 JWKS 엔드포인트를 노출하므로 디스커버리 모드를 사용하세요. 발급자 URL은 토큰의 iss 클레임과 정확히 일치해야 합니다. 클러스터당 하나의 발급자를 등록하세요.
{
"name": "prod-eks-uswest2",
"issuer_url": "https://oidc.eks.us-west-2.amazonaws.com/id/6FA42E7BFDE8549CB...",
"jwks": { "type": "discovery" }
}페더레이션 규칙: Kubernetes sub 클레임과 Anthropic audience https://api.anthropic.com을 매칭하세요. (해당 audience로 전용 서비스 계정 토큰을 프로젝션하세요. 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:*로 완화하세요(끝의 *는 접두사 매칭을 의미합니다).
토큰 획득 및 사용
파드 내부에서 프로젝션된 토큰은 /var/run/secrets/anthropic.com/token에 있습니다(Pod 스펙에서 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"))설정 확인
파드 내부에서 프로젝션된 토큰을 직접 교환하고 응답을 확인하세요:
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 측에서 가장 흔한 원인은 프로젝션된 토큰의 aud가 규칙과 일치하지 않는 것입니다(IRSA 기본값인 sts.amazonaws.com이 아니라 audience: https://api.anthropic.com으로 토큰을 프로젝션하세요).
규칙 범위 지정
규칙의 match 블록을 사용 사례에 맞는 가장 좁은 범위로 제한하세요:
- 전체 역할 ARN 고정: 계정의 다른 역할이 매칭되지 않도록 끝에
*없이subject_prefix: "arn:aws:iam::<account>:role/<role-name>"을 사용하세요. - 계정 ID 고정: 잘못 구성된 접두사에 대한 심층 방어 검사로서,
claims맵이나 CELcondition을 사용하여 토큰의https://sts.amazonaws.com/클레임의aws_account필드를 매칭하세요. - EKS에서 네임스페이스와 서비스 계정 고정:
system:serviceaccount:접두사 뒤에*없이 정확한system:serviceaccount:<namespace>:<name>값을 사용하세요. - 환경별로 별도의 규칙 사용: 하나의 접두사를 넓혀 모두를 포괄하기보다는 프로덕션, 스테이징, 개발 워크로드에 대해 각각 별도의 규칙을 생성하세요.
다음 단계
- 전체 자격 증명 우선순위, 프로필 구성, 규칙 매칭 레퍼런스는 WIF 레퍼런스를 검토하세요.
- EKS가 아닌 자체 관리형 Kubernetes 클러스터의 경우 Kubernetes에서 WIF 사용하기를 참조하세요.
Was this page helpful?