When it comes to AWS and account permissions, there is an uneasy moment when you and your organization attempt to give you all the accesses needed to excel in the Cloud but not enough to give away the keys to the kingdom (or to BitCoin farmers). Over the years, this tug of war has led to a very odd Enterprise group and role creation procedures that would make waterboarding somewhat more exciting. To that end, AWS released IAM Permission Boundaries (PM), with the sole purpose to help delegate account accesses and policy creation while enabling organizational control
IAM Permission Boundaries say this is the MAXIMUM level of permissions you will ever be able to use. No matter what your IAM policy states – the Permission Boundary will override it such that it will grant the permission that matches both your IAM policy and Permission Boundary. PM also gives you the ability to apply additional allows or denies based on your needs.
An easier way to understand this is via a scenario. Say you’re an enterprise and you want to give your DevOps team full access to work their magic across accounts but don’t want them to be able to create users or policies that don’t conform to corporate requirements. To show PM’s utility and for demo purposes, I’m going to give DevOps group full admin access via the following policy:
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “AllowAll”,
“Effect”: “Allow”,
“Action”: “*”,
“Resource”: “*”
}
]
}
I know, you see “Action”: ”*”, and I can picture your shocked faces; hearing you dialing the number to the local asylum. I get it this has been a faux pas for years. But with the following Permission Boundaries, I can configure the DevOps group such that they can only create accounts the promulgate the corporate access policy and explicitly deny other IAM permissions. The big take away is you can effectively control access in a way that was not possible before Permission Boundaries was released.
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “AllowAll”,
“Effect”: “Allow”,
“Action”: “*”,
“Resource”: “*”
},
{
“Sid”: “BasePermissionBoundary”,
“Effect”: “Deny”,
“Action”: [
“iam:UpdateAssumeRolePolicy”,
“iam:DeleteAccountPasswordPolicy”,
“iam:DeleteUserPolicy”,
“iam:DeletePolicy”,
“iam:AttachRolePolicy”,
“iam:DeleteUserPermissionsBoundary”,
“iam:PutRolePolicy”,
“iam:DeleteRolePermissionsBoundary”,
“iam:CreatePolicy”,
“iam:DetachRolePolicy”,
“iam:AttachGroupPolicy”,
“iam:DeleteRolePolicy”,
“iam:PutUserPolicy”,
“iam:DetachGroupPolicy”,
“iam:CreatePolicyVersion”,
“iam:DeleteGroupPolicy”,
“iam:DeletePolicyVersion”,
“iam:PutGroupPolicy”,
“iam:SetDefaultPolicyVersion”,
“iam:CreateUser”
],
“Resource”: “*”
},
{
“Sid”: “AllowCreationWithPermBound”,
“Effect”: “Allow”,
“Action”: [
“iam:PutUserPermissionsBoundary”,
“iam:DeleteUserPolicy”,
“iam:AttachUserPolicy”,
“iam:DetachUserPolicy”
],
“Resource”: “*”,
“Condition”: {
“StringEquals”: {
“iam:PermissionsBoundary”: “arn:aws:iam::*:policy/BasePermissionBoundary”
}
}
}
]
}
Let’s walk through this permission boundary, as it is doing several things.
- First I have to match the permission I am allowing from the given user policy; in this case, full admin access is being granted.
- In BasePermissionBoundary, I actively deny the whole suite of IAM permission management actions. Any user with this permission boundary will never be able to run those commands.
- Via AllowCreationWithPermBound, I effectively allow the DevOps team to create a user, but only if they also have the BasePermissionBoundary added as a permission boundary. Effectively continously enforcing my corporate policy as the DevOps team can work away without delays.
This is a good start, helping you fundamentally understand IAM Permission Boundaries. As an exercise, go ahead and extend this Permission Boundary to allow the DevOps team to create Roles, but then force those roles to also comply with a Permission Boundary of your choice.
By Gabriel Alix