IAM Permission Boundaries | Overview & Hands-On.

IAM Permission Boundaries - Overview & Hands-On.

Scope:

• Intro,
• Core Mechanics,
• Common Use Cases,
• Implementation Details,
• Overview of IAM Permission Boundaries,
• Core Concepts (terminologies),
• Architecture of IAM Permission Boundaries (Evaluation visual Model),
• Sample Setup for a created developer with DevRole & identity policy,
• Permission Boundaries vs Other Controls,
• Common Use Cases,
• Chaining IAM Permission Boundaries with Other Mechanisms,
• Gotchas and Limitations,
• Best Practices,
• Final takeaway,
• Project: Hands-On.

Intro:

• IAM permissions boundaries are an advanced feature used to set the maximum permissions that an identity-based policy can grant to an IAM entity (user or role).
• IAM permissions boundaries act as a preventative guardrail or "fence" to ensure that even if an entity is granted broader permissions later, they cannot exceed the limits defined by the boundary. 

Core Mechanics

• Intersection of Permissions: For an entity to perform an action, that action must be allowed by both its identity-based policy and its permissions boundary.
• No Direct Grant: A permissions boundary alone does not grant any access; it only restricts the maximum possible access.
• Explicit Deny: An explicit deny in either the identity-based policy or the permissions boundary will override any allow.
• Scope: Boundaries do not limit permissions granted by resource-based policies (like S3 bucket policies) or Service Control Policies (SCPs). 

Common Use Cases

• Delegated Administration: Allowing developers to create IAM roles for applications while ensuring those roles cannot exceed a specific set of permissions (e.g., limiting them only to S3 and EC2).
• Preventing Privilege Escalation: Ensuring a user with "iam:*" permissions cannot create a new user or role with more power than they themselves possess.
• Standardized Guardrails: Enforcing account-wide restrictions, such as preventing the deletion of critical resources like CloudTrail logs.

Implementation Details

• Managed Policies: Boundaries are created using customer managed policies.
• Condition Keys: To enforce boundaries, administrators often add Condition keys to a developer's policy that require a specific boundary be attached to any new role they create.
• Management Restrictions: It is critical to restrict the ability to delete or modify the boundary policy itself to prevent users from bypassing the "fence".

NB:

• IAM Permission Boundaries is a core but often misunderstood for advanced security control in AWS Identity and Access Management. 

 Overview of 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), 
• Permission boundary (what they’re allowed to have at most) to actually get permission.
•  Effective Permission = Principal Policy ∩ Permission Boundary

 Core Concepts (terminologies)

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).

Architecture of IAM Permission Boundaries (Evaluation visual Model)

NB:

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

Sample Setup for a created developer with DevRole & identity policy:

# json

{

  "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": "*"

}

# NB:

• 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

NB:

•   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.

Sample:

• 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.

Final takeaway

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 its users.

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) within 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 or to perform every tasks in the organization (twtechOrg), twtechadmin sets boundaries which limit user (twtechpat) to only

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  to some 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 specific tasks (even as an administrator) the organization admin need to set more boundaries as to what users (twtechpat) need perform at any point.
• users (twtechpat) is assigned just the needed permissions to perform task (PoLP)