Workload identity federation removes static cloud keys, but it replaces them with trust rules that decide which external tokens can become cloud identities, and a single loose issuer, subject or audience condition can let someone else's workload in. This template is a periodic review of those trust rules: every OIDC issuer an organisation trusts, every subject pattern and condition attached to it, and who can change them. It complements the Workload Identity Federation Guide, which explains how to design federation, by giving reviewers a repeatable set of checks with evidence. It covers federation into Amazon Web Services IAM, Google Cloud Workload Identity Federation and Microsoft Entra ID federated identity credentials, from CI/CD systems, Kubernetes clusters and other clouds. Platforms are listed alphabetically. It is written for cloud identity engineers, platform teams and auditors.
This is an independent guide from NHI Mgmt Group, based on the public documentation of AWS, Google Cloud and Microsoft as of November 2026. It is not sponsored or reviewed by any of these vendors. Product features change, so confirm settings against each vendor's current documentation.
How to use this template
- Run the review every [6 months] (ours), after any new issuer is trusted, and after a change of CI/CD platform, repository host or cluster.
- Work in three passes: build the trust register (section 4), apply the common checks to every trust (section 5), then the platform-specific checks (section 6).
- "Must" findings are remediated within [30 days] or recorded as an exception under section 9. Values marked "ours" are NHI Mgmt Group recommendations.
- Collect evidence as exports (trust policies, provider configurations, federated credential lists), not screenshots, so the next review can compare them.
- For fixing a failing exchange rather than reviewing a working one, use the Multi-Cloud Workload Identity Troubleshooting Guide.
1. Purpose
This review confirms that every federation trust in [Organisation]'s cloud estate accepts tokens only from the intended issuer, for the intended workload, for the intended audience, and grants only the access that workload needs. It supports NIST SP 800-53 IA-9 (service identification and authentication), AC-2 (account management) and AC-6 (least privilege), and NIST CSF 2.0 PR.AA-01 and PR.AA-05.
2. Scope
- AWS: IAM OIDC identity providers and every role whose trust policy uses
sts:AssumeRoleWithWebIdentity, plus EKS Pod Identity associations. - Google Cloud: workload identity pools and providers, their attribute mappings and conditions, and IAM bindings that grant
roles/iam.workloadIdentityUseror direct resource access to pool principals. - Microsoft Entra ID: federated identity credentials on app registrations and on user-assigned managed identities.
- Issuers in scope include CI/CD platforms (GitHub Actions, GitLab, Terraform Cloud and others), Kubernetes cluster issuers, other clouds and any internal OIDC provider.
- Out of scope: workforce SSO federation (see the SSO Integration Checklist) and SAML trust (see the Golden SAML and Federation Trust Abuse Defence Guide).
3. Roles
| Role | Responsibility |
|---|---|
| [Cloud identity engineering] | Exports configurations, runs the checks, owns remediation of platform-side settings. |
| Trust owner | The team whose workload uses the trust; confirms the workload still exists and the access is still needed. |
| [Reviewer] | Independent sign-off; must not own any trust being reviewed. |
| [Security operations] | Confirms logging in section 7 and investigates unexpected exchanges found during the review. |
4. Build the trust register
List every trust as one row. A trust is one issuer plus one condition set plus one target identity.
| Field | What to record |
|---|---|
| Issuer URL | Exact value, for example https://token.actions.githubusercontent.com or a cluster issuer URL. |
| Issuer tenancy | Single-tenant (your own cluster or IdP) or multi-tenant (one issuer URL serving many customers, such as a SaaS CI platform). |
| Audience | The aud value the trust accepts. |
| Subject and other conditions | Exact subject or pattern, plus any extra claim conditions. |
| Target identity | IAM role, Google service account or pool principal binding, Entra application or managed identity. |
| Permissions | Policies or roles attached to the target identity, with the resources they cover. |
| Owner and purpose | Team and workload; link to the [NHI inventory] record. |
| Last used | Last successful exchange from logs (section 7). |
5. Common checks for every trust
| # | Check | Level | Evidence |
|---|---|---|---|
| 5.1 | Issuer is expected: every trusted issuer is on the approved issuer list with an owner. Unknown issuers are investigated as a possible persistence mechanism. | Must | Provider export compared with the approved list. |
| 5.2 | Multi-tenant issuers are pinned to your tenant: for a shared issuer, a subject or tenancy condition limits the trust to your organisation, project or repository. The issuer check alone proves only that some customer of that platform obtained a token. | Must | Condition shown in export. |
| 5.3 | Subject is as narrow as the workload allows: an exact subject (one repository and environment, one namespace and service account) for anything that can deploy or read sensitive data. Wildcards only for read-only or low-impact roles, with justification (ours). | Must | Subject value per trust; wildcard list with justification. |
| 5.4 | Claims used are immutable: conditions use identifiers the issuer guarantees and a user cannot change or reuse (for example numeric repository or owner IDs where the platform provides them) rather than names that can be deleted and recreated. | Should | Claim list per trust. |
| 5.5 | Audience is specific: the trust accepts only an audience meant for this verifier, not a generic value another relying party also accepts. | Must | Audience value per trust. |
| 5.6 | One workload, one identity: unrelated workloads do not share a target identity, and pull request or test jobs do not share an identity with deployment jobs. | Must | Mapping of trusts to target identities. |
| 5.7 | Least privilege: the target identity's permissions match the workload's purpose and name specific resources. | Must | Attached policies reviewed by the trust owner. |
| 5.8 | Still in use: trusts with no successful exchange in [90 days] (ours) are disabled, then deleted after a further [30 days]. | Should | Last-used dates. |
| 5.9 | Change is controlled: only named roles can create or edit providers, trust policies and federated credentials, and changes go through infrastructure as code review. | Must | Role assignment export; repository link. |
| 5.10 | No static fallback: the workload has no leftover access key, service account key or client secret that would still work if federation were removed. | Must | Key and secret inventory for the target identity. |
6. Platform checks
AWS
- 6.1 Required tenancy claims (Must): AWS documents a list of shared OIDC providers whose tenancy claim must appear in role trust policies, for example
token.actions.githubusercontent.com:sub(orjob_workflow_ref) for GitHub Actions,gitlab.com:subfor GitLab andapp.terraform.io:subfor Terraform Cloud. Confirm each role trusting such an issuer evaluates the listed claim; AWS checks some of these at policy create or update time. - 6.2 Audience condition (Must): each trust policy has a
StringEqualscondition on<issuer>:aud. - 6.3 Subject operator (Must):
StringEqualsfor exact subjects; anyStringLikepattern is listed and justified, and no subject condition is a bare wildcard. - 6.4 Unused providers (Should): IAM OIDC providers with no role referencing them are removed. The step-by-step queries are in How to audit AWS IAM Roles Anywhere and OIDC identity providers.
- 6.5 Permissions boundary (Should): high-impact federated roles carry a permissions boundary as an extra ceiling.
Google Cloud
- 6.6 Central pool project (Must): pools and providers live in a dedicated project, and the organisation policy constraint
constraints/iam.workloadIdentityPoolProvidersdenies providers by default with exceptions for approved projects and issuers. - 6.7 Attribute conditions on multi-tenant providers (Must): every provider for a shared issuer has an attribute condition that limits it to your organisation or repository.
- 6.8 Provider and audience layout (Should): one provider per pool to avoid subject collisions, no second federation with the same identity provider, and the provider resource URL used as the audience.
- 6.9 Mapping integrity (Must):
google.subjectmaps each external identity to exactly one subject, only immutable, non-reusable attributes are mapped, and permission to update providers is limited to the owner and Workload Identity Pool Admin roles. - 6.10 Scoped impersonation (Must):
roles/iam.workloadIdentityUseris granted to specific principals, not to every member of a pool.
Microsoft Entra ID
- 6.11 Exact values (Must): issuer, subject and audience on each federated identity credential exactly match the external token. Microsoft documents that values are matched exactly, without wildcards, and that the subject is checked at token exchange rather than at creation, so an incorrect value surfaces only when an exchange fails. Remove credentials whose subject no longer matches any live workload.
- 6.12 Audience (Must): audience is
api://AzureADTokenExchangeunless a documented reason exists. - 6.13 Who can add credentials (Must): anyone who can add a secret or certificate to an app registration can add a federated credential, so review application owners and the Application Administrator role, and the tenant setting that controls whether users can register applications. Microsoft documents an Azure Policy deny rule for federated credentials on user-assigned managed identities where they should not be created.
- 6.14 Credential count (Should): each application or managed identity holds no more credentials than its workloads need; Microsoft documents a limit of 20 per application or identity, so a long list is also a sign of sprawl.
7. Logging and detection
| Platform | Log source | What to look for during and between reviews |
|---|---|---|
| AWS | AWS CloudTrail | AssumeRoleWithWebIdentity events by role and subject; CreateOpenIDConnectProvider and UpdateAssumeRolePolicy changes. |
| Google Cloud | Cloud Audit Logs, with Data Access logs enabled for the Security Token Service API and IAM API | Token exchanges and impersonation (the serviceAccountDelegationInfo section of entries); provider and pool changes. |
| Microsoft Entra ID | Entra audit logs and service principal sign-in logs | Federated credential additions and updates; workload identity sign-ins by application. |
Alert on new issuers, on trust policy or credential changes made outside the infrastructure as code pipeline, and on exchanges for a subject that has not been seen before. Adding a trust to an attacker-controlled issuer is a form of MITRE ATT&CK T1484.002 Trust Modification, and adding credentials to an existing identity is T1098.001 Additional Cloud Credentials.
8. Framework mapping
| Risk | Checks | Reference |
|---|---|---|
| External workload assumes your identity through a loose condition (T1078.004 Cloud Accounts) | 5.2, 5.3, 5.5, 6.1, 6.7, 6.11 | NIST SP 800-53 IA-9, AC-2; NIST CSF 2.0 PR.AA-03 |
| Persistence through a new trust or credential (T1484.002, T1098.001) | 5.1, 5.9, 6.6, 6.13 | NIST SP 800-53 AC-2, AU-2 |
| Over-privileged federated identity | 5.6, 5.7, 6.5, 6.10 | NIST SP 800-53 AC-6; NIST CSF 2.0 PR.AA-05 |
| Stale trusts and fallback keys | 5.8, 5.10, 6.4 | NIST SP 800-53 AC-2, IA-5; NIST CSF 2.0 PR.AA-01 |
9. Exceptions and sign-off
Record any unmet "Must" check in [Risk register] with the reason, compensating control, owner and a review date no later than [3 months]. The reviewer signs the completed register and findings list, and the next review starts from this register. If a review finds an unexpected issuer, a trust used by an unknown subject or a credential nobody owns, treat it as a potential incident and follow the Workload Identity Compromise Response Playbook.
Implementation guidance
- Export before judging: pull all providers, trust policies, pools and federated credentials into one register with a script that is read-only. The first export usually finds trusts nobody remembers creating.
- Fix the multi-tenant issuers first: missing tenancy conditions on shared CI/CD issuers carry the highest exposure, because anyone on that platform can mint a token with the right issuer.
- Tighten in stages: add the narrower condition alongside the existing one where the platform allows, watch logs for exchanges that would fail, then remove the wider rule. Rollback is restoring the previous policy version from source control.
- Disable before delete: for unused trusts, disable or detach first and wait [30 days] (ours) before deletion.
- Prevent drift: manage all trusts as code, block console changes with organisation policies or permissions, and alert on changes made outside the pipeline.
A small organisation with one CI/CD platform and one cloud can complete this review in a day. Larger estates should automate the register and track: trusts without an owner, trusts on multi-tenant issuers without a tenancy condition, wildcard subjects on write-capable identities, trusts unused for [90 days], and identities that still hold a static key alongside federation.
Standards and references
- AWS: Create a role for OpenID Connect federation
- AWS: Identity-provider controls for shared OIDC providers
- Google Cloud: Best practices for using Workload Identity Federation
- Microsoft Learn: Workload identity federation considerations
- MITRE ATT&CK: Domain or Tenant Policy Modification: Trust Modification
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Workload Identity Federation Guide · GitHub Actions OIDC Federation Hardening Guide · Cross-cloud workload identity federation · Kubernetes Workload Identity Checklist