IAM Fundamentals

Overview

AWS Identity and Access Management (IAM) is a core service that helps you securely manage access to AWS services and resources. It provides the tools to create users, roles, and policies and assign them specific permissions to AWS resources, ensuring fine-grained control over who can access what. Below are the essential concepts you need to understand to get started with AWS IAM.

Key Concepts in AWS IAM

1. IAM Users

2. IAM Groups

3. IAM Roles

4. Policies

5. Permissions and Policy Evaluation Logic

6. Access Keys and MFA

7. Federation with External Identity Providers

8. Best Practices for IAM

1. IAM Users

• An IAM user is an entity that represents an individual who needs access to AWS resources.

• A user is created within your AWS account and has credentials (password or access keys) for interacting with AWS.

• IAM users are used when permanent credentials are required, such as for developers accessing the AWS Management Console or CLI.

Example Use Case: A DevOps engineer logs into the AWS Console with their IAM credentials to manage EC2 instances.

2. IAM Groups

• An IAM group is a collection of users that share the same permissions.

• Groups simplify administration by allowing you to assign policies to a group, which are automatically inherited by all the users in that group.

Example:

• Create a Developers group and assign it permissions to interact with EC2 and S3 services.

• Add individual users to the group, and they will inherit the group’s permissions.

3. IAM Roles

• An IAM role is an identity that can be assumed by a trusted entity for temporary access to resources.

• Roles are preferred when you don't want to store long-term credentials in your code or services.

• Roles can be assumed by users, applications, AWS services (like EC2 or Lambda), or other AWS accounts.

Example Use Case: An EC2 instance assumes a role to access an S3 bucket without storing access keys in the instance.

4. Policies

• Policies are JSON documents that define permissions. They specify who can perform what actions on which resources.

• AWS IAM supports two types of policies:

  1. Managed Policies: Predefined by AWS or reusable across users, groups, and roles.

  2. Inline Policies: Attached directly to a single user, group, or role for specific use cases.

Example Policy: This policy allows a user to read objects from an S3 bucket.

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

5. Permissions and Policy Evaluation Logic

When a request is made in AWS, IAM evaluates all attached policies to determine whether the request is allowed or denied. Here’s the key logic:

1. Explicit Deny: If any policy denies the action, the request is denied.

2. Explicit Allow: If no explicit deny exists and at least one policy allows the action, the request is allowed.

3. Implicit Deny: If there is no policy allowing the action, it is denied by default.

Example: If a policy allows access to an S3 bucket, but another policy explicitly denies it, the access is denied.

6. Access Keys and MFA (Multi-Factor Authentication)

• Access keys are used for programmatic access (e.g., AWS CLI or SDK) and consist of an Access Key ID and Secret Access Key.

• Multi-Factor Authentication (MFA) adds an extra layer of security by requiring a second authentication factor (like an OTP from an authenticator app).

Example Use Case: Developers use access keys to interact with AWS services from their local CLI and are required to authenticate with MFA to access the AWS Management Console.

7. Federation with External Identity Providers

• IAM supports federation with external identity providers (IdPs) using SAML 2.0 or OIDC protocols.

• This allows users to log in to AWS using credentials from third-party services such as Microsoft Active Directory, Google Workspace, or Okta.

Example Use Case: A company’s employees log in to AWS using their corporate credentials managed by Active Directory, without needing dedicated IAM user accounts.

8. Best Practices for IAM

1. Use Roles Instead of Users:

   • Assign roles to services and applications to avoid using long-term credentials.

2. Follow the Principle of Least Privilege:

   • Grant only the permissions required to perform specific tasks.

3. Enable MFA for Privileged Accounts:

   • Secure the root account and critical IAM users with MFA.

4. Use Groups to Assign Permissions:

   • Instead of managing permissions for individual users, use groups.

5. Rotate Access Keys Regularly:

   • Avoid keeping the same access keys indefinitely to minimize risk.

6. Monitor and Audit IAM Activity:

   • Use AWS CloudTrail to track changes in IAM permissions and detect suspicious activity.

Example IAM Workflow

Let’s walk through a scenario to see IAM in action:

1. Create a Role for EC2 Access to S3:

   • Create an IAM role named EC2S3AccessRole.

   • Attach a policy to the role that allows s3:GetObject.

2. Assign the Role to an EC2 Instance:

   • Launch an EC2 instance and assign the EC2S3AccessRole to it.

3. Test Access from the EC2 Instance:

   • SSH into the EC2 instance.

   • Use the AWS CLI to access the S3 bucket:

     aws s3 ls s3://example-bucket/

   • The EC2 instance is able to list the contents of the bucket without any hard-coded credentials.