IAM CreateRole PassRole Permission Checker

The Incident (What Does the Error Mean?)

You hit this wall:

An error occurred (AccessDeniedException) when calling the CreateRole operation:
User: arn:aws:iam::123456789012:user/ci-deployer is not authorized to perform:
iam:CreateRole on resource: arn:aws:iam::123456789012:role/my-app-execution-role
with an explicit deny / no identity-based policy allows this action.

Sometimes the error surfaces as a missing iam:PassRole when the calling principal tries to attach the newly created role to a Lambda, ECS task, EC2 instance profile, or CodePipeline action:

User: arn:aws:iam::123456789012:role/deployer-role is not authorized to perform:
iam:PassRole on resource: arn:aws:iam::123456789012:role/my-app-execution-role

Immediate consequence: Your Terraform apply, CloudFormation stack create/update, CDK deploy, or SDK call halts completely. Any downstream resource depending on that role (Lambda function, ECS task definition, CodeBuild project) also fails to provision. CI/CD pipeline is dead.

The Attack Vector / Blast Radius

iam:PassRole is not a bureaucratic checkbox — it is a privilege escalation gate. Here is why AWS enforces it hard:

If a principal can call iam:CreateRole but not iam:PassRole, they can create a role with an AdministratorAccess managed policy attached, but they cannot hand it to any service. The PassRole check is the enforcement point that prevents a low-privilege CI user from creating a backdoor admin role and then attaching it to a Lambda or EC2 instance they control.

The exploit chain without PassRole enforcement:

1. Attacker compromises a CI/CD service account with broad iam:CreateRole but no PassRole restriction.
2. Attacker creates arn:aws:iam::account:role/backdoor with AdministratorAccess.
3. Attacker calls lambda:UpdateFunctionConfiguration to swap the execution role on an existing Lambda to the backdoor role.
4. Attacker invokes the Lambda — now executing as admin.

Conversely, if your legitimate deployer is blocked, every environment promotion, hotfix deploy, and infrastructure rollout stalls. In a microservices org with 40 services, one missing permission on the deploy role cascades into 40 broken pipelines simultaneously.

Prevention in CI/CD

Stop this from reaching production in the first place.

1. Checkov (Terraform / CloudFormation static analysis)

Add to your pipeline pre-plan stage:

checkov -d . --check CKV_AWS_274  # Disallows IAM role creation without permission boundary
checkov -d . --check CKV2_AWS_56  # Checks PassRole is not granted on wildcard resource

2. OPA / Conftest Policy (blocks wildcard PassRole in Terraform plans)

package terraform.iam

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_iam_policy"
  statement := resource.change.after.policy.Statement[_]
  statement.Action[_] == "iam:PassRole"
  statement.Resource == "*"
  msg := sprintf("DENY: iam:PassRole on wildcard resource in %v. Scope to specific role ARN.", [resource.address])
}

Run in CI:

terraform show -json tfplan.binary | conftest test -p policies/ -

3. AWS IAM Access Analyzer

Enable IAM Access Analyzer with a policy validation check in your pipeline:

aws accessanalyzer validate-policy \
  --policy-document file://deployer-policy.json \
  --policy-type IDENTITY_POLICY

This catches overly broad PassRole grants and missing iam:PassedToService conditions before the policy is ever attached.

4. SCPs at Org Level (Non-negotiable for production accounts)

{
  "Sid": "DenyPassRoleWithoutServiceCondition",
  "Effect": "Deny",
  "Action": "iam:PassRole",
  "Resource": "*",
  "Condition": {
    "Null": {
      "iam:PassedToService": "true"
    }
  }
}

This SCP hard-denies any PassRole call that does not specify a target service — even if a human admin tries it interactively.