DEV Community

Shuichi Takahashi
Shuichi Takahashi

Posted on

Using Permission Boundaries for IAM Role Creation in AWS Organizations Management Account

#aws

In AWS Organizations, the "management account" is a special account.
It owns all organizational settings and has powerful permissions.
By default, it can register and remove accounts from the organization, handle billing, and manage organization-wide settings.

Reference: AWS Organizations Management Account

Therefore, it is a best practice to limit management account access to a small number of people and delegate functions and operations whenever possible.
The functions that can be delegated are listed in the AWS Services integrated with Organizations documentation.
Functions with "Supports delegated administrator" set to "Yes" can be delegated to specified member accounts.

Reference: AWS Services Integrated with Organizations

Additionally, the management account is not subject to control policies such as SCPs, making it difficult to restrict.

Reference: Service Control Policies (SCP)

For cases where you cannot delegate everything and need to give access to the management account, you can use methods like assigning roles with limited permissions through IAM Identity Center.

Reference: AWS IAM Identity Center

The problem occurs when developers need to create IAM roles.
For example, they want to deploy a Lambda function or setup serverless infrastructure.
There are several ways to handle this. This article explains one approach: Permission Boundaries.

The Challenge: When Allowing iam:CreateRole

When you give someone iam:CreateRole permission, it looks reasonable.
However, there is a problem: they can create roles with much more permissions than they have.

Diagram showing privilege escalation when users can create IAM roles with more permissions than their own

When these IAM roles are used, the intended permission control becomes ineffective.

Why Permission Boundary Matters in Management Account

Management account has a difficult situation. Developers need to create IAM roles for their applications, but SCPs cannot help - they don't work on management accounts.

Here is an example: a development team wants to deploy a Lambda that reads from S3. They request iam:CreateRole permission.

The escalation pattern:

  1. Developer creates role with s3:GetObject (intended behavior)
  2. Developer needs CloudWatch logs, adds logs:CreateLogGroup
  3. Still getting errors, changes to logs:*
  4. More problems occur, adds *:* temporarily
  5. Six months later, that temporary role with full permissions is still in production

This escalation pattern happens frequently. Developers focus on making their application work rather than security boundaries.

Permission Boundary acts like a chain that restricts IAM entities. No matter what permissions you try to attach, you cannot break free from the boundary's constraints.

Important point: Setting the boundary is not enough. If users can remove it, the security is gone. You must block iam:DeleteRolePermissionsBoundary and iam:PutRolePermissionsBoundary actions.

Operational Reality: Developers initially resist the additional complexity. However, when they understand it enables self-service IAM role creation without security team approval, adoption improves. Self-service approach is more efficient than ticket-based processes.

Debugging Complexity: When permissions fail, troubleshooting becomes harder because you must check both identity-based policies AND Permission Boundaries. Invest in logging and documentation upfront.

Reference: IAM Permissions Boundaries

Implementing Permission Boundary Control

When you want to grant IAM role creation permissions but prevent users from creating roles with excessive permissions, you can use Permission Boundaries for control. By setting a policy that explicitly denies unwanted operations as a Permission Boundary and forcing the application of this Permission Boundary when creating IAM roles, you can control the upper limit of permissions.

Diagram illustrating how Permission Boundary controls and limits IAM role creation permissions

Enforcing Permission Boundary Inheritance

A critical challenge emerges when roles create other roles: how do you ensure that "child" and "grandchild" roles maintain the same constraints? Permission Boundaries don't automatically inherit, but you can enforce inheritance through policy design.

The Solution: Self-Referencing Permission Boundary

The key insight is to make the Permission Boundary policy reference itself. Include this condition in your baseline_policy Permission Boundary:

{
  "Effect": "Deny",
  "Action": [
    "iam:CreateUser",
    "iam:CreateRole"
  ],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "iam:PermissionsBoundary": "arn:aws:iam::ACCOUNT-ID:policy/baseline_policy"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Why Self-Reference Works:

The baseline_policy enforces that new roles must have the same Permission Boundary attached. This creates a chain where all created roles inherit the same constraints.

How Self-Reference Creates the Chain:

  1. Parent Role has baseline_policy as its Permission Boundary
  2. Parent Role attempts to create a new role
  3. The baseline_policy denies the creation unless the new role also gets baseline_policy as its Permission Boundary
  4. Child Role is created with the identical Permission Boundary (baseline_policy)
  5. When Child Role creates another role, the same self-referencing constraint applies
  6. Grandchild Role and all subsequent generations must also have baseline_policy as their Permission Boundary

Chain of Enforcement:

Parent Role (Boundary: baseline_policy)
  ↓ iam:CreateRole (must specify same boundary)
Child Role (Boundary: baseline_policy)
  ↓ iam:CreateRole (must specify same boundary)
Grandchild Role (Boundary: baseline_policy)
Enter fullscreen mode Exit fullscreen mode

Additional Protection:

To prevent boundary removal, also deny these actions:

{
  "Effect": "Deny",
  "Action": [
    "iam:DeleteRolePermissionsBoundary",
    "iam:PutRolePermissionsBoundary"
  ],
  "Resource": "*"
}
Enter fullscreen mode Exit fullscreen mode

This approach ensures that regardless of how many generations of roles are created, they all maintain the same constraints. This prevents privilege escalation problems.

Alternative Approaches

For permission control in management account, there are other methods besides Permission Boundary:

  • Data Migration: When data in the management account is needed, share or copy only the necessary parts of that data to member accounts and build solutions in the member accounts
  • Work Separation: Have administrators or CI/CD pipelines handle IAM role creation and deployment work, and give general users only execution permissions

Considerations for Permission Boundary Usage

Permission Boundaries can be used not only in management account but also in member accounts. However, they add operational complexity. Before implementation, evaluate whether the security benefits justify the operational overhead:

  • Operational Complexity: Permission Boundaries add an additional layer of policy evaluation, which can make troubleshooting permission issues more complex
  • Development Velocity: Strict boundaries may slow down development workflows, especially in environments requiring frequent role modifications
  • Maintenance Overhead: Permission Boundary policies need to be maintained and updated as business requirements evolve
  • User Experience: Developers may encounter unexpected permission denials, requiring additional training and documentation

Before implementing Permission Boundaries, ensure your team can manage the additional complexity and that the security benefits are significant for your use case.

Reference Links

AWS Organizations and IAM Related

AWS Well-Architected Related

Top comments (0)