A guide to AWS IAM – Identity and Access Management
When you first create an AWS account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user and this is accessed by signing in with the email address and password that you used to create the account. It is strongly recommended that you do not use the root user for your everyday tasks, even the administrative ones. Instead, it is a better practice to use the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks.
What is an IAM?
AWS IAM ( Identity and Access Management ) is a service that helps you securely control access to AWS resources. You can use IAM to control who is authenticated (signed in) and authorized (has permissions) to use resources.
IAM Facts
- IAM is free to use. It comes under free-tier service.
- IAM is a global service, which means it covers all regions within an account.
IAM as a service is accountable for 2 processes:
Authentication — are you the one who you claim to be?
- Authorization — are you actually allowed to do what you want to do?
- Shared access to your AWS account: You can grant other people permission to administer and use certain resources in your AWS account without having to share your password or access key.
- IAM is integrated with many other AWS services.
- Identity information for assurance : If you use AWS, you receive log records of the events that include information about those who made requests for resources in your account. That is based on IAM identities.
- Allow the users who already have passwords but elsewhere to get temporary access to your AWS account.
Methods to access AWS services through IAM
Users
Create IAM users if you want to grant other users access to your AWS account without sharing your login credentials. It is a better practice than to give root access directly.
Groups
Groups make it easy to manage access for multiple users with similar attributes.You could e.g. create a “S3accessDemoGroup” group with permissions to create S3 buckets and objects and add multiple users to this group. This way the users in this group can create S3 buckets and objects . If you change the permissions in this group affects all users who belong to that group. So what is permission and how can it be set up? To know that, you need to understand what policies are.
Policies
With policies you can define permissions for users, groups and roles. Policies are the building blocks to define what action can be performed for what resource.
Let’s take an example of a simple policy:
Example policy 1
{
“Version”: “2012-10-17”,
“Sid”: “AllowCreateBuckets”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: “s3:CreateBucket“,
“Resource”: “*”
}
]
}
Example policy 2
{
“Version”: “2012-10-17”,
“Sid”: “AllowS3services”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: “s3:*“,
“Resource”: “*”
}
]
}
The policies are defined with the help of the JSON syntax.
With Action you tell what kind of actions are allowed (in this case Create S3 bucket). Resources defines what resource this action affects (Here it’s the S3 bucket name can be anything because of ‘*’, it follows the regex rule. You can specify the resources too line this : “arn:aws:s3:::example_bucket”) Effect can either be “Allow” or “Deny”. You can also add more than one actions in lists. Make sure what are the actions available. In Example 2 you can see that I have mentioned ‘*’ in action for S3. That means that any action under S3 is allowed is for the user or the groups.
You can understand the above policy example 1 like this : “Allow to create a S3 bucket with the name you want”. If you attach this policy to a user, this user will be allowed to perform the mentioned action. If you attach it to a group all users in that group can perform this action. For example 2, you can read it like this: “Allow to create any action under S3 and you can name the resource as you like”.
Roles
Roles are similar to users as they hold an AWS identity with permissions. Roles are often used if you want to grant access to AWS resources that the users normally don’t have.
Another scenario would be that you want to grant an access to your AWS resources without exposing your AWS security credentials.
Once the IAM Role is assumed by an allowed entity, AWS Security Token Service (STS) provides the temporary security credentials to the entity. The temporary security credentials contain the following information.
- Session Token
- Access Key ID
- Secret Access Key
- Expiration
When an IAM user from a different AWS Account assumes an IAM role of another account (E.g. Using the Switch Account feature in AWS Console or using the API) the temporary credentials from STS will replace their existing credentials of the trusted account — The account they are from.
Identity providers
Identity providers enables you to let the users gain access to your AWS resources with the help of an external identity provider (IdP). You may have used an external identity providers in the past if you’ve used your GitHub,Facebook or any other external account to sign in to another website.
What next?
Now that’s it for this part. The IAM features are covered briefly in this part. I hope you are clear about IAM identities now. There is a lot to cover in this series. Like really a lot! In the next part, I am going to cover more about IAM and how to access AWS features in different ways.
