By Sujay Maheshwari in iam —

AWS IAM Permission Boundary and Why You Shouldn't Ignore It

Have you heard of the AWS IAM Permission Boundary yet? Well, if not, you would have probably heard of access control by now. Companies need to prevent breaches and other malicious insider threats. The fundamental concept of access control is that the company decides what an employee has access to in the system network. So, who gives this access control? Well, certain trained individuals do that. But, what if these individuals who grant and revoke access are compromised in any way. Let me give you some situations.

Due to the Covid-19 pandemic, more and more businesses have moved towards remote work. Even before the pandemic, as businesses grew, they moved the additional workloads to the cloud. This meant that businesses needed to train more individuals to configure permissions without sending a ticket every time. These are the individuals I referred to earlier. There is a big problem here, though. The individuals who are given this responsibility should not be misusing this powerful feature.

This is precisely where the AWS permissions boundary feature comes into play.

What is AWS IAM Permission Boundary?

AWS IAM permission boundary helps you set the maximum permissions the “trained individuals” can grant to users and roles they create and manage. Okay, now let’s go into the details.

On 13th July 2018, AWS released a new IAM feature called IAM Permission Boundary. It does basically what I mentioned earlier. Permissions boundaries are IAM restrictions that define the maximum allowed permissions for an IAM entity available within your AWS account. It enables you to delegate work to your trusted employees to perform tasks on your behalf within a specific boundary of permissions. As an IAM administrator, you can define one or more permissions boundaries using managed policies and permit another user in your organization to create a principal with this boundary. The trusted user can then attach a permissions policy to that principal.

IAM Permission Boundaries are key for restriction to maximum possible permissions an IAM Policy can have. Only the actions are allowed to fall within the overlap of what is specified within a given IAM policy and defined within a permission boundary.

On the other hand, Permission policies provide a centralized way to configure and manage a set of permissions that only a subset of users or groups. The employee defines them.

The Mechanism of a Permission Boundary

Admins create ‘delegated admins’ such that the roles and users created by them have a permission boundary. Now, the users and roles created by these roles have permission boundaries attached to them.

Let us take an example.

Suppose you have two employees. John and Jane.

You want Jane to manage Amazon CloudWatch and EC2 operations and John to manage Amazon S3 and DynamoDB operations. So, you delegate the creation duties to Jill and Jack, respectively.

To enforce this rule, they can have a policy like the following to set the permissions boundary.

Jack will do this for John:

In this example, the policy sets the maximum permissions for John as all operations in Amazon S3 and DynamoDB; and for Jane as all CloudWatch and Amazon EC2. Both can never perform operations in any other service. John cannot do operations in CloudWatch or EC2, and Jane cannot do operations in S3 or DynamoDB.

Why is AWS IAM Permission Boundary Important?

AWS draws its strength through its flexibility, speed to build and deploy, and the ability to interact with AWS resources. That power is rooted in cloud computing basics – having the access you need, when you need it and wherever you need it. It also has IAM features. However, most of the time, the ability to create IAM permissions can result in broad, overly permissive roles. These broad permissions increase the attack surface and risk of data exposure and breaches on an otherwise well-architected application.

Organizations often choose to pursue more restrictive models in their responsibility to manage this risk. In the IAM Permission Boundary feature, you can have delegated admins who only set permissions for a specific area. This certainly enhances your security. It is a more sophisticated approach to implementing IAM.

Furthermore, you get to grant access through roles. That means only those roles with associated policies are used to define appropriate permission boundaries. The roles are scoped with minimum privileges to accomplish the task. Lastly, one of the use-cases of using permission boundaries is restricting external access of your AWS users and roles. Even when you do not have any users, all access within AWS is controlled by temporary credentials (used by services or EC2 instance profiles). Most IAM policies do not have any limitations defined.

When your AWS keys are leaked (by accident or by a bug in your application), nothing prevents your keys from being used on any other machine. Using Permission Boundaries, you create generic policies to deny external access to your AWS services and thereby preventing data and security breaches. You may read about how to respond to a data or a security breach in our article at this link.

Permission boundaries make the work of admins easier as it lets them delegate permissions to users to create new AWS service roles without elevating their permissions. The whole part of admins fielding requests for these role creations gets eliminated, promoting self-service for the users, and enhancing productivity. This is also called developer autonomy.

  • AWS IAM Audit
  • Azure IAM Audit
  • GCP IAM Audit

    • How can Cloudanix help?

    Cloudanix audits your Cloud account and lets you know if you do not satisfy any of the above steps. In addition, we have an IAM recipe that checks if your cloud account follows the best practices for IAM regularly and notifies you if you have any above misconfigurations. To explore our audit recipe, you can start by signing up for a free trial here.


    Start Your Free Trial Now!

    References