How to provide Wasabi Cross Account access using IAM Roles?

Based on different and large organization scenarios, sometimes you may be required to share resources in one Wasabi account with users from another account. By setting up cross-account access in this way, you don't need to create individual IAM users in each account. In addition, users don't have to sign out of one account and sign into another in order to access resources in different Wasabi accounts. After configuring the role, you can see how to use the role from the Wasabi Management Console.

Note: This can also be achieved via AWS CLI which also works with STS to assume Roles present in your Wasabi account. We have also covered that part at the end of this document.

In this exercise, we will demo accessing a resource (say an S3 bucket) from another account using IAM Roles. Please see the following steps on how to do this:

For this demo, we have created two random accounts on Wasabi

• support+account-1@wasabi.com (Account ID: 100000080198)

• support+account-2@wasabi.com (Account ID: 100000080199)

1. Login into your first account and create a user.

I am now logged into "support+account-1@wasabi.com" account. We are naming this user as "account-1-user" and giving them programmatic access as well as console access because we will also demo this exercise using AWS CLI later.

In this example, we are giving them Admin Access in this account. This will depend on your use case.

2. Once the User is created, make sure to download the credential file and copy the ARN of this user(as shown below) in a secure location.

3. Now Log OUT of account-1 and Log IN into account 2 and create an S3 bucket which can be accessed by others.

I am now logged into "support+account-2@wasabi.com" account and we are creating a random bucket called "bucket-intended-for-shared-use". 

Note that we have also created another bucket called "bucket-not-to-be-shared" in this same account just to demo that the second bucket cannot be accessed if we do not give permission for the second bucket.

4. Now in this second account, create a policy describing what permissions do you want to allow for your resources. 

In this example, we are creating a policy called "read-write-shared-bucket" and only giving read and write access to the user who will perform cross account access on our S3 resource.

Actual Policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::bucket-intended-for-shared-use"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::bucket-intended-for-shared-use/*"
}
]
}

NOTE: Please be sure to replace "bucket-intended-for-shared-use" with your bucket name in the above JSON Policy document.

5. Now go to Roles tab and create a Role in the second account. Give a role name and you will be using this role name later. We are naming our Role as "SharedAccessRole".

Replace the Role document with the below shown JSON:

Actual Role policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::100000080198:user/account-1-user"
},
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::100000080199:role/SharedAccessRole"
}
]
}

Few things to note here:

• In the Principal section, go ahead and put your user's ARN which you saved earlier in step 2 above. You may use single user ARN, multiple users ARN separated by commas

• In the Resource section specify the ARN of this Role, make sure to replace "100000080199" with your account-2 ID where you are creating this role. Then replace "SharedAccessRole" with whatever your Role name is.

6. Once you have created the Role, click on that Role and now attach the IAM policy which you created in step 4 to this Role. You may search that policy and then attach as shown in the screenshot below:

7. Now configuration in both account 1 and account 2 is complete. All you need to do is Login into your account 1 as the sub-user you created in step 1. Let's do that here now:

Go to console.wasabisys.com and click on "Sign In As Subuser" and enter your sub-user credentials

8. Once logged in, Go to your profile top right corner and click on "Switch Role"

9. Enter the following details:

Account ID: This will the Account ID of your second account where you created the Role

Role Name: Name of your Role

Role Session Name: Give any session name and click on Assume Role

10. Now you can see with a display message "Successfully assumed role" that you have been directed to another Console wherein you can access the bucket you are permitted to and you will get "Access Denied" to the bucket you do not have permissions to

In this example, the user can successfully read and write to "bucket-intended-for-shared-use" bucket and will get Access Denied on "bucket-not-to-be-shared" bucket

____________________________________________________________________________________________________________

Part B: To perform the same operation using CLI

1. Download & install AWS CLI and configure using the credentials you downloaded for your user in step 1.

   We have configured that user as a profile called "account-1-user" on our terminal

2. Run the following command to get temporary credentials from STS

aws sts assume-role --role-arn "arn:aws:iam::100000080199:role/SharedAccessRole" --role-session-name "name" --profile account-1-user --endpoint-url=https://sts.wasabisys.com

NOTE: Make sure to enter your Role ARN as mentioned earlier

You will receive an output with temporary credentials and an expiration time (by default, 12 hours) similar to the following:

{
"Credentials": {
"SecretAccessKey": "secret-access-key",
"SessionToken": "temporary-session-token",
"Expiration": "expiration-date-time",
"AccessKeyId": "access-key-id"
}
}

3. Now this user needs to configure the AWS CLI environment to use these parameters in subsequent calls to access the permitted resource(s) in other account.

In order to achieve that, edit the credentials file in the .aws folder in the home directory of the user to add a new profile configuration. Here's an example profile configuration:

Note: In this example, we are configuring a profile name as "cross-account-temporary" and saved this in the credentials file

[cross-account-temporary]
aws_access_key_id = example-access-key-as-in-returned-output
aws_secret_access_key = example-secret-access-key-as-in-returned-output
aws_session_token = example-session-Token-as-in-returned-output

You may now operate on "bucket-intended-for-shared-use" bucket using this profile