Identity and Access Management or IAM is one of the most important services for cloud customers today. Creating and managing the identities of multiple users and resources and what unique actions each user needs to be able to perform is daunting, but it is also critical in keeping your cloud account and infrastructure secure. You wouldn’t want to build a house on a foundation full of cracks.

In this article, we will elaborate on the various ways you can limit or restrict actions performed on resources or by users, or by roles. We will also discuss some of the different components and features of AWS IAM like permission boundaries and how they can be used in combination to achieve desired authorization while still proactively restricting any unwanted actions or escalation of privilege.

AWS IAM

IAM is a service that aids to control access to resources. IAM is used to control authentication and authorization to your cloud account and resources. So simply put, who is who, and what can they do?

In most cases, IAM is the first security layer that can be implemented when it comes to securing your AWS resources and services. IAM allows us to create and manage identities. An identity can be as simple as a user that needs to interact with AWS services. An identity also can also be allowing one AWS service to interact with another AWS service.

The Who — Identities and Authentication

IAM identities typically revolves around the following components:

IAM Users: Users are entities that are created in AWS to represent a person to allow interaction with AWS. For example, a user named Bob could be created in IAM for an employee named Bob. Users can define a password (please rotate your passwords and configure MFA while your at it) to access AWS. Users also can be granted access keys to perform programmatic calls to AWS. Keep both safe and secure and never share with anyone or post on any repository.

IAM Groups: Groups are collections of IAM users. Using IAM Groups you can bundle multiple users together to share a common set of policies. Our IAM user Bob could be assigned to an IAM group for admins.

IAM Roles: A Role is an identity, much like a user, that can be created to allow interactions with AWS. The difference with a role is that it does not need to be uniquely associated with one person. A role can be used by users, applications, or services like EC2 to assume in order to perform actions on other AWS services such as S3.

By default, both newly created users, groups, and roles have no permissions attached to access resources. A policy will need to be attached in order for the identities to successfully interact with AWS services.

The What — Authorization

IAM Policy: This is where all the actions are defined. These beautiful documents are defined in the easily readable format of JSON. These JSON policies define permissions that either allow or deny certain requests made. It is best practice in AWS to ensure you only grant the required permissions to complete the task or job and nothing more. This is the golden rule known as implementing least privilege.

### IAM Policy attached to user Bob
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ListObjectsInBucket",
            "Effect": "Allow",
            "Action": ["s3:ListBucket"],
            "Resource": ["arn:aws:s3:::bobsbucket"]
        },
        {
            "Sid": "AllObjectActions",
            "Effect": "Allow",
            "Action": "s3:*Object",
            "Resource": ["arn:aws:s3:::bobsbucket/*"]
        }
    ]
}

Above is an example policy that will be attached to our user named ‘Bob’. In this policy we have two defined action statements. The first is to “Allow” our principal “Bob” to perform an “S3:ListBucket” api call to a specific bucket defined as ‘bobsbucket’. The second part “Allows” to perform any object based call (S3:Object) to the same specific S3 resource “bobsbucket” for any object. The addition of the asterisks () to a policy allows all. Try to limit the inclusion of these when creating your policies.

IAM policies come in two different flavors:

Managed Policies — These can either be AWS managed, meaning AWS creates and manages the policy. Alternatively, you can create a customer-managed policy in which you define and manage the policy, allowing for more precise control. I came across this fantastic website where one can see all AWS managed policies here.

Inline Policies — These are policies attached directly to a single identity, such as a user, role, or group. When the user or role is deleted, the inline policy is also deleted.

An IAM entity with an attached IAM policy will be able to perform only the actions defined in its policy. So, take the policy example above and we will assign it to our user Bob. Bob makes a request to list objects in his S3 bucket. Bob’s permissions will be evaluated and the request will succeed in this case due to no higher priority policy being attached either at the resource or account-level, or a permission boundary in place (these are discussed later).

How are policies evaluated?

Determining whether a request is allowed or denied within an account, for a user, a role or group involves understanding how decision making is accomplished when different types of policies are being used combination. AWS created the flowing policy evaluation flowchart that details how decisions are made depending on the combinations of policy types in play.

The Where — Resource Authorization

Resource-based Policy: Resource-based policies are unique permission policies that are attached directly to a service resource such as S3. The powerful thing about these policies is that you can specify who or what has access to that specific resource and what exact actions can be performed on it. My recommendation is if the AWS service you are leveraging allows a resource-based policy to be attached, apply one.

Using the same user Bob and policy as before we can submit the same request to S3. The code snippet below has been applied to our S3 resource. It allows our ‘principal’ user ‘Bob’ the ability to perform any action on a S3 resource named ‘bobsbucket’ and all its objects. In this case, the resource based policy will be evaluated first as it has the highest priority in this example.

### Resource-Based Policy attached to S3 bucket
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/bob"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::bobsbucket/*",
                "arn:aws:s3:::bobsbucket"
            ]
        }
    ]
}

The identity’s or in our case user “bob’s” policy will then be evaluated if no conflicts occurred in the resource policy. As in the prior example our request will be allowed due to both the resource policy allowing this action and the user policy attached to Bob.

How to limit the blast radius

When creating and managing your IAM it is important to place additional layers of security to gain the most control over an entity’s effective permissions. We want to effectively limit our identity’s capabilities to prevent any misuse of permissions or privilege escalations. Effectively building a cap to extinguish any unplanned actions from occurring.

IAM Permission boundaries: A Permission boundary is a feature for setting the maximum allowed permissions that an IAM User or IAM Role can be granted. By leveraging permissions boundaries, you can enforce only the actions that are granted by BOTH the IAM user/role and its defined permission boundary.

For example, assume that the IAM user named Bob should be allowed to interact only with Amazon S3. To enforce this rule, you can use the following policy to set the permissions boundary for the user Bob. With the policy below any action made to an outside service such as IAM or DynamoDB will be denied.

### IAM Permission Boundary Policy Example
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::bobsbucket/*",
                "arn:aws:s3:::bobsbucket"
            ]
        }
    ]
}

Service-Control Policy (SCP): These are used in tandem with AWS Organizations. It is an organizational-level policy to manage permissions. Like permission boundaries, SCPs offer control over the maximum permissions for all accounts in your organization or specific organizational unit (OU). Users and Roles must still be created and have IAM policies associated with them. So, for example, if a user or role has an IAM policy that grants access to S3 and that action is either not permitted or explicitly denied by the SCP, the user or role will not be allowed to perform that action. SCPs only affect IAM users and roles associated WITH the organization. SCPs do not affect resource-based policies directly. So, even if an S3 bucket policy allows an entity to perform some action; if both the SCP and IAM user policies do not allow that action, it will be denied.

Combining the same user Bob and policy as before, also attaching the same permission boundary as before, we can submit the same request to S3. The code snippet below has been applied to our AWS Account. It denies our account the ability to perform 2 actions on any resource. In this scenario, the SCP will first be evaluated, then the resource-based policy, third is the IAM identity Bob’s attached permissions, last for evaluation is the permission boundary. For our scenario, the request would be successful.

### AWS Organization Service Control Policy 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObject",
        "s3:PutAccountPublicAccessBlock"      ],
      "Resource": "*"
    }
  ]
}

However, lets take the same scenario and change the request. The user Bob now makes a request to delete an object from S3. Using the AWS policy evaluation flowchart the first policy to be evaluated would be our attached SCP. We have an explicit deny for objects in S3 being deleted. So Bob’s request would be rejected even though the user has permissions to perform any S3 actions and the resource grants access to our user.

Both Permission Boundaries and Service Control Policies can limit permissions but do not directly grant/provide permissions. They can be considered guardrail functionality, think of them as using “bumpers” when bowling. The bumpers create a defined channel in which the bowling ball will be allowed to go toward the pins. These IAM guardrails will prevent your trusted users from performing any erroneous actions as well as reduce the blast radius if an IAM entity compromise were to occur escalation of privilege could not proceed any further.

Conclusion

When creating users, groups, or roles be sure to always implement the practice of least privilege. This will ensure all business operations are still successful while effectively limiting our identity’s access to only what is absolutely required to do their job or task. Further, bolster resource-based security by enforcing policy at the resource level to prevent any actions on a resource from being successfully allowed unless stated. By using advanced features like permission boundaries, you can place a guardrail on the IAM identity to set the maximum permissions allowed for an IAM entity. Last is if you own more than one AWS account leverage AWS Organizations and implement service control policies to centrally manage each individual account. When SCPs are applied in conjunction with the above policy types you gain the most cloud-native control. For any request to be allowed would need to be approved by the SCP, the IAM policy, and the permission boundary. By implementing all the policy types mentioned in this article you will gain the most control.

Follow me on Medium