What Is IAM:
AWS IAM stands for Identity and Access Management, it's a service used for securely control or limit the access to the AWS resources.
Why We Need IAM:
When we create a new AWS account the only user we have is the Root user which can perform any operations in the AWS there is no limit to root user i.e the root user has full access to all the AWS resources. As root user has full access to the AWS resources it can lead to some big problems like if somehow root user credentials are compromised then it may lead to huge billings which you can not imagine because the person who got user root access can spin up more machines, can destroy existing resources and what not, he can do anything he wants with the help of root user access. So it's always recommended to create a user with some specific access to the AWS resources and how we can achieve this is by using the IAM service.
IAM:
We understood that we use IAM service to create the users, now suppose we are working in an organization having many teams so there will be more users with different set of permissions, so we can achieve this in AWS using IAM service by creating different groups and then we can add the different users to different teams. Now the permission part comes, how we can grant the permissions to the users or the groups? In AWS we can define the policies to control the access to the resources and can assign those policies to the user or the groups, In IAM we call the users and groups as an IAM identities. So we can assign the policies to the IAM identies as well as to the AWS resources. There is one more IAM identity i.e Role, Role is very similar to the user but is used by resources on AWS to perform certain actions.
Policies And Permissions In IAM:
Policy in an object in AWS once its attached to the IAM identities or resources it defines their permissions, usually policies are defined with the help of JSON object.
Policy Structure:
{
"Statement":[{
"Effect":"effect",
"Action":"action",
"Resource":"arn",
"Condition":{
"condition":{
"key":"value"
}
}
}
]
}
An IAM policy consists of one or more statements, the statement is nothing but the permissions.
Effect: There are two possible values for effect i.e ALLOW & DENY which comes into the picture once AWS evaluates the mentioned policy.
Action: It defines the set of actions that can be performed on the resources mentioned in the 'Resource' key-value pair.
Resource: It specifies the resources on which the actions can be performed.
Condition: We can define the conditions in this section, once matched the respective actions will be performed on the resources depending upon the respective effect value.
Apart from above JSON keys we also have two more keys i.e Principal & Sid which are optional.
Principal: Principal is the WHO i.e IAM identity i.e (users, groups, role) and resource, usually we assign the policies to IAM identity so in that case the principal key is optional as AWS internally inferred the mentioned policies are for the IAM indentity in other words we can say that the policies are by default for the IAM identities. But if we want to specify the policies for AWS resource then we need to explicitly needs to define the Principal value to the respective AWS resource, there are only few AWS resources to which we can assign the policies.
Sid: Sid is nothing but the statement id.
A simple analogy to understand the IAM policy is:
Suneet's mom allow Suneet to play GTA-V on PS4 only if he completes his homework, this can be transformed in IAM policy as below:
{
"Statement":[{
"Principal": "Suneet",
"Effect":"ALLOW",
"Action":"PLAY GTA-V",
"Resource":"PS4",
"Condition":{
"condition":{
"OnComplete":"Homework"
}
}
}
]
}
IAM Policy Types:
There are mainly two types of IAM policies i.e Identity based policies & Resource based policies.
Identity Based Policies:
Identity based policies are applied to the IAM identities i.e users, groups or roles., these policies are further divided in two types i.e Managed policies & Inline policies.
Managed Policies:
AWS Managed Policies: These policies are created and managed by the AWS, user is not responsible for managing these policies, so if we are using the AWS managed policies then suppose in future if they did any enhancement to the policy those enhancements will be automatically updated by AWS wherever we are using that policy.
Customer Managed Policies: These policies are created and managed by customer so we have more control on these type of policies, but likewise if we made any changes to an existing policy we need to make those changes wherever we have used that policy.
Inline Policies:
Inline policies are directly attached to the IAM identities i.e it has one to one relationship between policy and IAM Identity. these policies will be deleted once we delete the IAM identity.
Note: The managed policies are reusable but the inline policies are not.
Resource Based Policies:
We can attach inline policies to the resources, the most common examples of resource based policy is Amezon S3 bucket policies and IAM role trust policies. Role based policies grant permissions to the principals mentioned for that policy, Principal can be in the same account as of resource or in other account.