Permissions Boundary

Permissions Boundary

Permissions Boundary is another type of AWS policy but instead of granting or revoking permissions, it is used to limit the total permissions that can be applied to a particular IAM principal – IAM users, groups or roles. If you have a Permissions Boundary applied to a principal, the total permissions that the principal can have would be limited by what you have put in the Permissions Boundary policy. Example, consider if a user – Shizuka has been granted S3 full admin permissions using the IAM managed policy of AmazonS3FullAccess. Then a Permissions Boundary is assigned to Shizuka’s IAM user with an IAM managed policy of AmazonS3ReadOnlyAccess. What are the effective permissions that Shizuka has? Answer is AmazonS3ReadOnlyAccess since the PB limits the total permission that a principal can have.

The problem of Delegated IAM Permissions Management

Now let’s take a look at a practical use case of Permissions Boundary. The Permissions Boundary serves a very unique purpose in AWS IAM which is to be able to securely delegate permissions to a principal. Consider a scenario – Katrina, the Administrator for an AWS account, wants to create an agile and flexible AWS permissions management model. In this model, Katrina wants their company’s software developers to be able to create their own AWS IAM permissions as needed for application development needs. But Katrina understands that creating such a delegated permissions model might cause a security compromise. If Katrina grants Developers the iam:CreateRole permission, this will enable Developers to create their own permission grants for their custom applications but Developers might also inadvertently create roles with permissions for sensitive activities like creation of long lived credentials with admin access, deletion of customer data, deletion of audit logs, etc.

Solution of Delegated IAM Permission Management

So how does Katrina give Developers the permission to create roles but also ensure that these roles don’t get created with sensitive permissions? One solution is via Permission Boundaries. 

If a permission boundary is attached to an identity (user or role), it limits the maximum permissions that the identity can have, even if that permission is allowed by the IAM policy. So Katrina creates a Permissions Boundary with the following:

• Allow all permissions on AWS (this is the base rule)
• Deny permissions for sensitive activities like creation of long lived credentials with admin access, deletion of customer data, deletion of audit logs, etc.
• Deny creation of any Principal like IAM users, groups or roles without this permissions boundary
• Deny updates to this permissions boundary except from Katrina’s user or another IAM Admin user/role

Then Katrina attaches this to the Developers role along with the iam:createRole IAM policy, and bingo, with this design Katrina solved the problem we started with. Now developers have the flexibility to create their own custom roles with permissions that they want and Katrina still gets the security assurance that Developers will not inadvertently create roles with permissions for sensitive activities.

Lab Demo

We will do a video lab walk-through of Katrina’s use case of delegated IAM Permissions model that we discussed above.

Security tidbits

Summary of security best practices to keep in mind regarding Permissions Boundary: