Answers: <p>There are several ways to enable access, and your question touches on more than one.</p>
  
  <p>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 <code>sts:AssumeRole</code> API call in the account of this IAM/EC2, and assume a role in the second account. <a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html" rel="nofollow noreferrer">https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html</a></p>
  
  <p>I have not tested this, but as far as I know, while the above description is correct - it will not work with the <code>sts:AssumeRole</code> API since it requires non-temporary (non-session) credentials. And the credentials provided to the EC2 instance are in fact <code>sts:GetSessionToken</code> type of credentials provided to it via the EC2 metadata service.</p>
  
  <p>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. <a href="https://docs.aws.amazon.com/eks/latest/userguide/security-iam.html" rel="nofollow noreferrer">https://docs.aws.amazon.com/eks/latest/userguide/security-iam.html</a></p>
  
  <p>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. <a href="https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html" rel="nofollow noreferrer">https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html</a></p>
  
  <p>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 <code>sts:AssumeRole</code> credentials might not work, you can create S3 buckets that do allow access from a peer account. <a href="https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-s3/" rel="nofollow noreferrer">https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-s3/</a></p>
  
  <p>Very similar to this, the ECR service also has an option to allow the <code>GetLogin</code> API call from another account. <a href="https://aws.amazon.com/premiumsupport/knowledge-center/secondary-account-access-ecr/" rel="nofollow noreferrer">https://aws.amazon.com/premiumsupport/knowledge-center/secondary-account-access-ecr/</a></p>
  
  <p>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 <code>aws</code> CLI is using the file <code>~/.aws/credentials</code>, and it allows to specify multiple named profiles so you can specify which account needs to be controlled. <a href="https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html" rel="nofollow noreferrer">https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html</a></p>
  
  <p>Another alternative, is to create a service that is a "Credentials ATM Machine". One excellent tool for doing this is HashiCorp Vault <a href="https://www.hashicorp.com/resources/deep-dive-vault-aws-auth-backend" rel="nofollow noreferrer">https://www.hashicorp.com/resources/deep-dive-vault-aws-auth-backend</a>. AWS even has a QuickStart CloudFormation template to deploy Vault in your account. <a href="https://aws.amazon.com/quickstart/architecture/vault/" rel="nofollow noreferrer">https://aws.amazon.com/quickstart/architecture/vault/</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2019-12-31T17:22:23.233Z
Answers: 2019-12-31T17:22:23.233Z
Answers: Evgeny Zislis
Body: <p>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.</p>
  
  <p>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?</p>
  
Tags: <amazon-web-services><role-based-access-control>
Title: How to grant all resources in an AWS account the ability to assume role?
UserDisplayName: roni
ThreadText: # How to grant all resources in an AWS account the ability to assume role?
  
  (Asked by: username_0 on 2019-12-31)
  
  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?
  
  **Tags:** amazon-web-services, role-based-access-control
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-12-31. Score: 1
  
  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/>
  
  
  ---
  
  