3.4.1.1. IAM Entities for Human & Machine Access (Users, Groups, Roles, Identity Providers, Policies)

First Principle: Controlling who can access your resources and what actions they can perform minimizes risk.

AWS Identity and Access Management (IAM) embodies this principle of security. IAM entities are the building blocks for this granular control, managing both human and machine access.

• IAM Users: Represent individual human identities. They are for people who need to interact directly with AWS, like developers or administrators.
• IAM Groups: Collections of IAM users. Attaching policies to a group grants the same permissions to all users within it, simplifying management (e.g., "Developers" group with S3 read access).
• IAM Roles: Grant temporary permissions to trusted entities. This is crucial for services (e.g., an EC2 instance accessing S3) or for users assuming elevated privileges for a specific task, adhering to least privilege.
• Identity Providers (IdPs): Enable federation, allowing users to sign in with corporate credentials (e.g., Active Directory, Okta) and gain temporary AWS access without creating IAM users.
• IAM Policies: JSON documents that define permissions. They specify "who" (principal), "what" (actions), "on which" (resources), and "under what conditions). Policies can be identity-based (attached to users, groups, roles) or resource-based (attached to resources like S3 buckets).

Key IAM Entities:

• Users: Individual human identities (persistent credentials).
• Groups: Collections of users, simplify management.
• Roles: Temporary permissions for trusted entities (human or machine).
• Identity Providers: Enable federation with external identity systems.
• Policies: Define permissions (Allow/Deny actions on resources).

Scenario: A DevOps team needs to manage access for human users (developers, administrators) and machine identities (EC2 instances running applications) to various AWS resources. They need to simplify permission management for groups of users and ensure machines only have temporary, necessary access.

Reflection Question: How would you use IAM Users, IAM Groups, and IAM Roles (with appropriate IAM Policies) to establish granular control over both human and machine access to AWS resources, minimizing risk and adhering to least privilege?

These entities combine to form a robust access strategy. Users are organized into Groups, Roles provide temporary access for services or federated users, and Policies are the definitive rulebooks governing all permissions.

💡 Tip: Always apply the principle of "least privilege" when crafting IAM policies. Grant only the permissions required to perform a specific task, and nothing more.