AWS Identity and Access Management (IAM) Overview

• Definition: A web service that securely controls individual and group access to AWS resources.
• Manages: Users, Groups, Access Policies, Roles, User Credentials, Password Policies, MFA, API keys.
• Provides centralized control and enables shared access to your AWS account.
• Default Access: New users are created with NO access to any AWS services by default; permissions must be explicitly granted.
• Granular Permissions: Allows applying highly specific permissions.
• Not for Application-level Authentication: IAM is for AWS resource access, not for authenticating end-users of your application (use Cognito for that).
• Global Service: IAM is universal (global) and does not apply to specific regions. (Exam Tip!)
• Consistency: IAM is eventually consistent. Changes replicate across data centers globally. (Exam Tip!)
• Root Account: The account created during AWS setup; has complete Admin access by default.
  • Best Practice: Do not use the root account for daily tasks; use it only for billing and initial setup. Create an IAM user with administrative permissions instead.
• Power User Access: Allows all permissions except managing IAM groups and users.
• Integrates with many AWS services and supports PCI DSS compliance.
• AWS recommends using SDKs for programmatic API calls to IAM.

IAM Core Elements

• Principals: An entity that can take an action on an AWS resource (IAM users, roles, federated users, applications).
• Requests: Sent by principals via Console, CLI, SDKs, or APIs. Include actions, resources, principal info, and request context (IP, user agent, SSL status).
• Authentication: Verifying the principal's identity.
  • Console: Username/password.
  • API/CLI: Access key ID and secret access key.
• Authorization: IAM checks policies against request context to determine if the request is allowed or denied.
• Actions: Operations a principal can perform on a resource (e.g., s3:GetObject, ec2:RunInstances). Defined by each service.
• Resources: Entities within a service (e.g., S3 buckets, EC2 instances, IAM users).

Authentication Methods

• Console Password: For interactive sign-in to the AWS Management Console.
• Access Keys: (Access Key ID + Secret Access Key) for programmatic calls (API, CLI, SDK).
  • Can assign two active access keys per user.
  • Secret access key is shown only at creation time; must be regenerated if lost. (Exam Tip!)
  • Can disable keys temporarily.
  • Users can be given permission to change their own keys via IAM policy.
• Server Certificates: SSL/TLS certificates used with some AWS services. AWS recommends ACM for most cases.
• Multi-Factor Authentication (MFA): Adds an extra layer of security.
  • Uses a device generating random, single-use codes.
  • Can authenticate via Console, AWS API (STS requests), or AWS CLI (aws sts get-session-token).
  • Best Practice: Enable MFA for all users, especially privileged ones (Root, Admin).

IAM Users

• Represents a person or service.
• Can have programmatic access (access keys) and/or console access (password).
• By default, no permissions.
• Root account credentials (email/password) have full, unrestricted admin permissions.
• Can create "service accounts" for applications.
• Limit: Up to 5000 users per AWS account.
• Each user has a friendly name and an ARN.
• Best Practice: Create individual IAM accounts for users; do not share accounts.
• Password policies can be defined (length, complexity) and applied account-wide.

IAM Groups

• Collections of IAM users.
• Policies are attached to groups to grant permissions to all users within the group.
• Not an identity: Cannot be a principal in an IAM policy. (Exam Tip!)
• No nesting: Groups cannot contain other groups.
• Best Practice: Use the principle of least privilege.

IAM Roles

• Created and then "assumed" by trusted entities (IAM users, AWS services, federated users).
• Define a set of permissions for making AWS service requests.
• Purpose: Delegate permissions without using permanent credentials (passwords, access keys).
• Temporary Credentials: When a role is assumed, it provides temporary security credentials that automatically expire. (Exam Tip!)
• Can be assumed via console, CLI, SDK, API.
• IAM Roles with EC2 Instances:
  • Grant applications running on EC2 permissions to make AWS API requests using instance profiles.
  • Only one role can be assigned to an EC2 instance at a time. (Exam Tip!)
  • Can be assigned at launch or any time afterward.
  • Applications retrieve temporary credentials from the instance metadata.
• Role Delegation: Involves a Permissions Policy (grants permissions) and a Trust Policy (specifies who can assume the role).

IAM Policies

• JSON documents that define permissions (allowed or denied actions).
• Can be applied to users, groups, and roles.
• Default: All permissions are implicitly denied by default.
• Most Restrictive: The most restrictive policy is applied.
• IAM Policy Simulator: Tool to test and validate policy effects.
• Condition element: Used to apply further conditional logic.

Inline vs. Managed Policies

• Managed Policy:
  • Created and administered by AWS (AWS Managed Policies) or by you (Customer Managed Policies).
  • Standalone: Have their own ARN.
  • Can be attached to multiple users, groups, or roles.
  • AWS Managed Policies: Designed for common use cases (e.g., AdministratorAccess, S3FullAccess). You cannot change their permissions.
  • Customer Managed Policies: You create and administer; can be customized. Recommended over inline policies.
• Inline Policy:
  • Embedded directly within a single user, group, or role.
  • Strict 1:1 relationship: Deleted when the entity it's embedded in is deleted.
  • Useful when you want to ensure permissions are not inadvertently assigned elsewhere.
  • AWS generally recommends Managed Policies over Inline Policies.

Policy Evaluation Logic

• Default Deny: By default, all requests are denied.
• Explicit Allow: An explicit "Allow" statement in any applicable policy (identity-based or resource-based) overrides the default deny.
• Explicit Deny: An explicit "Deny" statement in any policy (identity-based, resource-based, permissions boundary, SCP, session policy) always overrides any allows. (Crucial Exam Point!)
• Order of Evaluation:
  1. Explicit Deny (highest precedence).
  2. Explicit Allow.
  3. Implicit Deny (default).
• Permissions Boundaries: Advanced feature setting maximum permissions an identity-based policy can grant to an IAM entity (user or role). Can implicitly deny.
• AWS Organizations Service Control Policies (SCPs): Specify maximum permissions for an organization or OU. Can implicitly deny.
• Session Policies: Advanced policies passed as parameters when creating temporary sessions for roles/federated users. Can implicitly deny.

IAM Instance Profiles

• Container for an IAM role used to pass role information to an EC2 instance at launch.
• Can contain only one IAM role, but a role can be in multiple instance profiles.
• Console handles creation transparently; CLI/API require manual creation.

AWS Security Token Service (STS)

• Definition: Web service to request temporary, limited-privilege credentials.
• For IAM users or federated users.
• Global Service: By default, requests go to a global endpoint (https://sts.amazonaws.com), but can use regional endpoints for lower latency. Credentials work globally regardless of endpoint.
• Integrates with CloudTrail for auditing.
• Advantages of Temporary Credentials:
  • No need to distribute/embed long-term credentials.
  • Provide access to AWS resources without creating permanent IAM identities.
  • Limited lifetime (minutes to hours), no explicit rotation/revocation needed.
• STS API Actions (for Developer Associate Exam):
  • AssumeRole: Used by IAM users to assume a role (can be used with MFA).
  • AssumeRoleWithSAML: For users authenticated via SAML.
  • AssumeRoleWithWebIdentity: For users authenticated via Web Identity Providers (e.g., Google, Facebook).
  • GetSessionToken: Used by IAM users or root account users to get temporary credentials (can be used with MFA).
  • GetFederationToken: Used by IAM users or root account users for federation.
• AWS recommends using Cognito for identity federation with Internet identity providers.

Identity Federation & Cross-Account Access

• Identity Federation: Allows secure access to AWS resources without creating IAM user accounts.
  • AD/SAML 2.0: Grants temporary access based on AD credentials; users don't need to be in IAM. Enables SSO.
  • Mobile Apps: Use Facebook/Amazon/Google/OpenID providers.
• Cross-Account Access: Allows users from one AWS account to access resources in another.
  • Useful for multi-account environments (dev/prod).
  • Achieved by:
    • Resource-based policy on the target resource in the other account.
    • OR assuming a role (identity-based policy) within the target account.

IAM Best Practices

• Lock away your AWS account root user access keys.
• Use roles to delegate permissions. (Exam Tip!)
• Grant least privilege (give only necessary permissions).
• Use AWS managed policies initially, then customer managed policies for customization (prefer over inline).
• Validate your policies (using Policy Simulator).
• Configure a strong password policy.
• Enable MFA for all users, especially privileged ones. (Exam Tip!)
• Use roles for applications running on EC2 instances. (Exam Tip!)
• Do not share access keys.
• Rotate credentials regularly.
• Remove unnecessary credentials.
• Use policy conditions for extra security.
• Monitor activity in your AWS account (CloudTrail).

Important Exam Tips & Tricks

• IAM is Global: Not region-specific.
• Eventually Consistent: Be aware of potential propagation delays for IAM changes.
• Root User: Only for billing and initial setup. Never for daily tasks. Always enable MFA.
• Default Deny: If no explicit allow, access is denied. An explicit deny always wins.
• Access Keys: Generated once, must be stored securely. Regenerate if lost. Not for console login.
• Roles vs. Users vs. Groups:
  • Users: Individual human or service identities.
  • Groups: Collections of users (for easier permission management), cannot be principals.
  • Roles: For delegation and temporary access, assumed by trusted entities (users, services, federated identities). No long-term credentials.
• EC2 Instance Roles: Best practice for EC2 instances to interact with other AWS services. Only one role per instance.
• Temporary Credentials: Always associated with roles and STS. Understand their benefits (limited lifetime, no distribution).
• Policy Types: Differentiate between AWS Managed, Customer Managed, and Inline policies. Know when to use each.
• Policy Evaluation Order: Deny > Allow > Implicit Deny.
• STS API Calls: Know the purpose of AssumeRole, GetSessionToken, and their federation counterparts.
• Cross-Account Access: Understand how roles and resource-based policies enable this.
• MFA: Crucial for security, know how it integrates with console, CLI, and API.
• CloudTrail: Always logs IAM API calls, essential for auditing.