Amazon VGT2 Las Vegas: Simplifying API Access to AWS Services with IAM Roles

More Info

Today, I’m excited to share insights from our Senior Product Manager, Emily Carter, who is part of the AWS Identity and Access Management team.

Imagine you manage a research laboratory where a terabyte of data is stored in Amazon DynamoDB for seamless processing and analysis. Your peers in other labs and commercial sectors are interested in replicating your findings and conducting further exploration of your data. Previously, this would have proven to be a complex task.

However, we are now providing you with the necessary tools to streamline this crucial use case. You can utilize an AWS Identity and Access Management (IAM) role alongside IAM users to facilitate cross-account API access or delegate API access within a single account. This new capability enhances your control over access management, particularly when handling services and resources across multiple AWS accounts.

Earlier this year, we rolled out IAM roles specifically for EC2 instances. These roles allow you to define permissions that an EC2 instance can assume on your behalf. Now, IAM users can also assume roles, enabling them to access APIs across accounts or delegate within an account without sharing long-term security credentials.

When an IAM role is assumed, you receive temporary security credentials that carry the permissions associated with that role. You utilize these credentials instead of your long-term ones when making calls to AWS services, allowing you to interact with the service using the permissions granted by the assumed IAM role.

Let’s delve deeper into how this can be applied in real-world scenarios.

Granting Users API Access Across AWS Accounts

Consider a scenario where your organization manages two AWS accounts:

• research@example.com, where data from various research initiatives is stored.
• aws@example.com, your company’s primary account hosting the majority of your IAM users.

Assume there is a developer named “Alex” defined as an IAM user in aws@example.com. Alex requires read-only access to the data in the DynamoDB tables located in research@example.com.

To enable cross-account API access, a trust relationship must be established between the two accounts (in this case, aws@example.com and research@example.com).

Steps for Account Administrators:

1. Configuring the Trusting Entity
   The administrator for research@example.com needs to perform the following actions to allow IAM users in aws@example.com to assume a role that grants read-only access to DynamoDB:
   • Sign in to the IAM console and select the Roles option.
   • Create a new role and name it, for example, DynamoDB-ReadOnly-role.
   • Expand the Roles for cross-account access section and choose the option that allows access between your own AWS accounts.
   • Add aws@example.com as the account from which IAM users may access research@example.com, using the AWS account ID retrieved from the My Account page in the AWS Management Console.
   • Assign a policy to the IAM role that permits read-only access to DynamoDB by selecting the Amazon DynamoDB Read Only Access policy from the list of templates.
2. Configuring the Trusted Entity
   After granting access to aws@example.com, the administrator for this account must explicitly allow individual IAM users to assume the DynamoDB-ReadOnly-role. Since IAM users are secure by default, they only have permissions that their administrators have granted. The following steps need to be followed:
   • Sign in to the IAM console.
   • Assign a policy to Alex (or a group that includes Alex) that allows them to call AssumeRole on the DynamoDB-ReadOnly-role. Below is an example of such a policy, assuming 111122223333 is the account ID for research@example.com:

   {
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "sts:AssumeRole",
         "Resource": "arn:aws:iam::111122223333:role/DynamoDB-ReadOnly-role"
       }
     ]
   }

How Alex Uses the IAM Role for Resource Access

Once the necessary setups are complete, the application Alex uses will make API calls to assume the IAM role and leverage the role’s temporary security credentials when accessing the DynamoDB table in research@example.com.

For a practical demonstration, here’s a simple code snippet using the AWS Java SDK that illustrates the steps for assuming a role and using the temporary security credentials to access DynamoDB.

import java.util.HashMap;
import com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient;
import com.amazonaws.services.securitytoken.model.AssumeRoleRequest;
import com.amazonaws.services.securitytoken.model.AssumeRoleResult;
import com.amazonaws.services.dynamodb.AmazonDynamoDBClient;
import com.amazonaws.services.dynamodb.model.*;
import com.amazonaws.auth.*;

public class AssumeRoleDemo {
    private static final String ROLE_ARN = "arn:aws:iam::111122223333:role/DynamoDB-ReadOnly-role";
    private static final String TABLE_NAME = "TestProject";
    private static final String KEY_VALUE = "1234567890";
    private static AWSCredentials longTermCredentials_;

    private static void init() throws Exception {
        longTermCredentials_ = new PropertiesCredentials(AssumeRoleDemo.class.getResourceAsStream("AwsCredentials.properties"));
    }

    public static void main(String[] args) throws Exception {
        init();
        // Step 1: Use Alex's long-term credentials to call the
        // AWS Security Token Service (STS) AssumeRole API.
        AWSSecurityTokenServiceClient stsClient = new AWSSecurityTokenServiceClient(longTermCredentials_);
        AssumeRoleRequest assumeRequest = new AssumeRoleRequest()
            .withRoleArn(ROLE_ARN)
            .withDurationSeconds(3600)
            .withRoleSessionName("demo");
        AssumeRoleResult assumeResult = stsClient.assumeRole(assumeRequest);
        // Further implementation...
    }
}

For additional insights, you can check this blog post that dives deeper into AWS IAM roles. Moreover, for expert guidance, refer to this resource, which provides authoritative information on the topic. Additionally, this Reddit discussion offers valuable perspectives on the area manager onboarding process.