I have an organization with a master account (account A) and a second account (account B). I want to create a role so all instances in account B will have read permission from everything in account A. For example, EKS in account B will be able to pull from ECR in account A. Or a resource in account B will be able to read data from an RDS or S3 in account A.

How can I create a role and apply it to all current and future resource in account B so they will have complete read assess to resources in account A?


There are several ways to enable access, and your question touches on more than one.

First method, is giving EC2 instances access to do API calls with the AWS API in another account. For this, the instances would need the appropriate IAM credentials. You can assign an IAM Role to an instance. The relationship is then "IAM Policy" -> "IAM Role" -> "IAM Instance Profile" -> "EC2 Instance". This Policy can give permission for this instance to do the sts:AssumeRole API call in the account of this IAM/EC2, and assume a role in the second account. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html

I have not tested this, but as far as I know, while the above description is correct - it will not work with the sts:AssumeRole API since it requires non-temporary (non-session) credentials. And the credentials provided to the EC2 instance are in fact sts:GetSessionToken type of credentials provided to it via the EC2 metadata service.

The same applies to worker nodes, and pods, running in EKS. There is a way to enable this for EKS that is described in details in the documentation. https://docs.aws.amazon.com/eks/latest/userguide/security-iam.html

On the other hand, if all you need is to access RDS and talk to your MySQL/PostgreSQL database - you don't need any IAM credentials. Just a clear path through the network where security groups allow these instances to access the RDS database. In EC2 and RDS, security groups allow to include foreign-account security groups as a filter for "source IP addresses". So when you choose to do something like that, you don't really need to specify the IP address of your EC2 instance where the application is executed, but rather just specify which security group is being used by that instance, with the addition of the account number. https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html

The S3 service does require IAM credentials to write/read data from it, but in this case it also allows to specify a permissions policy on the S3 bucket itself. So while the above method of sts:AssumeRole credentials might not work, you can create S3 buckets that do allow access from a peer account. https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-s3/

Very similar to this, the ECR service also has an option to allow the GetLogin API call from another account. https://aws.amazon.com/premiumsupport/knowledge-center/secondary-account-access-ecr/

And naturally the simplest way, is to provide credentials directly to EC2 instances. This can be done either by writing them into a file. For example the aws CLI is using the file ~/.aws/credentials, and it allows to specify multiple named profiles so you can specify which account needs to be controlled. https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html

Another alternative, is to create a service that is a "Credentials ATM Machine". One excellent tool for doing this is HashiCorp Vault https://www.hashicorp.com/resources/deep-dive-vault-aws-auth-backend. AWS even has a QuickStart CloudFormation template to deploy Vault in your account. https://aws.amazon.com/quickstart/architecture/vault/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.