AWS: IAM Fundamentals
AWS IAM Super Simplified
Prerequisites:
- Good understanding of how AWS Resources and Services operate.
If you are a complete beginner, i recommend you to read this article before starting AWS-IAM —
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 as we have understood the basic context of IAM, let us talk about the Core Elements of IAM —
IAM Elements
User
Group
Role
Policy
User — The fundamental identity in 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 — Role is very similar to User but used by Resources on AWS to perform certain actions.
Policy — Policy is the actual document which 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 are allowed to do, so a policy should be attached to 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 —
WHO
WHAT
WHERE
UNDER WHICH CONDITIONS
Policy Structure:
{
"Statement":[
{
"Effect":"effect",
"Principal":"principal",
"Action":"action",
"Resource":"arn",
"Condition":{
"key":"value"
}
}
}
]
}Let’s understand Policy with this simple example —
John’s mom allows John to play GTA V on XBOX only if he completes his homework in time.
Here —
- John is the User
- John’s Mom is AWS
- XBOX is the Resource
- GTA V is Action on Resource
- “Completes his Homework in time” is the Condition
- “Mom allows John” is Effect
Types of Policies in AWS
Before we see an actual AWS Policy, let me define how these policies are different from each other.
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 which defines what can be and cannot be done to Resources by that Identity. These Policies can be used as many times as required. AWS Manged 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 as 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, Inline Policy and Resource Based Policy(for ex. S3 Bucket Policy) will also look similar as the Policy structure remains the same. The only difference is —
- AWS Managed Policy is already created by AWS and is readily available to be attached to an Identity.
- Customer Manged 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, which 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 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 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 a 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:
- IAM is global, it is not region specific.
- IAM is free of cost.
- IAM Policies can be super granular.
- IAM supports MFA(Multi Factor Authentication)
- All IAM API calls via console/cli are logged, 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 unfolded once you start writing policies yourself and experiment 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 few parameters like User to which this policy is being attached, what actions he’s allowed to perform, on which resources.
Thank you for reading. You can connect with me on Linkedin . Happy to answer your queries.
Happy Cloud Computing Folks!!
