How to Secure AWS OIDC Integrations with the Right IAM Conditions
Summary
A review of more than 20 vendors’ AWS OIDC guidance finds that trust policies need vendor-specific conditions to limit role access. Recommendations include checking both aud and sub claims, while investigating exceptions.
Key points
- Missing conditions in AWS IAM trust policies can allow an account on a third-party service to assume a customer’s role.
- For GitHub Actions, the sub condition should restrict access to the intended repository and branch; AWS changes have largely prevented creating new roles without it.
- Required conditions vary: Microsoft Defender uses sts:RoleSessionName, while DoIT uses aws:RequestTag/DoitEnvironment.
- Some vendors use shared audience values, so those values do not uniquely restrict access to a customer.
- The author reviewed public documentation for more than 20 vendors and created detections for integrations missing desired conditions.
- The article recommends checking aud and sub conditions, investigating vendor-specific exceptions, and using narrower sub matching where possible.
Article Details
- Defense Focus
- Detect and prevent overly permissive AWS IAM trust policies for OIDC integrations by checking for provider-appropriate conditions that restrict which identities can assume roles.
- Detection Methods
- Use the article's detections to identify AWS OIDC integrations missing recommended conditions, including checks for both aud and sub where appropriate.
- Review each provider's documentation for required conditions beyond aud and sub, such as sts:RoleSessionName or aws:RequestTag conditions.
- Inspect sub condition patterns for overly broad StringLike matching that permits any repository or branch in an organization.
- Use AWS Access Analyzer's policy checks for missing condition keys and its suggestion to include an aud element.
- Data Sources
- AWS IAM role trust policies and OIDC provider configurations
- AWS Access Analyzer policy-check findings
- Provider documentation describing recommended OIDC claim and condition values
- Rule Types
- AWS IAM trust-policy configuration checks for missing or insufficient OIDC conditions
- Platforms
- AWS
- Defensive Actions
- Require aud and sub conditions for OIDC integrations when applicable, and investigate provider-specific exceptions.
- Use provider documentation or support guidance to verify the required claims and condition values for each integration.
- Constrain sub conditions to the intended repository and branch rather than broadly matching all repositories or branches.
- Consider restricting role access to recommended source IP addresses where providers support that control.
- Add any provider-specific conditions, such as sts:RoleSessionName or aws:RequestTag requirements, to the trust policy.
Vendors
Amazon Web ServicesA common way to allow third-party SaaS solutions to access AWS accounts is via OpenID Connect (OIDC) integrations.Bitbucket Other vendor integrations only document a need for a “sub” condition, such as Gitlab (docs) and Bitbucket (docs). DoITto avoid this issue is on the “sts:RoleSessionName” value as documented here. Similarly, a vendor named DoIT uses “aws:RequestTag/DoitEnvironment” instead of “sub” as documented here. GitHubThe first one: GitHub Actions GitLabthe same concept was also found to impact the integrations of Terraform Cloud, Microsoft Defender, and Gitlab. The general problem is that if a customer does not include certain conditions which restrict who canMicrosoft Defenderto GitHub Actions, the same concept was also found to impact the integrations of Terraform Cloud, Microsoft Defender, and Gitlab. The general problem is that if a customer does not include certain conditions whichTerraform Cloudthe integration to GitHub Actions, the same concept was also found to impact the integrations of Terraform Cloud, Microsoft Defender, and Gitlab. The general problem is that if a customer does not include certain