Easy way to understand AWS IAM permissions and policy

Easy way to understand AWS IAM permissions and policy

Identity and Access Management (IAM) is a security service that helps to manage access for AWS resources.  Authentication and authorization are important for the security of any system. This tutorial will help you to understand the AWS IAM entities and how to control permissions on AWS services/resources.

IAM Entities

Users: AWS/IAM user is a unique identity with security credentials like a password or access & secret key. User is associated with permissions to control the use of AWS resources.

Groups: A user group can contain many users. You can grant permissions to group using access control policies, Assigned permissions applicable to all users belongs to that group.

Roles: An IAM role is similar to an IAM user, Roles are used to delegating access to AWS resources and AWS Users temporarily instead of sharing credentials. A role is intended to be assumable by anyone who needs it.

When you create a role in an AWS account, you need to define two policies for granting permissions to someone to allow access to AWS resources that you control:-

• Trust Policy: To define who is allowed to assume the role (Principle: It includes users, roles, AWS accounts, and services)
• Permission policy: To define what actions and resources are allowed by the role.

Policies: A policy is a JSON document with information about permissions. IAM policies are associated with the AWS users, groups, and roles.

IAM Policy and Permissions

IAM policy let you define permissions such as:

• Who can access AWS resources.
• Which AWS resources are allowed to access.
• What actions are allowed and denied.
• When AWS resources can be accessed.

Identity-based and Resource-based permissions

By default IAM entities (users, groups, and roles) start with no permissions. You need to follow the Least privilege principle as a security best practices. Make sure you set permissions with IAM policies, and grant only the required permissions to complete a task. AWS permissions are managed by IAM Policies.

Types of IAM policies

• Identity-based policies: Identity-based policies are attached to AWS identities like user, group, or role. For example, you can attach the policy to an IAM user called “Bob” to list items from an Amazon S3 bucket named “my-example-bucket-123”. Identity-based policies can be further categorized :
  • Managed Policies: Managed policies are standalone identity-based policies that can be attached to multiple principal entities (users, groups, and roles).
    • AWS Managed – These policies are created, updated, and managed by AWS. By default, there are many pre-defined AWS managed policies available in your AWS Account that are aligned with job functions in the IT industry.
    • Customer Managed – These policies are created, updated, and managed by customers. AWS Customers can create their own policy for customized environment.
  • Inline Policies: Inline policies maintain the strict one-to-one relationship. It means inline policies directly embedded in a single principal entity (user, group, or role). Inline policies get deleted when you delete the entity that contains the policy.
• Resource-based policies: Resource-based policies are attached to the AWS resources like Amazon S3 buckets, VPC endpoints, Amazon SQS queues, AWS KMS, and Other services.

 

IAM Policy elements

A JSON policy document contains following elements :

Version – The version of the policy language (2012-10-17). As a best practice, use the latest version.

Statement – Main policy element as a container. You can add multiple statement in a policy.

Sid – It is an optional identifier for the policy to differentiate between your statements.

Effect – Grant permission (allow or deny)

Principal – Who can access it. In case of resource-based policy, you need to add a principal (account, user, role, or federated) to define allow or deny access. If you are creating an IAM permissions policy to attach to a user or role, you cannot include this element.

Action – List of actions that the policy allows or denies.

Resource – If you create an IAM permissions policy, you need to specify the list of resources to which the actions apply. In case of resource-based policy, this element is optional.

Condition – It is an optional element. You can specify the condition under which the policy grants permission.

IAM Policy Examples

Example-1: An identity-based policy to allow user to access EC2 service within a specific Region (Mumbai – ap-south-1)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "ec2:*",
            "Resource": "*",
            "Effect": "Allow",
            "Condition": {
                "StringEquals": {
                    "ec2:Region": "ap-south-1"
                }
            }
        }
    ]
}

Example-2: A resource-based policy that allows Amazon S3 to invoke a lambda function named store-url-function for a bucket named my-example-bucket-123 in account 100006009000.

{
    "Version": "2012-10-17",
    "Id": "default",
    "Statement": [
        {
            "Sid": "invoke-lambda-by-s3",
            "Effect": "Allow",
            "Principal": {
              "Service": "s3.amazonaws.com"
            },
            "Action": "lambda:InvokeFunction",
            "Resource":  "arn:aws:lambda:ap-south-1:100006009000:function:store-url-function",
            "Condition": {
              "StringEquals": {
                "AWS:SourceAccount": "100006009000"
              },
              "ArnLike": {
                "AWS:SourceArn": "arn:aws:s3:::my-example-bucket-123"
              }
            }
        }
     ]
}

Reference for more policy examples .

IAM Policy evaluation

When principal/user sends a request to access AWS resource from AWS Console, CLI, or API, AWS first authenticates and authorizes the principal that makes the request. Once the user’s request has been authenticated and authorized, AWS check for the requested actions/operations in your request and approves them if they are valid.

AWS evaluates policies depending on the types of policies that apply to the request context. Summary of AWS evaluation logic for policies within a single account:

• All requests are implicitly denied by default, except AWS account root user which has full access.
• An explicit allow in the policy overrides this default.
• If a permissions boundary, Organizations SCP, or session policy is present, it might override the allow with an implicit deny.
• An explicit denial in any policy overrides any allows.

Flow chart provides details about how the decision is made: –

Source: Flow chart from AWS