Aws Identity And Access Management Documentation

AWS Identity and Access Management Overview Introduction AWS Identity and Access Management (IAM) is a web service provided by Amazon Web Services that enables secure control of access to AWS resources.[1] IAM provides the infrastructure to manage authentication and authorization for AWS accounts, allowing administrators to define who can perform which actions on specific resources.[3] It supports the creation of identitiesâincluding users, groups, and rolesâas well as policies that grant or deny permissions to these identities.[1] IAM centralizes access management across an AWS account or multiple accounts, enabling consistent control over workforce and workload identities.[2] It facilitates the assignment of permissions to users for individual people or applications, to groups for simplified management of multiple users, and to roles for temporary access by trusted entities.[1] IAM also supports attribute-based access control (ABAC) through attributes such as tags, allowing fine-grained permissions based on conditions like department or project.[2] The service integrates deeply with most AWS services to secure workloads, enabling access control for resources such as EC2 instances, S3 buckets, and more.[1] IAM emphasizes principles such as least privilege and temporary security credentials to enhance security.[1]History AWS Identity and Access Management (IAM) was launched in May 2011 as a general availability service, enabling users to create individual IAM users, organize them into groups, and attach policy documents to control access to AWS resources across fifteen supported services at the time.

This initial release included the AWS Policy Generator and predefined policy templates to facilitate fine-grained permissions based on actions, resources, and conditions.[4][5][6] In August 2011, AWS introduced identity federation capabilities, allowing external identities to be federated into an AWS account with support for short-term temporary credentials, marking an early emphasis on avoiding long-term access keys.[4] June 2012 brought IAM roles for Amazon EC2 instances, enabling applications running on EC2 to securely access AWS APIs without embedding long-term credentials.[4] A significant enhancement arrived in February 2015 with the introduction of managed policies, which converted existing IAM policies into reusable, first-class objects that could be attached to multiple users, groups, or roles.[4] In November 2018, AWS added support for attribute-based access control (ABAC) as a complement to role-based access control, permitting the use of tags on users, roles, and resources within policies to enable scalable and fine-grained permissions.[4] December 2019 saw the launch of IAM Access Analyzer, a feature that analyzes policies to identify resources accessible from outside an account or publicly, helping enforce least-privilege principles through automated findings.[4][7] Throughout its evolution, IAM shifted toward greater reliance on temporary credentials and federation mechanisms, with early federation in 2011 and EC2 roles in 2012 laying foundational support for secure, short-lived access patterns that reduced dependence on static credentials.[4]Key Features AWS Identity and Access Management (IAM) is offered at no additional charge as part of an AWS account, with charges applying only when accessing other AWS services using IAM credentials.[1] IAM supports the creation and management of identities, including IAM users for individual access, groups to organize multiple users, and roles for temporary delegated access to users or AWS services.[1][8] Permissions are defined and enforced through policy-based mechanisms, allowing fine-grained control over actions and resources across AWS services.[9][8] IAM operates on an eventual consistency model, meaning that changes to identities or policies propagate across distributed systems and may not be immediately visible in all locations.[1] It achieves high availability through replication of data across multiple servers in Amazon's data centers worldwide.[1] IAM promotes the principle of least privilege by enabling granular permissions and supports multi-factor authentication (MFA) for enhanced security.[9]Components Root User The AWS account root user is the initial identity created automatically when an AWS account is established, using the email address and password provided during signup.[10] This identity has unrestricted access to all AWS services and resources within the account, granting full administrative privileges by design and enabling it to perform tasks that no other identity can, such as changing account contact information, closing the account, or activating IAM access to billing.[10] Unlike IAM users, which operate under defined permissions, the root user cannot be restricted by policies.[10] AWS strongly recommends limiting use of the root user to rare tasks that specifically require its credentials, and avoiding it for everyday operations.[11] Regular administrative tasks should instead use IAM users, roles, or IAM Identity Center workforce identities with temporary credentials.[11] To secure the root user, AWS advises the following best practices:- Enable multi-factor authentication (MFA) immediately, which adds a second authentication factor (such as a security key, hardware TOTP token, or virtual MFA device) beyond the password, significantly reducing the risk of unauthorized access.

AWS requires MFA registration for the root user within 35 days of first sign-in for console access across all account types.[12] - Use a strong, unique password meeting AWS requirements (at least 8 characters, up to 128, with a mix of character types) and consider periodic rotation.[11] - Do not create access keys for the root user, as they provide long-term programmatic access with full privileges; instead, use temporary credentials when programmatic access is needed.[13] - Secure recovery mechanisms by using a group-managed email address for the account and a dedicated phone number, while splitting responsibility for password and MFA access across multiple individuals to enforce multi-person approval.[11][13] IAM Users An IAM user is an entity created in an AWS account that represents a human user or workload needing to interact with AWS resources.

It consists of a unique name and associated credentials, allowing individualized assignment of permissions within the account. IAM users serve as long-term identities distinct from the root user and are intended for scenarios where direct, persistent access is required.[14] IAM users possess long-term credentials in the form of a password for interactive access and/or access keys for programmatic access. A password enables sign-in to interactive sessions such as the AWS Management Console.

Access keys consist of an access key ID and a secret access key pair, used to make programmatic calls to AWS services through tools like the AWS CLI, AWS SDKs, or direct API requests. New IAM users have no credentials by default, and administrators must explicitly create them based on the required access type.[14] To sign in to the AWS Management Console, an IAM user provides their account ID or account alias, username, and password at a dedicated sign-in URL (such as https://My_AWS_Account_ID.signin.aws.amazon.com/console/) or through the general console endpoint.

For programmatic access, the user employs their access key pair. As a best practice, multi-factor authentication (MFA) is recommended for all IAM users to enhance security during console sign-in.[15] The creation of an IAM user involves defining the user name, generating necessary credentials (console password and/or access keys), assigning permissions (directly or via groups), and optionally adding tags or configuring MFA. Administrators can perform these steps via the AWS Management Console, AWS CLI, or API.

Only the required credentials should be created to follow the principle of least privilege.[16] AWS best practices strongly recommend minimizing the use of IAM users with long-term credentials in favor of IAM roles and federation for temporary credentials. Human users should primarily use federation with an identity provider to access AWS, reserving IAM users for limited scenarios such as emergency access, certain workloads that cannot use roles (e.g., specific AWS CodeCommit or Amazon Keyspaces interactions), or third-party clients without alternative identity solutions.

Long-term access keys should be avoided where possible due to security risks, with roles providing a more secure alternative for most access needs.[14][17]Groups In AWS Identity and Access Management (IAM), a user group is a collection of IAM users designed to simplify the management of permissions across multiple users.[18] User groups allow administrators to attach identity-based policies to the group, automatically applying the associated permissions to every user who is a member.[18] This mechanism enables centralized administration for teams or roles within an organization, such as granting administrator privileges to all members of an Admins group or developer permissions to a Developers group.[18] When a new user joins and requires specific access, they can be added to the relevant group rather than having permissions configured individually.[18] Similarly, job changes or role transitions can be managed by removing the user from outdated groups and adding them to appropriate new ones, avoiding the need to edit individual user permissions directly.[18] Groups function solely as containers for organizing users and permissions; they do not possess their own credentials or serve as authenticated entities.[18] A group can contain many users, and a single user may belong to multiple groups simultaneously.[18] However, groups cannot be nestedâmeaning they contain only users, not other groupsâand there is no default group that automatically includes all users in an AWS account.[18] If a comprehensive group is needed, it must be created manually and users assigned to it.[18] Groups cannot be specified as principals in policies (such as resource-based policies), because they relate exclusively to permissions management rather than authentication.[18] The number of groups and group memberships per user are subject to IAM service quotas.[18] For example, in a small organization, an Admins group might be established to manage other groups such as Developers and Test, with users assigned accordingly to streamline access control across teams.[18]Roles IAM roles are identities in AWS Identity and Access Management that provide temporary security credentials when assumed by trusted entities, enabling delegated access to AWS resources without long-term credentials like access keys or passwords.

Unlike IAM users, which are permanently associated with individuals and use persistent credentials, roles are intended for assumption by AWS services, applications, users in other accounts, or federated identities.[19] Each IAM role includes a required trust policy, a JSON-based resource policy that defines the principals trusted to assume the role, such as IAM users, other roles, AWS accounts, AWS services, or external identity providers.

This policy establishes the trust relationship required for assumption, specifying conditions under which assumption is permitted.[19] When a trusted principal assumes a role, AWS Security Token Service (STS) issues temporary security credentials consisting of an access key ID, secret access key, and session token. These credentials are time-limited and automatically expire, reducing risks associated with credential exposure compared to long-term keys.[20] Roles support several common use cases.

For cross-account access, a role in one AWS account can be assumed by principals in another account, allowing delegation of permissions to resources without creating users in every account.[21] Roles attached to Amazon EC2 instances enable applications running on those instances to make AWS API calls securely by retrieving temporary credentials from the instance metadata service, eliminating the need to manage or embed long-term credentials.[22] For federation, roles are assumed after authentication with external identity providers using SAML 2.0 or OpenID Connect, granting temporary access to federated users or workloads without creating permanent IAM users in AWS.[23]Unique identifiers for IAM roles In addition to the ARN and friendly name, each IAM role has a unique, immutable RoleId assigned by AWS upon creation.

This identifier starts with the prefix AROA (for roles; other prefixes apply to users like AIDA, groups AGPA, etc.) followed by a unique string, e.g., AROAEXAMPLEID. The RoleId is stable for the lifetime of the role and does not change even if the role is renamed or its policies are updated.

It is not displayed in the AWS Management Console (which shows only the role name and ARN) and must be retrieved programmatically.Retrieving the RoleId Use the AWS CLI:- To get details for a known role: aws iam get-role --role-name your-role-name Look for the "RoleId" field in the response. - To search for a specific RoleId across all roles: aws iam list-roles --query 'Roles[?RoleId== AROAVRUVUF24GVQE5UNGC]' Usage in AWS service events and logs The RoleId appears in event notifications and audit logs when a role performs actions.

For example:- In Amazon S3 event notifications, the userIdentity.principalId field contains the value in the formatAWS:AROA...:session-name (e.g.,AWS:AROAVRUVUF24GVQE5UNGC:pii-masking ). - In AWS CloudTrail events, the userIdentity.principalId field contains the value in the formatAROA...:session-name . AWS: (in some contexts like S3 events) is a prefix for IAM principals.AROA... is the unique RoleId.session-name is the role session name (for Lambda, typically the function name; customizable in AssumeRole calls).

Identity Providers AWS Identity and Access Management (IAM) supports identity providers as entities that establish trust between AWS and external identity providers (IdPs) using the SAML 2.0 or OpenID Connect (OIDC) standards, enabling federation of external identities into AWS for secure access to resources without creating individual IAM users.[23] SAML 2.0 federation allows integration with external IdPs that support the Security Assertion Markup Language 2.0 standard, such as Microsoft Active Directory Federation Services or Shibboleth. Users authenticate through the external IdP, which issues a SAML assertion containing user attributes.

This assertion is exchanged for temporary AWS security credentials through the AWS Security Token Service (STS) AssumeRoleWithSAML API operation, with the credentials mapped to an IAM role that defines the permissions granted. Role mapping relies on attributes in the SAML assertion, such as group memberships or custom attributes, to enforce fine-grained access controls.

This approach is commonly used for workforce single sign-on (SSO), where employees access the AWS Management Console or AWS APIs using their organizational credentials, centralizing identity management across AWS accounts.[24] OIDC federation supports external IdPs compatible with OpenID Connect, an identity layer on top of OAuth 2.0, such as Google or Amazon Cognito. An OIDC-compatible IdP issues a JSON Web Token (JWT) after authentication, which applications or services exchange for temporary AWS credentials via the STS AssumeRoleWithWebIdentity API operation.

The token's claims, including attributes like subject or audience, map the external identity to an IAM role with attached permissions.

This method is particularly suited for third-party access and non-AWS workloads, such as CI/CD pipelines (e.g., GitHub Actions), mobile or web applications, or serverless workloads requiring secure, temporary access without embedding long-term credentials.[25][26] In both SAML and OIDC federation, external identities are mapped to IAM roles through trust relationships defined in the role's trust policy, which specifies the identity provider as a principal and can include conditions based on attributes from the IdP's assertion or token. This enables attribute-based access decisions while adhering to least privilege principles.

These capabilities support secure workforce SSO for organizational users and controlled third-party access for external applications or partners.[23]Policies and Permissions Policy Types AWS Identity and Access Management (IAM) supports several types of policies to control access to AWS resources, with identity-based policies serving as the primary mechanism attached to IAM users, groups, or roles. These identity-based policies are classified as managed policies or inline policies.[27] Managed policies are standalone policies that exist independently and can be attached to multiple IAM identities.

AWS managed policies are created and administered by AWS to provide predefined permissions for common use cases, such as read-only access or full access to specific services, and AWS automatically updates them when new features or actions become available.[28] Customer managed policies are created and maintained by the AWS account owner, offering customizable permissions that can be attached to multiple identities for consistent application across an account.[28] Inline policies are embedded directly into a single IAM user, group, or role and maintain a one-to-one relationship with that identity.

They are deleted when the identity is deleted and are typically used for unique or highly specific permissions that do not need reuse.[28] Permissions boundaries are an advanced feature that uses a managed policy (AWS managed or customer managed) to set the maximum permissions an IAM user or role can receive from any attached identity-based policies.

They do not grant permissions themselves but act as a guardrail, ensuring effective permissions do not exceed the defined boundary even if broader permissions are specified elsewhere.[29] Service control policies (SCPs) are part of AWS Organizations and interact with IAM by defining the maximum permissions available to IAM users and roles in member accounts.

SCPs do not grant permissions but limit the actions that identity-based policies can allow, providing centralized guardrails across an organization.[27][30]Policy Structure AWS Identity and Access Management (IAM) policies are JSON documents that define permissions for AWS resources using a structured syntax with defined elements. The policy typically includes a top-level Version element specifying the policy language version, followed by a Statement element containing one or more individual permission statements.[31][32] The Version element is recommended and determines the syntax rules AWS applies when processing the policy.

The current and recommended value is "2012-10-17", which enables all available policy features, including policy variables; older values like "2008-10-17" limit functionality and are not recommended for new policies.[33] The Statement element is required and consists of a JSON array of one or more individual statements.

Each statement is a JSON object that defines a permission rule and may include an optional Sid (statement identifier) for labeling.[34][32] Key elements within each statement include:- Effect: Required; specifies "Allow" or "Deny" to indicate whether the statement grants or revokes access.[31] - Action: Required (unless NotAction is used instead); specifies one or more AWS service actions (such as "s3:GetObject") or "*" for all actions, using a string or array.[31][32] - Resource: Required in most cases (unless NotResource is used instead); identifies the AWS resources affected by the statement, typically using Amazon Resource Names (ARNs) such as "arn:aws:s3:::example-bucket/" or "" for all resources.[31][35] - Principal: Not allowed in identity-based policies; required in resource-based policies (such as bucket policies) and role trust policies; specifies the entity (such as an AWS account, IAM user, role, or federated user) to which the statement applies, using ARNs or a map.[31][36] - Condition: Optional; specifies circumstances under which the statement applies, using condition keys, operators, and values.[31][37] { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:DescribeInstances", "Resource": "*" } ] } A more complex example with multiple statements, including a condition: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": "arn:aws:s3:::my-bucket/*", "Condition": { "Bool": { "aws:SecureTransport": "true" } } }, { "Effect": "Deny", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::my-bucket/*" } ] } These structures enable precise control over permissions while adhering to IAM's policy language grammar.[32] Policy Evaluation AWS Identity and Access Management (IAM) evaluates policies to determine whether a request is allowed or denied by processing the request context and applying a structured logic across applicable policy types.

The request context includes the principal making the request, the action requested, the resource targeted, and additional factors such as the source IP address, time of request, and any conditions specified in policies.[38][39] All requests are implicitly denied by default unless explicitly allowed by at least one applicable policy.

An explicit deny statement in any applicable policy overrides any allow statements and results in denial of the request.[40][39] AWS first checks for explicit deny statements across all relevant policies, including identity-based policies (attached to users, groups, or roles), resource-based policies (attached to resources such as S3 buckets), permissions boundaries, session policies, andâwhen applicableâAWS Organizations service control policies (SCPs) or resource control policies (RCPs).

If an explicit deny matches the request context in any of these policies, the request is denied immediately, regardless of any allow statements elsewhere.[38][41][39] If no explicit deny is found, AWS evaluates allow statements. For requests within a single account, identity-based and resource-based policies combine such that an allow in either can grant access unless restricted by other mechanisms. Permissions boundaries and SCPs/RCPs apply an intersection logic, requiring the action to be allowed by all relevant types. Session policies further restrict temporary credentials when present.

A request is allowed only if at least one applicable policy explicitly permits it and no explicit deny exists; otherwise, it is denied.[38][41][39] Conditions in policies can further refine evaluation based on elements of the request context, as detailed in the Conditions and Tags section.[38]Access Control Models Role-Based Access Control (RBAC) AWS Identity and Access Management (IAM) implements role-based access control (RBAC) as its traditional authorization model, where permissions are defined based on a person's job function or role rather than on an individual basis.[42] In this model, administrators create policies tailored to specific job functions and attach them to IAM identities such as roles or groups, enabling permissions to be tied to roles or groups rather than directly to individual users.[42] IAM roles are a primary mechanism for RBAC, serving as identities with attached permission policies that define allowable actions and resources.[19] Trusted entities, such as users or services, assume these roles to obtain temporary credentials and the associated permissions, allowing centralized management of access without assigning long-term credentials to individuals.[19] IAM groups further support RBAC by enabling administrators to assign permissions to collections of users through attached policies, with all group members automatically inheriting those permissions.[18] This approach simplifies administration, as adding a user to a group grants the relevant access immediately, and changing a user's responsibilities can be handled by updating group membership rather than modifying individual permissions.[18] These mechanisms make RBAC central to IAM's design for scalable access management, as permissions can be delegated efficiently across users, workloads, and accounts while adhering to principles like least privilege.[42] While IAM also supports attribute-based access control (ABAC) as an alternative model, RBAC through roles and groups remains a foundational approach for many access control scenarios.[42]Attribute-Based Access Control (ABAC) Attribute-Based Access Control (ABAC) Attribute-based access control (ABAC) is an authorization strategy in AWS Identity and Access Management (IAM) that defines permissions based on attributes associated with users, resources, and request context.

In AWS, these attributes are implemented as tags, which are key-value pairs attached to IAM principals (such as users and roles) and AWS resources. Access decisions are made by evaluating whether the tags on a principal match those on a resource, enabling dynamic authorization without hardcoding specific resources or users in policies.[42][43] ABAC supports fine-grained permissions by tying access to attributes such as department, project, team, or cost center.

For example, a developer might be granted read and write access only to resources tagged with matching project or team attributes, ensuring isolation across teams while allowing automatic access to newly created matching resources. This tag-matching mechanism reduces the need for policy updates when adding users, roles, or resources, as permissions apply dynamically based on attribute alignment.[44][43] Compared to role-based access control (RBAC), which assigns permissions based on static job functions or predefined roles, ABAC provides greater flexibility and scalability in dynamic environments.

RBAC often requires creating separate policies or roles for each new resource or job variation, leading to policy sprawl. In contrast, ABAC uses a smaller set of policies that scale with organizational growth, as new resources or users inherit access through consistent tagging without policy modifications. This makes ABAC a powerful complement or alternative to RBAC, particularly for large-scale or rapidly changing workloads.[42][43] ABAC promotes least-privilege principles by enabling precise control over actions based on attribute values.

It integrates with external identity providers through session tags, allowing corporate directory attributes (such as employee department) to influence AWS permissions.

This approach simplifies management, supports granular isolation, and adapts efficiently to organizational changes while maintaining security.[43][42]Security Features Multi-Factor Authentication Multi-Factor Authentication (MFA) in AWS Identity and Access Management (IAM) adds an extra layer of security by requiring a second authentication factor beyond username and password when accessing AWS resources.[45] AWS IAM supports several MFA methods, including virtual authenticator applications that generate time-based one-time passwords (TOTP) using apps such as Google Authenticator or Microsoft Authenticator, hardware TOTP tokens that are physical devices generating six-digit codes, and phishing-resistant passkeys and security keys based on FIDO standards, which include device-bound security keys (such as YubiKey) and synced passkeys managed by providers like Apple, Google, or Microsoft.[45][46] Users can register up to eight MFA devices of any supported type per root user or IAM user for flexibility and redundancy.[45] MFA is mandatory for the AWS account root user across all account types, including standalone, management, and member accounts in AWS Organizations, with users required to register an MFA device within 35 days of their first sign-in attempt to the AWS Management Console if not already enabled.[12] AWS recommends enabling MFA for privileged IAM users to protect sensitive operations, though it remains optional for other IAM users.[46] MFA integrates directly with the AWS Management Console sign-in process, where users must provide their credentials and then authenticate via their MFA device or passkey to gain access.[45] For API interactions, IAM policies can enforce MFA requirements on specific actions, ensuring additional protection for programmatic access.[45] AWS prioritizes phishing-resistant options like passkeys and security keys for stronger security.[45]Temporary Security Credentials AWS Identity and Access Management (IAM) supports temporary security credentials as a secure alternative to long-term access keys, enabling short-lived access to AWS resources without distributing permanent credentials.

These credentials, issued by the AWS Security Token Service (STS), consist of an access key ID, secret access key, and session token, and expire automatically after a defined duration. This design reduces the risk of credential compromise, as there is no need to embed, distribute, or manually rotate long-term keys.

Temporary credentials align with security best practices by limiting the window of exposure and eliminating the requirement for explicit revocation in most cases, since they become invalid upon expiration.[20] Temporary security credentials are primarily obtained by assuming an IAM role through the AWS STS AssumeRole API operation, which returns a new set of credentials for the duration of the session.

This approach supports scenarios such as cross-account access or delegated permissions within an account, where a principal (such as an IAM user or application) temporarily adopts the permissions defined in the role. Other STS operations, such as GetSessionToken, provide temporary credentials directly to IAM users (often requiring multi-factor authentication), though role assumption via AssumeRole is the recommended method for most programmatic and delegated access to avoid long-term keys.

Role assumption is detailed in the Roles section.[47][48] The duration of temporary credentials requested via AssumeRole ranges from a minimum of 900 seconds (15 minutes) to a maximum of 43,200 seconds (12 hours), with the default being 3,600 seconds (1 hour). The actual maximum is governed by the role's configured maximum session duration setting, which can be adjusted between 1 and 12 hours.

Credentials remain valid until this duration elapses, after which AWS denies any API requests made with them.[48][47] For scenarios requiring immediate invalidation before natural expirationâsuch as when credentials are exposedâadministrators can revoke active sessions for assumed roles. This is achieved by attaching an inline policy to the role that denies access based on the aws:TokenIssueTime condition key, using a timestamp earlier than the revocation time. In the AWS Management Console, this can be done via the role's "Revoke sessions" tab, which automatically applies a deny policy namedAWSRevokeOlderSessions .

Alternatively, a custom policy can be attached using the AWS CLI or SDK. Revocation affects all sessions issued before the specified time, though it does not apply retroactively to sessions assumed afterward, and changes may take up to approximately 30 seconds to propagate due to eventual consistency.

This capability is limited to standard IAM roles and does not apply to service-linked roles or certain IAM Identity Center permission sets.[49] Conditions and Tags AWS Identity and Access Management (IAM) policies support a Condition element that specifies additional requirements for the policy to apply, enabling fine-grained access control by comparing values in the request context against those defined in the policy.[37] Condition operators match condition keys to request values and fall into categories such as string (e.g., StringEquals for case-sensitive exact matches, StringLike for wildcard matching with * and ?), numeric (e.g., NumericEquals, NumericLessThan), date (e.g., DateGreaterThan for time-based restrictions using ISO 8601 format), boolean (e.g., Bool), IP address (e.g., IpAddress for CIDR-based matching on aws:SourceIp), ARN (e.g., ArnLike), and binary (e.g., BinaryEquals).[50] Operators like IfExists modify others to evaluate as true if the key is absent, and Null checks for key absence.[50] AWS provides global condition context keys for use across services, including request-related keys (e.g., aws:SourceIp, aws:SecureTransport), principal-related keys (e.g., aws:PrincipalArn, aws:PrincipalTag/tag-key), time-related keys (e.g., aws:CurrentTime, aws:EpochTime), and resource-related keys (e.g., aws:ResourceTag/tag-key).[51] These keys support flexible restrictions, such as limiting access to specific IP ranges or times, or enforcing secure transport.[51] Tag-based conditions enable attribute-based access control (ABAC), an authorization strategy that defines permissions based on tags attached to principals, resources, or requests (see Access Control Models for details on ABAC).[42] IAM supports condition keys such as aws:ResourceTag/key-name to restrict actions based on resource tags, aws:PrincipalTag/key-name to evaluate tags on the principal (e.g., user or role), aws:RequestTag/key-name to control tags passed during resource creation or tagging actions, and aws:TagKeys to enforce allowed tag keys.[52] For example, policies can allow operations only on resources tagged with specific values matching the principal's tags, such as department or project identifiers.[52] Session tags are key-value pairs passed when assuming IAM roles or federating users through AWS Security Token Service (STS) operations like AssumeRole, AssumeRoleWithSAML, or AssumeRoleWithWebIdentity.[53] These tags appear in the request context as aws:PrincipalTag keys, enabling ABAC policies to enforce access based on federated user attributes (e.g., department or cost center) for the duration of the temporary session.[53] Up to 50 session tags can be passed, with limits on key (128 characters) and value (256 characters) lengths, and transitive tags can propagate through role chains when specified.[53]Best Practices Least Privilege Principle The principle of least privilege is a foundational security concept in AWS Identity and Access Management (IAM) that requires granting identitiesâsuch as users, roles, or servicesâonly the permissions necessary to perform their required tasks, and no additional permissions.[54][55] This approach minimizes the risk of unauthorized access or privilege escalation by limiting the potential impact of compromised credentials or misconfigurations.[56] AWS recommends applying least-privilege permissions consistently across all IAM policies to enhance security posture.[54] To implement least privilege, AWS advises starting with AWS managed policiesâpredefined policies maintained by AWS that cover common job functions or use casesâas an initial way to grant permissions.[57] These policies provide a convenient starting point but often grant broader access than necessary for specific workloads, as they are designed for general use across all AWS customers.[57] Once initial access is established, permissions should be refined toward true least privilege by creating customer-managed policies that include only the actions, resources, and conditions actually required.[54] Tools such as IAM Access Analyzer support this refinement by analyzing CloudTrail access activity to generate fine-grained policies and by providing last accessed information to identify and remove unused permissions.[55] A key technique for achieving fine-grained least-privilege controls is the use of conditions in IAM policies.

Conditions allow administrators to restrict when a permission is in effect, such as requiring multi-factor authentication (MFA), specific IP ranges, or other contextual attributes, thereby further limiting access even when broad actions or resources are specified.[54][27] This enables more precise enforcement of least privilege without overly broad policy statements.[54]Managed Policies and Refinement AWS provides AWS managed policies that cover common use cases and job functions, such as read-only access, power user access, and roles like database administrator or system administrator.

These standalone policies are created and maintained by AWS, enabling quick assignment of permissions to IAM users, groups, and roles without writing custom policies from scratch.[57][28] AWS updates them automatically to include new services and features, making them a convenient starting point for granting appropriate permissions.[28] AWS managed policies often grant broader permissions than required for specific tasks and do not inherently follow the principle of least privilege.[57] To achieve more precise access control, best practices recommend starting with these policies and then refining them into customer managed policies that grant only the necessary permissions.[54] Customer managed policies are standalone, created and fully managed in your AWS account, and can be attached to multiple identities for reusability.

A common refinement approach involves copying an AWS managed policy and customizing it to remove unnecessary actions, resources, or conditions.[28] This results in tailored policies that better align with specific organizational needs while supporting centralized management and updates.[58] For scalability, managed policies (both AWS and customer) are preferred over inline policies, which embed permissions directly into a single IAM identity and cannot be reused or updated centrally.

Inline policies create management challenges in larger environments due to duplication and lack of centralized control, making them less suitable when permissions apply to more than one entity.[58][28] Using managed policies enables efficient scaling through reusable, versioned definitions that apply consistently across users, groups, and roles.[58]Federation for Human Access AWS recommends requiring human users to use federation with an identity provider to access AWS resources instead of creating individual IAM users in each account.[23] This best practice applies to workforce identities such as administrators, developers, operators, and other personnel who interact with AWS through consoles, CLIs, or SDKs.

Federation enables these users to authenticate via an external identity provider and assume IAM roles, which deliver temporary security credentials rather than relying on long-term access keys.[54] By mandating federation for human access, organizations avoid the security risks associated with permanent IAM user credentials, such as prolonged exposure of static access keys that may lead to unauthorized use if compromised.[54] Temporary credentials obtained through role assumption have limited duration and are automatically rotated, aligning with security principles that favor short-lived access over persistent credentials.[23] Federation for human users commonly relies on SAML 2.0 or OpenID Connect (OIDC) protocols to establish trust between the identity provider and AWS.[23] AWS IAM Identity Center is recommended as a centralized solution for managing workforce federation across multiple accounts, providing single sign-on and streamlined permission assignment without the need for individual IAM users.[54] This approach supports centralized identity governance while ensuring that human access remains temporary and auditable.[59]Credential Management Credential management in AWS IAM focuses on practices that reduce the risk of compromised or unnecessary credentials, particularly by removing unused ones, rotating long-term access keys when required, and prioritizing temporary credentials over persistent keys.

A key practice is to regularly remove unused credentials, such as IAM user passwords and access keys that have not been accessed for an extended period. Administrators can use IAM's last accessed information to identify inactive credentials and safely delete them, thereby reducing the attack surface.

AWS Config provides a managed rule,iam-user-unused-credentials-check , that flags IAM users with credentials unused beyond a configurable period (default 90 days) as non-compliant, enabling automated or manual remediation through revocation or deletion.[54][60] When long-term credentials like IAM access keys must be used, AWS recommends rotating them periodically to limit exposure if compromised. Rotation involves creating a new key, updating dependent applications or systems to use it, verifying functionality, and then deleting the old key.

Best practices suggest a maximum rotation interval of 90 days for such keys, with regular auditing to ensure compliance.[61][62] AWS strongly recommends preferring temporary security credentialsâsuch as those provided by IAM rolesâover long-term access keys whenever possible, as temporary credentials expire automatically and minimize risks associated with persistent keys (detailed in the Temporary Security Credentials section).[62][54] Auditing and Tools IAM Access Analyzer IAM Access Analyzer is a feature of AWS Identity and Access Management (IAM) that uses automated reasoning to identify unintended access to AWS resources and provide actionable findings to refine permissions.

It supports external access analysis, unused access detection, and policy validation with recommendations, helping maintain the principle of least privilege across accounts and organizations.[63][64] External access analysis examines resource-based policies to detect when resourcesâsuch as Amazon S3 buckets, IAM roles, AWS KMS keys, or Lambda functionsâare shared with principals outside a defined zone of trust (an AWS account or organization).

Findings are generated for each instance of external access, detailing the resource, external principal, and permissions granted, allowing users to review whether the sharing is intended or represents a security risk.[63][65] External access analyzers are region-specific and provide a dashboard summary of public and cross-account access by resource type.[63] Unused access analysis continuously monitors IAM roles, users, access keys, passwords, and permissions to identify those that remain unused over a defined period, based on last accessed information.

Findings highlight unused roles, inactive credentials, and unexercised service or action-level permissions in identity-based policies, enabling remediation such as revoking unused credentials or refining policies to remove superfluous grants.[65][63] Unused access analyzers operate organization-wide or account-wide and are not region-specific.[63] Policy validation and recommendations allow IAM Access Analyzer to check policies against IAM grammar and AWS best practices, producing findings categorized as security warnings (for overly permissive access), errors (syntax issues preventing functionality), general warnings, and suggestions.[66] It also supports custom policy checks to validate against user-defined security standards and generates least-privilege policy templates based on actual access activity recorded in AWS CloudTrail logs.[63] These capabilities facilitate refining policies during creation or editing in the console, CLI, or API, with validation findings displayed in a dedicated pane for iterative improvement.[66] IAM Access Analyzer thus supports regular audits by delivering ongoing findings and recommendations to identify and remediate unintended access.[64]Access Advisor and Monitoring AWS IAM Access Advisor provides last accessed information for services and actions, enabling administrators to review access history and refine permissions in alignment with least privilege principles.[67] This feature tracks attempts by IAM identities (users, groups, roles) and policies to access AWS services and specific management actions, recording the timestamp of the last attempt.[67] Service last accessed data indicates the date and time when an entity last attempted to use a service, while action last accessed data details management actions (such as create, delete, modify) with regional and timestamp specifics for supported services, including Amazon S3 (tracking began April 12, 2020), Amazon EC2, IAM, and Lambda (tracking began April 7, 2021), and many other services (tracking began May 23, 2023).[67] Administrators can view last accessed information through the AWS Management Console (via the "Last Accessed" tab for relevant entities), AWS CLI commands (such asgenerate-service-last-accessed-details and get-service-last-accessed-details ), or AWS API operations (such as GenerateServiceLastAccessedDetails and GetServiceLastAccessedDetails ).[68] The data covers a retention period of at least 400 days for services (with varying start dates by service and region) and shows "Not accessed in the tracking period" when no usage occurred.[67] This visibility supports identifying unused permissions, though it excludes unauthenticated attempts, data plane events, the iam:PassRole action, and access allowed by certain policy types including resource-based policies, access control lists (ACLs), AWS Organizations service control policies (SCPs), IAM permissions boundaries, and session policies.[67] IAM credential reports offer a comprehensive overview of user credentials in an AWS account for auditing and monitoring purposes.[69] The report, generated in CSV format, includes details such as user creation time, password status and last used/changed dates, MFA active status, access key activation and last used dates/regions/services (limited to the first two keys per user), and X.509 signing certificate status.[69] Reports can be generated via the IAM console, AWS CLI (generate-credential-report followed by get-credential-report ), or AWS API, with a new report available every four hours.[69] AWS CloudTrail integrates with IAM to log all API calls to IAM and AWS Security Token Service (STS) operations, providing an audit trail for monitoring management activities.[70] Logged events capture details including the principal identity, event time, source IP, request parameters, response elements (redacted for read-only events except certain STS calls), MFA status, and session context for assumed roles.[70] This enables tracking of actions such as user creation, role assumption, policy changes, and console sign-ins (successful and failed), supporting security auditing and compliance verification.[70] CloudTrail provides detailed logs that can complement last accessed information and IAM Access Analyzer findings for investigating access attempts and detecting unused access.[67] Integration With Other AWS Services AWS Identity and Access Management (IAM) serves as a foundational security layer for AWS, providing the centralized authorization framework that determines whether principals can perform actions on resources across other AWS services.[71] Most AWS services integrate with IAM primarily through identity-based policies attached to users, groups, or roles, which define the permitted actions and resources.

Some services additionally support resource-based policies, attached directly to resources such as Amazon S3 buckets, to specify which principals can access those resources and under what conditions.[72][27][71] Resource-based policies complement identity-based policies during IAM's evaluation process: AWS checks for explicit Deny statements in either type first, then grants access if at least one policy allows the action.

This dual approach enables fine-grained control, such as bucket-level restrictions in Amazon S3 that apply regardless of the requesting identity's policies.[72] Many AWS services also use service-linked roles, a unique type of IAM role predefined by the service and linked directly to it.

These roles include all required permissions for the service to invoke other AWS APIs on behalf of the account owner, eliminating the need for manual permission configuration.[73] Service-linked roles are typically created automatically when needed by the service, though some allow manual creation through the IAM console, AWS CLI, or API.

The linked service controls the role's permissions and lifecycle, ensuring secure and consistent integration without exposing long-term credentials.[73] Through these mechanismsâidentity-based policies, resource-based policies, and service-linked rolesâIAM enforces consistent, least-privilege access controls across the AWS ecosystem, including support for cross-account scenarios when combined with appropriate permissions.[71][72]Cross-Account Access AWS Identity and Access Management (IAM) enables secure cross-account access, allowing principals in one AWS account to access resources in another without sharing long-term credentials.[74] The primary and recommended mechanism for cross-account access is delegation through IAM role assumption.

A role is created in the resource-owning account with a trust policy specifying which principals (such as IAM users or roles) from other accounts are permitted to assume it. The role also attaches permission policies defining the specific actions allowed on resources once assumed. Principals in the source account require an identity-based policy permittingsts:AssumeRole on the target role's ARN. Upon assumption via the AWS Security Token Service (STS), temporary credentials are issued, granting access strictly limited to the role's permissions for the session duration.

This approach aligns with security best practices by avoiding long-term credentials and supporting services that do not offer resource-based policies. Role trust policies, which define trusted entities, are detailed in the Roles section.[21][19][74] For resources that support resource-based policies (such as Amazon S3 buckets, Amazon SNS topics, and Amazon SQS queues), access can be granted by attaching a policy directly to the resource. This policy specifies principals from other accounts (such as an entire account root, specific IAM entities, or conditions) and the allowed actions.

Principals in the source account must have identity-based policies permitting the desired actions on the resource ARN. Access is granted only if both the resource-based policy and identity-based policy explicitly allow it; a denial in either results in rejection.[74] In environments using AWS Organizations, cross-account delegation extends to organization-wide scenarios. Resource-based policies can grant access to all principals within the organization by specifying a wildcard principal (* ) combined with the aws:PrincipalOrgID condition key to restrict access to principals matching the organization's ID.

This enables controlled sharing across multiple accounts managed under the same organization.[75] Additionally, the management account can delegate administrative access to member accounts via the OrganizationAccountAccessRole . This IAM role is automatically created in accounts added directly by the organization (or manually in invited accounts) and trusts assumption from the management account. It attaches the AdministratorAccess managed policy, allowing management account principals (with appropriate sts:AssumeRole permissions) to gain administrative control over member accounts.[76]

People Also Asked

• AWS Identity and Access Management

AWS Identity and Access Management?

AWS Identity and Access Management Overview Introduction AWS Identity and Access Management (IAM) is a web service provided by Amazon Web Services that enables secure control of access to AWS resources.[1] IAM provides the infrastructure to manage authentication and authorization for AWS accounts, allowing administrators to define who can perform which actions on specific resources.[3] It supports...