WIF mit Google Cloud verwenden

Jede Google Cloud-Compute-Umgebung mit Zugriff auf den Instanz-Metadatenserver (Cloud Run, Cloud Functions, App Engine, Compute Engine (GCE) und GKE mit Workload Identity) kann ein Google-signiertes Identity-Token für das ihr zugeordnete Dienstkonto anfordern. Der Aussteller des Tokens ist https://accounts.google.com, und Anthropic kann es direkt über die standardmäßige OIDC-Discovery validieren, ohne dass eine zusätzliche Google Cloud-Konfiguration erforderlich ist.

Diese Anleitung zeigt, wie du den Google-Issuer bei Anthropic registrierst, ein Google-Dienstkonto an ein Anthropic-Dienstkonto bindest und deinen Workload sein Identity-Token gegen ein kurzlebiges Claude API-Zugriffstoken austauschen lässt.



Voraussetzungen

• Vertrautheit mit den WIF-Konzepten: Dienstkonten, Federation-Issuer und Federation-Regeln.
• Ein Google Cloud-Projekt mit einem Workload, der auf Cloud Run, Cloud Functions, App Engine, Compute Engine oder GKE läuft.
• Ein benutzerverwaltetes Google-Dienstkonto, das diesem Workload zugeordnet ist (nicht das Standard-Dienstkonto von Compute Engine).
• Berechtigung zum Erstellen von Dienstkonten, Federation-Issuern und Federation-Regeln in der Claude Console für deine Anthropic-Organisation.



Google Cloud konfigurieren

Google stellt Identity-Tokens automatisch für jeden Workload mit einem zugeordneten Dienstkonto aus. Auf der Google-Seite muss nichts weiter aktiviert werden, außer das richtige Dienstkonto zuzuordnen, aber die Schritte unterscheiden sich leicht zwischen Standard-Compute und GKE.

gcloud run deploy my-service \
  --service-account [email protected]

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

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

{
  "iss": "https://accounts.google.com",
  "aud": "https://api.anthropic.com",
  "sub": "104892...",
  "azp": "104892...",
  "email": "[email protected]",
  "email_verified": true,
  "exp": 1775527120
}



Anthropic konfigurieren

Öffne in der Claude Console Settings → Workload identity, klicke auf Connect workload und wähle die Kachel Google Cloud aus. Der Assistent führt dich durch die Registrierung des Issuers, die Erstellung eines Dienstkontos und die Erstellung einer Federation-Regel.

Der Assistent erstellt diese Ressourcen für dich. Verwende die folgenden Werte, unabhängig davon, ob du sie im Assistenten eingibst oder an die Admin API sendest:

Federation-Issuer: Google veröffentlicht sein OIDC-Discovery-Dokument öffentlich, verwende also den Discovery-Modus. Dieser eine Issuer deckt jede Google Cloud-Oberfläche ab (Cloud Run, GCE, Cloud Functions, App Engine und GKE mit Workload Identity). Unterscheide Workloads über Regeln, nicht über Issuer.

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

Federation-Regel: Prüfe sowohl auf den sub- als auch auf den email-Claim. email ist die lesbare Dienstkonto-Adresse; sub ist die numerische eindeutige ID des Dienstkontos, die Google niemals wiederverwendet. Das Festlegen dieser ID schützt die Regel also, falls das Dienstkonto gelöscht und später ein neues mit derselben E-Mail-Adresse erstellt wird. Die eindeutige ID findest du mit 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
}



Token abrufen und verwenden

Rufe innerhalb deines Google Cloud-Workloads das Identity-Token vom Metadatenserver ab, tausche es unter POST /v1/oauth/token aus und verwende das zurückgegebene Bearer-Token, um die Claude API aufzurufen. Jedes Anthropic SDK übernimmt den Austausch und die Aktualisierungsschleife für dich, wenn du ein Token-Provider-Callable bereitstellst, das ein frisches Identity-Token vom Metadatenserver zurückgibt, wie in den folgenden Beispielen gezeigt.

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"))

Google-Identity-Tokens laufen nach etwa einer Stunde ab. Die SDKs rufen den Token-Provider erneut auf und führen den Austausch automatisch vor Ablauf erneut durch. Für Shell-Skripte, die länger laufen als das expires_in des Zugriffstokens, aktualisiere über einen Timer und wiederhole den Austausch.



Einrichtung überprüfen

Dekodiere innerhalb deines Workloads das Identity-Token und bestätige, dass die Claims mit deiner Regel übereinstimmen:

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'

Prüfe, dass iss gleich https://accounts.google.com ist, aud gleich https://api.anthropic.com ist und email mit dem Wert in deiner Federation-Regel übereinstimmt. Führe dann den Austausch aus dem vorherigen Abschnitt aus. Ein erfolgreicher Austausch gibt ein access_token zurück, das mit sk-ant-oat01- beginnt, sowie einen expires_in-Wert in Sekunden. Bei 400 invalid_grant siehe Fehlerbehebung bei einem fehlgeschlagenen Austausch; die häufigste Ursache auf Google Cloud-Seite ist ein fehlender email-Claim (fordere das Token mit format=full an, damit er enthalten ist).



Regel einschränken

Beschränke den match-Block der Regel auf den engsten Geltungsbereich, der zu deinem Anwendungsfall passt:

• Prüfe sub exakt: Setze die vollständige numerische eindeutige ID in claims.sub und verwende niemals subject_prefix für Google-Tokens.
• Lege den email-Claim fest: Füge claims.email zusätzlich zu sub hinzu, damit sowohl die stabile ID als auch die lesbare Adresse übereinstimmen müssen.
• Lege die Audience fest: Setze audience auf den exakten Wert, den du vom Metadatenserver anforderst, damit Tokens, die für andere Konsumenten ausgestellt wurden, abgelehnt werden.
• Lege das Projekt auf GKE fest: Füge für format=full-Tokens eine condition wie claims.google.compute_engine.project_id == "my-project" hinzu, um die Regel auf die Nodes eines Projekts zu beschränken.



Nächste Schritte

• Lies die Seite Workload Identity Federation für das vollständige Ressourcenmodell und die SDK-Credential-Priorität.
• Füge eine separate Federation-Regel pro Umgebung (Produktion, Staging) hinzu, damit du eine widerrufen kannst, ohne die anderen zu beeinträchtigen.