IAM Role Trust Policies: Misconfigurations Hiding in Plain Sight

Even small misconfigurations in role trust policies can unintentionally create critical privilege escalation risks in AWS, such as allowing low-privileged users to assume admin roles.

In this first post of a three-part series on role trust policies, we’ll explore how AWS’s documentation makes these policies unnecessarily confusing and easy to misconfigure. Then, we’ll break down two surprisingly common misconfigurations with severe security implications.

Introduction

AWS is the most popular cloud service provider (CSP), and IAM roles are the best-practice way to delegate permissions to identities in AWS. This arguably makes IAM roles the most critical identity and permission management mechanism in the world - for both human and non-human identities (NHIs). Given that, it’s surprising how often organizations misconfigure them.

IAM roles have two key components:

1. The trust policy - defines who can assume the role
2. The permission policies - defines what actions are granted once the role is assumed

While the latter is essential for maintaining strong security posture - and right-sizing permissions remains a never-ending, complicated challenge - it is a well-known challenge that extends beyond IAM roles, affecting all IAM principal types and permission models.

In comparison, trust policies are much less understood, easier to misconfigure, and can have far-reaching security implications just as much. A single mistake in a trust policy - like accidentally allowing any AWS principal to assume a role - can lead to immediate full compromise of an organization's AWS environment.

Role Trust Policies: The Basics

A role trust policy is a JSON document that defines which principals are trusted to assume a role. It is separate from the permission policies, which define what actions can be performed once the role is assumed. Both are required and configured separately:

Key components of a trust policy:

• Principals – the identities (users, roles, accounts, or services) allowed to assume the role.
• Actions – the specific API calls permitted for role assumption (AssumeRole, AssumeRoleWithSAML and AssumeRoleWithWebIdentity - each for a different source identity and assumption method).
• Conditions - just like in other IAM policies, conditions that must be met for the assumption to succeed (e.g. MFA, external ID or source IP restrictions)

The Documentation Gap: Why Trust Policies Are Hard to Get Right

The problem all begins with lacking documentation: Shockingly, there is no dedicated AWS documentation page properly explaining trust policies.

The only significant reference is in the IAM roles documentation, wildly buried near the bottom of the page, where trust policies are described in just three sentences:

That’s not helpful. It’s like saying “It’s a JSON. Just write the principals you trust. Good luck!”. (and may the best threat actor win…)

Each link leads to other documentation pages, but none offer a clear, dedicated explanation of trust policies. Instead, they cover general IAM concepts like resource-based policies and principals. The referenced blog post provides some advanced examples but lacks key explanations, leaving readers to piece together information from multiple fragmented sources - often buried in unrelated details.

Even the naming is inconsistent - AWS refers to the same concept differently depending on where you look:

• "Trust policy" (documentation, the web console and some API calls)
• "Trust relationship" (the web console and other API calls)
• "AssumeRolePolicyDocument" (some API calls)

This inconsistency just makes this whole thing more confusing.

Two Simple but Dangerous Trust Policy Misconfigurations

This is not a new topic, nor is it a new problem. Much has already been written on misconfigurations in trust policies (e.g. some examples).

However, encountering the two following misconfigurations so frequently in organizations, especially the first one, prompted us to write this first post. These specific simple misconfigurations, which we haven’t seen explicitly written about, even though simple, can lead to serious security risks.

#1 - Trusting all principals in the role’s account

AWS security best practices - and AWS’s own documentation - strongly warn against using wildcard (”Principal”: {”AWS”: “*”}}) trust policies because they allow any AWS account to assume the role. AWS Access Analyzer correctly flags these as high-risk.

However, a less obvious but also dangerous mistake is trusting all principals within the same AWS account.

For a role in AWS account 123456789012, the following trust policy does not limit access to just the root user - it (confusingly) trusts every IAM principal in the account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

This is the equivalent of living in a gated community, but leaving the house’s front door open. A malicious threat actor still has to get past the community gate (i.e. gain initial access to some identity in your AWS account), but after passing that gate - in any way - they can simply walk through your door (i.e. assume this role and get all the permissions it has). All they need to do for this to work is to gain access to any identity in your AWS account that has permissions to call sts:AssumeRole, which isn’t considered a very privileged permission by itself.

It is hard to imagine any good reason to have a trust policy meaning “I allow all principals whatsoever in this account to get the permissions described in this role”. This misconfiguration (which isn’t alerted on by AWS Access Analyzer, by the way) creates a very simple-to-exploit privilege escalation path in the affected account - and more organizations than not have it on some of their IAM roles.

#2 - Having multiple principals intending AND between them

IAM trust policies allow multiple principals in the "Principal" section, but AWS always evaluates them as a logical OR, never AND. This means that if multiple principals are specified, any one of them can assume the role independently - they are not required to meet all conditions together.

AWS provides two ways to define multiple principals in a trust policy:

1. Separate statements – each statement in the policy defines an independent trust relationship.
2. A single "Principal" section with multiple values – AWS allows specifying multiple principals in an array under the same statement, which is interpreted as OR, not AND.

However, it is not clearly documented what happens when different principal types (e.g., an AWS account and a service principal) are combined in the same "Principal" section, which leads to the following misconfiguration.

Consider the following trust policy for a role in AWS account 555555555555:

"Principal": {
    "Service": "ec2.amazonaws.com",
    "AWS": "arn:aws:iam::123456789012:root"
}

One might mistakenly assume that this policy “ANDs” between both principals, only allowing EC2 instances from account 123456789012 to assume the role. However, AWS applies ORs also between different principal types.

This trust policy actually allows both of these to assume the role:

• Any EC2 instance in 555555555555 (if assigned it as instance profile)
• All IAM principals in 123456789012 (users, roles, Lambda functions, etc.)

Although AWS documentation mentions that principal types with multiple values are evaluated as OR, the fact that we encountered this misconfiguration several times suggests that the documentation does not make this distinction clear enough.

Closing Thoughts

Misconfigurations in trust policies can be subtle yet extremely risky, often leading to privilege escalation paths that organizations fail to notice. Understanding these pitfalls is key to securing IAM roles properly.

Next up: Cross-Account Trust Mistakes

In the second part of this series, we'll take a deeper look at a more complex aspect of trust relationships - secure cross-account access - exploring some common mistakes and consequential misconceptions organizations make.

‍