If your Claude application runs on Google Kubernetes Engine (GKE), it needs Google Cloud credentials to call Vertex AI. The tempting shortcut — export a JSON key for a service account and mount it into the pod — creates a long-lived secret that can leak through images, repositories, and logs, and that someone must remember to rotate. Workload Identity Federation for GKE removes the key entirely: your Kubernetes workload proves its identity to Google Cloud directly, and Google issues short-lived credentials on the fly.
Why this works without touching your Claude code
The AnthropicVertex Python client authenticates through Application Default Credentials (ADC) — Google's standard credential discovery chain (the TypeScript SDK goes through the standard google-auth-library flow). ADC checks, in order, an explicitly configured key file, then the credentials of the environment it is running in. On a GKE cluster with Workload Identity configured, the environment provides credentials for the Google identity your Kubernetes service account is bound to. The practical consequence: the same code runs on a laptop (via gcloud auth application-default login), in CI, and in a pod, with no auth branches.
from anthropic import AnthropicVertex
# No key file, no api_key. ADC resolves the pod's federated identity.
client = AnthropicVertex(project_id="my-project", region="global")
message = client.messages.create(
model="claude-opus-4-8",
max_tokens=1024,
messages=[{"role": "user", "content": "Summarize this ticket..."}],
)
print(message.content[0].text)The moving parts
Conceptually there are three identities involved, chained together:
- The Kubernetes service account (KSA) your pod runs as — declared in the pod spec.
- The federated Google identity that GKE's Workload Identity mechanism presents to Google Cloud on the KSA's behalf.
- The IAM roles granted to that identity, which determine what it may do on Vertex AI.
The exact setup steps — enabling Workload Identity on the cluster and node pool, annotating or referencing the KSA, and the precise principal identifier format — have evolved across GKE versions, so follow Google's current Workload Identity Federation for GKE documentation for the binding syntax rather than copying an older tutorial.
Which roles the workload actually needs
For Claude as a Vertex AI partner model, keep the runtime identity minimal. Making inference requests requires the aiplatform.endpoints.predict permission, which is included in the Vertex AI User role (roles/aiplatform.user). Grants can target any principal type, including service accounts:
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:PRINCIPAL" \
--role="roles/aiplatform.user"The separate Consumer Procurement Entitlement Manager role (roles/consumerprocurement.entitlementManager) is only needed to enable Claude models in Model Garden — a one-time administrative act. Do not grant it to workload identities; a pod that serves traffic has no business accepting model terms of service. Likewise, enabling the Vertex AI API itself requires Service Usage Admin, which belongs to your platform team, not your pods.
roles/aiplatform.user and nothing else. Enablement and admin roles stay with humans and provisioning pipelines.What you gain operationally
No rotation burden. Credentials are short-lived and minted automatically; there is no key file to rotate, revoke, or accidentally commit.
Cleaner audit trails. Vertex AI records online prediction calls (including rawPredict) in Data Access audit logs once you enable them, attributed to the calling identity. Distinct identities per workload mean per-application attribution instead of one shared key everywhere — the foundation for the usage forensics described in exporting audit logs to BigQuery.
Least privilege per namespace. Different applications in different namespaces can run as different KSAs bound to different Google identities, each scoped to its own project or quota context.
One caveat to plan around: local development doesn't have a federated identity, so developers use their own ADC login instead. Keep the two paths identical at the code level — see the local development workflow — and never "fix" a local auth problem by generating a key that then drifts into production.
Where to go next
Start with service account auth basics if the ADC chain is new to you, then the Cloud Run deployment guide for the serverless equivalent of this pattern.