Open OIDC trust on a role that can escalate to admin

Severity: critical.

What it means

This is FD001 or FD002 on an identity that also holds permissions which convert access into ownership. The findings are separate because either alone is survivable. Together they are an account takeover that needs no exploit.

What makes an identity "privileged" here

Not "has a lot of permissions" — specifically, permissions that grant more permissions, or that run code as something else.

AWS: *, iam:*, iam:PassRole, iam:CreateAccessKey, iam:UpdateAssumeRolePolicy, iam:AttachRolePolicy, iam:CreatePolicyVersion, sts:AssumeRole, lambda:UpdateFunctionCode, ssm:SendCommand, and the AdministratorAccess / PowerUserAccess / IAMFullAccess managed policies. Allow combined with NotAction lands here too: it grants everything not listed, which is almost never what was meant.

GCP: roles/owner, roles/editor, roles/iam.securityAdmin, roles/iam.serviceAccountTokenCreator, roles/iam.serviceAccountUser, roles/iam.workloadIdentityPoolAdmin, and the deploy roles that run code as an attached service account.

Azure: Owner, Contributor, User Access Administrator, Global Administrator, Application Administrator, Managed Identity Operator, and the roles that deploy code onto a resource with an attached identity.

Every finding names which permission triggered it and why.

How to fix it

Fix the door first — FD001 and FD002 on the same resource — because that is the half an attacker actually needs. Then cut the permissions:

• Replace iam:PassRole on * with a specific role ARN and an iam:PassedToService condition.
• Replace AdministratorAccess with the actions the pipeline genuinely calls. Its CloudTrail history tells you what those are.
• On GCP, roles/iam.serviceAccountTokenCreator on a CI account is worth questioning: it is how a short chain becomes a long one — see FD030.