Permissions Boundaries – Determining an Authentication and Access Control Strategy for Complex Organizations – SAP-C02 Study Guide

Permissions Boundaries

Permissions boundaries allow us to define the maximum permissions that identity-based policies can give to IAM entities (user or role). An entity can then only perform actions allowed by both its identity-based policies and its permissions boundaries. Setting a permissions boundary does not give permissions on its own but it limits what the entity can do. It is also worth noting that permissions boundaries do not affect the permissions provided by resource-based policies. A resource-based policy can provide permissions to an IAM entity beyond the scope defined by permissions boundaries.

Look at an example to learn how this all works.

Suppose that you have an IAM user with the following identity-based policy:

{
  “Version”: “2012-10-17”,
  “Statement”: {
    “Effect”: “Allow”,
    “Action”: “iam:ChangePassword”,
    “Resource”: “*”
  }
}

The policy gives them the ability to change their user’s password.

Now, imagine that you set for the same user the following permissions boundary:

{
  “Version”: “2012-10-17”,
  “Statement”: [
    {
      “Effect”: “Allow”,
      “Action”: [
        “lambda:*”,
        “ec2:*”
      ],
      “Resource”: “*”
    }
  ]
}

The permissions boundary policy limits the user to any action on both AWS Lambda and Amazon Elastic Compute Cloud (EC2) resources in their AWS account.

Now, if the user tries to change their password (after all, they were given the permissions to do so) the operation will fail. Why? The user was given permissions in their identity-based policy to change their password, but their permissions boundary only allowed actions to be performed on AWS Lambda and Amazon EC2, not on AWS IAM. For the iam:ChangePassword action to work, the user’s permissions boundary would need to be expanded to include at least that action on AWS IAM.

On a second note, the user was not given permission to perform any other action than iam:ChangePassword. So, even though their permissions boundary would authorize them to perform any action on AWS Lambda and Amazon EC2, they simply cannot do so because their identity-based policy is too restrictive.

Additionally, imagine that you have defined on the same account the previous sample resource-based policy providing permissions to any principal (user or role) in the account to get any object from the S3 bucket identified by the Resource attribute. Even though the permissions boundary policy limits your user’s actions to AWS Lambda and Amazon EC2 resources, your user will nevertheless be able to get any object from the S3 bucket specified in the resource-based policy. Why is that? Because permissions boundaries only affect the scope of permissions defined by identity-based policies, not by resource-based policies.

That said, permissions boundaries are an efficient mechanism to thwart privilege escalation by limiting what IAM entities (user or role) can do independently of the identity-based policies that are attached to them. Diving deeper into this goes beyond the scope of this chapter.

Remember that permissions boundaries do not add permissions to what an IAM entity can do; they only limit what it can do.