Usar WIF com Google Cloud

Qualquer ambiente de computação do Google Cloud com acesso ao servidor de metadados da instância (Cloud Run, Cloud Functions, App Engine, Compute Engine (GCE) e GKE com Workload Identity) pode solicitar um token de identidade assinado pelo Google para sua conta de serviço anexada. O emissor do token é https://accounts.google.com, e a Anthropic pode validá-lo diretamente por meio da descoberta OIDC padrão, sem necessidade de configuração adicional no Google Cloud.

Este guia mostra como registrar o emissor do Google na Anthropic, vincular uma conta de serviço do Google a uma conta de serviço da Anthropic e fazer com que seu workload troque seu token de identidade por um token de acesso de curta duração da API do Claude.

Pré-requisitos

• Familiaridade com os conceitos de WIF: contas de serviço, emissores de federação e regras de federação.
• Um projeto do Google Cloud com um workload em execução no Cloud Run, Cloud Functions, App Engine, Compute Engine ou GKE.
• Uma conta de serviço do Google gerenciada pelo usuário anexada a esse workload (não a conta de serviço padrão do Compute Engine).
• Permissão para criar contas de serviço, emissores de federação e regras de federação no Claude Console para sua organização da Anthropic.

Configurar o Google Cloud

O Google emite tokens de identidade automaticamente para qualquer workload com uma conta de serviço anexada. Não há nada a habilitar do lado do Google além de anexar a conta de serviço correta, mas as etapas diferem ligeiramente entre computação padrão e GKE.

Configurar a Anthropic

Siga o passo a passo de configuração para registrar um emissor de federação, criar uma conta de serviço da Anthropic e criar uma regra de federação no Claude Console. Use estes valores específicos do Google Cloud.

Emissor de federação: o Google publica seu documento de descoberta OIDC publicamente, então use o modo de descoberta. Este único emissor cobre todas as superfícies do Google Cloud (Cloud Run, GCE, Cloud Functions, App Engine e GKE com Workload Identity). Diferencie workloads com regras, não com emissores.

{
  "name": "gcp",
  "issuer_url": "https://accounts.google.com",
  "jwks_source": "discovery"
}

Regra de federação: faça a correspondência tanto da claim sub quanto da claim email. email é o endereço legível da conta de serviço; sub é o ID numérico exclusivo da conta de serviço, que o Google nunca reutiliza, então fixá-lo protege a regra caso a conta de serviço seja excluída e uma nova seja criada posteriormente com o mesmo email. Encontre o ID exclusivo com gcloud iam service-accounts describe SA_EMAIL --format='value(uniqueId)'.

{
  "name": "gcp-inference-worker",
  "issuer_id": "fdis_...",
  "match": {
    "audience": "https://api.anthropic.com",
    "claims": {
      "sub": "104892101234567890123",
      "email": "[email protected]"
    }
  },
  "target": {
    "type": "service_account",
    "service_account_id": "svac_..."
  },
  "workspace_id": "wrkspc_...",
  "oauth_scope": "workspace:developer",
  "token_lifetime_seconds": 600
}

Obter e usar o token

Dentro do seu workload do Google Cloud, obtenha o token de identidade do servidor de metadados, troque-o em POST /v1/oauth/token e use o bearer token retornado para chamar a API do Claude. Cada SDK da Anthropic cuida da troca e do ciclo de renovação para você quando você fornece um callable provedor de token que retorna um token de identidade novo do servidor de metadados, conforme mostrado nos exemplos a seguir.

import os
import anthropic
import google.auth.transport.requests
import google.oauth2.id_token
from anthropic import WorkloadIdentityCredentials

AUDIENCE = "https://api.anthropic.com"


def fetch_google_identity_token() -> str:
    request = google.auth.transport.requests.Request()
    return google.oauth2.id_token.fetch_id_token(request, AUDIENCE)


client = anthropic.Anthropic(
    credentials=WorkloadIdentityCredentials(
        identity_token_provider=fetch_google_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 Cloud Run"}],
)
print(message.content[0].text)

Os tokens de identidade do Google expiram após aproximadamente uma hora. Os SDKs reinvocam o provedor de token e refazem a troca automaticamente antes da expiração. Para scripts de shell que rodam por mais tempo que o expires_in do token de acesso, renove com um temporizador e repita a troca.

Verificar a configuração

De dentro do seu workload, decodifique o token de identidade e confirme que as claims correspondem à sua regra:

curl -sS -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://api.anthropic.com&format=full" \
  | jq -rR 'split(".")[1] | gsub("-";"+") | gsub("_";"/") | @base64d | fromjson'

Verifique se iss é https://accounts.google.com, aud é https://api.anthropic.com e email corresponde ao valor na sua regra de federação. Em seguida, execute a troca da seção anterior. Uma troca bem-sucedida retorna um access_token começando com sk-ant-oat01- e um valor expires_in em segundos. Em caso de 400 invalid_grant, consulte Solucionar problemas de uma troca com falha; a causa mais comum do lado do Google Cloud é a ausência da claim email (solicite o token com format=full para que ela seja incluída).

Delimitar o escopo da sua regra

Restrinja o bloco match da regra ao escopo mais estreito que se adeque ao seu caso de uso:

• Corresponder sub exatamente: defina o ID numérico exclusivo completo em claims.sub e nunca use subject_prefix para tokens do Google.
• Fixar a claim email: adicione claims.email junto com sub para que tanto o ID estável quanto o endereço legível precisem corresponder.
• Fixar o audience: defina audience com o valor exato que você solicita do servidor de metadados, para que tokens emitidos para outros consumidores sejam rejeitados.
• Fixar o projeto no GKE: para tokens format=full, adicione uma condition como claims.google.compute_engine.project_id == "my-project" para restringir a regra aos nós de um único projeto.

Próximos passos

• Leia a página Workload Identity Federation para conhecer o modelo completo de recursos e a precedência de credenciais do SDK.
• Adicione uma regra de federação separada por ambiente (produção, staging) para que você possa revogar uma sem afetar as outras.