Identity and access management (IAM) in AWS cloud


Introduction to Identity and Access Management

Identity and access management (IAM) is a combination of tools and processes to identify, authenticate and authorise access to resources to keep systems and data secured. With IAM we can ensure that the source entity (users, groups, applications, devices, etc.) accessing a resource is who they say they are before access control determines their level of access and grants or denies their access. Access control allows system administrators to add and edit source entities, but also determine their access level. Best practice for determining level of access is to grant only the minimum required access. IAM acts in a crucial role of systems security, and it’s extremely important to do it correctly.

AWS Identity and Access Management

Amazon Web Services (AWS) has a service called AWS Identity and Access Management (or IAM in short) and it enables AWS users to control access and permissions to AWS services and resources, for free! IAM is one of the core services in AWS, and it is integrated into most of the AWS services [1]. In this blog post I am going to showcase some basic functions of IAM.

“IAM lets you manage permissions for your users and applications, use identity federation to manage access to an AWS account, and analyze access to resources and services.”


IAM roles & IAM users

In the AWS world the source entities are AWS IAM users and AWS IAM roles. There are few key differences between these two. IAM users have long-term credentials and are used to directly access AWS services. IAM roles are meant to be assumed by authorised entities before accessing AWS services, when an authorised entity assumes an IAM role a new session is created. The maximum duration for a session is 12 hours [2]. IAM users are usually created for a person or an application to interact with AWS. IAM roles on the other hand are intended to be shared by anyone who has access to it. Examples of authorised entities that can assume IAM roles are IAM users, applications or AWS services like AWS lambda.

An IAM user can be assigned to one or multiple IAM groups. An IAM group is a collection of IAM users. All users within a user group will get permissions that are defined for the group. This way system administrators can specify permissions for all users in the group. This makes it easier to manage permissions of multiple similar IAM users.


Policies and Permissions

In the AWS environment policies and permissions are managed with IAM policies. There are several different policy types but in this blog post we are focusing on identity-based policies.

Access management in AWS is done by creating, editing and attaching an IAM policy to a user, role or a group. A policy is a JSON document in AWS which determines permissions of an entity when attached to one. With IAM policies we can define what the entity can and can not do. Policies support different kinds of conditions which allows even more complex setups. They are re-usable which means that the same IAM policy can be attached to multiple different entities. All the identity-based IAM policies have one or more statements which will either allow or deny specified actions. If an entity has both allow and deny statements on the same action — the deny statement overrides the allow statements [3].

Real world use-cases

Now that we have understood the basic building blocks of AWS IAM, it’s time to have a look at some real world use-cases. We will cover some common scenarios and different setups that I would build with AWS IAM to overcome the obstacle. Keep in mind these setups are not the only way to solve these example scenarios.

AWS Management Console Login

A very common use-case: a new AWS account is created, and we need a way for users to login to the AWS management console. There are a few solutions that I think should be considered for this depending on what systems are already available for the team. If the team has a SAML 2.0-compliant identity provider (IdP) available, you can configure AWS Single Sign-On (AWS SSO) to allow federated users to assume an IAM role to access the management console[4]. We already have great blog posts about this topic and I highly suggest taking a look at them[5][6]. If the team does not have a SAML 2.0-compliant IdP available and maybe a fast and easy setup is required. Then I recommend creating individual IAM users and adding these users to IAM groups.

Let’s imagine a scenario where we have a small company that just created their first AWS account. This company has four employees: 1x admin, 2x developers and 1x security. It’s required that each and every employee has their own sign-in credentials and each role should have their own permissions.

IAM users for every employee is an easy solution for this scenario. Users can then be added to IAM groups that have the required permissions attached. This solution provides easy management for administrators. If a new person joins the team, it will only require a new IAM user for that person. The user can then be added to correct user groups to get the required permissions. A user can be part of multiple IAM groups, which provides flexibility and easier management.

Machine Users

In some use-cases a machine user is required. Machine users can be used to perform automated tasks like application deployment with CI/CD pipeline. AWS does offer a CI/CD solution called AWS CodeDeploy[7]. CodeDeploy uses an IAM role to get permissions to access AWS resources and to perform tasks for you. But what if you want to use 3rd party CI/CD solutions or even build one for yourself? No problemo, with an IAM user you can provide access to your AWS resources for automated tasks that are running outside of AWS. Since these automated tasks usually only require programmatic access to AWS, you can disable IAM users access to the management console. Access keys are long-term credentials for an IAM user, and you can use them to sign requests to the AWS CLI or AWS API. An access key consists of two different keys; an access key ID and a secret access key. These keys act as a username and password, so it’s extremely important not to share them. It is also highly recommended to rotate these keys from time to time.

Cross Account Access

Cross account access is usually required when we have an environment where resources are shared between different AWS accounts. For example, a scenario where we need to read some objects from a private S3 bucket located in a different AWS account.

To enable cross-account access a trust relationship between these accounts needs to be established. We don’t need to create a new user for everyone that needs this cross-account access. We can simply create a new IAM role with required permissions and configure this IAM role to be assumed from another AWS account with an assume role policy document[8][9]. When a trusted entity sends an assume request to AWS, it will get temporary credentials as a response. This means that AWS has already created a new session with these given temporary credentials, and they can be used to access AWS resources from the other AWS account.


[1] AWS services that work with IAM


[3] Policy evaluation logic

[4] Enabling SAML 2.0 federated users to access the AWS Management Console



[7] AWS CodeDeploy features

[8] IAM tutorial: Delegate access across AWS accounts using IAM roles

[9] Delegating API Access to AWS Services Using IAM Roles

Heikki Ma
Heikki Ma
Cloud Architect, Full Stack Developer, Consultant