AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources for your users. It allows you to manage users, security credentials such as access keys, and permissions that control which AWS resources users and applications can access. Essentially, IAM enables you to manage "who" (authentication) can do "what" (authorization) in your AWS environment.

Core Components of IAM

1. IAM Users: Individual people or services who will interact with AWS resources. Each user will have unique security credentials and assigned permissions.

2. IAM Groups: A way to bundle IAM users and set permissions across them collectively, rather than individually. For example, you could have a 'Developers' group with permissions to access certain EC2 instances and an S3 bucket.

3. IAM Policies: These are sets of rules that define what actions are allowed or denied on which resources. These can be attached to users, groups, or roles.

4. IAM Roles: Unlike users, roles do not have long-term credentials. Roles are meant to be assumed by authorized entities (either AWS services like EC2 or Lambda, federated users, or other IAM users). Roles are useful for temporary permissions escalation and for tasks that require different permissions.

5. Identity Providers (IdP): IAM supports integration with external identity providers such as Google, Facebook, or a SAML-based IdP like Active Directory, allowing users to log in to AWS using existing credentials.

Key Features

1. Fine-Grained Permissions: IAM enables you to specify granular permissions at the level of individual API calls. For example, you can specify that a user is allowed to launch an EC2 instance but not terminate instances.

2. Multi-Factor Authentication (MFA): You can add two-factor authentication to your IAM users for extra security.

3. Organizational Scoping: With AWS Organizations, you can apply IAM policies to an entire hierarchy of accounts, allowing centralized control over permissions.

4. Temporary Credentials: With features like AssumeRole and GetSessionToken, you can grant temporary access to resources, which automatically expire after a set period.

5. Audit and Compliance: IAM is integrated with AWS CloudTrail, enabling you to log all actions taken by IAM users or roles for auditing and compliance.

6. Free to Use: There is no extra charge for using IAM. You are charged only for the use of other AWS services by your users.

7. Cross-Account Access: IAM roles can be assumed by entities in other AWS accounts, allowing for secure cross-account collaboration.

Typical Use Cases

• Administrative Access: Granting full access to AWS services for system administrators.

• Read-Only Access: Allowing certain users to view but not modify resources.

• Service-Level Access: Giving services like EC2, Lambda, or ECS permissions to access other AWS services (like S3, DynamoDB, etc.)

• Temporary Access: For example, giving a contractor limited permissions for a limited time.

• Programmatic Access: Providing keys for applications to make API requests.

By managing permissions carefully, you can improve the security posture of your entire AWS environment.

IAM Identities

The IAM identities determine "who" is being authenticated and authorized. There are three main types of IAM identities:

1. Users: These are persistent identities typically associated with human users.

2. Groups: These are collections of users, used to specify permissions for multiple users at once, making it easier to manage the permissions for those users.

3. Roles: These are temporary identities designed to be assumed by authorized entities (could be a user, an application, or a service).

Default permission for the IAM Identities

AWS IAM (Identity and Access Management) has a default "deny-all" permission model for all IAM identities. In other words, by default, IAM users, groups, and roles have no permissions. They are not allowed to perform any actions on any AWS resources unless explicit permission is granted.

Here is how the default permissions are set for different IAM identities:

IAM Users:

• No permissions: When you create a new IAM user, that user has no permissions by default. You have to explicitly attach policies to that user to grant them permissions to access AWS resources.

IAM Groups:

• No permissions: Like IAM users, IAM groups also don't have any permissions by default. Permissions can be granted by attaching one or more policies to the group. Any IAM user who is a member of that group inherits the permissions from the attached policies.

IAM Roles:

• No permissions: When you create a new IAM role, you have the opportunity to attach permissions policies to it, but you are not required to do so. If no policies are attached, the role has no permissions.

Root User:

• Full Access: This is the exception to the rule. The root user of an AWS account has full, unrestricted access to all AWS services and resources in the account. It's recommended to use the root user only to create the first IAM user and then to lock away root user access keys and password, using the root user only for necessary, high-level administrative tasks.

To give any IAM identity permissions, you attach policies to it. Policies are JSON documents that explicitly list permissions. AWS provides managed policies for common sets of permissions (like "Read-only access to S3") or you can write custom policies to meet your specific needs.

Always remember the principle of "least privilege" when assigning permissions. This means granting only the permissions necessary to perform a task. Reducing permissions to a minimum helps to maintain a secure environment.

Examples:

Users

Suppose you have a developer named Alice. You can create an IAM User called Alice, and assign her the necessary permissions to, say, read and write data to an S3 bucket, and launch EC2 instances.

Here's how you might do it through the AWS Management Console:

• Navigate to IAM dashboard

• Click on "Users" on the sidebar

• Click on "Create user" and provide the username (Alice)

  

• Attach a permissions policy that has S3 and EC2 permissions

  

Groups

Now, let's say you have multiple developers and you want to manage their permissions in a uniform way. You could create a group called Developers, and attach the necessary permissions to that group. Then you can add all developer users (like Alice) to the Developers group.

Here's how you might do it:

• Navigate to IAM dashboard

• Click on "User Groups" on the sidebar

• Click on "Create Group" and provide the name (Developers)

  

• Attach the policy with the required permissions (S3 and EC2, for example)

• Add users to this group

  

Now, any user in this group will inherit the permissions attached to the group.

Roles

Roles are a bit different. Let's say you have an EC2 instance that needs to access an S3 bucket. Instead of storing AWS Access Keys on the EC2 instance, you can assign a role to the EC2 instance with the necessary S3 permissions.

Here's how you might create a role and attach it to an EC2 instance:

• Navigate to IAM dashboard

• Click on "Roles" on the sidebar

• Click on "Create role"

• Choose the trusted entity (in this case, EC2)

  

• Attach a policy with the required S3 permissions

  

• Finally, assign this role to your EC2 instance either at launch or later.

  

Roles can also be assumed by services like AWS Lambda, or by users to elevate their permissions temporarily for specific tasks.

So, in summary, IAM identities are crucial for controlling both authentication and authorization in AWS. Users are generally long-lived and meant for interactive operations, Groups help manage users at scale, and Roles provide a secure way to delegate permissions that can be assumed by different entities.

References

1. What is IAM?

2. AWS IAM Roles – Everything You Need to Know & Examples