What is a Permissions Boundary
Permissions Boundary is a feature of AWS IAM that allows you to attach a policy to a user or role to limit its effective permissions. The user/role might have full Administration permissions attached to it but if you attach a permissions boundary that gives it S3 read access only, then the effective permissions for that user/role will be S3 read only. The effective permissions determined by the overlap between the user/roles Identity-based policies and the permissions boundary policies. Sounds complicated? Let’s try an analogy – One Piece style. 🙂
Luffy was a perfectly ordinary boy who dreamed of being Pirate King. Luffy is our IAM user here. Luffy ate a devil fruit that gave him super human abilities. The devil fruit is the IAM identity-based policy. Ability to stretch any part of his body is the IAM permission. However, Luffy was captured and was handcuffed. You might say, “well he could just stretch and make his hands and arms small and wiggle out of the handcuffs, right?”. Not so fast, the handcuffs are made from seastone. It nullifies the devil fruit users powers or abilities. The seastone is the permissions boundary. The policy in this permissions boundary is Deny all.
Still confused or got even more confused? Probably not the best analogy but read on. We’ll make it easier to understand with a demo and some common examples.
When should you use a Permissions Boundary
The perfect use case for a permissions boundary is setting up a Restricted Administrator.
Say you are the Administrator in your organization. And you wanted to delegate a part of your tasks. Say this task is just for creating users and roles that your developers can use. (I know, this should be automated, but bear with me for the purposes of this post.) Now you give this Restricted Admin full permissions to create users, roles, and policies. All is well, the restricted admin is doing their job and you are able to just sit back and chill. Life is good! But then one morning the restricted admin got and gave a full Admin permission to a developer. He can do this because, remember, you gave him full permissions to create IAM users, roles and policies. It so happened that the policy he created for the developer had full Admin permissions. Not cool, right?
This is a perfect example where a permissions boundary should be used to avoid over-provisioning IAM permissions.
How do I configure a Permissions Boundary
To set it up, let’s do a demo using the above example use case. I am the organization Admin. So first I create a restricted admin role.
In Console:
I give this role full Administrator permissions. Now I assume this role and try to create a user.
Notice from the upper right corner that I am using the RestrictedIAMAdmin role. I give the new user DeveloperJoe full admin permissions. This is not a good idea and should not be allowed. But in this case I was able to do it. We’ll add a permissions boundary next to fix this.
I will return as Org Admin and add a permissions boundary to the RestrictedIAMAdmin role. I attach this policy as the permissions boundary. To break down the policy, first I give it permission to create users and roles and pretty much all write access to policies. But there is a condition. It can only do these actions if it also attaches a permissions boundary. This is the Developers permissions boundary, not to be confused with the RestrictedIAMAdmin role’s permissions boundary. Simply put, if I was the restricted admin and I create a user and I give that user full admin permissions, I would not be able to do so, unless I attach the boundary specifically named DevelopersPermissionsBoundary to the said user.
With the permissions boundary attached, I try to create a user again with full admin permissions. This time it fails. Remember, I can only create a user if I add the Developers permissions boundary to the user. So I go back 2 pages and add the Developers permissions boundary. This time, user creation is successful. You can change the DevelopersPermissionsBoundary policy to suit the required permissions for your developers.
So as the Org admin, I don’t have to worry about the restricted IAM admin making a mistake and granting excessive permissions for the developers. I have made it so that he/she has absolutely no chance of making a mistake in the first place.
The example demonstrates the create user action. But it’s the same for create role, create/update/delete policy, and attach/detach policy to user/role. Below images show the error when trying to detach or change a permissions boundary on an existing user.
Wrap Up
In this post, we learned about the power of permissions boundary. How it can help you avoid crucial misconfigurations. It helps you enforce the least privilege principle in your Organization’s identity and access management.
Go ahead and try it out for yourself. I encourage you to use permissions boundary as often as you can. For those who have used permissions boundary before, I’m interested to learn about your use cases. Hit me up on the comments section.