AWS Identity and Access Management (IAM) Basics

Read my next post about Understanding AWS IAM Identity Center: The Modern Approach to Cloud Access Management

---

For anyone venturing into the world of Amazon Web Services (AWS), understanding Identity and Access Management (IAM) is not just important, it's fundamental.

This article will delve into the core concepts of AWS IAM, explaining how it empowers you to securely control who can access your AWS resources and what actions they can perform.

We'll cover the four main pillars of IAM:

• Users
• Groups
• Roles, and
• Policies

and discuss the best practices for managing access in your AWS environment.

The Problem: Uncontrolled Access and the Need for IAM

Many new AWS users encounter a common challenge:

• After setting up an AWS account and deploying resources as the root user, they find that other individuals or applications cannot access these resources.
• This immediately highlights the critical need for a robust access management system.
• The root user, while having full administrative privileges, is not intended for day-to-day operations due to the inherent security risks associated with such broad permissions. This is where AWS Identity and Access Management (IAM) comes into play.

IAM is a web service that helps you securely control access to AWS resources.

It allows you to manage:

• who is authenticated (signed in) and
• authorized (has permissions) to use resources.

Without proper IAM configuration, your AWS environment is vulnerable to unauthorized access, data breaches, and operational disruptions. IAM provides the granular control necessary to ensure that only the right entities can perform the right actions on the right resources, under the right conditions.

Core Concepts of AWS IAM

Users and Groups

AWS IAM is built upon several core concepts that work together to define and manage access. Let's start with Users and Groups.

IAM Users

An IAM User represents a

• Person or
• An Application that interacts with AWS.

When you create an IAM user , you are essentially creating an identity within your AWS account that can be used

• To log in to the AWS Management Console,
• Make programmatic calls to AWS services, or
• interact with resources via the AWS Command Line Interface (CLI) or SDKs.

It's crucial to understand that an IAM user is distinct from your AWS account root user. The root user has unrestricted access to all resources in the account and should only be used for initial setup and highly sensitive tasks.

For example, if you have a team of developers, each developer should have their own IAM user. This allows for individual accountability and enables you to grant specific permissions to each developer based on their responsibilities. Best practice dictates that you should never share IAM user credentials.

IAM Groups

An IAM Group is a collection of IAM users.

• Groups are a convenient way to manage permissions for multiple users simultaneously.
• Instead of attaching policies (which define permissions) to individual users, you can attach policies to a group.
• All users within that group automatically inherit the permissions defined by the policies attached to the group.

Consider a scenario where you have a ' Developers' group and a ' Testers' group. You can attach a policy that grants access to development resources to the 'Developers' group, and a different policy that grants access to testing resources to the 'Testers' group. When a new developer joins your team, you simply add their IAM user to the 'Developers' group, and they instantly gain all the necessary permissions. This simplifies administration and ensures consistency in permission management.

Roles and Policies

Beyond users and groups, Roles and Policies are fundamental to defining and managing permissions within AWS IAM.

IAM Roles

An IAM Role is an IAM identity that you can create in your account that has specific permissions.

• It is similar to an IAM user in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS.
• However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone or anything that needs it.
• This could be an IAM user in the same account, an IAM user in a different AWS account, an AWS service (like an EC2 instance or Lambda function), or even an external identity provider.

Roles are particularly useful for granting temporary access to AWS resources without sharing long-term credentials. For instance, you can create a role that allows an EC2 instance to access an S3 bucket. The EC2 instance assumes this role, and AWS automatically provides it with temporary credentials, which are rotated regularly. This is a much more secure approach than embedding AWS access keys directly into your application code or configuration files.

Another common use case for roles is cross-account access. If you have multiple AWS accounts (e.g., development, staging, production), you can define a role in one account that allows users or services from another account to temporarily assume that role and access resources. This facilitates secure collaboration and resource sharing across your AWS organization.

IAM Policies

IAM Policies are the documents that define permissions. They are JSON documents that explicitly state what actions are allowed or denied on which AWS resources, and under what conditions. Policies are the heart of IAM, as they dictate the precise level of access granted to users, groups, or roles.

An IAM policy consists of one or more statements. Each statement includes:

• Effect: Whether the statement allows (Allow) or denies (Deny) access.
• Action: The specific AWS API actions that are allowed or denied (e.g., s3:GetObject, ec2:RunInstances).
• Resource: The AWS resources to which the action applies (e.g., a specific S3 bucket, all EC2 instances).
• Principal (for trust policies): The entity that is allowed to assume a role.
• Condition (optional): Additional criteria that must be met for the policy to take effect (e.g., access only from a specific IP address, during certain hours).

Policies can be managed (AWS managed policies or customer managed policies) or inline policies. AWS managed policies are predefined policies created and managed by AWS, offering common use cases. Customer managed policies are policies that you create and manage, providing more granular control. Inline policies are embedded directly within a user, group, or role.

By attaching policies to users, groups, or roles, you grant them the necessary permissions to interact with AWS services. It's a best practice to apply the principle of least privilege, meaning you should grant only the permissions required to perform a specific task, and no more.

Best Practices for AWS IAM

To effectively manage access and maintain a strong security posture in AWS, consider these best practices:

Principle of Least Privilege

Grant only the permissions required to perform a specific task. Avoid granting overly broad permissions.

Example

Definition: Grant only the permissions necessary for a user, role, or service to perform its job — nothing more.

Instead of giving a developer full S3 access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-app-bucket/*"
    }
  ]
}

This allows the developer to upload/download objects but not delete the bucket or change permissions. Avoid using "Action": "s3:*" which grants excessive access.

Use IAM Groups

Organize users into groups and attach policies to groups rather than individual users for easier management.

Example

Definition: Group users by role (e.g., Developers, Admins) and assign permissions at the group level for easy management.

• Create a group called Developers.
• Attach the AmazonEC2ReadOnlyAccess policy to it.
• Add all developers to this group.

Now all developers can view EC2 instances but not modify them — and you manage permissions at the group level, not per user.

Utilize IAM Roles

Use roles for granting temporary access to AWS services, applications, or for cross-account access. Never embed AWS credentials directly into applications.

Example

Definition: Use IAM roles for temporary access or cross-account access instead of long-term credentials.

1 (Application Role):

• An EC2 instance running a web app needs to read from S3.
• Attach an IAM Role to the EC2 instance with the following policy:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-app-data/*"
}

The app now accesses S3 securely via the instance’s role - no need to hardcode access keys.

2 (Cross-Account Role):

• Account A allows Account B to assume a role:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::123456789012:root" },
  "Action": "sts:AssumeRole"
}

Developers from Account B can temporarily assume this role to manage resources in Account A.

Example Use Case

You have two AWS accounts:

• Account A (DevOps Tools Account): where you run CI/CD tools like Jenkins, CodePipeline, etc.
• Account B (Production Account): where your production applications and CloudWatch logs reside.

Your CI/CD pipelines in Account A need to:

• Deploy applications to EC2 or ECS in Account B (PROD).
• Fetch CloudWatch logs or metrics from Account B for post-deployment validation.

Solution: Cross-Account IAM Role

Enable MFA

Implement Multi-Factor Authentication (MFA) for all IAM users, especially for privileged accounts, to add an extra layer of security.

Example

Definition: Add an extra layer of security for IAM users, especially admins.

• Enable MFA for [e-mail].
• Configure a virtual MFA device (e.g., Authenticator App).
• When signing in, the admin must provide:
  • Password
  • 6-digit code from their authenticator app

Protects against unauthorized access even if the password is compromised.

Regularly Review Permissions

Periodically review your IAM policies and permissions to ensure they are still necessary and adhere to the principle of least privilege.

Example

Definition: Periodically check IAM users, groups, and policies for unnecessary or excessive permissions.

Example Process:

• Use IAM Access Analyzer or AWS Trusted Advisor to identify unused permissions.
• Example: You find a user has s3:DeleteBucket permission but never uses it.
• Remove that permission from their policy.

Keeps your environment aligned with the least privilege principle.

Monitor IAM Activity

Use AWS CloudTrail to log and monitor all API calls and related events in your AWS account, providing an audit trail for security analysis.

Example

Definition: Track all IAM and API activities for security auditing.

Example:

• Enable AWS CloudTrail for all regions.
• CloudTrail logs events like:
  • CreateUser
  • DeleteAccessKey
  • AttachUserPolicy
• Store logs in an S3 bucket with restricted access.
• Use Amazon CloudWatch to alert on suspicious activities (e.g., root login attempts).

Ensures traceability and helps investigate security incidents.

Avoid Using Root User Credentials

Never use your AWS account root user credentials for daily tasks. Always create and use IAM users with appropriate permissions.

Example

Definition: The root account has unrestricted access - use it only for initial setup or critical operations.

• Use root only to:
  • Create your first IAM admin user.
  • Enable MFA on the root account.
  • Configure billing or account settings.

Then:

• Create an IAM user named AdminUser.
• Attach AdministratorAccess policy.
• Use AdminUser for all day-to-day management.

Root credentials should be locked away securely and never used for routine work

Conclusion

AWS IAM is a powerful and essential service for securing your AWS environment. By understanding and effectively utilizing IAM Users, Groups, Roles, and Policies, you can implement robust access controls, adhere to security best practices, and ensure that your AWS resources are protected. Proper IAM configuration is not just about security; it's about enabling your teams and applications to interact with AWS safely and efficiently, paving the way for scalable and secure cloud operations.

Sign up for Rajendra Khope

Thoughts, stories and ideas.
https://rajendrakhope.com/
No spam. Unsubscribe anytime.