Permissions boundaries and delegation

Exam tasks: 4.2 (Skills 4.2.1 authorization controls for human, application and system access, 4.2.3 least-privilege policies with permission boundaries)

The decision: how do you let a team create and attach IAM roles for their own workloads without letting them create a role more powerful than themselves?

What a boundary isCopy Anchor Link

• A managed policy set as the permissions boundary of a user or role. One boundary per entity.
• Effective permissions are the intersection of the identity policies and the boundary. The boundary never grants anything by itself.
• It doesn't limit resource-based policies that name the user or role session directly (same account), and it doesn't apply to groups.
• An explicit deny in the boundary works like any other explicit deny.

Delegating role creation safelyCopy Anchor Link

The pattern: developers in account 7788 may create roles for their Lambda functions, but every role they create must carry the dev-workload-boundary policy, and they can't remove or weaken it.

{
  "Sid": "CreateRolesOnlyWithBoundary",
  "Effect": "Allow",
  "Action": ["iam:CreateRole", "iam:PutRolePermissionsBoundary", "iam:AttachRolePolicy", "iam:PutRolePolicy"],
  "Resource": "arn:aws:iam::778899001122:role/app/*",
  "Condition": {
    "StringEquals": {
      "iam:PermissionsBoundary": "arn:aws:iam::778899001122:policy/dev-workload-boundary"
    }
  }
}

IAM pathsCopy Anchor Link

• Paths such as /app/ or /platform/security/ are part of the ARN, so policies can scope actions to arn:aws:iam::*:role/app/*.
• They're organisational only: a path grants nothing and can't be changed on an existing role. Use them with boundaries to separate what teams can touch.

iam:PassRoleCopy Anchor Link

A service such as EC2, Lambda, ECS or Glue acts as a role you hand it. Handing over the role needs iam:PassRole on that role's ARN.

• Without a scope, iam:PassRole on * lets anyone who can launch an instance attach any role, including an admin one, then use it from the instance. It's a classic privilege-escalation path.
• Scope the resource to a path (role/app/*) and add iam:PassedToService so the role can only go to the service you intend.
• iam:AssociatedResourceArn narrows which resource the role can be attached to, for services that support it.
• PassRole is a permission, not an API call, so there's no PassRole event in CloudTrail. You see it inside the service call that used it, such as RunInstances or CreateFunction.

{
  "Sid": "PassAppRolesToLambdaOnly",
  "Effect": "Allow",
  "Resource": "arn:aws:iam::778899001122:role/app/*",
  "Action": "iam:PassRole",
  "Condition": { "StringEquals": { "iam:PassedToService": "lambda.amazonaws.com" } }
}

Service-linked rolesCopy Anchor Link

• Created and owned by an AWS service (AWSServiceRoleFor...), with a trust policy and permissions you can't edit. Some are created automatically when you first use a feature.
• SCPs and RCPs don't restrict them. That's by design, so services keep working, and it means you can't use an SCP to stop, say, a service writing to its own resources with its linked role.
• Creating one needs iam:CreateServiceLinkedRole. You can deny that in an SCP to block a service being set up, which is an indirect control.
• Deleting one usually requires cleaning up the service's resources first.

ScenariosCopy Anchor Link

Further readingCopy Anchor Link

• Permissions boundaries for IAM entities
• Grant a user permissions to pass a role to an AWS service
• Using service-linked roles