AWS Security Blog

Now Create and Manage AWS IAM Roles More Easily with the Updated IAM Console

Today, we updated the AWS Identity and Access Management (IAM) console to make it easier for you to create, manage, and understand IAM roles. We made improvements that include an updated role-creation workflow that better guides you through the process of creating trust relationships (which define who can assume a role) and attaching permissions to roles. Additionally, you can now view and understand the permissions attached to roles more easily by using policy summaries for each role in your account.

In this post, I provide background information about roles, show how to create roles correctly by using the updated IAM console, and review other changes to the role list and details pages that help you better manage your roles.

Background information about IAM roles

What are IAM roles?

IAM roles are a secure way to grant permissions to entities you trust. You can use a role in the following scenarios:

What are the different parts of an IAM role?

As illustrated in the following diagram, roles have two types of policies attached to them:

  • Trust policy – This policy defines the entities that can assume a role. When you create a role by using the IAM console, the trust policy is created for you. You can customize the trust policy after it has been created. A role can have only one trust policy.
  • Permissions policies – These policies define which AWS resources a role can access and the actions it can perform on those resources. These policies can be AWS managed policies, customer managed policies, or inline policies attached directly to the role. You can attach multiple permissions policies to an IAM role.

IAM role diagram with trust policy and permissions policy

How do I use an IAM role?

Roles can be used to access AWS both programmatically and via the AWS Management Console.

Using a role to access AWS programmatically

You can assume a role programmatically by using the AWS CLI or SDK. When you assume a role, the role issues temporary security credentials that you can use to access resources and call AWS service actions. Using roles enables you to follow the security best practice to use temporary security credentials instead of long-term security credentials.

If you are using AWS services such as EC2 or AWS Lambda, you can assign a role to your EC2 instance or Lambda function. Your code running on either the instance or function will then be able to access AWS using the short-term credentials from that role. These services automatically assume the role and use the returned credentials to enable you to access resources or perform actions. Learn more about IAM roles for EC2 and IAM roles for Lambda.

Using a role to access the AWS Management Console

You can also assume a role to access an account in the AWS Management Console by using Switch Role functionality. You can access this functionality by using the drop-down menu in the upper right corner of the console or through a custom sign-in URL. To switch roles, you must sign in as either an IAM or federated user. Swith Role is not supported for root users.

Introducing the updated role-creation workflow

To make it easier to create IAM roles, we’ve updated the role-creation workflow in the IAM console. To introduce the new experience, let’s look at a specific example.

Let’s suppose I am developing a new application running on an EC2 instance that reads and writes image data to S3. To enable that application to access the S3 bucket where the image data is stored, I need to create a new role that the EC2 instance running my application code can assume. This role trusts EC2 (defined in the trust policy) and has permissions to read and write to S3 (defined in the permissions policy).

I first navigate to the Roles page of the IAM console, and choose Create role.

I then select the type of trusted entity this role will allow. I have four options in this step:

  • AWS service – To grant access to an AWS service to manage resources in my account.
  • Another AWS account – To grant access to my account from another account.
  • Web identities – To grant access to Amazon Cognito or other OpenID Connect providers.
  • SAML – To grant access to identities from a SAML-enabled identity provider.

For this example, I choose AWS service. I then see a list of AWS services the new role could trust. Because I need a role that can be assumed by an EC2 instance, I choose EC2. This opens a section below it with specific use cases for this service. I choose the EC2 (Allows EC2 instances to call AWS services on your behalf) use case. This defines the role’s trust policy to include EC2 as an entity that can assume that role.

Then, I set the permissions that the role needs to access S3. I already created a permissions policy that grants access to my S3 bucket and named it MyImageApp-S3Access. I choose that policy and choose Next to move to the final step.

Screenshot showing the MyImageApp-S3Access permissions policy

In the final step, I name the role MyImageAppRole and describe it this way: “Allows application code running on EC2 instances to access data in S3.” I choose Create role and I am done! I can now attach this role to EC2 instances on which my application is running to give them permissions to access data in S3.

Screenshot of finishing the role creation process

Other updates to help you manage your roles

With this update, you will see a new column called Trusted entities on the Roles list page. This column allows you to review at a glance which entities can assume a role. This makes it easier to identify roles that trust a specific account or AWS service. It also makes it easier to audit the trust relationships across all your roles. You also can add other columns to this table, including Creation time and Role ARN, by clicking the gear icon. Your column selection preference will be remembered when you return to the Roles page.

Screenshot of the Roles page with new column, "Trusted entities"

To help you understand the permissions attached to your role, we’ve also updated the Permissions tab to include IAM policy summaries. Policy summaries make it easier for you to understand the permissions for IAM permissions policies attached to roles without having to view a policy’s JSON.

Screenshot of the updated "Permissions" tab

Conclusion

Now it is easier for you to create and manage your IAM roles using the IAM console. As you manage your roles, be sure to review and follow IAM best practices, which can help to improve the security of your AWS resources and make your account easier to manage.

If you have comments about this post, submit them in the “Comments” section below. If you have questions or suggestions, start a new thread on the IAM forum or contact AWS Support.

– Rob