Usar WIF con AWS

Las cargas de trabajo de AWS pueden autenticarse ante la API de Claude sin claves de API estáticas intercambiando un token de identidad OIDC firmado por AWS. La ruta recomendada llama a la API GetWebIdentityToken de AWS STS, que funciona en cualquier lugar donde la carga de trabajo tenga credenciales de AWS: Lambda, EC2, ECS y EKS. Las cargas de trabajo de EKS pueden usar alternativamente la ruta de token proyectado de Kubernetes, que tiene menos pasos de configuración pero solo funciona dentro de un pod.

Esta guía muestra ambas rutas. Para los conceptos subyacentes (cuentas de servicio, emisores de federación y reglas de federación), consulta Workload Identity Federation.

Requisitos previos

• Familiaridad con los conceptos de WIF: cuentas de servicio, emisores de federación y reglas de federación.
• Una carga de trabajo de AWS (pod de EKS, tarea de ECS, función de Lambda o instancia de EC2) con un rol de IAM adjunto.
• La CLI aws o un SDK de AWS disponible en la carga de trabajo.
• Permiso para crear cuentas de servicio, emisores de federación y reglas de federación en Claude Console para tu organización de Anthropic.

Usar tokens de identidad web de STS (recomendado)

La API GetWebIdentityToken de AWS STS devuelve un token OIDC firmado por AWS que afirma la identidad de IAM del llamador. Como usa las credenciales de AWS ambientales de la carga de trabajo, la misma integración cubre Lambda, EC2, ECS y EKS.

Configurar AWS

Configurar Anthropic

Sigue el tutorial de configuración para registrar un emisor de federación, crear una cuenta de servicio de Anthropic y crear una regla de federación en Claude Console. Usa estos valores específicos de STS.

Emisor de federación: Registra la URL del emisor de STS por cuenta que copiaste en el paso anterior. Expone un endpoint JWKS público, así que usa el modo de descubrimiento.

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

Regla de federación: Haz coincidir la audiencia que pasas a GetWebIdentityToken y el ARN del rol de IAM del rol llamador en el claim sub. El valor de sub es el ARN del rol de IAM de la carga de trabajo que llamó a la API, con la forma arn:aws:iam::<account>:role/<role-name>. El token también incluye un claim https://sts.amazonaws.com/ con aws_account, org_id, principal_id y cualquier request_tags que hayas pasado; puedes hacer coincidir esos valores con el mapa claims de la regla o una condition de CEL para un control más fino.

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

Sé tan específico como la carga de trabajo lo permita. Haz coincidir el ARN exacto del rol, y solo amplía subject_prefix (por ejemplo, a arn:aws:iam::123456789012:role/*) si varios roles de IAM deben asignarse a la misma cuenta de servicio de Anthropic.

Adquirir y usar el token

Llama a GetWebIdentityToken con https://api.anthropic.com como audiencia, luego pasa el resultado a las credenciales de federación del SDK. El proveedor de tokens es un callable, por lo que el SDK vuelve a invocar a STS en cada actualización.

Verificar la configuración

Desde dentro de la carga de trabajo, intercambia un token emitido por STS directamente e inspecciona la respuesta:

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 intercambio exitoso devuelve un access_token que comienza con sk-ant-oat01- y un valor expires_in en segundos. Si recibes 400 invalid_grant, consulta Solucionar problemas de un intercambio fallido; la causa más común del lado de AWS es una discrepancia de iss (la URL del emisor de STS por cuenta debe coincidir exactamente con la issuer_url registrada).

Usar tokens de cuenta de servicio proyectados de EKS

Si tu carga de trabajo se ejecuta en un pod de EKS, puedes omitir la llamada a STS y leer un token de cuenta de servicio proyectado por Kubernetes directamente desde el disco. Kubernetes proyecta de forma nativa un token compatible con OIDC en el pod, y el SDK puede leerlo desde una ruta de archivo, por lo que no se requiere un callable proveedor de tokens. Esta ruta tiene dos pasos de configuración de AWS menos que la ruta de STS, pero solo funciona dentro de un pod; el mecanismo subyacente es el mismo que el de la integración genérica de Kubernetes.

Esta ruta requiere adicionalmente un clúster de EKS con un proveedor OIDC de IAM habilitado y acceso kubectl al clúster.

Configurar tu clúster de EKS

Configurar Anthropic

Sigue el tutorial de configuración para registrar un emisor de federación, crear una cuenta de servicio de Anthropic y crear una regla de federación en Claude Console. Usa estos valores específicos de EKS.

Emisor de federación: Los emisores de EKS exponen un endpoint JWKS público, así que usa el modo de descubrimiento. La URL del emisor debe coincidir exactamente con el claim iss del token. Registra un emisor por clúster.

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

Regla de federación: Haz coincidir el claim sub de Kubernetes y la audiencia de Anthropic https://api.anthropic.com. (Proyecta un token de cuenta de servicio dedicado con esa audiencia; no reutilices el token predeterminado de 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
}

Sé tan específico como la carga de trabajo lo permita. Relaja subject_prefix a system:serviceaccount:inference:* (el * final lo convierte en una coincidencia de prefijo) solo si todas las cuentas de servicio del namespace deben asignarse a la misma cuenta de servicio de Anthropic.

Adquirir y usar el token

Dentro del pod, el token proyectado está en /var/run/secrets/anthropic.com/token (expuesto como ANTHROPIC_IDENTITY_TOKEN_FILE en la especificación del Pod). Pasa ese archivo a las credenciales de federación del SDK y el SDK se encarga del intercambio y la actualización.

Verificar la configuración

Desde dentro del pod, intercambia el token proyectado directamente e inspecciona la respuesta:

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 intercambio exitoso devuelve un access_token que comienza con sk-ant-oat01- y un valor expires_in en segundos. Si recibes 400 invalid_grant, consulta Solucionar problemas de un intercambio fallido; la causa más común del lado de EKS es que el aud del token proyectado no coincida con la regla (proyecta un token con audience: https://api.anthropic.com, no el predeterminado de IRSA sts.amazonaws.com).

Delimitar el alcance de tu regla

Restringe el bloque match de la regla al alcance más estrecho que se ajuste a tu caso de uso:

• Fija el ARN completo del rol: Usa subject_prefix: "arn:aws:iam::<account>:role/<role-name>" sin * final para que otros roles de la cuenta no coincidan.
• Fija el ID de la cuenta: Haz coincidir el campo aws_account del claim https://sts.amazonaws.com/ del token mediante el mapa claims o una condition de CEL como una verificación de defensa en profundidad contra un prefijo mal configurado.
• Fija el namespace y la cuenta de servicio en EKS: Usa el valor exacto system:serviceaccount:<namespace>:<name> sin * después del prefijo system:serviceaccount:.
• Usa una regla separada por entorno: Crea reglas distintas para cargas de trabajo de producción, staging y desarrollo en lugar de ampliar un solo prefijo para cubrirlas todas.

Próximos pasos

• Revisa la referencia de WIF para la referencia completa de precedencia de credenciales, configuración de perfiles y coincidencia de reglas.
• Para clústeres de Kubernetes autogestionados que no están en EKS, consulta Usar WIF con Kubernetes.