Find Us

Bound Those Permissions

Insight

News

Bound Those Permissions
December 3, 2020

Below is a blog post from our VP of Intelligence, Gabriel Alix, as he discusses his experience using AWS’s IAM Permission Boundaries.

When it comes to AWS and account permissions, there is an uneasy moment when your organization attempts to give you all the access 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 an odd enterprise group and role creation procedures that would make waterboarding somewhat more exciting. To help with this, AWS released IAM Permission Boundaries (PM) – with the sole purpose to help delegate account access and policy creation, all 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.

To further explain, let’s look at this hypothetical scenario: you’re an enterprise and you want to give your DevOps team full access to work their magic across accounts, but you 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 the 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 – 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 that promulgate the corporate access policy and explicitly deny other IAM permissions. The big take away is that 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.

  1. I have to match the permission I’m allowing from the given user policy; in this case, full admin access is being granted.
  2. 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.
  3. 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, this is continuously enforcing my corporate policy as the DevOps team can work without delays.

This is a good start to 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.

To learn more about our AWS expertise:

Visit our AWS Partner Page

contact@applied-insight.com

Related News