AWS IAM
IAM: Identity and Access Management Service
As defined by AWS, “AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. You use IAM to control who is authenticated (signed in) and authorized (has permissions) to use resources.”
So AWS IAM is one of the best web services that help to provide secured control access to all the AWS resources. You can use this IAM option in order to control both authorized and unauthorized resources easily.
To access any service of AWS every request pass through IAM to check if the requested user have the appropriate permission.
IAM Components
Users: are people within your organization, A user is also called Principle. A principle is a person or application that can make request for an action or a resource. Users have no permissions by default.
User Groups: groups are collections of users. Users can be members of up to 10 group. The main reason to use groups is to apply permissions to users using policies. The user gains the permissions applied to the group through the policy.
Roles : an IAM role is an IAM identity that that has specific permissions. Roles are assumed by users, applications, and services. Some AWS service will need to perform actions on your behalf , to do so we will assign permissions to AWS services with IAM Roles.
Also you can say,
Roles are temporary credentials that other identities (users and roles) can assume to gain access to the permissions the role has. For example, when a bucket can only be accessed by a role then if a user can assume that role he then can access the bucket indirectly.
Use case of Roles:
To give access to your account, you can use a role that can be used by identities in another account. This way you don’t need to create users and transfer secrets (passwords or access keys) to grant cross-account access.
Another use-case is users logging in via SSO. Instead of creating a user for every single person who can log in, you define a role and all users assume it. Then you can give permissions to the role and all users signed in this way will gain those permissions.
Policy : policies are documents that define permissions and are written in JSON. All permissions are implicitly denied by default.
There are two kind of Policy
Identity-based: These are JSON-based permissions policy documents that control the actions an identity can perform. So they are applied to an identity and they control the actions that that identity can perform on resources and under what specific conditions. So let’s say we have a user account, we might have a group, and then we have a role. These are all different places that you can apply an identity-based policy.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"s3:GetObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::<bucket>/text.txt"
}
]
}Now, there are a few ways that you can attach identity-based policies.
Inline policy: Inline policies have a one to one relationship with the user, the group, or the role. So you create an inline policy for a specific user, group, or role. You can’t share them. You can’t use them across other roles. For example If you delete that user, you’ll delete the policy along with it.
Managed policies: Managed policies can be either AWS managed or customer managed. As the name suggests, AWS managed are created and managed by AWS and customer managed are created and managed by you. So you can’t modify an AWS managed policy, but you can use those policies in your account. So we can attach a managed policy to multiple entities. So we can attach the policy to a user, a group, and a role at the same time if we want to. And they’re known as standalone policies for that reason, because you can attach them to multiple identities in your account.
Resource-based policy: The JSON policy documents that you can attach to a AWS resource like S3 bucket, DynamoDB table.
{
"Sid": "Stmt1667495217654",
"Action": [
"s3:CreateBucket"
],
"Effect": "Deny",
"Resource": "arn:aws:s3:::demo-s3-event-minakshee",
"Principal": {
"AWS": [
"arn:aws:iam::712680302906:user/Mukesh"
]
}
}
]
}Let say we have S3 bucket and a user Mukesh, and we want to prevent Mukesh to create bucket.
So in this case, we could apply a permissions policy to the bucket itself using a resource-based policy and in that policy, we can define the principal. So if we look at how this policy is written above, it’s a bit different to the policies that are applied to identity-based policies. In this case, you get the principal. So we have the effect “allow/Deny”, the principal, which is the ARN of the user account, and then we have the action, which is CreateBucket. So in this case user(Mukesh) will not allowed to create bucket in S3. In resource-based policy we grant the specified principal the permission to perform actions on the resource.
It’s also possible to attach a resource-based policy to an IAM role. So remember with IAM we have a trust policy and a permissions policy that we apply to the role. Now, a trust policy is also an example of a resource-based policy, whereas the permissions policy is an example of an identity-based policy for roles.
lets see few key points of IAM components.
- IAM is Global service
- Up to 5000 individual user accounts can be created.
- groups only contain users, not other groups.
- One user can be part of multiple group
- groups can’t be part of different group
- If needed User don’t have to belong to a group
As IAM is very huge topic to understand, I have divided this article into separate parts . Please click on the links below to know more about these topics.
