AWS IAM Policy Basics

IAM request context

In order to talk about IAM policies, you first need to cover the three main pieces of logic that define what is in the policy and how the policy actually works. These pieces make up the request context that is authenticated by IAM and authorized accordingly. You can think of the principal, action, and resource as the subject, verb, and object of a sentence, respectively.

Principal	Action	Resource
User, role, external user, or application that sent the request and the policies associated with that principal	What the principal is attempting to do	AWS resource object upon which the actions or operations are performed

Access through identity-based policies

You manage access in AWS by creating policies and attaching them to IAM identities or AWS resources. An identity-based policy is an object in AWS that, when associated with an IAM identity, defines their permissions. AWS evaluates these policies when a principal entity (IAM user or role) makes a request. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents.

There are three types of identity-based policies. Choose each flashcard below for more information.

AWS managed

AWS manages and creates these types of policies. They can be attached to multiple users, groups, and roles. If you are new to using policies, AWS recommends that you start by using AWS managed policies. 

Customer managed

These are policies that you create and manage in your AWS account. This type of policy provides more precise control than AWS managed policies and can also be attached to multiple users, groups, and roles. 

Inline

Inline policies are embedded directly into a single user, group, or role. In most cases, AWS doesn’t recommend using inline policies. This type of policy is useful if you want to maintain a strict one-to-one relationship between a policy and the principal entity that it’s applied to. For example, use this type of policy if you want to be sure that the permissions in a policy are not inadvertently assigned to a principal entity other than the one they’re intended for. 

How this

• First, IAM checks that the user (the principal) is authenticated (signed in) to perform the specified action on the specified resource. 

• Then, IAM confirms that the user is authorized (has the proper permissions) by checking all the policies attached to your user. 
• During authorization, IAM verifies that the requested actions are allowed by the policies.
• IAM also checks any policies attached to the resource that the user is trying to access. These policies are known as resource-based policies. If the identity-based policy allows a certain action but the resource-based policy does not, the result will be a deny.
• AWS authorizes the request only if each part of your request is allowed by the policies. By default, all requests are denied. An explicit allow overrides this default, and an explicit deny overrides any allows. After your request has been authenticated and authorized, AWS approves the actions in your request. Then, those actions can be performed on the related resources within your account. 

IAM allows you to add conditions to your policy statements. The Condition element is optional and lets you specify conditions for when a policy is in effect. In the condition element, you build expressions in which you use condition operators (equal, less than, etc.) to match the condition keys and values in the policy against keys and values in the request.

"Condition" : { "{condition-operator}" : { "{condition-key}" : "{condition-value}" }}

For example, the following condition can be added to an Amazon S3 bucket policy to further restrict access to the bucket. In this case, the condition includes the StringEquals operator to ensure that only requests made by JohnDoe will be allowed.

"Condition" : { "StringEquals" : { "aws:username" : "JohnDoe" }}

Here’s another example. This example uses the IpAddress condition operator and the aws:SourceIP condition key. In this scenario, the request must come from the IP range 203.0.113.0 to 203.0.113.255 in order for the desired action to be allowed.

"Condition": {"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}}

Reference for the condition from here.

Policy types

AWS supports six types of policies: identity-based policies, resource-based policies, IAM permissions boundaries, AWS Organizations service control policies (SCPs), access control lists (ACLs), and session policies. All of these polices are evaluated before a request is either allowed or denied. 

• Identity-based

Also known as IAM policies, identity-based policies are managed and inline policies attached to IAM identities (users, groups to which users belong, or roles).

Impacts IAM principal permissions

• Resource-based

These are inline policies that are attached to AWS resources. The most common examples of resource-based policies are Amazon S3 bucket policies and IAM role trust policies. Resource-based policies grant permissions to the principal that is specified in the policy; hence, the principal policy element is required. 

Grants permission to principals or accounts (same or different accounts)

The resource-based policy below is attached to an Amazon S3 bucket. According to the policy, only the IAM user carlossalzar can access this bucket.

• Permissions boundaries

A permissions boundary sets the maximum permissions that an identity-based policy can grant to an IAM entity. The entity can perform only the actions that are allowed by both its identity-based policies and its permissions boundaries. Resource-based policies that specify the user or role as the principal are not limited by the permissions boundary.

Restricts permissions for the IAM entity attached to it

For example, assume that one of your IAM users should be allowed to manage only Amazon S3, Amazon CloudWatch, and Amazon EC2. To enforce this rule, you can use the customer-managed policy enclosed in the square to set the permissions boundary for the user. Then, add the condition block below to the IAM user’s policy. The user can never perform operations in any other service, including IAM, even if it has a permissions policy that allows it.

• AWS Organizations

AWS Organizations is a service for grouping and centrally managing AWS accounts. If you enable all features in an organization, then you can apply SCPs to any or all of your accounts. SCPs specify the maximum permissions for an account, or a group of accounts, called an organizational unit (OU). 

Restricts permissions for entities in an AWS account, including AWS account root users

• ACLs

Use ACLs to control which principals in other accounts can access the resource to which the ACL is attached. ACLs are supported by Amazon S3 buckets and objects. They are similar to resource-based policies although they are the only policy type that does not use the JSON policy document structure. ACLs are cross-account permissions policies that grant permissions to the specified principal. ACLs cannot grant permissions to entities within the same account.

• Session policies

A session policy is an inline permissions policy that users pass in the session when they assume the role. The permissions for a session are the intersection of the identity-based policies for the IAM entity (user or role) used to create the session and the session policies. Permissions can also come from a resource-based policy. Session policies limit the permissions that the role or user’s identity-based policies grant to the session. 

Guardrails vs. grants

some policies are used to restrict permissions while others are used to grant access. Using a combination of different policy types not only improves your overall security posture but also minimizes your blast radius in case an incident occurs.

how the decision is made as AWS authenticates the principal that makes the request

Note

• that within an account, you need a service control policy AND an IAM policy OR a resource-based policy. Across accounts, you need a service control policy AND an IAM policy AND a resource-based policy.

• By default, all requests are implicitly denied (the AWS account root user has full access by default).

• An explicit allow in an identity-based or resource-based policy overrides the default.

• If a permissions boundary, AWS Organizations SCP, or session policy is present, it might override the allow with an implicit deny.

• An explicit deny in any policy overrides any allows.

• If the requested resource has a resource-based policy that allows the requested action, then AWS returns a final decision of allow. If there is no resource-based policy or if the policy does not include an Allow statement, then the evaluation continues.

• If there is a session policy present and it does not allow the requested action, then the request is implicitly denied.

Cheers

Osama