AWS S3 Account "Cross Account IAM" benefit over using resource-based policy?

[PSAmmirata]

We operate in an environment where our SnapLogic snaplex is in one AWS account (the trusted AWS account) and our S3 resources are in other AWS accounts (the trusting AWS accounts).

In most of our AWS S3 Accounts we have ‘IAM role’ enabled. Prior to the introduction of the “Cross Account IAM” capability we implemented cross account access by adding a resource-based policy (i.e. an S3 bucket policy) that granted access on the bucket to the principal in the trusted AWS Account (where SnapLogic groundplex nodes are). What are the pros and cons of using the “Cross Account IAM” capability which is a role for cross-account access vs using the resource-based policy?

In cases where using access-key ID and secret key, a similar question, Why use the “Cross Account IAM” capability when you could use resource-based policy to grant the access?

[kzhou · Accepted solution]

Hi Paul,
The cross account IAM role is using a role inside the trusting account to delegate the role or user in trusted account. In this case, trusting role would be granted with all the permissions we want the trusted account to have, and we don’t need to explicitly expose a resource to some external account in the policy.

Also, the cross-account role is more secure. The way it works is relying on the sts:AssumeRole API, the access it granted to the trusted role is a temporary one. Plus, it can be set with an external ID to provide an extra layer of security. This is especially beneficial for the case where the trusting account and trusted account are from different organizations

The downside of cross-account role vs resource-based role is that, when we assume the role in the trusting AWS account, we are losing the original permissions we have in our own AWS account (since now we are acting as a role in trusting AWS account)

As for the case using access-key ID and secret key, the goal of the cross-account effort above is to avoid sharing AWS credentials with different teams or organizations.

Hope this helps!

[sanjaynayak]

@PSAmmirata @kzhou , we are looking for convenient work round for one of the use case. Use case is like below.

Use case 1:

We have one snaplogic snaplex running under one AWS account and using this snaplex we have to access a s3 bucket(x), we are using IAM role to access s3 bucket instead client id and client secret id. We have created bucket policy for bucket x.

All user who have access to snaplogic snaplex able to access x bucket by default
Now we are looking for best workaround, how to give permission user A to x bucket and B not to X bucket.

[PSAmmirata]

Hi @sanjaynayak - Since the IAM role is attached to the ec2 instances hosting the snaplex nodes, I believe you can control access within SnapLogic at the project level by whether or not you create the SnapLogic account.