IAM Permissions Boundaries: Secure Delegation in AWS

Permissions boundaries are an advanced AWS IAM feature used to delegate the creation of IAM entities (like roles or users) to others without allowing them to escalate their own privileges. It defines the maximum permissions that an identity-based policy can grant to an IAM entity.

Learning Objectives

After studying this guide, you should be able to:

• Explain the purpose of permissions boundaries in preventing privilege escalation.
• Calculate the effective permissions of a user when an identity-based policy and a boundary coexist.
• Implement a delegation strategy that allows developers to create IAM roles safely.
• Distinguish between Service Control Policies (SCPs) and Permissions Boundaries.

Key Terms & Glossary

• Permissions Boundary: A managed policy that sets the maximum permissions for an IAM entity. It does not grant permissions on its own.
• Identity-based Policy: The standard IAM policy attached to a user or role that grants specific permissions.
• Privilege Escalation: An exploit where a user gains a higher level of access than intended (e.g., a developer creating an Admin role for themselves).
• Effective Permissions: The actual actions a user can perform, determined by the intersection of all applicable policy types.
• Delegate Administrator: A non-admin user (like a DevOps lead) who is given limited iam:* permissions to manage their team's access.

The "Big Idea"

In large-scale AWS environments, the central security team cannot manage every individual IAM role. They need to delegate this task to team leads. However, giving a team lead iam:CreateRole is dangerous because they could create a role with AdministratorAccess. Permissions boundaries solve this by acting as a "guardrail": the central admin says, "You can create roles, but those roles can never do more than what this boundary allows."

Formula / Concept Box

The Evaluation Logic

The permissions boundary and the identity-based policy must both allow an action for it to be permitted. This is a logical AND operation.

Visual Anchors

Permission Intersection

This diagram shows that the effective permissions are only where the two policies overlap.

Evaluation Flow

Hierarchical Outline

• I. Anatomy of a Boundary
  • Managed Policy: Boundaries use standard JSON managed policies.
  • Attachment: Attached via the Permissions Boundary tab in the IAM console or the --permissions-boundary CLI flag.
• II. The Delegation Pattern
  • The Condition Key: Use iam:PermissionsBoundary in the delegate's policy to enforce boundary attachment.
  • Logic: "You can create a role ONLY IF you attach this specific boundary to it."
• III. Scope of Impact
  • Entities: Applies to IAM Users and Roles.
  • Exclusions: Does not apply to Resource-based policies (like S3 Bucket policies) or the Root user.

Definition-Example Pairs

• Term: Maximum Permission Set
• Definition: The theoretical limit of what an entity can do, regardless of what its identity policy says.
• Example: If a boundary allows S3:* but the identity policy allows S3:* and EC2:*, the user cannot touch EC2 because it exceeds the maximum set by the boundary.

Worked Examples

Scenario: Secure Developer Delegation

Goal: Allow a Developer to create IAM roles for Lambda functions, but ensure those roles can only access a specific S3 bucket.

1. Create the Boundary Policy (AppBoundary):
   jsonCopy

   { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": "arn:aws:s3:::my-app-data/*" } ] }
2. Create the Developer's Policy: This policy allows the developer to create roles, but only if they attach the AppBoundary.
   jsonCopy

   { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["iam:CreateRole", "iam:AttachRolePolicy"], "Resource": "*", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::123:policy/AppBoundary" } } } ] }

Checkpoint Questions

1. If a boundary allows dynamodb:PutItem and the identity policy allows dynamodb:*, can the user perform dynamodb:DeleteItem?
   (Answer: No. The boundary restricts the maximum to PutItem only.)
2. Does a permissions boundary grant permissions to a user if they have no identity-based policy attached?
   (Answer: No. A boundary only limits existing permissions; it never grants them.)
3. Can a permissions boundary be used to restrict the permissions of the AWS account Root user?
   (Answer: No. Boundaries do not affect the Root user.)

Muddy Points & Cross-Refs

• Boundaries vs. SCPs: Students often confuse these. Remember: SCPs apply to the entire Account (in AWS Organizations). Boundaries apply to specific IAM Users/Roles within an account.
• Resource-based Policies: A boundary does not limit a resource-based policy. If an S3 bucket policy allows a user access, the boundary does not block it unless the identity policy is also involved.
• Session Policies: These are used during AssumeRole calls and are even more temporary than boundaries.

Comparison Tables