AWS Identity and Access Management (IAM)

Preparation for the AWS certification consumes lots of time and effort. I decided to help myself with future re-certification and create articles describing the most important facts about AWS services required to pass the certification. This article provides the most important information about the AWS Identity and Access Management (AWS IAM) terminology, users, groups, roles, and policies.

What is AWS IAM?

AWS IAM is a web service that helps you to manage access users’ access to the AWS account and securely control access to AWS resources. IAM is a global AWS service, and its resources are available in all AWS Regions in your AWS account. With IAM, you can create and manage users and groups for your AWS account and use permissions (policies) to allow and deny their access to AWS resources. IAM is a free service that is integrated with other AWS services, and it does not incur any additional charges.

You can use IAM to create as many users and groups as you need, and you can give each user or group the permissions they need to access the AWS resources they need. You can also control which users have access to which AWS resources and what actions they can perform on those resources. Additionally, IAM provides features that let you password-protect your account, recover lost or forgotten passwords, and enforce strong password policies.

How AWS IAM works?

The IAM introduction needs to start with the basic terminology.

Basic terms

When working with IAM, you need to understand its terminology:

• IAM Resource is the user, group, role, policy, and identity provider objects stored in IAM
• IAM Identities are groups of IAM Resources, for example, users, groups, and roles.
• IAM Entities are objects that AWS uses for authentication, for example, users or roles.
• IAM Principals are people or applications that use the AWS account root user, an IAM user, or an IAM role to sign in and make requests to AWS. Principals include federated users and assumed roles.
• IAM Actions are AWS APIs used by the user through AWS Management Console, AWS CLI, or direct API call by AWS SDK.

Authentication

Principals must be authenticated (or signed in to AWS) using their credentials to send API requests to AWS. An anonymous or unauthenticated user is an exception allowed in STS, Cognito, and S3 services. IAM service authenticates principals and entities in the AWS cloud.

Authorization

Principals must be authorized (or have permission) to make API calls to access AWS resources. AWS Web Console uses the same APIs under the hood as AWS CLI tools or any AWS SDK. IAM service authorizes principals and Entities to make Actions (API calls) to the AWS cloud services.

IAM Workflow

Here’s an IAM workflow describing how the IAM service authorizes Principals to make API requests to the AWS cloud:

IAM Users

Root account user

The first IAM user available in your AWS account is a root account user (or root user). This is a special user in the account, which should not be used regularly, and root user credentials should never be shared with other AWS accounts or users.

Regular users

You can create and store users in the IAM service for people in your organization or on-premises applications that run outside your AWS infrastructure but need to interact with AWS.

Federated users

If users in your organization are already authenticated, for example, in Active Directory, you don’t have to create separate AWS IAM users and can federate those user identities into Amazon Web Services account.

AWS Federation workflow:

1. A user authenticates within the corporate Active Directory and requests the SAML token.
2. The user exchanges the SAML token for temporary security credentials using the AWS Security Token Service (AWS STS) AssumeRoleWithSAML API call.
3. The user uses temporary credentials to interact with the AWS cloud (AWS console, AWS CLI tools, APIs).

IAM Groups

You can use an IAM Group to assign permissions to a set of users and manage AWS users.

Additional information about Groups:

• Groups can contain multiple users but can’t contain other Groups or Roles.
• A user does not have to belong to any IAM Group.
• A User can belong to multiple Groups.

Note: it is not an AWS IAM security best practice to manage individual users separately.

IAM Policies (Permissions)

An IAM User, Group, or Role can be assigned a JSON document called IAM Policy, for example:

{
  "Version": "2012-10-17",
  "Id": "MyPolicy",
  "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:::confidential-data",
        "arn:aws:s3:::confidential-data/*"
      ],
      "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    }
  ]
}

The IAM Policy defines permissions allowing Users, Groups of Users, or Roles associated with this Policy to make specific API calls.

In our example, we’re allowing:

• iam:ChangePassword – Password changes.
• s3:ListAllMyBuckets – Query a list of S3 Buckets.
• s3:List* and s3:Get* – listing and downloading objects from the S3 bucket named confidential-data only if the user was authenticated with MFA.

Note: All API requests are denied by default for all Users, Groups, or Roles.

Note: we apply the least privilege principle by not giving IAM principals more permissions than they need. It is an AWS best practice to use granular permissions wherever possible.

IAM policy types

There are three policy types available for you in AWS:

• Managed policy – a policy managed by AWS to simplify common scenarios of managing AWS cloud
• Customer-managed policy – any policy that the user in the AWS account defines
• Inline policy – the policy that is embedded into an IAM identity (a user, group, or role)

IAM Policy Structure

Every IAM Policy consists of:

• Version – A required policy syntax version, usually “2012-10-17“
• Id – an optional identifier of the policy. In our example above, “MyPolicy“
• Statement – a required list of one or more policy statements

Every policy statement consists of the following:

• Sid – An optional identifier of the statement, for example, “FirstStatement“
• Effect – a required effect of the policy (“Allow” or “Deny“) that defines if the policy statement allows or denies specific API calls listed in the statement
• Principal – an IAM principal ARN (user, role, or account) to which the policy is applied. For example, "Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" }
• Action – a required list of API calls (actions) allowed or denied by the policy statement
• Resource – a required list of AWS resources’ ARNs to which the policy action is applied to
• Condition – an optional condition for the statement to be in effect

Note: IAM policies deny access to any AWS API calls that are not explicitly allowed by policy statements, so you have to grant precise access to any AWS service the IAM Role suppose to use by listing its API calls in the Action section of the statement.

Password policy

You can apply several actions to prevent brute-force attacks on your AWS user accounts. One of them is to specify a password policy for your users. The password policy configuration might include the following requirements:

• Minimum password length
• Use specific characters (uppercase, lowercase, numbers, or special characters)
• Allow account users to change their passwords
• Password expectation – users have to change their password periodically
• Password re-use – disallow users to re-use their passwords

IAM Roles

An IAM Role is an IAM identity you can create in your account and provide specific permissions to Users, Federated Users, other Roles, or AWS services. A Role is similar to an IAM User with assigned permission Policies. But instead of being assigned to a specific User, IAM Roles are intended to be assumable by anyone who needs them (usually, AWS services or Federated Users) by providing temporary credentials for a short time.

Each IAM Role has two policies:

• Trust policy – A JSON document defines trusted principals who can assume the role.
• Permissions policy – A JSON document defines the actions and resources the Role can use.

Optionally, the IAM Role might have a Permissions boundary – an advanced security feature that limits permissions that an identity-based policy can grant to a role.

IAM Role types

• AWS Service role – A role that can be assumed by AWS service to perform actions in your account on your behalf.
• EC2 instance profile role (AWS service role for an EC2 instance) – a special type of AWS Service role that an application running on an Amazon EC2 instance can assume to perform actions in your account.
• AWS service-linked role – a unique predefined service role linked directly to an AWS service. This role includes all required permissions to start using the service and might be created in your AWS account automatically.

Multi-Factor Authentication (MFA)

It is a best practice to enable MFA for your root and users’ accounts. If the AWS user password is stolen, MFA will still protect the user account.

You can use the following MFA devices:

• Universal 2nd Factor (U2F) Security Key (for example, FIDO U2F Security Key)
• Hardware Key FOB MFA device (for example, Symantec VIP Hardware Authenticator)
• Software (virtual) MFA token generator (1Password, Authy, Google Authenticator)

IAM Security Tools

AWS provides you with several important security tools for validating IAM security:

• IAM credentials report – generate and download a credential report that lists all users in your account and the status of their various credentials, including passwords, access keys, and MFA devices on the account level
• IAM Access Advisor allows you to check users’ permissions to different services and the time when these permissions were used (user level)

IAM Best Practices

Let’s summarize some IAM best practices:

• Don’t use your AWS account root user except for account setup, decommission, and special operations, e.g., delete a deny-all blocking policy for the S3 bucket.
• Never share AWS user credentials and access keys (one user = one IAM AWS user)
• Avoid assigning policies directly to users; assign users to AWS Groups and permissions to AWS Groups instead.
• Configure a strong password policy in your account
• Enable and enforce MFA for all users’ accounts
• Automate IAM Credentials report generation to audit users’ permissions

Free hands-on AWS workshops

For gaining hands-on experience with Amazon IAM, we strongly suggest you check out IAM AWS workshops:

• How and when to use different IAM policy types
• IAM policy evaluation workshop
• Integrating IAM Access Analyzer into a CI/CD Pipeline
• IAM Identity Center – Workforce Identity management at scale