Advantages of AWS IAM Permission Boundaries - A tool for robust security

AWS enables engineering teams to iterate faster and deliver value to their end customers at a rapid pace. But this great speed comes with a responsibility of ensuring robust security of the cloud environment. Any gaps in the security posture can be exploited by malicious actors to harness valuable information like customer data to harm the business.

To address this, traditionally organisations have setup a central cloud team that amongst many other things also manages IAM roles and policies. Whilst this model works, it is not scalable and can hinder progress in certain cases, especially in regulated environments.

So what should you do? The obvious solution is to trust and empower your engineering teams and let them manage IAM roles and polcies. Unfortunately, for a Head of Security or Chief Information Security Officer, this might start causing nightmares over the high risk of potential compromise.

Look no further than AWS IAM Permission Boundary.

What are Permission Boundaries?

Permission Boundaries are managed policies which set the maximum permissions for an AWS IAM entity. Entities can only perform actions that are allowed in both identity-based policies and permission boundaries. This means that you can delegate trusted employees to complete tasks within the boundary you set for them. Permission boundaries are key for restricting the maximum permissions you delegate to a user. The allowed actions are only actions which fall in the overlapping area of the image below.

For example, let’s assume our employee is creating a blog and needs access to a collection of photos in one of our S3 buckets. The following policy will limit the permissions of our employee to only S3 GetObject.

{
    "Version": "2012-10-17",
    "Statement": [
        {
			"Sid": "AllowGetS3Object",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
            ],
            "Resource": "*"
        }
    ]
}

This statement alone is not enough to grant permissions while an identity-based policy is still required. Although if an AdministratorAccess policy is attached to an IAM entity with the above permission boundary, getting an S3 object is the only action which can be performed.

What are the Advantages of AWS IAM Permission Boundaries?

The Advantages of AWS IAM Permission Boundaries is that they don’t have to completely shut users out from our resources. Admins can create delegated admins which are only permitted to create users/roles with permission boundaries attached. We still can allow our users freedom while also protecting our resources.

Below is an example of how to limit IAM Roles to only create new roles with a specified permission boundary attached.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAll",
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        },
		{
            "Sid": "DenyIamWithoutBoundaries",
            "Effect": "Deny",
            "Action": [
                "iam:Attach*Policy",
                "iam:CreateRole",
                "iam:CreateUser",
                "iam:Delete*Policy",
                "iam:Detach*Policy",
                "iam:Put*PermissionsBoundary",
                "iam:Put*Policy",
                "iam:Update*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/examplePermissionBoundary"
                }
            }
        },
    ]
}

Building out the boundary further, we can use a conditional statement to limit delegated users/roles read-only access to our tagged S3 buckets while denying all other actions.

{
    "Version": "2012-10-17",
    "Statement": [
        {
			"Sid": "AllowGetS3Object",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
            ],
            "Resource": "*"
						"Condition": {
	              "ForAnyValue:StringLike": {
	                  "aws:ResourceTag/Owner": "Innablr"
	              }
	          }
        }
    ]
}

Considerations

While permission boundaries can be very useful, they do not come without risks. Careful planning, testing and communication should be at front of mind before implementing a new boundary. For example, every role will need to have the boundary attached which could mean a developer may bump their head a few times when attempting to deploy IAM Roles. This may result in some complaints and unhappy team members until everyone gets used to the new boundary in place.

Given the correct due diligence, permission boundaries are an excellent choice to tighten up your AWS security.

Lastly, Innablr has significant experience working in highly regulated environments, with a deep understanding of common industry standards. This includes APRA governed financial services, VCGLR licensed gaming, utility, and government, as well as PCI for payment card services. Innablr has successfully built easily auditable cloud platforms that reduce the burden of measurement and compliance. Additionally, we have successfully assisted enterprises' work with external auditors to prove architecture alignment, governance, security posture and process compliance.

Rourke O’Sullivan, Associate Engineer @ Innablr