What is AWS IAM PassRole?

iam:PassRole in AWS Defined

Think of iam:PassRole as a key to a powerful uniform. An AWS service, like EC2 or Lambda, often needs temporary permissions to perform tasks, such as reading an S3 bucket or updating a DynamoDB table. It can't simply inherit the permissions of the user who launched it. Instead, you create a specific IAM Service Role with only the necessary permissions.

The iam:PassRole permission lets a user or service attach or assign a Service Role to another AWS service when setting it up. Without this permission, you can create a Service Role, but you won't be able to give it to the service that needs it.

How IAM Roles and Trust Policies Work in AWS

To understand why iam:PassRole is so sensitive, it helps to review how IAM Roles work.

An IAM Role is an identity with permission policies but no long-term credentials. Instead, an entity assumes the role to get its permissions temporarily. Every IAM Role has two key parts:

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.

For Service Roles, the Trust Policy is critical. It usually specifies an AWS service principal such as ec2.amazonaws.com or lambda.amazonaws.com, allowing that service to assume the role.

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

The iam:PassRole permission acts at the point of delegation. When an engineer launches a new EC2 instance and assigns an Instance Profile Role to it, they are effectively saying: "I want this EC2 service to have the permissions defined in Role-X."

The AWS API call to launch that instance (e.g., ec2:RunInstances) requires the engineer's IAM principal to have two things:

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

The iam:PassRole check ensures the delegating principal is authorized to delegate the specific role's permissions to the target service. This is critical for least privilege because it prevents a low-privileged user from delegating a high-privileged role they couldn't use themselves.

Real-World Example Scenarios

The iam:PassRole permission is necessary any time you assign a role to an AWS service, which happens frequently in cloud deployments.

Example 1: Launching an EC2 Instance with a Role

If a DevOps engineer needs to launch an EC2 instance that reads data from an S3 bucket, they will:

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

Lambda functions need an Execution Role to perform actions. When a developer runs the lambda:CreateFunction API 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.

This allows the Lambda service to assume the role and execute its code with the role's permissions.

Why iam:PassRole Can Lead to Privilege Escalation If Misconfigured

This is where the security sensitivity of iam:PassRole becomes critical. It is one of the most common and powerful permissions involved 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 attack logic is straightforward:

1. The Attacker's Principle: 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

Effective cloud security requires proactive monitoring for iam:PassRole usage, especially when high-privileged roles are involved.

AWS CloudTrail Monitoring

CloudTrail is your primary source of truth. You should look for API calls that use the RoleName or RoleArn parameter, and also check 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 detects suspicious credential usage broadly, but you must rely on CloudTrail analysis and custom CloudWatch Logs filters for iam:PassRole-specific anomalies. CSPM tools should actively check your IAM policies for iam:PassRole grants on Resource: "*".

Best Practices for Securing iam:PassRole Permissions

Securing iam:PassRole is a matter of strict adherence to the principle of least privilege, particularly regarding the Resource element of the IAM policy.

Restrict the Resource Scope

The single most important control is restricting the Resource element.

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

Use the Condition block in your policy to enforce that a role can only be passed when performing a specific service action. For example, only allow the role to be passed 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 being passed must itself be hardened. Regularly review the Trust Policies of all roles with high permissions (like S3 full access, administrative access, or key management permissions). Ensure the Trust Policy only allows the exact services that need to assume the role.

Separate Duties

Do not grant the ability to create highly privileged roles and the ability to pass them (iam:PassRole) to the same low-privileged user or group. Separation of duties prevents a single identity from creating a path for privilege escalation.

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?

The primary security risk is privilege escalation. If an attacker has iam:PassRole permission on an unconstrained resource (*) and can create or manipulate an AWS service like EC2, they can assign a highly privileged existing role (e.g., an Administrator Role) to that service. This allows them to assume the powerful role and gain full control of the AWS account, effectively bypassing their own low-level permissions.

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

It is required because when you assign an Instance Profile Role to an EC2 instance, you are delegating the permissions of that role to the EC2 service. AWS enforces the iam:PassRole check to verify that the principal launching the instance is authorized to delegate the specific role's permissions to the EC2 service principal (ec2.amazonaws.com).

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

Adherence to least privilege requires that the iam:PassRole action be scoped as narrowly as possible. This means the Resource element in the policy must list only the specific IAM role ARNs that a user or service needs to delegate, rather than using a wildcard (*). Failing to restrict the resource violates least privilege and creates a common security vulnerability.

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

No. The iam:PassRole permission only authorizes the principal to assign a role to an AWS service. To assume the role themselves (e.g., using sts:AssumeRole), the principal must be explicitly listed in the role's Trust Policy and have the sts:AssumeRole action allowed in their own IAM policy. iam:PassRole is about delegation, not direct assumption.

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

The most critical events to monitor are service API calls like ec2:RunInstances and lambda:CreateFunction that include the RoleArn parameter. PassRole checks occur within these parent API calls and are not independently logged in CloudTrail. Monitoring these service-specific API calls ensures you catch the exact moment a high-privileged role is delegated - the precursor to a potential privilege escalation.