AWS Identity & Access Management (IAM)

Core Components of IAM

IAM is built on four fundamental components: Users, Groups, Roles, and Policies.

1. IAM Users

An IAM User represents the person or application that interacts with AWS.

• Credentials: A user has long-term security credentials:

  • Password: For signing in to the AWS Management Console.

  • Access Keys (Access Key ID and Secret Access Key): For making programmatic calls to AWS via the API, CLI, or SDKs.

• Best Practice: Create individual IAM users for each person who needs access to AWS. Avoid using the root account for daily tasks.

2. IAM Groups

An IAM Group is a collection of IAM users.

• Purpose: Groups are used to simplify permission management. You can attach a permission policy to a group, and all users within that group will inherit those permissions.

• Key Features:

  • A user can belong to multiple groups (up to 10).

  • Groups cannot contain other groups (they cannot be nested).

  • Groups are a management convenience; you cannot log in as a group.

3. IAM Roles

An IAM Role is an identity that you can assume to gain specific permissions. Unlike a user, a role does not have its own long-term credentials.

• Temporary Credentials: When an entity assumes a role, it receives temporary security credentials for that session. This is the most secure way to grant permissions.

• Trusted Entities: A role must have a "trust policy" that defines who can assume it. Trusted entities can be:

  • An AWS Service: Such as an EC2 instance, Lambda function, etc. (e.g., allowing an EC2 instance to access an S3 bucket).

  • Another AWS Account: For secure cross-account access.

  • Web Identity / Identity Federation: Users authenticated through an external provider like Active Directory (SAML) or a public provider like Login with Amazon, Facebook, or Google (OIDC).

4. IAM Policies

An IAM Policy is a JSON document that explicitly defines one or more permissions. Policies are attached to users, groups, or roles to grant them access to AWS resources.

• Structure of a Policy Statement:

  • Effect: Allow or Deny. An explicit Deny always overrides an Allow.

  • Action: The specific API call or service action being permitted or denied (e.g., s3:GetObject, ec2:StartInstances).

  • Resource: The Amazon Resource Name (ARN) of the AWS resource(s) the policy applies to.

  • Condition (Optional): Specifies circumstances under which the policy is in effect (e.g., access is only allowed from a specific IP address).

• Types of Policies:

  • Identity-Based Policies: Attached directly to an IAM identity (user, group, or role).

  • Resource-Based Policies: Attached directly to a resource, such as an S3 bucket policy or an SQS queue policy.

  • Managed vs. Inline:

    • AWS Managed: Pre-defined policies created and managed by AWS (e.g., AdministratorAccess, AmazonS3ReadOnlyAccess).

    • Customer Managed: Policies you create and manage. They are reusable and can be attached to multiple identities.

    • Inline: Policies that are embedded within a single user, group, or role. They have a strict one-to-one relationship and are not reusable.

IAM Best Practices

• Lock away the Root User: Don't use your root account for everyday tasks. Secure it with a strong password and enable Multi-Factor Authentication (MFA).

• Create Individual IAM Users: Don't share credentials. Create a user for each person.

• Use IAM Groups for Permissions: Assign permissions to groups rather than individual users to simplify management.

• Grant Least Privilege: Always start with a minimum set of permissions and grant additional permissions as necessary.

• Use IAM Roles for Applications: Grant permissions to applications running on EC2 instances or other AWS services using roles, not by storing access keys on the instance.

• Enable a Strong Password Policy: Enforce password complexity and rotation for your users.

• Enable MFA for All Users: Add a second layer of security for both console access and sensitive API calls.

• Rotate Credentials Regularly: Regularly rotate passwords and access keys.

• Use IAM Access Analyzer: Periodically review which resources are shared with external entities to ensure intended access.