Claude Platform Docs
AdministrationFournisseurs d'identité

Utiliser WIF avec Google Cloud

Fédérez les charges de travail Google Cloud (Cloud Run, Cloud Functions, App Engine, GCE, GKE) vers l'API Claude à l'aide de jetons d'identité signés par Google au lieu de clés API statiques.

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 le compte de service qui lui est attaché. 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

  • Une 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 attaché à 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é pour toute charge de travail disposant d'un compte de service attaché. Il n'y a rien à activer du côté de Google au-delà de l'attachement du bon compte de service, mais les étapes diffèrent légèrement entre le calcul standard et GKE.

Attachez un compte de service dédié à votre service ou instance :

CLI
gcloud run deploy my-service \
  --service-account inference-worker@my-project.iam.gserviceaccount.com

À l'intérieur de la charge de travail, le serveur de métadonnées renvoie un jeton d'identité signé à la demande. Demandez-le avec l'audience que vous avez l'intention d'enregistrer du côté d'Anthropic, et incluez format=full afin que la réponse contienne la revendication (claim) email :

GET http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://api.anthropic.com&format=full
Metadata-Flavor: Google

Ou, avec la CLI gcloud :

CLI
gcloud auth print-identity-token \
  --audiences="https://api.anthropic.com" \
  --include-email

Les équivalents SDK sont présentés dans Acquérir et utiliser le jeton.

La charge utile décodée du jeton ressemble à ceci :

{
  "iss": "https://accounts.google.com",
  "aud": "https://api.anthropic.com",
  "sub": "104892...",
  "azp": "104892...",
  "email": "inference-worker@my-project.iam.gserviceaccount.com",
  "email_verified": true,
  "exp": 1775527120
}

La revendication sub est l'identifiant unique numérique opaque du compte de service Google. La revendication email est l'adresse lisible du compte de service. Faites correspondre à la fois sub et email dans votre règle de fédération.

Configurer Anthropic

Dans la Claude Console, ouvrez Settings → Workload identity, cliquez sur Connect workload et sélectionnez la tuile Google Cloud. L'assistant vous guide à travers l'enregistrement de l'émetteur, la création d'un compte de service et la création d'une règle de fédération.

L'assistant crée ces ressources pour vous. Utilisez les valeurs suivantes, que vous les saisissiez dans l'assistant ou que vous les envoyiez à l'Admin API :

É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, et non avec des émetteurs.

{
  "name": "gcp",
  "issuer_url": "https://accounts.google.com",
  "jwks": { "type": "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, de sorte que 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 e-mail. 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": "inference-worker@my-project.iam.gserviceaccount.com"
    }
  },
  "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 pour vous la boucle d'échange et de renouvellement 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-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"))

Les jetons d'identité Google expirent après environ une heure. Les SDK réinvoquent le fournisseur de jeton et effectuent à nouveau 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, renouvelez selon 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
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 de 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. Si l'échange échoue avec la réponse opaque 401 authentication_error (message Authentication failed), consultez la page d'historique d'authentification pour connaître la raison du refus et reportez-vous à 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 sur 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 sur 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 l'ordre de priorité des identifiants dans les SDK.
  • Ajoutez une règle de fédération distincte par environnement (production, préproduction) afin de pouvoir en révoquer une sans affecter les autres.

Was this page helpful?