Azure Kubernetes Service (AKS) is Azure's managed Kubernetes offering, and workload identity is the Azure mechanism that federates a Kubernetes service account — the identity a pod runs as — with a Microsoft Entra ID identity. Once the two are linked, a pod can obtain Entra ID tokens without any secret mounted into it. Claude on Microsoft Foundry supports exactly this style of authentication: alongside Azure-issued API keys, it accepts Entra ID bearer tokens, governed by Azure role-based access control (RBAC). Put together, your Claude-calling services on AKS can be entirely credential-free.
Why bother replacing keys
A Foundry API key is a long-lived bearer credential: anyone who reads the Kubernetes secret, the CI logs, or a misconfigured backup can call your deployment and spend your quota and budget. Entra ID authentication changes the model. Tokens are short-lived and issued on demand; access is granted and revoked through role assignments rather than key rotation; and every service gets its own identity, so audit trails show which workload made a call rather than "whoever had the key." Anthropic's documentation highlights the same benefits — centralized identity management and Azure RBAC — and one Foundry capability actually requires it: the gated Claude Mythos models support Entra ID authentication only, with no API keys at all.
The moving parts
The AKS-specific wiring (OIDC issuer on the cluster, a federated credential linking the service account to a managed identity) is standard Azure platform setup — follow Microsoft's current AKS workload identity documentation for those steps. The Foundry-specific parts are two:
1. A role assignment. Grant the managed identity a role that permits inference on the Foundry resource. Microsoft's Claude documentation names Cognitive Services User; Anthropic's page mentions Foundry User or Cognitive Services User. A 403 from the endpoint almost always means this assignment is missing or hasn't propagated.
2. A token-aware client. The Anthropic Python SDK's AnthropicFoundry client accepts an Entra ID token provider. DefaultAzureCredential from the azure-identity package automatically detects the workload identity environment that AKS injects into the pod, so the code is identical to what you would run on any other Azure compute:
from azure.identity import DefaultAzureCredential, get_bearer_token_provider
from anthropic import AnthropicFoundry
token_provider = get_bearer_token_provider(
DefaultAzureCredential(),
"https://ai.cognitiveservices.com/.default",
)
client = AnthropicFoundry(
azure_ad_token_provider=token_provider,
base_url="https://YOUR-RESOURCE.services.ai.azure.com/anthropic/",
)
msg = client.messages.create(
model="claude-sonnet-5", max_tokens=256,
messages=[{"role": "user", "content": "Hello from AKS"}],
)Under the hood the token is sent as Authorization: Bearer <token> to the same Azure-hosted endpoint that key-based calls use. One documented wrinkle: Microsoft's samples use the token scope https://ai.cognitiveservices.com/.default while Anthropic's docs use https://ai.azure.com/.default. Both appear in official documentation; if token acquisition succeeds but calls are rejected, trying the other scope is a legitimate first debugging step.
Operational notes for cluster workloads
Rate limits are per subscription, not per pod. Foundry quota is managed at the Azure subscription level, with all Global Standard deployments of the same model and version sharing one pool. Ten replicas do not get ten times the throughput — they share the same requests-per-minute and input-tokens-per-minute budget, so horizontal scaling of a Claude-calling service needs client-side pacing, and 429 responses need exponential backoff. Foundry does not return anthropic-ratelimit-* headers, so build visibility from Azure monitoring and your own metrics.
Network isolation composes with identity. If your security posture requires it, the Foundry resource can disable public network access and expose a private endpoint into your virtual network, so pods reach Claude without traversing the public internet. That is a resource-level Foundry feature — see Foundry private endpoints — and it is independent of, and complementary to, workload identity.
Log the trace headers. Responses include request-id and apim-request-id; emitting both into your cluster logging makes support conversations across Anthropic and Azure much faster.
Where to go next
Read Entra ID authentication for Foundry for the auth mechanics in depth, Foundry RBAC for role design, and managed identity patterns for non-Kubernetes compute.