Everything You Need To Get Started With AWS IAM

What is IAM on AWS?

Identity and access management is one of AWS's most essential services. IAM lays the foundation for solid identity management, allowing granular access to entities within AWS.

IAM within AWS splits into two main components:

1. Identities - Takes care of identifying a user within an AWS account. It is essential to understand that AWS requires a unique value for each account, represented by a 12-digit account ID or a unique account alias. Within each AWS account, administrators are only allowed to create 5000 users per AWS account, and each username must be distinctive from one another.
2. Access Management - Assigns and manages access to the level of access granted to a specific resource within AWS.

IAM Features

AWS IAM provides various features that allow administrators to manage users and access the AWS account.

There are some key IAM components that every administrator must be familiar with:

1. Users - Individual users created within an AWS account
2. User Groups - A collection of IAM users; used to specify permissions to a collection of IAM users
3. Roles - A short-lived credential with specific permissions that entities can assume to gain access
4. Policies - Object that defined specific permissions within AWS
5. Identity Providers - Enables administrators to use SAML 2.0 or OpenID connect to integrate a third-party directory service.

Creating and Managing Users on AWS IAM

One of the first steps when configuring an AWS account is to create users within IAM that can be accessed instead of the default root account.

An administrator may specify a unique user name for each user created; however, it is essential to remember the user name contains a 64-character limit.

Next, the administrator must specify the access type for the method of access for each IAM user:

1. Access Key - Grants programmatic access to the user via AWS API, CLI, SDK, etc.
2. Password - Grants AWS management console access to the user

Once the required access is selected, the following steps require the necessary permissions for the user. There are multiple methods for granting access to a user, such as adding a user to an existing user group, copying permissions from a current user or attaching a policy directly. However, it is best practice to grant users access by adding them to a user group since it is easily scaled and managed.

Additionally, administrators may specify permission boundaries to restrict the maximum user permissions allowed for a specific user; this prevents unnecessary and overly permissive policies from being granted to a user.

After completing this step, the administrator may choose to assign tags. These tags can help further organize, track and control access.

After completing these steps, the administrator may decide to create the user by reviewing the defined parameters and confirming the action.

Managing Access with IAM User Groups & Roles

One of the best practices used to manage access within IAM is by using user groups and roles. User groups enable administrators to easily control access at scale without manually assigning multiple permissions to a single user.

AWS user groups are a collection of IAM users that require specific access, such as Full access to an S3 bucket. In this instance, the administrator may assign the required policy to the user group and add the users to the user group to gain Full access to the S3 bucket.

However, user groups have default limitations; therefore, it is crucial that administrators plan accordingly and do not exceed these limits:

1. Maximum of 300 groups per AWS account
   • To increase this limit, you'll need to contact AWS support
2. A user can only be associated with ten user groups
3. Each user group may only contain ten different policies attached at once

Unlike permissions granted via policies and user groups, IAM roles are issues temporarily. It allows users to assume temporary roles to perform a specific task they would not have been granted access to within their user groups; they can also grant access to users to access services from a different AWS account.

Considering the functionality of the IAM roles, the following entities may use this function:

1. User in the AWS account
2. User in a different AWS account
3. AWS service
4. Externally federated AWS user account

Managing Permissions using IAM Policies

Policies are the foundation of enabling access within AWS IAM and will be used to grant and even limit the maximum access for a specific entity.

There are four policy categories used within AWS IAM:

1. Identity-based policies
2. Resource-based policies
3. Permission boundaries
4. Service control policies

Identity-based policies

These policies can be attached to users, user groups or roles within AWS IAM to control each entity's access.

Identity-based policies have two different types:

Managed policies

1. These policies are stored within the AWS policy library and can be assigned to multiple users, user groups and roles

Inline Policies

1. These policies are not stored within the AWS policy library. However, they can be assigned to a single user, user group or role. These policies cannot be shared amongst entities.
2. Using inline policies is not considered best practice since they scale well and must only be used if necessary.

Managed policies are further separated into two categories:

AWS Managed Policies

• These policies are predefined by AWS and are available for standard permissions

Customer Managed Policies

• These policies are defined by the administrator and saved within the AWS policy library to grant custom permissions

Resource-based policies

These policies are effectively inline policies associated with a resource rather than an identity. For example, resource-based policies grant principles permissions so they can access a particular resource such as AWS S3.

The difference between an identity-based and resource-based policy is that it does not have the "principle" parameter within the policy as it is associated with an identity. On the other hand, resource-based policies must have the "principle" parameter to specify which identity the policy permissions apply.

Permission boundaries

Permission boundaries differ from identity-based and resource-based policies, as permission boundaries do not grant permissions. However, they restrict the maximum permission level for a specific user or role.

These policies can be attached to a user or role but cannot be linked to user groups within IAM. These policies can be AWS-managed policies or customer-managed policies.

These policies build a fence for the maximum permissions granted for a user or role, ensuring that these entities do not obtain excessively permissive access.

Service control policies

These policies are similar to permission boundaries as they define the maximum level of permissions allowed. However, organization service control policies or SCPs, such as AWS accounts or Organizational Units (OUs), restrict access at a much larger scale.

AWS Policy Generator

The AWS policy generator is a quick and easy method to create and define your AWS policies rather than writing all the policies from scratch.

Instead, when creating the new IAM policy, you can use the graphical interface to select the necessary permissions and services that need access and transfer the compiled policy into the AWS IAM console.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1665324279615",
      "Action": "s3:*",
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::firsts####"
    }
  ]
}

Identity Federation with AWS IAM

Identity federation within AWS IAM supports two types of federation:

1. Web ID federation
   • Supports OpenID Connect providers such as Google, Facebook, Amazon, etc.
2. SAML 2.0-based federation

AWS allows users and accounts from third-party identity providers such as Microsoft Active Directory to use AWS services with the federation. In addition, it will enable organizations that already use identity providers to use the same accounts to grant access to AWS services, thus cutting down the requirement of users needing to have separate AWS IAM accounts.

It also allows you to create seamless single sign-on capabilities within the organization to improve the user experience.

Conclusion

AWS IAM is an integral part of the AWS services and builds the foundational blocks for all user and access management.

This article covered the basics required to understand key features that will allow administrators and users to start their AWS journey.

I hope you have found this helpful. Thank you for reading!