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 sua carga de trabalho troque seu token de identidade por um token de acesso de curta duração da Claude API.
O Google emite tokens de identidade automaticamente para qualquer carga de trabalho com uma conta de serviço anexada. Não há nada a habilitar no lado do Google além de anexar a conta de serviço correta, mas os passos diferem ligeiramente entre computação padrão e GKE.
Anexe uma conta de serviço dedicada ao seu serviço ou instância:
gcloud run deploy my-service \
--service-account [email protected]Dentro da carga de trabalho, o servidor de metadados retorna um token de identidade assinado sob demanda. Solicite-o com o audience que você pretende registrar no lado da Anthropic e inclua format=full para que a resposta contenha a claim email:
GET http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://api.anthropic.com&format=full
Metadata-Flavor: GoogleOu, com a CLI do gcloud:
gcloud auth print-identity-token \
--audiences="https://api.anthropic.com" \
--include-emailOs equivalentes em SDK são mostrados em Adquira e use o token.
O payload do token decodificado se parece com isto:
{
"iss": "https://accounts.google.com",
"aud": "https://api.anthropic.com",
"sub": "104892...",
"azp": "104892...",
"email": "[email protected]",
"email_verified": true,
"exp": 1775527120
}A claim sub é o ID numérico único e opaco da conta de serviço do Google. A claim email é o endereço legível da conta de serviço. Faça a correspondência tanto em sub quanto em email na sua regra de federação.
No Claude Console, abra Settings → Workload identity, clique em Connect workload e selecione o bloco Google Cloud. O assistente orienta você no registro do emissor, na criação de uma conta de serviço e na criação de uma regra de federação.
O assistente cria esses recursos para você. Use os seguintes valores, seja inserindo-os no assistente ou enviando-os para a Admin API:
Emissor de federação: o Google publica seu documento de descoberta OIDC publicamente, então use o modo de descoberta. Esse único emissor cobre todas as superfícies do Google Cloud (Cloud Run, GCE, Cloud Functions, App Engine e GKE com Workload Identity). Diferencie cargas de trabalho com regras, não com emissores.
{
"name": "gcp",
"issuer_url": "https://accounts.google.com",
"jwks": { "type": "discovery" }
}Regra de federação: faça a correspondência tanto na claim sub quanto na claim email. email é o endereço legível da conta de serviço; sub é o ID numérico único da conta de serviço, que o Google nunca reutiliza, portanto fixá-lo protege a regra caso a conta de serviço seja excluída e uma nova seja criada posteriormente com o mesmo e-mail. Encontre o ID único 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
}Dentro da sua carga de trabalho 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 Claude API. Cada SDK da Anthropic lida com o loop de troca e renovação para você quando você fornece um callable provedor de token que retorna um token de identidade novo do servidor de metadados, como 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-opus-5",
max_tokens=1024,
messages=[{"role": "user", "content": "Hello from Cloud Run"}],
)
print(next(block.text for block in message.content if block.type == "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 executam por mais tempo do que o expires_in do token de acesso, renove com um temporizador e repita a troca.
De dentro da sua carga de trabalho, 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).
A claim sub do Google é o ID numérico único e opaco da conta de serviço e
não tem um prefixo estável. Um subject_prefix com um * no final corresponde a
contas de serviço arbitrárias em todos os projetos do Google Cloud, e qualquer uma
delas poderia obter um token federado da Anthropic.
Restrinja o bloco match da regra ao escopo mais estreito que atenda ao seu caso de uso:
sub exatamente: defina o ID numérico único completo em claims.sub e nunca use subject_prefix para tokens do Google.email: adicione claims.email junto com sub para que tanto o ID estável quanto o endereço legível precisem corresponder.audience com o valor exato que você solicita do servidor de metadados para que tokens emitidos para outros consumidores sejam rejeitados.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.Was this page helpful?