AWS Identity and Access Management

TL;DR

Core Concepts

• AWS Identity and Access Management (IAM) is a service for managing access to AWS accounts and resources, providing centralized control over authentication and authorization
• Authentication verifies user identity, while authorization determines what actions users can perform

IAM Components

• IAM users represent individuals or services interacting with AWS, with credentials for console or programmatic access
• IAM groups simplify permission management by allowing you to assign permissions to multiple users at once
• IAM roles provide temporary permissions to trusted entities without the need for permanent credentials

Security Best Practices

• Follow the principle of least privilege by granting only necessary permissions
• Secure the root user account by not sharing credentials, deleting access keys, and enabling multi-factor authentication (MFA)
• Use IAM roles when possible for more efficient credential management compared to long-term user credentials
• Regularly review and remove unused users, roles, and credentials to maintain security

I. Authentication and authorization

When you configure access to any account, two terms come up frequently: authentication and authorization. Although these terms might seem basic, you must fully understand them to properly configure access management on AWS.

Authentication

Authentication ensures that the user is who they say they are. User names and passwords are the most common types of authentication. But you might also work with other forms, such as token-based authentication or biometric data, like a fingerprint.

Authentication simply answers the question, “Are you who you say you are?”

Authorization

After you’re authenticated and in your AWS account, you might be curious about what actions you can take. This is where authorization comes in. Authorization is the process of giving users permission to access AWS resources and services. Authorization determines whether a user can perform certain actions, such as read, edit, delete, or create resources.

Authorization answers the question, “What actions can you perform?”

II. What is IAM?

AWS Identity and Access Management (IAM) is an AWS service that helps you manage access to your AWS account and resources.

It also provides a centralized view of who and what are allowed inside your AWS account (authentication), and who and what have permissions to use and work with your AWS resources (authorization).

With IAM, you can share access to an AWS account and resources without sharing your set of access keys or password. You can also provide granular access to those working in your account, so people and services only have permissions to the resources that they need.

For example, to provide a user of your AWS account with read-only access to a particular AWS service, you can granularly select which actions and which resources in that service that they can access.

III. IAM features

To help control access and manage identities in your AWS account, IAM offers many features to ensure security.

To learn more, expand each of the following six categories.

Global

IAM is global and not specific to any one Region. You can see and use your IAM configurations from any Region in the AWS Management Console.

Integrated with AWS services

IAM is integrated with many AWS services by default.

Shared access

You can grant other identities permission to administer and use resources in your AWS account without having to share your password and key.

Multi-factor authentication

IAM supports MFA. You can add MFA to your account and to individual users for extra security.

Identity federation

IAM supports identity federation, which allows users with passwords elsewhere—like your corporate network or internet identity provider—to get temporary access to your AWS account.

Free to use

Any AWS customer can use IAM; the service is offered at no additional charge.

IV. AWS Root User

When you first access AWS, you begin with a single sign-in identity known as the root user.

This root user has unrestricted access to everything in your account in most cases.

AWS root user credentials

The AWS root user has two sets of credentials associated with it:

• One set of credentials is the email address and password that were used to create the account. This allows you to access the AWS Management Console.
• The second set of credentials is called access keys, which allow you to make programmatic requests from the AWS Command Line Interface (AWS CLI) or AWS API.

Access keys consist of two parts:

• Access key ID: for example, A2lAl5EXAMPLE
• Secret access key: for example, wJalrFE/KbEKxE

Similar to a user name and password combination, you need both the access key ID and secret access key to authenticate your requests through the AWS CLI or AWS API. Access keys should be managed with the same security as an email address and password.

AWS root user best practices

• Choose a strong password for the root user.
• Enable multi-factor authentication (MFA) for the root user.
• Never share your root user password or access keys with anyone.
• Disable or delete the access keys associated with the root user.
• Create an Identity and Access Management (IAM) user for administrative tasks or everyday tasks.

Supported MFA devices

V. IAM user

An IAM user represents a person or service that interacts with AWS. You define the user in your AWS account.

Any activity done by that user is billed to your account. When you create a user, that user can sign in to gain access to the AWS resources inside your account.

IAM user credentials

You can have up to 5000 users per AWS account. You should create individual IAM accounts for users (best practice not to share accounts).

Each user account has a friendly name and an ARN which uniquely identifies the user across AWS. A unique ID is also created which is returned only when you create the user using the API, Tools for Windows PowerShell, or the AWS CLI.

By default, users cannot access anything in your account. When you create an IAM user, you can grant permissions directly at the user level. This can seem like a good idea if you have only one or a few users. However, as the number of users increases, keeping up with permissions can become more complicated.

An IAM user consists of a name and a set of credentials. When you create a user, you can provide them with the following types of access:

• Access to the AWS Management Console with a user name and password
• Programmatic access to the AWS CLI and AWS API with a set of access keys (must be regenerated if lost)

A password policy can be defined for enforcing password length, complexity etc. (applies to all users). You can allow or disallow the ability to change passwords using an IAM policy. Access keys and passwords should be changed regularly.

IAM users can be created to represent applications, and these are known as “service accounts”.

VI. IAM groups

An IAM group is a collection of users. All users in the group inherit the permissions assigned to the group. This makes it possible to give permissions to multiple users at once. It’s a more convenient and scalable way of managing permissions for users in your AWS account. This is why using IAM groups is a best practice.

This provides a way to see who has what permissions in your organization. It also helps you scale when new people join, leave, and change roles in your organization.

Keep in mind the following features of groups:

• Groups can have many users.
• Users can belong to many groups.
• Groups cannot belong to groups.
• IAM Group is NOT truly an identity because it cannot be identified as a Principal in a resource-based or trust policy. It is only a way to attach policies to multiple users at one time.

Use the principle of least privilege when assigning permissions.

VII. IAM policies

To manage access and provide permissions to AWS services and resources, you create IAM policies and attach them to an IAM identity. Whenever an IAM identity makes a request, AWS evaluates the policies associated with them.

IAM policy examples

Most policies are stored in AWS as JSON documents with several policy elements. The most restrictive policy is applied.

The following examples provides admin access through an IAM identity-based policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "FirstStatement",
      "Effect": "Allow",
      "Action": ["iam:ChangePassword"],
      "Resource": "*"
    },
    {
      "Sid": "SecondStatement",
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*"
    },
    {
      "Sid": "ThirdStatement",
      "Effect": "Allow",
      "Action": [
        "s3:List*",
        "s3:Get*"
      ],
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket-confidential-data",
        "arn:aws:s3:::amzn-s3-demo-bucket-confidential-data/*"
      ],
      "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    }
  ]
}

JSON policy document structure

As illustrated in the following figure, a JSON policy document includes these elements:

• Optional policy-wide information at the top of the document
• One or more individual statements

Each statement includes information about a single permission. If a policy includes multiple statements, AWS applies a logical OR across the statements when evaluating them. If multiple policies apply to a request, AWS applies a logical OR across all of those policies when evaluating them.

The information in a statement is contained within a series of elements.

• Version – Specify the version of the policy language that you want to use. We recommend that you use the latest 2012-10-17 version. For more information, see IAM JSON policy elements: Version
• Statement – Use this main policy element as a container for the following elements. You can include more than one statement in a policy.
  • Sid (Optional) – Include an optional statement ID to differentiate between your statements.
  • Effect – Use Allow or Deny to indicate whether the policy allows or denies access.
  • Principal (Required in only some circumstances) – If you create a resource-based policy, you must indicate the account, user, role, or federated user to which you would like to allow or deny access. If you are creating an IAM permissions policy to attach to a user or role, you cannot include this element. The principal is implied as that user or role.
  • Action – Include a list of actions that the policy allows or denies.
  • Resource (Required in only some circumstances) – If you create an IAM permissions policy, you must specify a list of resources to which the actions apply. If you create a resource-based policy, this element is optional. If you do not include this element, then the resource to which the action applies is the resource to which the policy is attached.
  • Condition (Optional) – Specify the circumstances under which the policy grants permission.

Policy Types

The following policy types, listed in order from most frequently used to less frequently used, are available for use in AWS. For more details, see the sections below for each policy type.

• Identity-based policies – Attach managed and inline policies to IAM identities (users, groups to which users belong, or roles). Identity-based policies grant permissions to an identity.
• Resource-based policies – Attach inline policies to resources. The most common examples of resource-based policies are Amazon S3 bucket policies and IAM role trust policies. Resource-based policies grant permissions to the principal that is specified in the policy. Principals can be in the same account as the resource or in other accounts.
• Permissions boundaries – Use a managed policy as the permissions boundary for an IAM entity (user or role). That policy defines the maximum permissions that the identity-based policies can grant to an entity, but does not grant permissions. Permissions boundaries do not define the maximum permissions that a resource-based policy can grant to an entity.
• Organizations SCPs – Use an AWS Organizations service control policy (SCP) to define the maximum permissions for account members of an organization or organizational unit (OU). SCPs limit permissions that identity-based policies or resource-based policies grant to entities (users or roles) within the account, but do not grant permissions.
• Access control lists (ACLs) – Use ACLs to control which principals in other accounts can access the resource to which the ACL is attached. ACLs are similar to resource-based policies, although they are the only policy type that does not use the JSON policy document structure. ACLs are cross-account permissions policies that grant permissions to the specified principal. ACLs cannot grant permissions to entities within the same account.
• Session policies – Pass advanced session policies when you use the AWS CLI or AWS API to assume a role or a federated user. Session policies limit the permissions that the role or user's identity-based policies grant to the session. Session policies limit permissions for a created session, but do not grant permissions. For more information, see Session Policies.

Grant least privilege

When you create IAM policies, follow the standard security advice of granting least privilege, or granting only the permissions required to perform a task. Determine what users and roles need to do and then craft policies that allow them to perform only those tasks.

As an alternative to least privilege, you can use AWS managed policies or policies with wildcard * permissions to get started with policies.

IAM provides several options to help you refine the permissions that you grant.

• Understand access level groupings – You can use access level groupings to understand the level of access that a policy grants. Policy actions are classified as List, Read, Write, Permissions management, or Tagging. To learn how to use policy summaries to understand access level permissions, see Access levels in policy summaries.
• Validate your policies – IAM Access Analyzer provides over 100 policy checks to validate your policies. To learn more about policy checks provided by IAM Access Analyzer, see IAM Access Analyzer policy validation.
• Generate a policy based on access activity – IAM Access Analyzer reviews your AWS CloudTrail logs and generates a policy template that contains the permissions that have been used by the entity in your specified time frame. You can use the template to create a managed policy with fine-grained permissions and then attach it to the IAM entity.To learn more, see IAM Access Analyzer policy generation.
• Use last accessed information – For more information, see Refine permissions in AWS using last accessed information.
• Review account events in AWS CloudTrail – To further reduce permissions, you can view your account's events in AWS CloudTrail Event history. CloudTrail event logs include detailed event information that you can use to reduce the policy's permissions. The logs include only the actions and resources that your IAM entities need. For more information, see Viewing CloudTrail Events in the CloudTrail Console in the AWS CloudTrail User Guide.

VIII. IAM roles

An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.

You can use roles to delegate access to users, applications, or services that don't normally have access to your AWS resources.

Some example:

• Grant users in your AWS account access to resources they don't usually have, or grant users in one AWS account access to resources in another account.
• Allow a mobile app to use AWS resources, but not want to embed AWS keys within the app (where they can be difficult to update and where users can potentially extract them)
• Give AWS access to users who already have identities defined outside of AWS, such as in your corporate directory.
• Grant access to your account to third parties so that they can perform an audit on your resources.

We recommend you only use IAM users for use cases not supported by federated users. Some of the use cases include the following:

• Workloads that cannot use IAM roles – You might run a workload from a location that needs to access AWS. In some situations, you can't use IAM roles to provide temporary credentials, such as for WordPress plugins. In these situations, use IAM user long-term access keys for that workload to authenticate to AWS.
• Third-party AWS clients – If you are using tools that don’t support access with IAM Identity Center, such as third-party AWS clients or vendors that aren't hosted on AWS, use IAM user long-term access keys.
• AWS CodeCommit access – If you are using CodeCommit to store your code, you can use an IAM user with either SSH keys or service-specific credentials for CodeCommit to authenticate to your repositories.
• Amazon Keyspaces (for Apache Cassandra) access – In a situation where you are unable to use users in IAM Identity Center, such as for testing purposes for Cassandra compatibility, you can use an IAM user with service-specific credentials to authenticate with Amazon Keyspaces.
• Emergency access – In a situation where you can't access your identity provider and you must take action in your AWS account. Establishing emergency access IAM users can be part of your resiliency plan. We recommend that the emergency user credentials be tightly controlled and secured using multi-factor authentication (MFA).

Roles terms and concepts

Here are some basic terms to help you get started with roles.

• Role

Defined above
Roles can be assumed by the following:
• An IAM user in the same AWS account or another AWS account
• IAM roles in the same account
• Service principals, for use with AWS services and features like:
◦ Services that allow you to run code on compute services, like Amazon EC2 or AWS Lambda
◦ Features that perform actions to your resources on your behalf, like Amazon S3 object replication
◦ Services that deliver temporary security credentials to your applications that run outside of AWS, such as IAM Roles Anywhere or Amazon ECS Anywhere
• An external user authenticated by an external identity provider (IdP) service that is compatible with SAML 2.0 or OpenID Connect

• AWS service role

A service role is an IAM role that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see Creating a role to delegate permissions to an AWS service in the IAM User Guide.

• AWS service-linked role

A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles.

• Role chaining

Role chaining is when you use a role to assume a second role through the AWS CLI or API. For example, RoleA has permission to assume RoleB. You can enable User1 to assume RoleA by using their long-term user credentials in the AssumeRole API operation. This returns RoleA short-term credentials. With role chaining, you can use RoleA's short-term credentials to enable User1 to assume RoleB.

• Delegation

The granting of permissions to someone to allow access to resources that you control. Delegation involves setting up a trust between two accounts. The first is the account that owns the resource (the trusting account). The second is the account that contains the users that need to access the resource (the trusted account). The trusted and trusting accounts can be any of the following:
• The same account.
• Separate accounts that are both under your organization's control.
• Two accounts owned by different organizations.
To delegate permission to access a resource, you create an IAM role in the trusting account that has two policies attached. The permissions policy grants the user of the role the needed permissions to carry out the intended tasks on the resource. The trust policy specifies which trusted account members are allowed to assume the role.
When you create a trust policy, you cannot specify a wildcard (*) as part of and ARN in the principal element. The trust policy is attached to the role in the trusting account, and is one-half of the permissions. The other half is a permissions policy attached to the user in the trusted account that allows that user to switch to, or assume the role. A user who assumes a role temporarily gives up his or her own permissions and instead takes on the permissions of the role. When the user exits, or stops using the role, the original user permissions are restored. An additional parameter called external ID helps ensure secure use of roles between accounts that are not controlled by the same organization.

• Trust policy

A JSON policy document in which you define the principals that you trust to assume the role. A role trust policy is a required resource-based policy that is attached to a role in IAM. The principals that you can specify in the trust policy include users, roles, accounts, and services.

• Role for cross-account access

A role that grants access to resources in one account to a trusted principal in a different account. Roles are the primary way to grant cross-account access. However, some AWS services allow you to attach a policy directly to a resource (instead of using a role as a proxy). These are called resource-based policies, and you can use them to grant principals in another AWS account access to the resource. Some of these resources include Amazon Simple Storage Service (S3) buckets, S3 Glacier vaults, Amazon Simple Notification Service (SNS) topics, and Amazon Simple Queue Service (SQS) queues. To learn which services support resource-based policies, see AWS services that work with IAM. For more information about resource-based policies, see Cross account resource access in IAM.

Additional resources

The following resources can help you learn more about IAM terminology related to IAM roles.

• Principals are entities in AWS that can perform actions and access resources. A principal can be an AWS account root user, an IAM user, or a role. A principal that represents the identity of an AWS service is a service principal. Use the Principal element in role trust policies to define the principals that you trust to assume the role.

  For more information and examples of principals you can allow to assume a role, see AWS JSON policy elements: Principal.

• Identity federation creates a trust relationship between an external identity provider and AWS. You can use your existing OpenID Connect (OIDC) or Security Assertion Markup Language (SAML) 2.0 provider to manage who can access AWS resources. When you use OIDC and SAML 2.0 to configure a trust relationship between these external identity providers and AWS , the user is assigned to an IAM role. The user also receives temporary credentials that allow the user to access your AWS resources.

  For more information about federated users, see Identity providers and federation.

• Federated users are existing identities from AWS Directory Service, your enterprise user directory, or an OIDC provider. These are known as federated users. AWS assigns a role to a federated user when access is requested through an identity provider.

  For more information about federated users, see Federated users and roles.

• Permissions policies are identity-based policies that define what actions and resources the role can use. The document is written according to the rules of the IAM policy language.

  For more information, see IAM JSON policy reference.

• Permissions boundaries are an advanced feature in which you use policies to limit the maximum permissions that an identity-based policy can grant to a role. You cannot apply a permissions boundary to a service-linked role.

  For more information, see Permissions boundaries for IAM entities.

IX. AWS Security Token Service (AWS STS)

The AWS STS is a web service that enables you to request temporary, limited-privilege credentials for IAM users or for users that you authenticate (federated users).

Temporary security credentials work almost identically to long-term access key credentials that IAM users can use, with the following differences:

• Temporary security credentials are short-term.
• They can be configured to last anywhere from a few minutes to several hours.
• After the credentials expire, AWS no longer recognizes them or allows any kind of access to API requests made with them.
• Temporary security credentials are not stored with the user but are generated dynamically and provided to the user when requested.
• When (or even before) the temporary security credentials expire, the user can request new credentials, if the user requesting them still has permission to do so.

Advantages of STS are:

• You do not have to distribute or embed long-term AWS security credentials with an application.
• You can provide access to your AWS resources to users without having to define an AWS identity for them (temporary security credentials are the basis for IAM Roles and ID Federation).
• The temporary security credentials have a limited lifetime, so you do not have to rotate them or explicitly revoke them when they’re no longer needed.
• After temporary security credentials expire, they cannot be reused (you can specify how long the credentials are valid for, up to a maximum limit)

Users can come from three sources.

1. Federation (typically AD):
2. Uses SAML 2.0.
3. Grants temporary access based on the users AD credentials.
4. Does not need to be a user in IAM.
5. Single sign-on allows users to login to the AWS console without assigning IAM credentials.
6. Federation with Mobile Apps:
7. Use Facebook/Amazon/Google or other OpenID providers to login.
8. Cross Account Access:
9. Allows users from one AWS account access resources in another.
10. To make a request in a different account the resource in that account must have an attached resource-based policy with the permissions you need.
11. Or you must assume a role (identity-based policy) within that account with the permissions you need.

X. IAM best practices

Lock down the AWS root user

The root user is an all-powerful and all-knowing identity in your AWS account. If a malicious user were to gain control of root-user credentials, they would be able to access every resource in your account, including personal and billing information. To lock down the root user, you can do the following:

• Don’t share the credentials associated with the root user.
• Consider deleting the root user access keys.
• Activate MFA on the root account.

Follow the principle of least privilege

Least privilege is a standard security principle that advises you to grant only the necessary permissions to do a particular job and nothing more. To implement least privilege for access control, start with the minimum set of permissions in an IAM policy and then grant additional permissions as necessary for a user, group, or role.

Use IAM appropriately

IAM is used to secure access to your AWS account and resources. It provides a way to create and manage users, groups, and roles to access resources in a single AWS account. IAM is not used for website authentication and authorization, such as providing users of a website with sign-in and sign-up functionality. IAM also does not support security controls for protecting operating systems and networks.

Use IAM roles when possible

Maintaining roles is more efficient than maintaining users. When you assume a role, IAM dynamically provides temporary credentials that expire after a defined period of time, between 15 minutes and 36 hours. Users, on the other hand, have long-term credentials in the form of user name and password combinations or a set of access keys.

User access keys only expire when you or the account admin rotates the keys. User login credentials expire if you applied a password policy to your account that forces users to rotate their passwords.

Consider using an identity provider

If you decide to make your cat photo application into a business and begin to have more than a handful of people working on it, consider managing employee identity information through an identity provider (IdP). Using an IdP, whether it's with an AWS service such as AWS IAM Identity Center (successor to AWS Single Sign-On) or a third-party identity provider, provides a single source of truth for all identities in your organization.

You no longer have to create separate IAM users in AWS. You can instead use IAM roles to provide permissions to identities that are federated from your IdP. Being federated is a process that allows for the transfer of identity and authentication information across a set of networked systems.

For example, your employee Martha has access to multiple AWS accounts. Instead of creating and managing multiple IAM users named Martha in each of those AWS accounts, you could manage Martha in your company’s IdP. If Martha moves in the company or leaves the company, Martha can be updated in the IdP rather than in every AWS account in the company.

Regularly review and remove unused users, roles, and other credentials

You might have IAM users, roles, permissions, policies, or credentials that you are no longer using in your account. IAM provides last accessed information to help you identify irrelevant credentials that you no longer need so that you can remove them. This helps you reduce the number of users, roles, permissions, policies, and credentials that you have to monitor.

Thank you, reader, for taking the time to explore this comprehensive guide on AWS Identity and Access Management. I hope this information has been valuable in enhancing your understanding of IAM best practices and security principles.