Permissions Boundary Policy in AWS

AWS Permissions Boundaries is an advanced feature for using a managed policy that allow you to define the maximum permissions a user or role can have. This ensures that even if an administrator grants excessive permissions (through policies or groups), the permissions boundary restricts the effective permissions to only those explicitly allowed by the boundary.

You can use an AWS managed policy or a customer managed policy to set the boundary for an IAM entity (user or role). That policy limits the maximum permissions for the user or role.

❗

When you use a policy to set the permissions boundary for a user, it limits the user's permissions but does not provide permissions on its own.

How Permissions Boundaries Work

Definition: A permissions boundary is an IAM policy attached to a user or role.
Evaluation: When a user or role tries to perform an action, AWS checks:
- Identity-based Policies (e.g., attached to the user or role)
- Permissions Boundary (if applied)
- The intersection of these determines the effective permissions.

Key Limitation: Permissions boundaries do not add permissions; they only limit permissions.

For example:

User A has a policy allowing s3:* on all S3 buckets.
A permissions boundary restricts s3:* to only bucket X.
User A’s effective permissions are constrained to bucket X despite the identity policy.

Permissions Boundary with Resource-based Policies

Resource-based policies – control how the specified principal can access the resource to which the policy is attached.

Within the same account, resource-based policies that grant permissions to an IAM user ARN (that is not a federated user session) are not limited by an implicit deny in an identity-based policy or permissions boundary.

Permissions Boundary with Organizations SCPs

Organizations SCPs – are applied to an entire AWS account. They limit permissions for every request made by a principal within the account. An IAM entity (user or role) can make a request that is affected by an SCP, a permissions boundary, and an identity-based policy. In this case, the request is allowed only if all three policy types allow it. The effective permissions are the intersection of all three policy types. An explicit deny in any of these policies overrides the allow.

Permissions Boundary with Session Policies

Session policies – are advanced policies that you pass as a parameter when you programmatically create a temporary session for a role or federated user. The permissions for a session come from the IAM entity (user or role) used to create the session and from the session policy. The entity's identity-based policy permissions are limited by the session policy and the permissions boundary. The effective permissions for this set of policy types are the intersection of all three policy types. An explicit deny in any of these policies overrides the allow. For more information about session policies, see Session Policies.

Best Practices for Using Permissions Boundaries

Enforce Guardrails for Delegated Administration:
- Use permissions boundaries to limit permissions for IAM users or roles created by administrators. For instance, you can allow users to create roles but ensure the roles they create cannot have permissions beyond those specified by the boundary.
Isolate Privileged Actions:
- Restrict sensitive operations, such as modifying critical infrastructure, by setting boundaries that only permit scoped-down permissions.
Enable Self-Service While Maintaining Security:
- Allow teams or developers to manage their resources autonomously, but limit their actions with permissions boundaries (e.g., restricting EC2 instance sizes or the ability to create resources in specific regions).
Use in Combination with SCPs and Identity Policies:
- Combine permissions boundaries with AWS Organizations Service Control Policies (SCPs) for multi-account environments to provide additional layers of security.
Audit and Review Boundaries:
- Regularly audit permissions boundaries to ensure they still align with organizational needs and compliance requirements.

When to Use Permissions Boundaries

Controlled Delegation of Access Management:
- When you allow specific users or groups to create and manage IAM roles or policies, permissions boundaries ensure these users cannot grant more permissions than allowed by the boundary.
Third-party Integrations:
- Use permissions boundaries to limit permissions granted to third-party tools or applications integrating with your AWS environment.
Scoping Permissions for Temporary or Project-based Roles:
- Apply boundaries to limit permissions for temporary roles used for specific tasks or projects.
Enforcing Least Privilege:
- When onboarding new teams or integrating with external collaborators, permissions boundaries help enforce the principle of least privilege effectively.
Restricting Permissions in Large, Decentralized Teams:
- In organizations with decentralized management of AWS resources, boundaries ensure that distributed teams operate within predefined permission limits.

Common Use Cases

IAM Role Creation by Developers:
- Developers can create roles to support their workloads, but boundaries prevent them from attaching policies with excessive permissions.
Multi-Account Environment in AWS Organizations:
- Permissions boundaries supplement SCPs to ensure that users in specific accounts cannot exceed their allocated permissions.
Restricting Access to Specific AWS Regions or Services:
- Prevent users from creating resources or performing actions in regions not allowed for compliance reasons.
Controlling Automation Frameworks:
- Limit the scope of permissions granted to CI/CD pipelines, automation scripts, or Infrastructure-as-Code (IaC) tools.

Best Practices Recap

Keep Boundaries Minimal and Specific: Define narrow permissions in boundaries to reduce the attack surface.
Combine with SCPs for Layered Security: Use permissions boundaries with SCPs for stronger governance.
Document and Communicate Policies: Ensure that users understand the purpose and scope of the boundaries.
Regularly Test Boundaries: Use AWS Access Analyzer and other tools to validate that boundaries are effective and align with organizational policies.

By implementing permissions boundaries thoughtfully, you can strike a balance between flexibility for teams and robust security governance across your AWS environment.

Privilege Escalation Scenario Without Permissions Boundary

Context: An organization allows developers to create and manage their own IAM roles to enable autonomy for deploying workloads. However, without a permissions boundary in place, this setup can lead to a privilege escalation vulnerability.

Scenario

1. Initial Permissions of a User

The user, DeveloperUser, has permissions to create IAM roles and policies:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "iam:CreateRole",
          "iam:PutRolePolicy",
          "iam:AttachRolePolicy",
          "iam:PassRole"
        ],
        "Resource": "*"
      }
    ]
  }

The intent is that DeveloperUser should only create roles to manage their workloads with limited permissions.

2. Exploiting the Lack of Permissions Boundary

Without a permissions boundary, DeveloperUser can:

Create an Admin Role:

Create an IAM role with administrative privileges (AdministratorAccess managed policy or equivalent inline policy):

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": "*",
        "Resource": "*"
      }
    ]
  }

Assume the Role:
- Add the iam:PassRole action to the DeveloperUser’s permissions, allowing them to pass the created admin role to services like EC2 or Lambda.

Escalate Privileges:

Assume the newly created admin role using AWS CLI or SDK:

  aws sts assume-role --role-arn arn:aws:iam::123456789012:role/AdminRole --role-session-name EscalatedSession

Gain Full Administrative Access:
- The DeveloperUser now has unrestricted access to all AWS services and resources, bypassing the intended scope of their original permissions.

Why a Permissions Boundary Prevents This

With a permissions boundary, you can enforce a policy that restricts the maximum permissions any role created by DeveloperUser can have. For example:

Permissions Boundary Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": "iam:*",
      "Resource": "*"
    }
  ]
}

This ensures that even if DeveloperUser tries to create a role with admin permissions, the permissions boundary restricts the effective permissions to only ec2:* and s3:*.