Utiliser WIF avec Google Cloud

Tout environnement de calcul Google Cloud ayant accès au serveur de métadonnées d'instance (Cloud Run, Cloud Functions, App Engine, Compute Engine (GCE) et GKE avec Workload Identity) peut demander un jeton d'identité signé par Google pour son compte de service associé. L'émetteur du jeton est https://accounts.google.com, et Anthropic peut le valider directement via la découverte OIDC standard, sans aucune configuration Google Cloud supplémentaire requise.

Ce guide montre comment enregistrer l'émetteur Google auprès d'Anthropic, lier un compte de service Google à un compte de service Anthropic, et faire en sorte que votre charge de travail échange son jeton d'identité contre un jeton d'accès à l'API Claude de courte durée.

Prérequis

• Familiarité avec les concepts WIF : comptes de service, émetteurs de fédération et règles de fédération.
• Un projet Google Cloud avec une charge de travail s'exécutant sur Cloud Run, Cloud Functions, App Engine, Compute Engine ou GKE.
• Un compte de service Google géré par l'utilisateur associé à cette charge de travail (et non le compte de service par défaut de Compute Engine).
• L'autorisation de créer des comptes de service, des émetteurs de fédération et des règles de fédération dans la Claude Console pour votre organisation Anthropic.

Configurer Google Cloud

Google émet automatiquement des jetons d'identité à toute charge de travail disposant d'un compte de service associé. Il n'y a rien à activer côté Google au-delà de l'association du bon compte de service, mais les étapes diffèrent légèrement entre le calcul standard et GKE.

Configurer Anthropic

Suivez le guide de configuration pour enregistrer un émetteur de fédération, créer un compte de service Anthropic et créer une règle de fédération dans la Claude Console. Utilisez ces valeurs spécifiques à Google Cloud.

Émetteur de fédération : Google publie son document de découverte OIDC publiquement, utilisez donc le mode découverte. Cet émetteur unique couvre toutes les surfaces Google Cloud (Cloud Run, GCE, Cloud Functions, App Engine et GKE avec Workload Identity). Différenciez les charges de travail avec des règles, pas avec des émetteurs.

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

Règle de fédération : Faites correspondre à la fois les revendications sub et email. email est l'adresse lisible du compte de service ; sub est l'identifiant unique numérique du compte de service, que Google ne réutilise jamais, donc l'épingler protège la règle si le compte de service est supprimé et qu'un nouveau est créé ultérieurement avec le même email. Trouvez l'identifiant unique avec 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
}

Acquérir et utiliser le jeton

À l'intérieur de votre charge de travail Google Cloud, récupérez le jeton d'identité depuis le serveur de métadonnées, échangez-le via POST /v1/oauth/token, et utilisez le jeton bearer renvoyé pour appeler l'API Claude. Chaque SDK Anthropic gère l'échange et la boucle de rafraîchissement pour vous lorsque vous fournissez un callable fournisseur de jeton qui renvoie un jeton d'identité frais depuis le serveur de métadonnées, comme illustré dans les exemples suivants.

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)

Les jetons d'identité Google expirent après environ une heure. Les SDK réinvoquent le fournisseur de jeton et réexécutent l'échange automatiquement avant l'expiration. Pour les scripts shell qui s'exécutent plus longtemps que la valeur expires_in du jeton d'accès, rafraîchissez sur un minuteur et répétez l'échange.

Vérifier la configuration

Depuis l'intérieur de votre charge de travail, décodez le jeton d'identité et confirmez que les revendications correspondent à votre règle :

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'

Vérifiez que iss est https://accounts.google.com, que aud est https://api.anthropic.com, et que email correspond à la valeur dans votre règle de fédération. Exécutez ensuite l'échange de la section précédente. Un échange réussi renvoie un access_token commençant par sk-ant-oat01- et une valeur expires_in en secondes. En cas de 400 invalid_grant, consultez Dépanner un échange échoué ; la cause la plus courante côté Google Cloud est l'absence de la revendication email (demandez le jeton avec format=full pour qu'elle soit incluse).

Restreindre la portée de votre règle

Verrouillez le bloc match de la règle à la portée la plus étroite qui convient à votre cas d'usage :

• Faites correspondre sub exactement : Définissez l'identifiant unique numérique complet dans claims.sub et n'utilisez jamais subject_prefix pour les jetons Google.
• Épinglez la revendication email : Ajoutez claims.email aux côtés de sub afin que l'identifiant stable et l'adresse lisible doivent tous deux correspondre.
• Épinglez l'audience : Définissez audience à la valeur exacte que vous demandez au serveur de métadonnées afin que les jetons émis pour d'autres consommateurs soient rejetés.
• Épinglez le projet sur GKE : Pour les jetons format=full, ajoutez une condition telle que claims.google.compute_engine.project_id == "my-project" pour restreindre la règle aux nœuds d'un seul projet.

Étapes suivantes

• Lisez la page Workload Identity Federation pour le modèle de ressources complet et la priorité des identifiants SDK.
• Ajoutez une règle de fédération distincte par environnement (production, staging) afin de pouvoir en révoquer une sans affecter les autres.