← Problem Library
K8s L6 K8S 1325 · 15 min

A projected service account token looks valid and a custom API aggregation...

The pod has a token, yet one aggregated API path fails because the token audience does not match the audience that component now enforces.

K8sPlatform ReliabilityLevel 6Pro15 min
Scenario

A platform hardens token audiences and later one extension API begins returning auth failures from pods that still work against the core API server.

What to check first
  • Identify the primary failure signal in the The Token Was Real but for the Wrong Audience scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Compare token audience claims with the aggregated API expectation before rotating the service account or RBAC.

Questions worth viewing together
What should you verify first when A projected service account token looks valid and a custom API aggregation... appears?

Community-field Kubernetes problem inspired by community auth threads where aggregated APIs rejected default service account token audiences. In Kubernetes auth, a valid token can still be unusable if its audience is no longer accepted.

What usually causes A projected service account token looks valid and a custom API aggregation... in production?

Teams often blame RBAC when the token audience is the actual mismatch.

What should you document after resolving A projected service account token looks valid and a custom API aggregation...?

Audience hardening needs an inventory of every extension API or webhook that reads projected tokens.