DEV Community

Cover image for AWS Trust Policy Complete Guide: How to Control IAM Role Access in 2025
AWS Community Builders profile image KUSEH SIMON WEWOLIAMO
KUSEH SIMON WEWOLIAMO for AWS Community Builders

Posted on

AWS Trust Policy Complete Guide: How to Control IAM Role Access in 2025

Table of Contents

Introduction

Most AWS architects and developers create and use IAM roles but do not understand how the permissions described in the policies attached to a role are assigned to principals. The permissions assigned to the principal are always temporary and short-lived. These short-lived credentials are generated by AWS Security Token Service (STS), but wait – what ensures that the right principals assume a role? In this article we will look at AWS Trust Policy, the security gatekeeper that ensures that the right principal can assume a role to perform its actions.

What is AWS Trust Policy?

A trust policy is a type of AWS resource-policy that controls which principals and under which conditions can assume a role. Trust policy essentially enforces " who can wear this hat" and under what condition. You can think of trust policy as the "front door" to a role, before anyone can use the permissions define in the role, they must first pass a trust policy to verify their eligibility.

Basic Trust Policy Structure

Just like AWS traditional policy document, a trust policy is made up of 3 main components,statement, Effect and Action, but because this is a resource -based policy there is an additional component, the Princpal that is required.

Trust Policy Structure

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

How trust Policy Works

Trust policy works

  1. First the principals, IAM user, AWS service or Federated Users (SAML/OIDC) will request to assume a role
  2. The trust policy will then evaluate the request based on,who is making the request, if there are any conditions specified and Whether if the actions are allowed.
  3. If the request is comming from right principal who is allowed to assume the role and meets the conditions specified, the request is approved.
  4. If approved, the principal gets temporary credentials, Permission policies then control what actions the assumed role can perform on AWS resource

Principal Types

The principal component of a trust policy defines which principals can assume a role. The table below summarizes the various types of principals that can be used with a trust policy.

Principal Type Example Use Case
Service "Service": "lambda.amazonaws.com" AWS services assuming roles
AWS "AWS": "arn:aws:iam::123456789012:user/john" IAM users, roles, or accounts
Federated "Federated": "arn:aws:iam::123456789012:saml-provider/ExampleProvider" Identity federation
Root "AWS": "arn:aws:iam::123456789012:root" Entire AWS account

Adding Conditions to Trust Policies

It is possible to add conditions to a trust policy. Conditions add extra security layers and it is best practice to use conditions in your trust plocies.
EXAMPLE Require MFA

  {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/AdminUser"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        },
        "NumericLessThan": {
          "aws:MultiFactorAuthAge": "3600"
        }
      }
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

EXAMPLE Restrict by Source IP

  {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/RemoteUser"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Trust Policy vs. Permission Policy

Trust Policy Permission Policy
Controls who can assume the role Controls what the role can do
Attached to the role itself Attached to the role or inherited
Uses sts:AssumeRole action Uses various AWS service actions
Defines principals (who) Defines resources and actions (what)

Common Use Cases of Trust Policies

Trust policies are fundamental to AWS security architecture and enable secure, temporary access patterns without sharing long-term credentials.
Cross-account access: Allow users in Account A to access resources in Account B
Service roles: Allow AWS services (like EC2, Lambda) to access other AWS resources
Federation: Enable users from external identity providers to access AWS resources
Temporary access: Grant time-limited access to external parties or contractors
CI/CD pipelines: Allow deployment tools to assume roles for automated deployments

Common Trust Policy Examples

1. Allow EC2 Service to Assume Role

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

2. Allow Specific AWS Account to Assume Role

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

3. Allow Specific IAM User to Assume Role

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/DevOpsEngineer"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

4. Cross-Account Access with External ID

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::987654321098:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-external-id-12345"
        }
      }
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

5. Web Identity Federation (for Mobile/Web Apps)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/accounts.google.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "accounts.google.com:aud": "your-app-client-id"
        }
      }
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

6. SAML Federation

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/accounts.google.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "accounts.google.com:aud": "your-app-client-id"
        }
      }
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Best Practices for Trust Policies

  • 1.Principle of Least Privilege: Only grant assume role permissions to entities that actually need them
  • 2.Use External IDs: For third-party access to prevent confused deputy attacks
  • 3.Add Conditions: Use conditions to restrict when and how roles can be assumed
  • 4.Regular Audits: Periodically review who has permission to assume critical roles
  • 5.Avoid Wildcards: Be specific about which principals can assume roles and avoid using the wildcard,*.
  • 6.Monitor Usage: Use CloudTrail to monitor role assumption activities

Conclusion

Security is paramount when it comes to the cloud. In this article, we dive deep into one of the security features of AWS, AWS Trust Policy, which controls who can assume an IAM role. In my next article, we will examine the service that generates temporal and short-lived credentials, AWS Security Token Service (STS). Till then, it's a bye for now. Don't forget to add a comment

References

  1. https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/
  2. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html
  3. https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html

Top comments (1)

Collapse
 
chariebee profile image
Charles Brown •

Great post, but I think some AWS use cases can require longer-lived access through identity federation, not just temporary credentials. Also, IAM roles can sometimes be granted permissions in ways other than what’s described here. Would be interested to hear your thoughts on those exceptions!