Why IAM?

IAM in AWS stands for Identity & Access Management. As it suggests, it is a Service by AWS to manage Identity and Access to Resources and Services.

Now that we have understood the primary context of IAM, let us talk about the Core Elements of IAM —

IAM Elements

User

The fundamental identity of AWS is a User. You will need a user to do anything on AWS

Group

You guessed it right, a group is a collection of one or more users.

Role

The role is very similar to User but used by Resources on AWS to perform specific actions.

Policy

The policy is the document that specifically tells who can perform which action on what entities.

One key thing to understand here is — a policy says what a User/Group/Role is allowed to do, so a policy should be attached to the User/Group/Role in order to make them useful. Without a Policy, a User/Group/Role is useless.

So we start with Policy. Before diving into different types of Policies, let us understand the basic structure of an AWS Policy. An AWS Policy just defines this

Policy Structure:

{
   "Statement":[
      {
         "Effect":"effect",
         "Principal":"principal",
         "Action":"action",
         "Resource":"arn",
         "Condition":{
            "key":"value"
         }
      }
   }
 ]
}

Let’s understand Policy with this simple example —

Jeff's mom allows Jeff to eat BIRYANI at BIRYANI HOUSE RESTAURANT only if he completes his homework on time.

Here —

• Jeff is the User

• Jeff's Mom is AWS

• BIRYANI HOUSE RESTAURANT is the Resource

• BIRYANI is Action on Resource

• “Completes his Homework on time” is the Condition

• “Mom allows Jeff” is the Effect

Types of Policies in AWS

Identity-Based Policy

As the name suggests, these policies are attached to Identities(User, Group, and Role). This is sub-classified into Managed and Inline Policies

• Managed Policies — Managed Policies are simple JSON documents that define what can be and cannot be done to Resources by that Identity. These Policies can be used as many times as required. AWS Managed Policies are predefined by AWS and Customer Managed Policies should be defined by us.

• Inline Policies — Inline policies are not predefined by anyone. These policies are directly attached to an Identity and cannot be reused. Inline Policy strictly applies to the Identity it is attached to only.

Resource-Based Policies

Resource-Based Policies are also Inline Policies because they are directly attached to Resources and cannot be reused in any other place. Resource Based Policies are strictly one-to-one.

Let us see some examples of different types of Policies and understand what each section does in the policy.

Sample AWS Customer Managed Policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-example-bucket001/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "10.0.0.0/24"
                }
            }
        }
    ]
}

This Policy is written or generated by us and named Read_Only_S3 in Fig 3. As already mentioned, managed policies can be attached to many Identities. So I can just attach this Policy to a User/Group/Role. If this policy is attached to a User —

That User can Read Objects from my-example-bucket001 if his Source IP is from 10.0.0.0/24 Subnet.

• AWS Managed Policy is already created by AWS and is readily available to be attached to an Identity.
• Customer Managed Policy should be created by us for a specific use and should be attached to the appropriate Identities.
• Resource Based Policy is written whenever needed and attached only to that Resource. For example, an S3 bucket makes sure the access to the bucket is controlled.
• Inline Policy is also written in Real-time as needed and attached only to that specific identity.

If all this explanation is put in an image, it looks somewhat like this

Accessing AWS

A user can access AWS in two ways

• Management Console — web-based access using provided credentials.

• AWS CLI — command-line-based access using Access keys.

Access keys are different from Web Credentials. Access keys can be created by the user under the Security Credentials section in IAM. A unique Access Key and Secret Key will be created which can be used to access AWS resources. The Access Key created for a user will have the same permissions attached to it.

When a Resource in AWS needs to access other resources/services without user intervention, Roles can be attached to the Resources. For example, an EC2 with an S3ReadAccess Role attached can access S3 and read its contents without any User Intervention.

Key Things to remember about IAM in AWS:

1. IAM is global, it is not region specific.
2. IAM is free of cost.
3. IAM Policies can be super granular.
4. IAM supports MFA(Multi-Factor Authentication)
5. All IAM API calls via console/CLI are logged, and can be managed in Cloud Trial.

Conclusion:

As always said, this whole theory is only to open a doorway for you to go and experiment with AWS Cloud, you will start seeing things unfold once you start writing policies yourself and experimenting with them. If you don’t want to get your hands dirty by writing JSON documents yourself, you can always use this free Policy Generator tool from AWS — https://awspolicygen.s3.amazonaws.com/policygen.html. All we have to do is input a few parameters like the User to which this policy is being attached, what actions he’s allowed to perform, and on which resources.

Thank you for reading. You can connect with me on Linkedin. Happy to answer your queries.

Happy Learning :)