Abuse OpenID Connect and GitLab for AWS Access

What this lab covers

You examine how a GitLab pipeline authenticates to AWS without stored credentials, identify that the trust relationship is scoped more loosely than intended, and use that to obtain access from somewhere it was never meant to be available.

This is an important counterpoint to the usual advice. Federation is the right direction and it is not automatically safe, because it shifts the security property from secret handling to condition writing, and the latter is easy to get wrong quietly.

It assumes no prior AWS or GitLab experience and suits anyone who has migrated pipelines away from stored keys.

How OIDC federation is misconfigured

In OIDC federation, the CI system presents a signed token describing the pipeline, and AWS exchanges it for temporary credentials if the token satisfies the role's trust policy. There is no long-lived secret anywhere, which removes the most common cause of credential leaks.

The trust policy decides who may exchange a token. It names the identity provider and should include a condition on the token's subject claim, which encodes details such as the project path and branch. That condition is the whole boundary.

The failure is a condition that matches too broadly, or is omitted, or uses a wildcard in the wrong position. In that case any project on the same identity provider, including one an attacker creates on a shared platform, produces a token the policy accepts. GitLab's own documentation warns about scoping this correctly, which is a good indication of how easily it goes wrong.

How to detect this in your own environment

Role assumption via federation is recorded in CloudTrail with the identity provider and the subject claim from the token. That means you can see exactly which project and branch assumed the role, which is unusually good evidence.

Baseline the expected subjects. A pipeline role should be assumed by one project and usually one branch, so any other subject appearing is a clear signal rather than a judgement call.

Alert on trust policy modifications. Broadening a condition is a quiet way to create durable access, and it is a control plane event you can watch.

How to prevent it

Write the condition on the subject claim to match the exact project path and branch, using string equality rather than a pattern. This single line is the boundary, and it deserves review as carefully as any credential handling.

Verify the audience claim as well, so tokens intended for a different relying party are rejected.

Scope the role's own permissions narrowly, so that even a correctly assumed role cannot do more than the pipeline needs. Federation controls who gets in, and permissions control what that is worth.

Real-world context

Misconfigured OIDC trust policies have been a recurring finding as organizations migrate CI/CD away from long-lived credentials. The migration is correct, and the failure mode simply changed shape from a leaked key to a permissive condition.

Shared identity providers make this consequential. On a multi-tenant CI platform, a condition that does not pin the project path is satisfiable by anyone who can create a project on the same platform, which is a very low bar.

The pattern maps to MITRE ATT&CK T1078.004 Cloud Accounts and T1550 Use Alternate Authentication Material.

Applying this at work

• Review every OIDC trust policy in your accounts and confirm the subject condition pins the exact project and branch.
• Check for wildcards in subject conditions, particularly at the start of the value, which is where over-matching hides.
• Confirm the audience claim is validated.
• Baseline which subjects assume each federated role and alert on anything else.
• Reduce the permissions on pipeline roles so a successful assumption is worth less.

Frequently asked questions

Is OIDC federation safer than storing access keys?

Yes, in that there is no long-lived secret to leak. The trade-off is that security now depends on the trust policy condition being written correctly, which is a different failure mode rather than none.

What does the subject claim contain?

Details identifying the workload, such as the project path and branch for a CI pipeline. Conditioning the trust policy on this value is what restricts role assumption to the intended pipeline.

How can a wildcard in a trust policy be dangerous?

If the condition matches more than the intended project, any workload producing a token that satisfies it can assume the role. On a shared CI platform that can include a project created by an attacker.

Do I need my own AWS account to practice this?

No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS attack and detection paths in full, including IAM abuse and privilege escalation, and is assessed hands-on in a live AWS account.