Simplifying AWS IAM — Part 2 (Policies and Permissions)

Now that we understand the basic concepts and working of AWS IAM (Part 1 of this series), let us understand policies and permissions in IAM, a vital part of access management or authorisation.

For access management in AWS, we create policies and attach them to IAM identities (users/ groups/ roles) or AWS resources. When you associate or attach a policy to an identity or resource, it defines their permissions. Permissions in the policies determine whether the request made by the IAM principal (user or role) is allowed or denied.

Most policies are stored in AWS as JSON documents.

Types of policies:

A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. When you create a permissions policy to restrict access to a resource, you can choose an identity-based policy or a resource-based policy or both.

• Identity-based policies: Identity-based policies are attached to an IAM user, group, or role (identities). These policies control what actions an identity can perform, on which resources, and under what conditions. These policies are used to provide your users with permissions to access the AWS resources in their own account. Most users have multiple policies that together represent the permissions for that user.
• Resource-based policies : Resource-based policies are attached to a resource such as an Amazon S3 bucket. These policies control what actions a specified principal can perform on that resource and under what conditions.

Not all AWS services support resource-based policies. For a list of services that support resource-based policies, see AWS services that work with IAM. In this post, I have used S3 bucket to illustrate resources in all diagrams. This is mainly because S3 supports resource-based policies.

Identity-based policies are of 2 types, managed policies and inline policies:

• Managed policies: Standalone policies (Standalone policy means that the policy has its own Amazon Resource Name (ARN) that includes the policy name) that you can attach to multiple users, groups, and roles in your AWS account. Managed policies can be either: AWS managed policies, example Administrator access (full access to all resources), Power user access (Admin access except AWS IAM and AWS Organizations.), etc, or Customer managed policies which you create and manage in your AWS account. Customer managed policies provide more precise control over your policies than AWS managed policies.

— Permission Boundaries: You can use an AWS managed policy or a customer managed policy to set the boundary for an IAM entity (user or role). A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity’s permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.

Identity-based policies grant permission to the entity, and permissions boundaries limit those permissions. The effective permissions are the intersection of both policy types. An explicit deny in either of these policies overrides the allow.

• Inline policies: Policies that are embedded in an IAM identity (a user, group, or role). The policy is an inherent part of the identity. Inline policies maintain a strict one-to-one relationship between a policy and an identity. They are deleted when you delete the identity.

To read more about Managed policies and Inline policies and when to use when, read this.

Resource-based policies are inline policies, and there are no managed resource-based policies.

• Access control lists (ACLs): Another type of IAM policy, ACLs are similar to resource-based policies, although they are the only policy type that does not use the JSON policy document format. You can use ACLs to grant basic read/write permissions to other AWS accounts. ACLs cannot be used to control access for a principal within the same account. Amazon S3, AWS WAF, and Amazon VPC are examples of services that support ACLs. You cannot grant conditional permissions, nor can you explicitly deny permissions. Read this to learn more about ACL’s.

Example use case: If a bucket owner allows other AWS accounts to upload objects, permissions to these objects can only be managed using object ACL by the AWS account that owns the object.

Policy evaluation logic

For a request to which only permissions policies apply, identity-based policies and resource-based policies (both permissions policies) are evaluated together.

Request within a single AWS account

When the request is made within a single AWS account, AWS first checks all policies for a Deny. If a Deny exists in any of the policies, then the request is denied. Then AWS checks for each Allow. If at least one policy statement allows the action in the request, the request is allowed. It doesn’t matter whether the Allow is in the identity-based policy or the resource-based policy.

Request made from one AWS account to another

For requests made from one account to another, the requester in Account A must have an identity-based policy that allows them to make a request to the resource in Account B. Also, the resource in Account B must have a resource-based policy that allows access to the requester in Account A. There must be policies in both accounts that allow the operation, otherwise the request fails.

To enable cross-account access, you can specify an entire account or IAM entities in another account as the principal in a resource-based policy.

Permissions boundaries reduce permissions that are granted to an entity by identity-based policies, and then resource-based policies provide additional permissions to the entity. In this case, the effective permissions are everything that is allowed by the resource-based policy and the intersection of the permissions boundary and the identity-based policy. An explicit deny in any of these policies overrides the allow.

Explicit and implicit allow/deny: What does that mean?

By default, any IAM user, role, or federated user is denied access. So, they must be explicitly allowed to perform an action. Otherwise, they are implicitly denied access. An implicit denial occurs when there is no applicable Deny statement but also no applicable Allow statement.

Policy evaluation always starts with checking for Deny statements in any of the policies. Final decision results in an explicit deny if any applicable policy includes a Deny statement. This means, if various policies that apply to a request include an Allow statement and a Deny statement, the Deny trumps the Allow. The request is explicitly denied.

When you design your authorization strategy, you must create policies with Allow statements to allow your principals to successfully make requests. You can choose any combination of explicit and implicit denies.

Conclusion

In this blog, we discussed about the IAM Policies and permissions and their evaluation logic. If this seemed like an arduous task, let me tell you that this is not the complete picture yet. There are a couple more policies that AWS IAM looks at before giving the final allow/deny. For now, let’s chew upon what we have learnt so far and leave the rest on the next post, part 3 of our AWS IAM series.