Table of Contents
- Prerequisites
- Create a role in the Production Account
- Grant access to the role
- Test access by switching roles (Console)
- Revoke an assumed role
- Clean Up
- Summary
- Referrals
In this blog we are going to go through the steps to delegate access to resources in two different AWS accounts called Production and Development.
Developers should be able to access an S3 bucket in the Production account, however the testers from the same account should not be able to access the S3 bucket in the Production account.
By setting up cross-account access this way:
- You don't have to create individual IAM users in each account.
- Users don't have to sign out of one account and sign into another in order to access resources in different AWS accounts.
- A user in one account can switch to a role in the same or a different account. While using the role, the user can perform only the actions and access only the resources permitted by the role; their original user permissions are suspended. When the user exits the role, the original user permissions are restored.
Picture source: AWS
Prerequisites
- Two different AWS accounts, one for Production and the other for Development.
- Users and users groups in the Development account.
User | User Group |
---|---|
John | Developers |
Sri | Testers |
We will be using the following substitutions in the following bucket policies:
Parameter | Example |
---|---|
[ProdAccountID] | 99999999999 |
[DevAccountID] | 11111111111 |
[BucketName] | sriprodbucketrandomnumber
|
Step 1: Create a role in the Production Account
Before we can create a role, we need the account ID of the Development AWS account. Each AWS account has a unique account ID identifier assigned to it.
Obtain the Development AWS account ID by signing in to the console then click on the account name and copy the 12-digit account number (ID).
Sign in to the AWS Management Console as an administrator of the Production account, and open the IAM console.
We are going to create a custom policy by navigating to Policies and then choose Create policy
-
Choose the JSON tab and copy the text from the following JSON policy document. Paste this text into the JSON text box, replacing the resource ARN (arn:aws:s3:::[BucketName]) with the real one for your Amazon S3 bucket.
Policy from the documentation
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::[BucketName]" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::[BucketName]/*" } ] }
The ListBucket permission allows users to view objects in the productionapp bucket. The GetObject, PutObject, DeleteObject permissions allows users to view, update, and delete contents in the productionapp bucket.
-
On the Review page, enter
S3ProductionAccessPolicy
for the policy name. Review the policy Summary to see the permissions granted by your policy, and then choose Create policy.The new policy appears in the list of managed policies.
In the navigation pane, choose Roles and then choose Create role.
Choose the An AWS account role type.
For Account ID, type the
[DevAccountID]
, which we copied earlier at the start of this section.Choose Next: Permissions to set the permissions associated with the role.
-
Select the check box next to the policy named
S3ProductionAccessPolicy
and then, click Next.Tip: For Filter, choose Customer managed to filter the list to include only the policies that you created. This hides the AWS created policies and makes it much easier to find the one you need.
Click on Create role and name it as
S3ProductionAccessRole
.Copy the ARN of
S3ProductionAccessRole
role by navigating to IAM > Roles > Search forS3ProductionAccessRole
> Click on it > Copy the ARN
At this point, we have established trust between the Production and Development accounts. We did this by creating a role in the Production account that identifies the Development account as a trusted principal. We also defined what the users who switch to the S3ProductionAccessRole
can do.
Step 1.3
Step 1.3
Step 1.6
Step 1.10
Step 1.11
Step 1.11
Step 2: Grant access to the role
To modify the Developers user group to allow them to switch to the S3ProductionAccessRole role
Create two users, John and Sri, and two user groups, Developers and Testers.
Add John to Developers and Sri to Testers user groups.
Sign in as an administrator in the Development account, and open the IAM console.
Choose User groups, and then choose Developers.
Choose the Permissions tab, choose Add permissions, and then choose Create inline policy.
Choose the JSON tab.
-
Add the following policy statement to allow the AssumeRole action on the
S3ProductionAccessRole
in the Production account. Be sure that you change [ProdAccountID] in the Resource element to the actual AWS account ID of the Production account.Policy from the documentation
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::[ProdAccountID]:role/S3ProductionAccessRole" } }
The Allow effect explicitly allows the Developers group access to the S3ProductionAccessRole role in the Production account. Any developer who tries to access the role succeeds.
Choose Review policy.
Type a Policy name such as
allow-assume-S3-role-in-production
.Choose Create policy.
To modify the testers user group to deny permission to assume the S3ProductionAccessRole role
- Choose User groups, and then choose Developers.
- Choose the Permissions tab, choose Add permissions, and then choose Create inline policy.
- Choose the JSON tab.
-
Add the following policy statement to allow the AssumeRole action on the
S3ProductionAccessRole
in the Production account. Be sure that you change [ProdAccountID] in the Resource element to the actual AWS account ID of the Production account.Policy from the documentation
{ "Version": "2012-10-17", "Statement": { "Effect": "Deny", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::[ProdAccountID]:role/S3ProductionAccessRole" } }
The Deny effect explicitly denies the Testers group access to the S3ProductionAccessRole role in the Production account. Any tester who tries to access the role receives an access denied message.
Choose Review policy.
Type a Policy name such as
deny-assume-S3-role-in-production
.Choose Create policy.
Step 3: Test access by switching roles (Console)
We now have a role that grants access to a resource in the Production account. We also have one user group in the Development account with users allowed to use that role. This step discusses how to test switching to that role from the AWS Management Console.
Switching roles using the AWS Management Console only works with accounts that do not require an ExternalId. For example, assume that you grant access to your account to a third party and require an ExternalId in a Condition element in your permissions policy. In that case, the third party can access your account only by using the AWS API or a command line tool. The third party cannot use the console because it cannot supply a value for ExternalId. More informaton at How to use an external ID when granting access to your AWS resources to a third party,
To assume a role
- Logon to AWS console as John (Developer) in the Development user group.
- Select John on top right corner (the Identity menu) on the navigation bar, and then choose Switch Role.
- Next, in order to access the role, John must type the
ProdAccountID (999999999999)
, the role name (S3ProductionAccessRole
), Display name asS3-Production
and then chooses Switch Role. - John can now use the Amazon S3 console to work with the Amazon S3 bucket, or any other resource to which the
S3ProductionAccessRole
has permissions. - When done, John can return to his original permissions. To do that, he chooses S3-Production role display name on the navigation bar and then chooses Switch Back.
- The next time that John wants to switch roles and chooses the Identity menu in the navigation bar, he sees the S3-Production entry still there from last time. He can simply choose that entry to switch roles immediately without reentering the account ID and role name.
- Repeat the above steps with Sri (Tester) and he will not be able to assume the role
S3ProductionAccessRole
,
Revoke an assumed role
- Navigate to S3ProductionAccessRole under IAM > Roles in the Production Account.
- Click on Revoke Sessions > Click on Revoke active sessions > Select I acknowledge that I am revoking all active session for this role > Click Revoke active sessions.
- This will add an inline policy with a policy name as AWSRevokeOlderSessions with a condition of DateLessThan the aws:TokenIssueTime. All existing sessions will be revoked.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"*"
],
"Resource": [
"*"
],
"Condition": {
"DateLessThan": {
"aws:TokenIssueTime": "2022-07-04T10:27:56.051Z"
}
}
}
]
}
Clean Up
- Empty the bucket
- Delete the bucket
- Delete S3ProductionAccessPolicy and in the Production Account
- Delete John and Sri users.
- Delete Developers and Testers User groups
Summary
- In this demo we have learned how to delegate access across AWS accounts using IAM roles.
- You don't have to create individual IAM users in each account.
- Users don't have to sign out of one account and sign into another in order to access resources in different AWS accounts.
- A user in one account can switch to a role in the same or a different account. While using the role, the user can perform only the actions and access only the resources permitted by the role; their original user permissions are suspended. When the user exits the role, the original user permissions are restored.
Referrals
IAM tutorial: Delegate access across AWS accounts using IAM roles)
Cover Image by @timswaanphotography from unsplash.
Top comments (0)