AWS Roles

AWS Roles

An important security concern with IAM users is that the credentials attached to them, whether it be username/password or access keys, are long-term and will last forever unless deactivated/deleted. IAM Roles solve this key credential problem for AWS by using temporary credentials for accessing AWS APIs. As of the writing of this article, the maximum session duration for an AWS role can be 12 hours. The other key difference from IAM users is that roles as identities are designed to be assumable by multiple users/services whereas IAM users should be uniquely attributed to a single identity.

Obviously, there still needs to be an identity with long-term credentials to be able to assume this role. The list of such identities that can assume the AWS Roles are –

• An IAM user or role in any AWS account (does not have to be the same one)
• An AWS service like AWS EC2, Lambda, API Gateway, etc
• An external user authenticated by an external identity provider (IdP) service that is compatible with SAML 2.0 or OpenID Connect, or a custom-built identity broker

A better way to understand Roles is via scenarios, so lets a take a look at some of the most common scenarios for using AWS Roles:

Scenario 1

Ravi, the Identity Admin for an organization wants to create a Just-in-time access for AWS, meaning, that he does not want to provide long-term credentials for AWS to the employees, but get temporary access as and when the employees need it. Ravi first creates a set of IAM Roles like Admin, IAM Admin, Security, Developer, Read-only, etc. which are mapped to only specific permissions needed by that role via IAM policies. Notice that the design here is that the Role can be assigned to multiple users, in contrast to IAM users. Ravi then creates a SAML integration of AWS with his organization’s IdP where he provides a mapping between the Org users and the AWS Roles. Now when the employees log into IdP, they have a link for AWS console which when clicked logs them to AWS console by assuming the corresponding AWS Role, and the access is only valid for up to 12 hours. So in summary, the users are able to login to AWS with their organizational credentials and their session is only valid for up to 12 hours. In practice, this can be a complex process so for the purpose of this introductory article, I have kept things at a very high-level.

Scenario 2

Becky, a software developer, is building a serverless application on AWS and wants to provide access to the Lambda function to be able to read and write data from an AWS DynamoDB database. Becky creates an IAM role assumable by Lambda service and assigns it get and put DynamoDB permissions to the specific DynamoDB db resource via IAM policies. Becky then assigns this role to the Lambda function which solves her access use case.

Scenario 3

Ahmed, a security engineer, wants to run a security tool to scan his company’s AWS account. In order to do so, Ahmed needs to provide READ permissions to an external AWS account (where the scanner runs). Ahmed creates an IAM role assumable only by the external AWS account and assigns it IAM policy to be only able to perform READ operations. Ahmed then provides the Role ARN (unique identifier for the Role) to the security scanning tool who can then assume the role from their AWS account and read data from Ahmed’s account.

Two Policies Attached to an IAM role

The two foundation aspects that you must have noticed in all the above three scenarios, and are generally valid for any AWS Role are – trust policy and IAM policy.

Trust policy is attached to all roles and provides a means to determine who can assume this role. In Ravi’s example, this was the SAML IdP. In the case of Becky, it was the Lambda function and in the case of Ahmed, this was the AWS account Id of the external AWS account.

IAM policy, as we will cover in detail in the next chapter, is the curated list of AWS apis and actions that the role can access after it’s assumed. In Ravi’s example, this was role-based permissions depending on the role being assumed. In Becky’s example, it was the read and write permissions to the DynamoDB Database. In the case of Ahmed, it was the read permissions to the entire AWS account.

Lab Demo

In the video lab walk-through, we will create an IAM role and see how it can be assumed by a Lambda function as well as an IAM user.

Security tidbits

Summary of security best practices to keep in mind regarding AWS roles: