IAM role trusts a public OIDC provider without pinning the owner

What this check finds

The role trusts GitHub Actions, GitLab.com, HCP Terraform or Cognito identity pools, but the trust policy does not pin the repository owner, group, organisation or identity pool. Anyone with an account at that provider can assume the role from their own workflow, pipeline or pool.

Passing looks like: Roles trusting a public OIDC provider pin the owner.

How to fix it

Add a condition on the provider's subject that names your owner, for GitHub: "StringLike": {"token.actions.githubusercontent.com:sub": "repo:<your-org>/<repo>:*"}, plus "StringEquals" on the :aud key. For GitLab.com pin project_path:<group>/, for HCP Terraform organization:<org>:, for Cognito pin cognito-identity.amazonaws.com:aud to your pool id.

Compliance controls it is evidence for

A failing result counts against these controls in KloudLytics; a passing one is evidence towards them. How compliance mapping works

Checked on every scan

KloudLytics runs this check each time it scans a connected AWS account, through a read-only role, and lists every affected resource with its region. On Pro and Business a fix is written for the specific resource rather than the general case above. The exact access it needs

More IAM checks

• HighDeprecated or flawed AWS managed policy in use
• HighIAM role allows assumption from anywhere
• HighIAM role with admin privileges can be assumed by unexpected principals
• HighIAM role with s3 listing and get privileges can be assumed by unexpected principals
• HighIAM user access key has not been rotated in over 180 days
• HighIncorrect policy used to attempt to enforce MFA
• HighInline policy allows privilege escalation to admin
• HighPrincipal can pass any role to compute it can launch

All IAM checks