Federated subject recycling continued: AWS edition

Thu, 12 Nov 2026 12:00:19 +0100

Federated credentials reduce the risks of token exposure and leaked secrets, but they can leave dangling trust relationships too. In my previous post, I covered subject recycling in Microsoft Entra ID: how to find GitHub Actions and GitLab trusts that rely on mutable subjects and how to switch to immutable identifiers.

This time, I’m looking at AWS IAM role trust policies. The question is the same: does the trust rely on an immutable identifier or a name that could be recycled?

As a quick recap, here’s how mutable and immutable subjects differ:

GitLab example:

-"sub": "project_path:nicolonsky/ITDR:ref_type:branch:ref:main"
+"sub": "project_id:715070358:ref_type:branch:ref:main"

GitHub example:

 -"sub": "repo:nicolonsky/ITDR:ref:refs/heads/main"
+"sub": "repo:nicolonsky@32899754/ITDR@715070358:ref:refs/heads/main"

AWS IAM role trust policies
#

If you’re coming from the Microsoft world, it’s worth distinguishing three core AWS IAM concepts:

Permissions policy: Defines which actions are allowed or denied on which resources. For example, s3:ListBucket allows listing objects in a bucket. The permissions are comparable to those in an Azure RBAC role. ¹ ²
Role trust policy: Defines who can assume a role and under which conditions. In the Microsoft world, principals always refer to Entra ID objects, such as users, groups and service principals (instances of app registrations). AWS can delegate trust directly to an external identity provider without local objects. ³
IAM role: Combines a trust policy with permissions policies. ⁴

Example configuration
#

Before using GitHub Actions or GitLab as a federated principal, add the IdP as an OIDC provider in IAM:

AWS on Nicola Suter

Federated subject recycling continued: AWS edition

AWS IAM role trust policies #

Example configuration #

AWS IAM role trust policies
#

Example configuration
#