IAM Permission Boundaries | Overview & Hands-On.

A deep dive into IAM Permission Boundaries.

It is a core but often misunderstood for advanced security control in AWS Identity and Access Management. 

 Overview: IAM Permission Boundaries

A Permission Boundary is an advanced IAM feature that sets the maximum permissions that an IAM principal (user or role,) can have — even if their attached policies would normally grant more. 

NB:

Persmission Boundaries are Not for Groups

Think of it like a "fence" around what the principal can ever do.
twtech still need an allow in both the:

• Principal’s policy (what they’re granted), and
• Permission boundary (what they’re allowed to have at most) to actually get permission.

 Effective Permission = Principal Policy ∩ Permission Boundary

 Core Concepts

Concept	Description
Principal policy	Normal identity-based policy attached to a user or role. Defines what actions and resources are allowed.
Permission boundary	A special policy attached to the principal that limits the scope of the principal’s permissions.
Resource policies	Separate policies attached to resources (like S3 buckets, KMS keys). These still must allow access.
Evaluation logic	IAM evaluates both the principal’s identity policies and the boundary, along with any SCPs (if in an organization).

 How IAM Permission Boundaries Works (Evaluation Model)

 # Visualize-layered-evaluation.jpg

NB:

All layers must ALLOW an action for it to succeed.If any layer denies, access fails.

 Example: Setup

# Let’s say twtech create a developer role DevRole with this identity policy:

{

  "Effect": "Allow",

  "Action": "s3:*",

  "Resource": "*"

}

# Now attach this permission boundary called DevBoundary:

{

  "Effect": "Allow",

  "Action": [

    "s3:GetObject",

    "s3:ListBucket"

    "CloudWatch:*"

    "IAM:CreateUser"

   "sqs:DeleteQueue"

    "sqs:CreateQueue"

     "ec2:*"

     "ec2:DescribeInstances"

  ],

  "Resource": "*"

}

 Result:

Even though the identity policy allows s3:*, the boundary restricts users or roles to only GetObject and ListBucket.

# Thefore, effective permission for the above s3 Bucket is:

s3:GetObject ✅

s3:ListBucket ✅

s3:PutObject ❌

s3:DeleteObject ❌

 Permission Boundaries vs Other Controls

Control Type	Scope	Purpose
Identity Policy	Defines what the user/role can do	Grants permissions
Resource Policy	Attached to a resource	Grants cross-account or resource-level access
SCP (Service Control Policy)	Organization-level (AWS Organizations)	Restricts what any principal in an account can do
Permission Boundary	Attached to individual users/roles	Restricts that principal’s maximum permissions

#  SCPs are top-down org controls, Permission Boundaries are bottom-up IAM guardrails.

 Common Use Cases

1. Delegated IAM Administration

twtech can let a “power user” or “devops admin” to create roles/users — but constrain them via a permission boundary so they can’t escalate privileges.

Example:

• Allow them to iam:CreateRole
• But attach a boundary that prevents those roles from having AdministratorAccess.

2. Self-Service Access

Developers can create roles for CI/CD pipelines within limits (e.g., access only to specific services like Lambda, S3).

3. Multi-Tenant / Account Factory Models

Enforce consistent limits across automatically provisioned roles (e.g., in Control Tower customizations).

 Chaining IAM Permission Boundaries with Other Mechanisms

Mechanism	Works Together With Boundaries?	Notes
SCPs	✅	SCPs apply before boundaries — can deny even if boundary allows
Resource Policies	✅	Both must allow access
Session Policies (STS...Security Token Service )	✅	Further restrict the session after assuming a role
Inline/Managed Policies	✅	Provide the base permissions which the boundary limits

 Gotchas and Limitations

1. Permission boundaries don’t grant permissions — they only limit.
2. twtech must explicitly attach them when creating or updating a user/role.
3. They don’t affect existing sessions — changes apply to new sessions only.
4. Boundary policies must be managed policies (twtech can’t write them inline on a user/role).
5. Boundary doesn’t apply to resource-based permissions granted to a role/user directly (e.g., S3 bucket policy giving access to a role).

Best Practices

• Use permission boundaries for all delegated administrators.
• Combine with SCPs for multi-account governance.
•  Keep boundaries service-scoped (e.g., limit to specific AWS services).
•  Monitor boundary attachment with AWS Config Rules (e.g., iam-user-permission-boundary-check).
• Log all IAM actions via CloudTrail and analyze with Access Analyzer.

 Summary

Concept	Analogy	Example
Identity Policy	"What I want to do"	“I can use S3”
Permission Boundary	"What I’m allowed to want"	“But only read from S3”
SCP	“Company-wide rulebook”	“No one can delete KMS keys”

 NB: 

Boundaries let twtech delegate without losing control.

Project: Hands-On

How twtech creates users and set IAM Permission Boundaries to users in its Environment.

Search for aws service: IAM (Identity and Access Management)

Create a user

Give user access (providing console access to): twtechpat

Set permissions

Add user to an existing group or create a new one. Using groups is a best-practice way to manage user's permissions by job functions

Review and create

Review  choices. After creating the user, twtech can view and download the autogenerated password, if enabled.

Create user: twtechpat

How twtech sets permission boundaries for users (twtechpat) in Organizations (twtechOrganization)

Download the csvfile for credential of user: twtechpat

Return to users list in IAM : UI

An IAM user is an identity with long-term credentials that is used to interact with AWS in an account.

How twtech assign a policy with Permission Boundaries to users: twtechpat

Select user and click open to its console: twtechpat

Users (twtechpat) should be added perimission: First,

User are assign access base on PoLP, twtechpat is an admin for twtechOrg and should be granted to he can do everything in the Organization (twtechOrg): AdminstratorAccess

Review the following policies will be attached to this user: twtechpat

How twtech uses advanced feature to sets permission boundary for users created: twtechpat

Eventhough user (twtechpat) has administrator access ( to do everything in the organization(twtechOrg), we are setting boundaries which limit user to only:  AmazonS3FullAccess

Set boundaries for user: twtechpat

AmazonS3FullAccess

Provides full access to all buckets via the AWS Management Console.

User (twtechpat) needs to login with the account url and password (from another browser or another computer): to verify the permissions granted him and the IAM Permission boundaries set.

Sample Console sign-in: Console sign-in link

https://twtechuserpat.signin.aws.amazon.com/console

 

Successful sign in for usercreate:  twtechpat

How to verify the IAM Persmission boundaries set user: twtechpat

twtech has full Persmission to only s3 bucket:  Yes

Eventhough users twtechpat has admintrator access, he is limited by the boundaries permform other tasks. For example:

twtechpat can’t:

•        Create create other users
•        Create policies
•        Launch ec2 instance,

twtech is Not Authorized to perfom tasks for : ec2 service

Final tip:

In order for twtechpat to perform tasks (even as an administrator) the organization (twtechOrg) need to set more boundaries as to what users (twtechpat) can perform.