Workload Identity Is Not Just Secret Rotation
Workload identity is often introduced as a safer way to deliver cloud credentials. Replacing static secrets with short-lived tokens is useful, but it addresses only the credential lifecycle.
The larger architectural change is explicit trust between a workload, its runtime identity, and an external service. That trust must be designed as platform infrastructure, not delegated to each application team.
What matters
- Narrow identity boundaries: Assign identities per workload responsibility, not per cluster, namespace, or node.
- Audience restrictions: Tokens should be valid only for the intended relying service.
- Separated ownership: Platform teams manage federation and delivery. Service owners define the permissions their workloads require.
- Default denial: Workloads without an explicit binding should receive no cloud access.
- Observable issuance: Authentication failures, unusual token exchange, and permission changes need operational visibility.
- Controlled migration: Remove legacy credentials after identity-based access is verified, or the old path remains the effective security boundary.
Recommendation
Treat workload identity as a standard platform capability with one supported integration path and clear ownership. Keep authorization close to the external resource, while the platform provides reliable identity issuance and policy guardrails.
Short-lived tokens reduce exposure. A consistent trust model reduces complexity and makes that reduction durable.