Permissions boundaries for IAM entities
Amazon supports permissions boundaries for IAM entities (users or roles). A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity's permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.
For more information about policy types, see Policy types.
Important
Don't use resource-based policy statements that include a NotPrincipal
policy element with a Deny
effect for IAM users or roles that have a
permissions boundary policy attached. The NotPrincipal
element with a
Deny
effect will always deny any IAM principal that has a permissions
boundary policy attached, regardless of the values specified in the
NotPrincipal
element. This causes some IAM users or roles that would
otherwise have access to the resource to lose access. We recommend changing your
resource-based policy statements to use the condition operator ArnNotEquals with the aws:PrincipalArn context
key to limit access instead of the NotPrincipal
element. For information
about the NotPrincipal
element, see Amazon JSON policy elements:
NotPrincipal.
You can use an Amazon 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.
For example, assume that the IAM user named ShirleyRodriguez
should be
allowed to manage only Amazon S3, Amazon CloudWatch, and Amazon EC2. To enforce this rule, you can use the
following policy to set the permissions boundary for the ShirleyRodriguez
user:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:*", "cloudwatch:*", "ec2:*" ], "Resource": "*" } ] }
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. In this example, the policy sets
the maximum permissions of ShirleyRodriguez
as all operations in Amazon S3, CloudWatch,
and Amazon EC2. Shirley can never perform operations in any other service, including IAM, even
if she has a permissions policy that allows it. For example, you can add the following
policy to the ShirleyRodriguez
user:
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "iam:CreateUser", "Resource": "*" } }
This policy allows creating a user in IAM. If you attach this permissions policy to the
ShirleyRodriguez
user, and Shirley tries to create a user, the operation
fails. It fails because the permissions boundary does not allow the
iam:CreateUser
operation. Given these two policies, Shirley does not have
permission to perform any operations in Amazon. You must add a different permissions policy
to allow actions in other services, such as Amazon S3. Alternatively, you could update the
permissions boundary to allow her to create a user in IAM.
Evaluating effective permissions with boundaries
The permissions boundary for an IAM entity (user or role) sets the maximum permissions that the entity can have. This can change the effective permissions for that user or role. The effective permissions for an entity are the permissions that are granted by all the policies that affect the user or role. Within an account, the permissions for an entity can be affected by identity-based policies, resource-based policies, permissions boundaries, Organizations SCPs, or session policies. For more information about the different types of policies, see Policies and permissions in Amazon Identity and Access Management.
If any one of these policy types explicitly denies access for an operation, then the request is denied. The permissions granted to an entity by multiple permissions types are more complex. For more details about how Amazon evaluates policies, see Policy evaluation logic.
Identity-based policies with boundaries – Identity-based policies are inline or managed policies that are attached to a user, group of users, or role. Identity-based policies grant permission to the entity, and permissions boundaries limit those permissions. The effective permissions are the intersection of both policy types. An explicit deny in either of these policies overrides the allow.
Resource-based policies – Resource-based policies control how the specified principal can access the resource to which the policy is attached.
- Resource-based policies for IAM users
-
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.
- Resource-based policies for IAM roles
-
IAM role – Resource-based policies that grant permissions to an IAM role ARN are limited by an implicit deny in a permissions boundary or session policy.
IAM role session – Within the same account, resource-based policies that grant permissions to an IAM role session ARN grant permissions directly to the assumed role session. Permissions granted directly to a session are not limited by an implicit deny in an identity-based policy, a permissions boundary, or session policy. When you assume a role and make a request, the principal making the request is the IAM role session ARN and not the ARN of the role itself.
- Resource-based policies for IAM federated user sessions
-
IAM federated user sessions – An IAM federated user session is a session created by calling GetFederationToken. When a federated user makes a request, the principal making the request is the federated user ARN and not the ARN of the IAM user who federated. Within the same account, resource-based policies that grant permissions to a federated user ARN grant permissions directly to the session. Permissions granted directly to a session are not limited by an implicit deny in an identity-based policy, a permissions 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 limited by an implicit deny in a permission boundary or session policy.
Organizations SCPs – SCPs are applied to an entire Amazon Web Services 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.
You can learn whether your account is a member of an organization in Amazon Organizations.
Organization members might be affected by an SCP. To view this data using the Amazon CLI
command or Amazon API operation, you must have permissions for the
organizations:DescribeOrganization
action for your Organizations entity. You
must have additional permissions to perform the operation in the Organizations console. To learn
whether an SCP is denying access to a specific request, or to change your effective
permissions, contact your Amazon Organizations administrator.
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.
Delegating responsibility to others using permissions boundaries
You can use permissions boundaries to delegate permissions management tasks, such as user creation, to IAM users in your account. This permits others to perform tasks on your behalf within a specific boundary of permissions.
For example, assume that María is the administrator of the X-Company Amazon Web Services account. She wants to delegate user creation duties to Zhang. However, she must ensure that Zhang creates users that adhere to the following company rules:
-
Users cannot use IAM to create or manage users, groups, roles, or policies.
-
Users are denied access to the Amazon S3
logs
bucket and cannot access thei-1234567890abcdef0
Amazon EC2 instance. -
Users cannot remove their own boundary policies.
To enforce these rules, María completes the following tasks, for which details are included below:
-
María creates the
XCompanyBoundaries
managed policy to use as a permissions boundary for all new users in the account. -
María creates the
DelegatedUserBoundary
managed policy and assigns it as the permissions boundary for Zhang. Maria makes a note of her admin user's ARN and uses it in the policy to prevent Zhang from accessing it. -
María creates the
DelegatedUserPermissions
managed policy and attaches it as a permissions policy for Zhang. -
María tells Zhang about his new responsibilities and limitations.
Task 1: María must first create a managed policy to
define the boundary for the new users. María will allow Zhang to give users the
permissions policies they need, but she wants those users to be restricted. To do this,
she creates the following customer managed policy with the name
XCompanyBoundaries
. This policy does the following:
-
Allows users full access to several services
-
Allows limited self-managing access in the IAM console. This means they can change their password after signing into the console. They can't set their initial password. To allow this, add the
"*LoginProfile"
action to theAllowManageOwnPasswordAndAccessKeys
statement. -
Denies users access to the Amazon S3 logs bucket or the
i-1234567890abcdef0
Amazon EC2 instance
{ "Version": "2012-10-17", "Statement": [ { "Sid": "ServiceBoundaries", "Effect": "Allow", "Action": [ "s3:*", "cloudwatch:*", "ec2:*", "dynamodb:*" ], "Resource": "*" }, { "Sid": "AllowIAMConsoleForCredentials", "Effect": "Allow", "Action": [ "iam:ListUsers", "iam:GetAccountPasswordPolicy" ], "Resource": "*" }, { "Sid": "AllowManageOwnPasswordAndAccessKeys", "Effect": "Allow", "Action": [ "iam:*AccessKey*", "iam:ChangePassword", "iam:GetUser", "iam:*ServiceSpecificCredential*", "iam:*SigningCertificate*" ], "Resource": ["arn:aws-cn:iam::*:user/${aws:username}"] }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws-cn:s3:::logs", "arn:aws-cn:s3:::logs/*" ] }, { "Sid": "DenyEC2Production", "Effect": "Deny", "Action": "ec2:*", "Resource": "arn:aws-cn:ec2:*:*:instance/i-1234567890abcdef0" } ] }
Each statement serves a different purpose:
-
The
ServiceBoundaries
statement of this policy allows full access to the specified Amazon services. This means that a new user's actions in these services are limited only by the permissions policies that are attached to the user. -
The
AllowIAMConsoleForCredentials
statement allows access to list all IAM users. This access is necessary to navigate the Users page in the Amazon Web Services Management Console. It also allows viewing the password requirements for the account, which is necessary when changing your own password. -
The
AllowManageOwnPasswordAndAccessKeys
statement allows users to manage only their own console password and programmatic access keys. This is important if Zhang or another administrator assigns a new user a permissions policy with full IAM access. In that case, that user could then change their own or other users' permissions. This statement prevents that from happening. -
The
DenyS3Logs
statement explicitly denies access to thelogs
bucket. -
The
DenyEC2Production
statement explicitly denies access to thei-1234567890abcdef0
instance.
Task 2: María wants to allow Zhang to create all
X-Company users, but only with the XCompanyBoundaries
permissions boundary.
She creates the following customer managed policy named
DelegatedUserBoundary
. This policy defines the maximum permissions that
Zhang can have.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "CreateOrChangeOnlyWithBoundary", "Effect": "Allow", "Action": [ "iam:AttachUserPolicy", "iam:CreateUser", "iam:DeleteUserPolicy", "iam:DetachUserPolicy", "iam:PutUserPermissionsBoundary", "iam:PutUserPolicy" ], "Resource": "*", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws-cn:iam::123456789012:policy/XCompanyBoundaries" } } }, { "Sid": "CloudWatchAndOtherIAMTasks", "Effect": "Allow", "Action": [ "cloudwatch:*", "iam:CreateAccessKey", "iam:CreateGroup", "iam:CreateLoginProfile", "iam:CreatePolicy", "iam:DeleteGroup", "iam:DeletePolicy", "iam:DeletePolicyVersion", "iam:DeleteUser", "iam:GetAccountPasswordPolicy", "iam:GetGroup", "iam:GetLoginProfile", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:GetRolePolicy", "iam:GetUser", "iam:GetUserPolicy", "iam:ListAccessKeys", "iam:ListAttachedRolePolicies", "iam:ListAttachedUserPolicies", "iam:ListEntitiesForPolicy", "iam:ListGroups", "iam:ListGroupsForUser", "iam:ListMFADevices", "iam:ListPolicies", "iam:ListPolicyVersions", "iam:ListRolePolicies", "iam:ListSSHPublicKeys", "iam:ListServiceSpecificCredentials", "iam:ListSigningCertificates", "iam:ListUserPolicies", "iam:ListUsers", "iam:SetDefaultPolicyVersion", "iam:SimulateCustomPolicy", "iam:SimulatePrincipalPolicy", "iam:UpdateGroup", "iam:UpdateLoginProfile", "iam:UpdateUser" ], "NotResource": "arn:aws-cn:iam::123456789012:user/Maria" }, { "Sid": "NoBoundaryPolicyEdit", "Effect": "Deny", "Action": [ "iam:CreatePolicyVersion", "iam:DeletePolicy", "iam:DeletePolicyVersion", "iam:SetDefaultPolicyVersion" ], "Resource": [ "arn:aws-cn:iam::123456789012:policy/XCompanyBoundaries", "arn:aws-cn:iam::123456789012:policy/DelegatedUserBoundary" ] }, { "Sid": "NoBoundaryUserDelete", "Effect": "Deny", "Action": "iam:DeleteUserPermissionsBoundary", "Resource": "*" } ] }
Each statement serves a different purpose:
-
The
CreateOrChangeOnlyWithBoundary
statement allows Zhang to create IAM users but only if he uses theXCompanyBoundaries
policy to set the permissions boundary. This statement also allows him to set the permissions boundary for existing users but only using that same policy. Finally, this statement allows Zhang to manage permissions policies for users with this permissions boundary set. -
The
CloudWatchAndOtherIAMTasks
statement allows Zhang to complete other user, group, and policy management tasks. He has permissions to reset passwords and create access keys for any IAM user not listed in theNotResource
policy element. This allows him to help users with sign-in issues. -
The
NoBoundaryPolicyEdit
statement denies Zhang access to update theXCompanyBoundaries
policy. He is not allowed to change any policy that is used to set the permissions boundary for himself or other users. -
The
NoBoundaryUserDelete
statement denies Zhang access to delete the permissions boundary for himself or other users.
María then assigns the DelegatedUserBoundary
policy as the permissions
boundary for the Zhang
user.
Task 3: Because the permissions boundary limits the
maximum permissions, but does not grant access on its own, Maria must create a
permissions policy for Zhang. She creates the following policy named
DelegatedUserPermissions
. This policy defines the operations that Zhang
can perform, within the defined boundary.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "IAM", "Effect": "Allow", "Action": "iam:*", "Resource": "*" }, { "Sid": "CloudWatchLimited", "Effect": "Allow", "Action": [ "cloudwatch:GetDashboard", "cloudwatch:GetMetricData", "cloudwatch:ListDashboards", "cloudwatch:GetMetricStatistics", "cloudwatch:ListMetrics" ], "Resource": "*" }, { "Sid": "S3BucketContents", "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws-cn:s3:::ZhangBucket" } ] }
Each statement serves a different purpose:
-
The
IAM
statement of the policy allows Zhang full access to IAM. However, because his permissions boundary allows only some IAM operations, his effective IAM permissions are limited only by his permissions boundary. -
The
CloudWatchLimited
statement allows Zhang to perform five actions in CloudWatch. His permissions boundary allows all actions in CloudWatch, so his effective CloudWatch permissions are limited only by his permissions policy. -
The
S3BucketContents
statement allows Zhang to list theZhangBucket
Amazon S3 bucket. However, his permissions boundary does not allow any Amazon S3 action, so he cannot perform any S3 operations, regardless of his permissions policy.Note
Zhang's policies allow him to create a user that can then access Amazon S3 resources that he can't access. By delegating these administrative actions, Maria effectively trusts Zhang with access to Amazon S3.
María then attaches the DelegatedUserPermissions
policy as the
permissions policy for the Zhang
user.
Task 4: She gives Zhang instructions to create a new
user. She tells him that he can create new users with any permissions that they need,
but he must assign them the XCompanyBoundaries
policy as a permissions
boundary.
Zhang completes the following tasks:
-
Zhang creates a user with the Amazon Web Services Management Console. He types the user name
Nikhil
and enables console access for the user. He clears the checkbox next to Requires password reset, because the policies above allow users to change their passwords only after they are signed in to the IAM console. -
On the Set permissions page, Zhang chooses the IAMFullAccess and AmazonS3ReadOnlyAccess permissions policies that allow Nikhil to do his work.
-
Zhang skips the Set permissions boundary section, forgetting María's instructions.
-
Zhang reviews the user details and chooses Create user.
The operation fails and access is denied. Zhang's
DelegatedUserBoundary
permissions boundary requires that any user he creates have theXCompanyBoundaries
policy used as a permissions boundary. -
Zhang returns to the previous page. In the Set permissions boundary section, he chooses the
XCompanyBoundaries
policy. -
Zhang reviews the user details and chooses Create user.
The user is created.
When Nikhil signs in, he has access to IAM and Amazon S3, except those operations that are denied by the permissions boundary. For example, he can change his own password in IAM but can't create another user or edit his policies. Nikhil has read-only access to Amazon S3.
If someone adds a resource-based policy to the logs
bucket that allows
Nikhil to put an object in the bucket, he still cannot access the bucket. The reason is
that any actions on the logs
bucket are explicitly denied by his
permissions boundary. An explicit deny in any policy type results in a request being
denied. However, if a resource-based policy attached to a Secrets Manager secret allows
Nikhil to perform the secretsmanager:GetSecretValue
action, then Nikhil can
retrieve and decrypt the secret. The reason is that Secrets Manager operations are not
explicitly denied by his permissions boundary, and implicit denies in permissions
boundaries do not limit resource-based policies.