Skip to main content

AWS Identity and Access Management(IAM)

AWS Identity and Access Management (IAM) is a core service that enables you to securely manage access to AWS resources. It allows you to control who (users, groups, roles) can access what resources and under what conditions. Understanding IAM is critical for securing your AWS environment. Here are the essential aspects of IAM:

1. Users, Groups, and Roles​

  • Users: Represents individual users or applications that need to interact with AWS resources. Each IAM user has a unique set of credentials (username, password, access keys) and permissions that define what they can do within an AWS account.
  • Groups: A collection of IAM users. Groups simplify permission management by allowing you to assign policies to a group instead of individual users (e.g., Admin, Developers, ReadOnly groups).
  • Roles: IAM roles are used to grant permissions to entities you trust, such as AWS services, users, or external identities. Roles do not have credentials (passwords or access keys). Instead, they are assumed by other entities to gain temporary access to AWS resources. Common use cases include:
    • Cross-Account Access: Granting access to users from a different AWS account.
    • AWS Services: Allowing services like EC2, Lambda, or ECS to access other AWS services (e.g., an EC2 instance accessing an S3 bucket).
    • Federation: Providing access to IAM roles via external identities (e.g., corporate Active Directory, Google Workspace) using identity providers.

2. Policies and Permissions​

  • IAM Policies: JSON documents that define what actions are allowed or denied for users, groups, or roles. Policies are attached to IAM entities (users, groups, roles) to grant permissions. Key components of a policy:
    • Effect: Specifies whether the policy allows (Allow) or denies (Deny) access.
    • Action: Defines the specific API operations (e.g., s3:PutObject, ec2:DescribeInstances) that the policy permits or restricts.
    • Resource: Identifies the AWS resources (e.g., an S3 bucket, an EC2 instance) that the policy applies to.
    • Condition: Optional; used to apply additional logic to when the policy is in effect (e.g., restrict access based on IP addresses, time of day).
  • Policy Types:
    • Managed Policies: AWS managed policies are pre-built policies provided by AWS (e.g., AmazonS3ReadOnlyAccess). Customer managed policies are custom policies you create and manage in your account.
    • Inline Policies: Policies embedded directly within a user, group, or role. They provide fine-grained control but are less reusable compared to managed policies.

3. Best Practices​

  • Principle of Least Privilege: Always follow the principle of least privilege by granting users, groups, and roles only the permissions they need to perform their tasks, nothing more.
  • Use Roles Over Access Keys: Avoid using long-term access keys for applications and services. Use IAM roles with temporary security credentials (STS tokens) instead. This enhances security by limiting the exposure of access keys.
  • Password Policies: Implement a strong password policy for IAM users, specifying requirements such as minimum password length, character types, and mandatory password rotation.
  • MFA (Multi-Factor Authentication): Enable MFA for all IAM users, especially those with privileged access, to add an extra layer of security.
  • Use Groups for Permissions: Assign permissions to groups rather than individual users. This makes it easier to manage and update permissions as users change roles within your organization.
  • Monitor and Rotate Access Keys: Regularly monitor the use of access keys and rotate them periodically to reduce the risk of compromise.

4. Access Management​

  • IAM Policies vs. Resource-Based Policies:
    • IAM Policies: Attached to IAM users, groups, or roles to grant permissions to resources in the account.
    • Resource-Based Policies: Attached directly to AWS resources (e.g., S3 bucket policies, SNS topic policies) to grant cross-account access or control access at the resource level.
  • Access Analyzer: AWS IAM Access Analyzer helps you identify resources that are shared with external accounts. It automatically analyzes permissions granted to resources in your account, providing insights into potential security risks.
  • Identity-Based Policies vs. Permission Boundaries:
    • Identity-Based Policies: Policies attached to IAM identities (users, groups, roles) to define what actions are allowed on which resources.
    • Permission Boundaries: Advanced feature that sets the maximum permissions an IAM identity can have. Useful for enforcing guardrails when delegating permissions management (e.g., for administrators creating IAM roles).

5. Cross-Account Access​

  • Cross-Account Roles: Use IAM roles to grant access to AWS resources in another account. To assume a role in another account, an IAM user or service must have the necessary permissions (sts:AssumeRole) in their policy, and the target role's trust policy must allow the source account to assume it.
  • Resource-Based Policies: Some AWS services (e.g., S3, KMS, SQS) support resource-based policies that can be used to grant cross-account access directly on the resource.

6. Federated Access​

  • Identity Federation: Allows users from external identity providers (e.g., corporate Active Directory, Google Workspace, or third-party identity providers using SAML or OIDC) to access AWS resources without needing an IAM user account. Common federation methods include:
    • SAML 2.0: Federates access using your organization's existing identity provider (e.g., Active Directory Federation Services).
    • AWS Single Sign-On (SSO): Provides centralized access management for AWS accounts and applications. It integrates with various identity providers for seamless access.
  • Temporary Security Credentials: Federation typically grants temporary security credentials using the AWS Security Token Service (STS), reducing the risks associated with long-term credentials.

7. Temporary Security Credentials​

  • AWS STS (Security Token Service): Provides temporary, limited-privilege credentials to users or applications. Temporary credentials are created using API calls like AssumeRole, GetFederationToken, and AssumeRoleWithSAML.
  • Session Duration: Temporary credentials have a limited validity period (from a few minutes to several hours) to minimize security risks. Adjust the session duration based on the use case and security requirements.

8. Service-Linked Roles​

  • Service-Linked Roles: Special IAM roles predefined by AWS services to delegate permissions needed for service operations. These roles simplify service management by automatically providing the necessary permissions for the service to operate within your account.
  • Automatic Creation: Service-linked roles are typically created automatically when you enable or configure an AWS service that requires them (e.g., Amazon RDS, AWS Lambda).

9. Security Auditing and Monitoring​

  • IAM Access Analyzer: Helps identify resources shared with external accounts. It continuously monitors for potential access risks and provides alerts for unintended access.
  • IAM Credential Report: The credential report lists all users in the AWS account and provides details about their passwords, access keys, MFA status, and more. This is useful for auditing and managing IAM user credentials.
  • CloudTrail: Use AWS CloudTrail to monitor IAM activities, including user logins, policy changes, and API usage, providing a detailed audit trail of all actions taken by IAM entities.

10. IAM Best Practices Summary​

  • Use IAM Roles for Applications: Instead of embedding access keys in applications, use IAM roles to securely grant permissions to applications running on EC2, Lambda, ECS, or other AWS services.
  • Rotate Credentials Regularly: Regularly rotate access keys and passwords to mitigate the risk of credential compromise.
  • Review Permissions Periodically: Regularly review IAM policies and permissions to ensure that they align with the principle of least privilege. Remove or reduce unnecessary permissions as needed.
  • Enable IAM Access Analyzer: Use IAM Access Analyzer to identify and analyze resources in your account shared with external entities.

11. IAM Quotas and Limits​

  • Account Limits: Each AWS account has specific quotas for IAM entities:
    • Maximum of 5,000 IAM users per account.
    • Maximum of 300 IAM groups per account.
    • Maximum of 1,000 IAM roles per account.
  • Policy Size: IAM policies have size limitations (maximum of 6,144 characters for inline policies and managed policies). Plan policy structure accordingly to avoid hitting these limits.