Understanding AWS Identity and Access Management (IAM)
Once we create an account, we see one default user account created, named root user. The root user has complete access to all AWS services and resources in the account. We can access the root user using the email and password provided at the time of the account's creation.
What we can achieve using IAM
provide access to the user
restricts or fine-grain access to users to access AWS resources
enable an extra level of security using MFA (Multi-Factor Authentication)
create and manage the access keys for the account or any AWS resources
provide programmatic user creation that can only access aws using CLI
group the users and give permissions to all those users
enable single sign-on using external providers like Okta, Google Workspace, Microsoft Extra ID, etc
provide temporary access or role to any user or AWS service without creating access keys
Let's see how to achieve it ...
Create a user
The user creation process goes through 3 steps.
In the first step, acquire details like
User Name: The name of the user for whom access is configured.
Access Type: Determine if the user requires access to the AWS Management Console (user interface) or only CLI (Command Line Interface) access.
Password Settings:
Auto-generate a password: Automatically create a secure password.
Set a custom password: Allow for a manually specified password.
Enforce password reset: Require the user to reset their password upon their first login.
In the second step, we need to select permission options
Add a user to the group: We can add a user to the existing group or create a new group and then attach that group to the user.
Copy permissions: We can copy permission from the existing user to the new user.
Attach policies directly: We can attach existing AWS managed or previously created custom policies. We can see what the policy is shortly.
In the third step, we can review choices. After user creation, we can view and download the autogenerated password, if enabled.
User Groups
An IAM user group is a collection of IAM users who need the same permissions. We can create a group and attach the permissions to that group. After that, any user added to that group can inherit the permission policy assigned to that group.
Create Role
If we look closely, we can see that the IAM user and role look similar, but the major difference is the duration for which we planned to use the user or role. A role does not have standard long-term credentials such as passwords or access keys. Instead, when you assume a role, it provides temporary security credentials for your role session. Unlike IAM users, which are tied to specific people or services, roles can be assumed by any entity that needs temporary access—whether it's an AWS service, a user, or a third-party application.
While creating a role, we can see options like AWS service, AWS account, etc. Let's look at some of them.
AWS Service:
This option is used for AWS services like EC2, Lambda, or RDS to perform tasks on your behalf. For example, you can create a role that allows an EC2 instance to read from an S3 bucket. After assigning this role to the EC2 instance, it can access the S3 bucket without the IAM user's hardcoded credentials.
AWS Account:
If you have multiple AWS accounts (e.g., separate accounts for development, staging, and production), you can create a role in one account and allow another account to assume it. This is especially useful for granting access to resources across accounts while maintaining strong security boundaries. We can create a role with the same account too.
Once we create a role, we will get the new console url under "Link to switch roles in console". Redirecting to this URL switches your current user login to a role-based login. Once switched, we can do only activities that are permissible in the role. This is a nice way to give temporary access.
Create Policies
A policy in AWS is an object that defines permissions for identities or resources. In simple words, it determines whether a user has access to specific resources and what actions they can perform. For example, AWS provides managed policies like:
AWSCodeCommitFullAccess: Grants full permissions to perform any action related to CodeCommit, including creating and deleting repositories.
AWSCodeCommitPowerUser: Allows users to perform most actions, such as working with repositories, but doesn't permit creating or deleting them. Developers typically use this policy.
AWSCodeCommitReadOnly: Provides read-only access, allowing users to view repositories but not make any changes.
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"codecommit:GitPull",
"codecommit:GitPush",
"codecommit:CreateBranch",
"codecommit:DeleteBranch",
"codecommit:MergeBranchesByFastForward",
"codecommit:MergeBranchesBySquash",
"codecommit:MergeBranchesByThreeWay"
],
"Resource": "arn:aws:codecommit:ap-south-1:123456789012:dem0-repo"
}
This is a valid AWS Identity and Access Management (IAM) policy document. Let’s break down what this policy does:
Version
"Version": "2012-10-17"
: This specifies the version of the policy language, which is the latest as of 2012-10-17. It’s a standard field in AWS policies.Statement
The
Statement
array contains one or more permission rules.Sid (Statement ID)
"Sid": "VisualEditor0"
: This is an optional identifier for the statement. It's useful for managing and editing the policy, especially in the AWS Management Console.Effect
"Effect": "Allow"
: This field specifies that the actions listed in the policy are allowed. We can create a "Deny" rule too.Action
"Action": [...]
: This field lists the specific actions that the policy allows.Resource
"Resource": "arn:aws:codecommit:ap-south-1:123456789012:dem0-repo"
This field specifies the ARN (Amazon Resource Name). In this case, it targets a specific AWS CodeCommit repository nameddem0-repo
in theap-south-1
the region, under the AWS account with ID123456789012
. By providing resource ARN like this, we can provide access to only that resource.
In short, IAM in AWS provides a robust and flexible system for managing access to your cloud resources. You can ensure your AWS environment is secure and efficient by understanding and effectively using IAM users, groups, policies, and roles. Thanks.
Subscribe to my newsletter
Read articles from Jeevan directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by