Permissions boundaries

Introduction

AWS provides support for permission boundaries for IAM entities, such as users or roles. This advanced feature enables you to utilize a managed policy to define the maximum permissions an identity-based policy can give to an IAM entity. The permissions boundary of an entity only allows actions that are permitted by both its identity-based policies and its permissions boundaries. You have the option to use an AWS-managed policy or a customer-managed policy to establish the boundary for an IAM entity, either a user or role. This policy sets a cap on the maximum permissions for that user or role.

The permissions boundary for an IAM entity dictates the highest level of permissions that an entity can attain. This could alter the effective permissions for the user or role in question. The effective permissions are the combined permissions granted by all policies affecting the user or role. Within an account, the permissions for an entity can be influenced by identity-based policies, resource-based policies, permissions boundaries, Organizations' SCPs, or session policies. Remember, if any one of these policy types explicitly forbids access for an operation, the request will be denied.

Identity-based policies and boundaries

Identity-based policies, which can either be inline or managed, are attached to a user, a group of users, or a role. These policies grant permission to the specified entity, while permission boundaries set a limit to those permissions. The effective permissions are the overlap of both policy types. If either of these policies explicitly denies permission, it takes precedence over the granted permissions.

• Resource-based policies - These policies dictate the way a specific principal can access a resource, to which the policy is attached.

• Resource-based policies for IAM users - In the same account, resource-based policies granting permissions to an IAM user ARN (not a federated user session)are not restricted by an implicit deny in an identity-based policy or permission boundary.

Resource-based policies for IAM roles:

• IAM role: Resource-based policies granting permissions to an IAM role ARN are restricted by an implicit deny in a permission boundary or session policy.

• IAM role session: Within the same account, resource-based policies granting permissions to an IAM role session ARN directly authorize the assumed role session. These permissions aren't restricted by an implicit deny in an identity-based policy, a permission boundary, or session policy. When a role is assumed and a request is made, the IAM role session ARN, not the ARN of the role itself, is the principal making the request.

Resource-based policies for IAM federated user sessions:

• IAM federated user sessions: An IAM federated user session is created by calling GetFederationToken. When a federated user makes a request, the federated user ARN, not the IAM user ARN who federated, is the principal making the request. Within the same account, resource-based policies granting permissions to a federated user ARN directly authorize the session. These permissions aren't restricted by an implicit deny in an identity-based policy, a permission boundary, or session policy.

However, if a resource-based policy grants permission to the ARN of the IAM user who federated, then requests made by the federated user during the session are restricted by an implicit deny in a permission boundary or session policy.

Organizations SCPs

Service Control Policies (SCPs) are applied across an entire AWS account, limiting permissions for every request made by a principal within that account. An IAM entity, such as a user or role, may make a request influenced by an SCP, permissions boundary, and an identity-based policy. The request will only be granted if it's permitted by all three policy types. The effective permissions are the common permissions across all three policy types. If any of these policies explicitly denies a certain action, it supersedes any allows.

You can check if your account is part of an organization in AWS Organizations. Being a member of an organization might mean you're affected by an SCP. To view this information via the AWS CLI command or AWS API operation, you need permissions for the organizations:DescribeOrganization action for your Organizations entity. Further permissions are required to perform the operation in the Organizations console. If you need to ascertain whether an SCP is denying access to a particular request, or if you want to change your effective permissions, get in touch with your AWS Organizations administrator.

Session policies

Session policies are sophisticated policies passed as a parameter when you programmatically initiate a temporary session for a role or federated user. The permissions for a session derive from the IAM entity (user or role) used to establish the session, as well as from the session policy. The permissions granted by the entity's identity-based policy are constrained by the session policy and the permissions boundary. The effective permissions for this combination of policy types are the common permissions across all three policy types. If any of these policies explicitly denies an action, it takes precedence over any allows. To learn more about session policies, refer to the section on Session Policies.

A permissions boundary is a mechanism designed to limit the permissions of IAM entities, such as roles, to prevent them from exceeding predefined limits. It employs an AWS or customer-managed policy to curtail access, and its structure, including resource, action, and effect statements, is similar to other familiar IAM policies. A permissions boundary does not independently grant access to resources. Instead, it sets a maximum limit on permissions that cannot be surpassed, even if a more permissive policy is attached to the role. Permissions boundaries function as a preventive safeguard, as opposed to a detection and correction mechanism. To provide access permissions, resource-based policies ( like S3 bucket policies) or identity-based policies (like managed or inline permissions policies) are used.

The primary use case for permissions boundaries is to constrain the privileges associated with IAM roles, particularly those created by developers or delegated administrators, who have the authority to create and manage such roles. For instance, a developer might create an IAM role with access to all Amazon S3 buckets and Amazon DynamoDB tables within their accounts. If these accounts contain sensitive S3 buckets, such expansive permissions could pose a risk.

To mitigate this risk, the central administrator can attach a condition to the developer's identity policy that ensures the developer can only create a role if it has a permissions boundary policy attached to it. This permissions boundary, enforced by AWS during the authorization process, outlines the maximum permissions the IAM role can possess. The developer remains able to create IAM roles with permissions tailored to specific use cases (e.g., permitting specific actions on non-sensitive Amazon S3 buckets and DynamoDB tables). However, the attached permissions boundary acts as a barrier, blocking access to sensitive AWS resources, even if the developer includes these higher-level permissions in the role’s IAM policy.