Workload identity federation

Instead of giving a workload a stored cloud key, federation lets it prove its identity to an external provider and trade that proof for temporary cloud credentials. A continuous integration job, for example, presents an OpenID Connect token issued by its platform; the cloud account has a role configured to trust that provider under specific conditions, verifies the token, and returns short-lived credentials. Nothing long-lived is stored anywhere, and the credentials expire quickly. The security of the arrangement rests entirely on the trust conditions: the role should be assumed only for a specific repository, branch or workload, checked against the token’s subject and audience claims. Get the conditions right and this replaces a stored secret with a scoped, ephemeral one.

The failure is a trust condition that is too broad. A role configured to trust the provider without pinning the subject will be assumed for any workload on that provider, so any repository or job on the same platform (including a fork, or a pull request from an outsider) can obtain the production role’s credentials. From the attacker’s side, this is a clean escalation: no stolen key, no exploit, just a token their own job is entitled to, exchanged for access it should never have. In deployments we review, the conditions are frequently copied from an example and left permissive, or the audience is unchecked, which turns a mechanism meant to remove risk into an open door.

We review the trust policies behind federation: which providers are trusted, how tightly the subject and audience conditions are pinned, and whether any external or untrusted workload could satisfy them. Where a condition is loose we demonstrate assuming the role from a workload that should not qualify. It is assessed alongside the other routes a non-human identity obtains cloud access, including cross-account trust. The finding is written against the over-broad condition. This is part of how we review federated access to your cloud.