How We Prevent Privilege Escalation with AWS IAM Permission Boundaries (A Practical DevOps Guide)

In environments like ours, it’s crucial to strike a balance between DevOps flexibility and tight security controls. Imagine a scenario where DevOps members can create admin roles for team members—but, we need to ensure that these admins cannot further create roles or users with the same admin privileges.

Today, I'll show you how we achieved this, ensuring that admin roles created with project lead permission cannot escalate privileges by creating new admin users or roles.

---

Step 1: Using IAM Permission Boundaries to Restrict Admin Capabilities

The Problem

Even when DevOps grants admin access to someone, we need to ensure that this admin cannot create other users or roles with AdministratorAccess.

The Solution

We implement IAM Permission Boundaries. When a role is created, the permission boundary ensures that the role (even with admin privileges) cannot escalate privileges further by creating other admin-level users or roles.

Here’s the boundary:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PreventPrivilegeEscalation",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:CreateRole",
        "iam:AttachUserPolicy",
        "iam:AttachRolePolicy"
      ],
      "Resource": "*",
      "Condition": {
        "ArnLike": {
          "iam:PolicyArn": [
            "arn:aws:iam::aws:policy/AdministratorAccess",
            "arn:aws:iam::aws:policy/PowerUserAccess"
          ]
        }
      }
    }
  ]
}

What This Achieves:

• This boundary prevents anyone, including admins, from creating new users or roles with full admin access.

• Admin roles can still perform their duties, but they cannot elevate privileges for others.

We attach the permission boundary to every role:

aws iam create-role --role-name AdminRole \
  --assume-role-policy-document file://trust-policy.json \
  --permissions-boundary arn:aws:iam::123456789012:policy/PreventPrivilegeEscalation

---

Step 2: Applying SCPs to Enforce Boundaries Across the Organization

While IAM Permission Boundaries limit actions, Service Control Policies (SCPs) ensure that permission boundaries are always applied whenever roles or users are created across the organization.

Here’s the SCP we used:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforcePermissionBoundaries",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:CreateRole",
        "iam:AttachUserPolicy",
        "iam:AttachRolePolicy"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/PreventPrivilegeEscalation"
        }
      }
    }
  ]
}

What This Achieves:

• This SCP enforces the use of the permission boundary across all accounts or OUs.

• No one can create a user or role without attaching the boundary.

This way, even if DevOps creates new admin roles, those roles are still restricted by the permission boundary.

---

Step 3: Role Creation Workflow with Project Lead Permission

In our scenario, DevOps needs the project lead’s permission to create admin roles. But, once that role is created:

• Admins can’t further create users or roles with admin permissions.

• They can’t attach policies that grant admin-level access to anyone else.

This ensures a hierarchical control where DevOps can assign admin roles but ensures no further escalation is possible.

Here’s the flow:

1. DevOps team requests permission from the project lead to create an admin role.

2. Once approved, DevOps creates the admin role, but the role has permission boundaries attached.

3. The admin role is created, but it cannot escalate privileges or create other users or roles with high privileges.

---

Conclusion

By using a combination of IAM Permission Boundaries and SCPs, we’ve created a secure environment where:

1. DevOps can create admin roles with project lead approval.

2. Admins are restricted from creating or attaching high-privilege policies like AdministratorAccess to users or roles.

3. SCPs enforce the use of permission boundaries across the organization, making sure everyone adheres to the same security standards.

This approach ensures complete control over privilege escalation while still allowing necessary flexibility in creating admin roles when needed. Let me know if you’ve faced similar challenges and how you’ve tackled them!