AWS Identity and Access Management (IAM) is a core service for securely managing access to your AWS resources.
AWS Identity and Access Management (IAM) is a foundational, free web service that securely controls access to AWS services and resources. It acts as the first layer of security for your AWS environment. IAM allows you to define who (identity) can do what (permissions) on which AWS resources.
IAM entities like users, roles, and groups are accessible across all AWS regions, functioning as a global service.
IAM utilizes Users, Groups, and Roles to manage access control.
The primary entities in IAM for defining identities and permissions are Users, Groups, and Roles.
IAM Users
IAM Users represent individuals or AWS services that require access to AWS. Each user is provisioned with unique credentials.
credentials:
User ID and Password
access_methods:
AWS Management Console, AWS CLI (via Access Keys), AWS SDK (via Access Keys)
Use Cases:
- Individual human access to AWS
- Programmatic access for applications
IAM Groups
IAM Groups are collections of IAM users. They simplify permission management by allowing policies to be attached to the group instead of individual users.
Use Cases:
- Simplifying permission management for multiple users
- Easier onboarding and offboarding of users
IAM Roles
IAM Roles are designed to grant permissions to AWS services or to users/applications outside of your AWS account. They do not have long-term credentials but provide temporary, short-term credentials that can have their duration configured.
credentials:
Temporary, short-term credentials (duration configurable)
default_duration_iam_user_assuming_role:
12 hours (can be 15 minutes to 36 hours)
default_duration_root_account_access_keys_in_scripts:
1 hour (can be 15 minutes to 1 hour)
Use Cases:
- Granting permissions to AWS services (e.g., EC2 instances accessing S3 buckets)
- Cross-account access
- Identity Federation with external identity providers
- Automated tasks requiring temporary access
IAM policies are JSON documents that define permissions, specifying what actions are allowed or denied on specific resources under certain conditions.
An IAM policy consists of one or more Statement blocks. Each statement includes key elements that define the permission rule.
The policy language version (e.g., 2012-10-17).
Technical Specs: Example: '2012-10-17'
The core of the policy, containing permission rules.
An optional identifier for the statement.
Determines whether the specified actions are allowed or denied.
Technical Specs: Either 'Allow' or 'Deny'
The specific AWS operations that can be performed.
Technical Specs: Example: s3:CreateBucket, s3:DeleteBucket, ec2:*
The AWS resources to which the actions apply.
Technical Specs: Example: '*' for all, or a specific ARN like 'arn:aws:s3:::my-bucket/*'
A logical element that further refines when the policy is in effect.
Technical Specs: Example: allowing access only from a specific IP address ('aws:SourceIp')
Identifies the IAM user or role that will have the privilege. This element is crucial for resource-based policies.
Users inherit permissions from any IAM groups they belong to. If a user is a member of multiple groups, their effective permissions are the cumulative union of all policies attached to those groups.
IAM policies can be categorized based on their attachment method and management.
AWS IAM supports various types of policies to manage permissions effectively.
Identity-based Policies
Policies attached directly to IAM identities (users, roles, or groups). They determine what actions the attached identity can perform on AWS resources.
attachment_target:
IAM users, roles, or groups
scope:
Determines who can use a resource
Use Cases:
- Granting permissions to individuals or groups
- Defining service permissions for roles
Resource-based Policies
Policies attached directly to an AWS resource. They specify which principals (identities) can access that specific resource and what actions they can perform.
attachment_target:
AWS resources (e.g., S3 buckets, Lambda functions, KMS keys, DynamoDB tables, VPC endpoints)
scope:
Determines which principals can access the resource
supported_services:
Amazon S3, SQS, Lambda, VPC endpoints, KMS, DynamoDB (not all AWS services support them)
Use Cases:
- Cross-account access to S3 buckets
- Defining access for Lambda function invocation
- Controlling access to KMS keys
Managed Policies - AWS Managed Policies
Predefined policies created and managed by AWS. They are reusable and are updated by AWS when new services or features launch.
management:
Created and managed by AWS
modifiability:
Cannot be modified by users
reusability:
Can be applied to many principals
arn:
Possess their own ARN
Use Cases:
- Common access patterns (e.g., AdministratorAccess, AmazonS3ReadOnlyAccess)
Managed Policies - Customer Managed Policies
Policies created and maintained by the customer. They are reusable and can be edited and applied to multiple entities.
management:
Created and managed by the customer
modifiability:
Can be changed/updated by the customer
reusability:
Can be applied to as many principals as desired
updates_responsibility:
Customer needs to update them when new services launch
arn:
Possess their own ARN
Use Cases:
- Specific scenarios not covered by AWS managed policies
- Granular access control tailored to organizational needs
Inline Policies
Policies embedded directly into a single IAM user, group, or role. They have a one-to-one relationship with the identity they are attached to and are not reusable elsewhere.
attachment:
Embedded directly into a single IAM user, group, or role
reusability:
Not reusable
relationship:
Strict one-to-one relationship
management:
Managed by the user; deleting the resource deletes the policy
modifiability:
Can be modified
Use Cases:
- Specific, one-off scenarios where a policy is tightly coupled to a single identity
Understanding how IAM evaluates policies is critical, especially when multiple policies or 'Allow' and 'Deny' effects are present.
In IAM, if a permission is not explicitly allowed, it is implicitly denied by default. Newly created IAM users have no permissions by default.
A statement with 'Effect': 'Deny' that specifically prohibits an action. Explicit deny statements always take precedence over allow statements, whether explicit or implicit. If any policy segment has an explicit deny, the final result is deny.
The order of policy evaluation determines access when permissions overlap or are defined in multiple policies. An explicit deny always overrides an explicit allow.
Technical Specs: 1. Explicit Deny (Always wins)
2. Service Control Policy (SCP)
3. Resource-Based Policy
4. Identity-Based Policy
5. Permissions Boundaries
6. Session Policies
7. Implicit Deny (The default state; all actions are denied unless explicitly allowed)
The Principle of Least Privilege is a fundamental security concept in AWS IAM.
Granting only the minimum permissions necessary for a user or service to perform its intended function, and nothing more. This enhances security by limiting potential damage from compromised accounts or accidental misconfigurations.
Specify only required actions (e.g., s3:DeleteObject, s3:PutObject) and restrict permissions to specific resources where absolutely necessary (e.g., a particular S3 bucket). This contrasts with granting overly broad permissions like s3:* (all S3 actions).
Tools like the S3 Policy Generator and IAM Access Analyzer can help identify and review unused permissions to promote least privilege access.
MFA is a critical security measure that adds an extra layer of protection to AWS accounts.
MFA significantly reduces the risk of unauthorized access, especially for privileged accounts like the root user and administrators. It requires users to provide two distinct forms of authentication beyond just a password.
AWS supports several types of MFA devices.
Free applications like Google Authenticator, Microsoft Authenticator, or Authy.
Hardware keys (e.g., YubiKey) that use biometrics and touch.
Physical devices that generate time-based one-time passwords (TOTP).
MFA can be enforced programmatically through IAM policies. By including a condition like 'aws:conditions:aws_multifacto_authentication_present': 'true' in a policy, you can block users from accessing AWS resources if they have not enabled and used MFA.
Technical Specs: Condition: 'aws:conditions:aws_multifacto_authentication_present': 'true'
AWS Security Token Service (STS) is a global web service that enables requesting temporary, limited-privilege credentials for IAM users or federated identities.
AWS STS is a global web service that enables requesting temporary, limited-privilege credentials for IAM users or federated identities. It is fundamental for roles, which leverage temporary credentials.
Technical Specs: Global and regional service; token duration configurable between 15 minutes and 36 hours.
Developers needing temporary, scoped access to AWS resources within the same AWS account can assume an IAM role with specific S3 permissions. The IAM principal invokes sts:AssumeRole to get temporary credentials.
Technical Specs: Session duration can be set (15 minutes to 12 hours). AWS STS validates permissions via IAM and issues temporary security credentials (Access Key ID, Secret Access Key, Session Token).
IAM Roles are the solution for managing user access across multiple AWS accounts. An IAM role is created in the target account (where resources reside) with a trust policy allowing principals from the source account to assume it. A permission policy attached to this role grants access to specific resources.
Technical Specs: The IAM role and trust policy must always be on the target account (the account where the resource resides).
IAM roles provide a secure and manageable way for AWS services to interact with other services without using long-term credentials.
IAM Roles provide a secure way for EC2 instances to access other AWS services without embedding access keys directly into applications or instance configurations. An EC2 instance assumes an IAM role (via an Instance Profile) which grants it temporary credentials to perform actions specified by the role's attached policies.
IAM Execution Roles grant AWS permissions to Lambda functions, allowing them to interact with other services (e.g., S3 object retrieval, DynamoDB item insertion, SQS message reception).
For containerized applications, a Task Role is assigned to tasks within containers, allowing applications to perform AWS actions. A Task Execution Role grants permissions to agents and services (e.g., pull images from ECR).
Appropriate IAM permissions are crucial for the SSM Agent to communicate with AWS Systems Manager. For EC2 instances, an IAM role attached to the EC2 instance profile is recommended. For on-premises or other cloud VMs, a non-administrator IAM user with programmatic access (access keys and secret access keys) is required.
Beyond basic users and roles, AWS offers advanced services and features to enhance identity management and security.
Helps identify resources that can be accessed publicly or from external AWS accounts. It employs automated reasoning to examine and evaluate resource policies, proactively identifying security risks. It can also detect unused permissions (IAM roles, user permissions, access keys, service-linked roles) that have not been used in the last 90 days (configurable from 1 to 365 days).
Technical Specs: Supported Resource Types: IAM Roles, S3 Buckets, KMS Keys, Secrets Manager Secrets, SQS Queues, AWS Lambda Resource-Based Policies; Default Tracking Period for Unused Access: 90 days; Configurable Period for Unused Access: 1 day to 365 days; Pricing for External Access: Free; Pricing for Unused Access: $0.20 per IAM user and role per month (no free tier).
A downloadable CSV file providing a snapshot of all IAM users and their security posture, including MFA enabled status, password last used, access key status (active/inactive), access key age, and usage. Useful for bulk auditing.
Technical Specs: Reports generated with new data approximately every 4 hours. Reports generated within a 4-hour window of each other will contain the same data. Report Storage: Stored for up to 4 hours after creation.
Analyzes CloudTrail logs to recommend IAM policies that adhere to the principle of least privilege, reducing overprovisioned roles.
Restrict the maximum permissions that can be granted to an IAM entity (user or role). They do not grant permissions themselves but set an upper limit, useful for delegation scenarios.
Enforce specific conditions for policy grants. Popular keys for exams include:
Addresses the confused deputy problem, preventing unintended privilege escalation.
Checks for MFA tokens in requests, enforcing MFA usage.
Restricts access based on specific IP addresses or CIDR blocks.
Restricts cross-account access to members of a specific AWS Organization.
A cloud-native service for centralized access management across multiple AWS accounts and applications. It simplifies managing user access in organizations with multiple AWS accounts and diverse user roles. It can create users directly or connect to existing identity providers (e.g., on-premises Active Directory, Azure AD, Okta). Requires an AWS Organization.
Technical Specs: Requires an AWS Organization.
A fully managed Microsoft Active Directory hosted across multiple Availability Zones for high availability. Supports Group Policies, LDAP, Kerberos, and trust relationships with on-premises AD (one-way or two-way).
Technical Specs: Editions: Standard (1 GB storage, up to 30,000 objects), Enterprise (17 GB storage, up to 500,000 objects).
A lightweight proxy that allows AWS services to authenticate against your on-premises Active Directory without storing directory data within AWS. Requires network connectivity (VPN or Direct Connect).
A cost-effective Samba-based directory service for small-scale environments. Supports user/group management, basic Group Policies, and Kerberos-based authentication.
Technical Specs: Editions: Small (up to 2,000 objects), Large (up to 20,000 objects).
Centralized permission policies that apply to accounts/Organizational Units (OUs) to restrict actions for users and roles. SCPs do not affect the management account but do impact member accounts and their root users. Actions must be explicitly allowed by both an SCP and an IAM policy for a principal to use them; SCPs override other permissions unless a 'deny' is present.
A secure, hierarchical storage for configuration data and secrets. It supports different parameter types, including SecureString for sensitive data.
Securely stores secrets (database credentials, API keys) and provides automatic rotation for managed secrets. Applications use Secrets Manager API calls to retrieve secrets.
Technical Specs: Supports automatic rotation of managed secrets.
Adhering to IAM best practices is crucial for maintaining a secure AWS environment.
Lock down the root user immediately after creating the AWS account and avoid using it for daily operations. Use dedicated IAM users instead.
Create dedicated IAM users and assign them only the minimum permissions necessary for their tasks, and nothing more.
Assign permissions to IAM groups rather than individual users for easier management, scalability, and to prevent privilege creep.
Use IAM roles for services and external identities, preferring roles over users for automation and temporary access due to their enhanced security from temporary credentials.
Enforce Multi-Factor Authentication (MFA) for all users, especially privileged ones, to protect against credential compromise.
Enable AWS CloudTrail to log and monitor all IAM-related activities, which is essential for detecting suspicious behavior.
Never share IAM credentials and rotate them regularly (e.g., every 90 days). Avoid creating long-term credentials for external users.
Technical Specs: Access Key Pairs and passwords should be rotated regularly (e.g., every 90 days).