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 Identitätstoken für ihr zugeordnetes Service-Konto anfordern. Der Issuer des Tokens ist https://accounts.google.com, und Anthropic kann es direkt über die standardmäßige OIDC-Discovery validieren, ohne dass zusätzliche Google Cloud-Konfiguration erforderlich ist.

Diese Anleitung zeigt, wie du den Google-Issuer bei Anthropic registrierst, ein Google-Service-Konto an ein Anthropic-Service-Konto bindest und deine Workload ihr Identitätstoken gegen ein kurzlebiges Claude API-Zugriffstoken austauschen lässt.



Voraussetzungen

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



Google Cloud konfigurieren

Google stellt Identitätstoken automatisch für jede Workload mit einem zugeordneten Service-Konto aus. Auf der Google-Seite muss nichts aktiviert werden, außer das richtige Service-Konto 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, das Erstellen eines Service-Kontos und das Erstellen 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 einzelne Issuer deckt jede Google Cloud-Oberfläche ab (Cloud Run, GCE, Cloud Functions, App Engine und GKE mit Workload Identity). Unterscheide Workloads mit Regeln, nicht mit Issuern.

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

Federation-Regel: Matche sowohl auf den sub- als auch auf den email-Claim. email ist die lesbare Service-Konto-Adresse; sub ist die numerische eindeutige ID des Service-Kontos, die Google niemals wiederverwendet, sodass das Festlegen dieser ID die Regel schützt, falls das Service-Konto gelöscht und später ein neues mit derselben E-Mail erstellt wird. Finde die eindeutige ID 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 deiner Google Cloud-Workload das Identitätstoken vom Metadatenserver ab, tausche es bei 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 Refresh-Schleife für dich, wenn du ein Token-Provider-Callable bereitstellst, das ein frisches Identitätstoken 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-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from Cloud Run"}],
)
print(message.content[0].text)

Google-Identitätstoken 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 als das expires_in des Zugriffstokens laufen, aktualisiere per Timer und wiederhole den Austausch.



Setup überprüfen

Dekodiere innerhalb deiner Workload das Identitätstoken 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'

Überprüfe, dass iss https://accounts.google.com ist, aud 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, und einen expires_in-Wert in Sekunden. Bei 400 invalid_grant siehe Fehlgeschlagenen Austausch beheben; die häufigste Ursache auf der Google Cloud-Seite ist ein fehlender email-Claim (fordere das Token mit format=full an, damit er enthalten ist).



Regel eingrenzen

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

• sub exakt matchen: Setze die vollständige numerische eindeutige ID in claims.sub und verwende niemals subject_prefix für Google-Token.
• email-Claim festlegen: Füge claims.email neben sub hinzu, sodass sowohl die stabile ID als auch die lesbare Adresse übereinstimmen müssen.
• Audience festlegen: Setze audience auf den exakten Wert, den du vom Metadatenserver anforderst, damit Token, die für andere Consumer ausgestellt wurden, abgelehnt werden.
• Projekt auf GKE festlegen: Füge für format=full-Token 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.