What is AWS IAM PassRole?

iam:PassRole in AWS Defined

The easiest way to picture iam:PassRole is as the authority to hand someone a powerful uniform. An AWS service like EC2 or Lambda regularly needs temporary permissions to get its job done (read an S3 bucket, update a DynamoDB table), and it cannot just borrow the permissions of whoever launched it. So you build a dedicated IAM Service Role carrying only the permissions it needs.

What iam:PassRole grants is the right to attach or assign that Service Role to an AWS service at setup time. Lacking it, you can still create the Service Role: you just can't hand it to the service that is supposed to use it.

How IAM Roles and Trust Policies Work in AWS

To see why iam:PassRole carries so much weight, it is worth revisiting how IAM Roles behave.

An IAM Role is an identity that carries permission policies but no long-term credentials of its own. Something assumes the role to pick up its permissions for a while. Two parts make up every role:

1. Permissions Policy: Defines what actions the role is allowed to perform (e.g., s3:GetObject, ec2:RunInstances).
2. Trust Policy (or Role Assumption Policy): Defines who or what can assume the role. It lists the principals - users, other roles, or AWS services - that are allowed to use the role.

With Service Roles the Trust Policy is the load-bearing piece. It typically names an AWS service principal (ec2.amazonaws.com or lambda.amazonaws.com, say), and that is what lets the service assume the role.

How iam:PassRole Allows a User or Service to Assign a Role

Think of iam:PassRole as the checkpoint at the moment of delegation. When an engineer spins up an EC2 instance and attaches an Instance Profile Role, what they are really declaring is: "give this EC2 service the permissions in Role-X."

For the launch API call (ec2:RunInstances) to succeed, the engineer's IAM principal has to hold two things at once:

1. Permission to launch the instance (ec2:RunInstances).
2. The iam:PassRole permission, explicitly scoped to the specific Role-X being assigned.

That iam:PassRole check exists to confirm the delegating principal is actually allowed to hand that role's permissions to the target service. It is what keeps least privilege honest: a low-privileged user cannot quietly delegate a high-privileged role they could never use directly.

Real-World Example Scenarios

You reach for iam:PassRole any time a role gets assigned to an AWS service, which in practice is constantly.

Example 1: Launching an EC2 Instance with a Role

Say a DevOps engineer needs an EC2 instance that reads from an S3 bucket. The steps are:

1. Create S3-ReadOnly-Role with an S3 Read-Only permission policy.
2. Set the S3-ReadOnly-Role Trust Policy to trust the EC2 service principal (ec2.amazonaws.com).
3. Ensure the DevOps engineer's IAM Policy contains:

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::123456789012:role/S3-ReadOnly-Role"
}

Note: If the engineer tries to launch the EC2 instance with S3-ReadOnly-Role assigned but is missing the iam:PassRole permission scoped to that role, the ec2:RunInstances call will fail with an authorization error.

Example 2: Creating a Lambda Function with an Execution Role

A Lambda function needs an Execution Role to do anything. When a developer makes the lambda:CreateFunction call:

1. The developer specifies an Execution Role ARN in the request.
2. The developer's IAM principal must have iam:PassRole access to that specific Execution Role ARN.

With that in place, the Lambda service can assume the role and run the function's code under its permissions.

Why iam:PassRole Can Lead to Privilege Escalation If Misconfigured

Here is where the sensitivity of iam:PassRole really bites. It is among the most common (and most potent) permissions in AWS privilege escalation (PE) paths.

Core vulnerability: A low-privileged user can abuse iam:PassRole to trick a high-privileged AWS service into executing commands on their behalf.

The logic is not subtle:

1. The Attacker's Principal: User A only has low-level permissions - for example, they can only run EC2 instances.
2. The High-Privilege Role: A powerful role exists in the account (Admin-Role) with AdministratorAccess.
3. The Misconfiguration: User A has iam:PassRole permissions scoped to any role:

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "*"
}

4. The Attack: User A uses their ec2:RunInstances permission and unconstrained iam:PassRole:* permission to launch a new EC2 instance and assigns the powerful Admin-Role to it.
5. The Escalation: User A connects to that EC2 instance and uses Admin-Role's temporary credentials to perform any administrative action in the account, completely bypassing their own low-privileged IAM policy.

Common Misconfigurations and Risky Policy Patterns

Risky Policy Pattern	Description	Recommendation
iam:PassRole on Resource: "*"	Allows the principal to pass any role in the account to any service. This is the most dangerous misconfiguration, enabling the privilege escalation attack described above.	Must restrict the Resource to a specific list of required role ARNs.
iam:PassRole combined with Effect: "NotResource"	Policies that attempt to block passing specific roles but allow all others are complex and often miss future high-privileged roles.	Avoid NotResource with sensitive actions like iam:PassRole. Use explicit Allow lists.
Overly Permissive Role Trust Policies	The role being passed has a Trust Policy that trusts services (e.g., EC2) that the user can manipulate. The combination of iam:PassRole and a manipulable service is the privilege escalation path.	Ensure high-privileged roles trust only necessary and secured service principals.

Detection and Monitoring Strategies for PassRole Abuse

Watching for iam:PassRole usage (especially where high-privileged roles are in play) is a core piece of cloud security, and it pays to be proactive about it.

AWS CloudTrail Monitoring

CloudTrail is your source of truth here. Hunt for API calls carrying the RoleName or RoleArn parameter, and watch for the PassRole event itself.

• Monitor service API calls that trigger PassRole checks: PassRole is evaluated as part of parent API calls (ec2:RunInstances, lambda:CreateFunction, etc.) and appears in CloudTrail within those events, not as an independent event.
• Targeted Service Calls: Look for resource-creating API calls that accept a role, such as:
  • ec2:RunInstances (with an Instance Profile Role)
  • lambda:CreateFunction (with an Execution Role)
  • ecs:CreateTaskDefinition
• Suspicious Source IP/Location: Look for PassRole events originating from an unusual IP address or region, which could indicate a compromised credential.

GuardDuty and Cloud Security Posture Management (CSPM) Tools

Amazon GuardDuty flags suspicious credential use in general, but for iam:PassRole-specific anomalies you will lean on CloudTrail analysis and custom CloudWatch Logs filters. Point your CSPM tooling at your IAM policies to actively surface any iam:PassRole grant sitting on Resource: "*".

Best Practices for Securing iam:PassRole Permissions

Locking down iam:PassRole comes down to disciplined least privilege, and the discipline lives almost entirely in the Resource element of the policy.

Restrict the Resource Scope

Constraining the Resource element is the single control that matters most.

Recommended policy (least privilege):

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": [
    "arn:aws:iam::123456789012:role/MyWebAppRole",
    "arn:aws:iam::123456789012:role/MonitoringAgentRole"
  ]
}

Risky policy (avoid):

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "*"
}

Use iam:PassRole with Service Action Constraints

Add a Condition block so a role can only be passed while performing a specific service action, for instance only when creating an EC2 instance:

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::123456789012:role/SpecificEc2Role",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "ec2.amazonaws.com"
    }
  }
}

Review High-Privilege Role Trust Policies

The role on the receiving end has to be hardened too. Make a habit of reviewing the Trust Policies of every high-permission role (S3 full access, administrative access, key management), and confirm each one trusts only the exact services that genuinely need to assume it.

Separate Duties

Never give one low-privileged user or group both the ability to create highly privileged roles and the ability to pass them (iam:PassRole). Splitting those duties stops a single identity from quietly assembling a privilege escalation path.

Related Labs

Explore AWS IAM privilege escalation and role abuse in hands-on lab environments:

• Intro to AWS IAM Enumeration - Enumerate IAM users, roles, and policies from a compromised low-privilege identity, identify dangerous permissions like PassRole and privilege escalation paths, and understand the attacker's reconnaissance workflow in AWS environments.
• Escalate from SSJI to EKS - Chain application compromise into Kubernetes RBAC abuse and AWS IAM role assumption, demonstrating how IRSA-mapped service accounts and sts:AssumeRole permissions enable attackers to escalate from pod access to sensitive AWS data exfiltration.

Further Reading

• Building Security Guardrails with AWS Resource Control Policies - How Resource Control Policies (RCPs) act as organization-wide guardrails to restrict dangerous IAM actions. Since iam:PassRole is essential for legitimate operations like assigning roles to EC2, Lambda, and ECS, RCPs allow scoped restrictions rather than blanket denial, such as preventing PassRole to highly privileged roles or limiting which principals can pass roles to sensitive services.
• Abusing Identity Providers in AWS - How attackers exploit identity federation and trust policy misconfigurations to assume IAM roles, chain privileges, and move laterally across AWS accounts.

Frequently Asked Questions

What is the primary security risk of the iam:PassRole permission?

Privilege escalation, above all. Give an attacker iam:PassRole on an unconstrained resource (*) plus the ability to create or manipulate a service like EC2, and they can attach an existing high-privilege role (an Administrator Role, say) to that service. They then assume the powerful role and run the account, sidestepping their own low-level permissions entirely.

Why is iam:PassRole required when launching an EC2 instance?

Because attaching an Instance Profile Role to an EC2 instance is an act of delegation: you are handing that role's permissions to the EC2 service. AWS runs the iam:PassRole check to confirm the principal doing the launch is actually authorized to delegate that role to the EC2 service principal (ec2.amazonaws.com).

How does iam:PassRole relate to the principle of least privilege?

Least privilege means scoping the iam:PassRole action as tightly as it will go. The Resource element should name only the specific role ARNs a user or service genuinely needs to delegate, never a wildcard (*). Leaving the resource wide open breaks least privilege and is exactly the misconfiguration attackers look for.

Can a user assume a role if they only have iam:PassRole for it?

No. iam:PassRole only lets a principal assign a role to an AWS service. To assume the role themselves (via sts:AssumeRole), they have to be named in the role's Trust Policy and hold the sts:AssumeRole action in their own IAM policy. PassRole is about delegation, not direct assumption.

What is the most critical CloudTrail event to monitor for iam:PassRole abuse?

The service API calls that carry a RoleArn: ec2:RunInstances, lambda:CreateFunction, and friends. PassRole is checked inside these parent calls and never logged on its own in CloudTrail, so watching those service-specific events is how you catch the precise moment a high-privilege role gets delegated, the step right before an escalation.