Cross account resource access in IAM

For some AWS services, you can grant cross-account access to your resources using IAM. To do this, you can attach a resource policy directly to the resource that you want to share, or use a role as a proxy.

To share the resource directly, the resource that you want to share must support resource-based policies. Unlike an identity-based policy for a role, a resource-based policy specifies who (which principal) can access that resource.

The following list includes some of the AWS services that support resource-based policies. For a complete list of the growing number of AWS services that support attaching permission policies to resources instead of principals, see AWS services that work with IAM and look for the services that have Yes in the Resource Based column.

Amazon S3 buckets — The policy is attached to the bucket, but the policy controls access to both the bucket and the objects in it. For more information, see Access Control in the Amazon Simple Storage Service User Guide. In some cases, it may be best to use roles for cross-account access to Amazon S3. For more information, see the example walkthroughs in the Amazon Simple Storage Service User Guide.
Amazon Simple Notification Service (Amazon SNS) topics
Amazon Simple Queue Service (Amazon SQS) queues

Solution

Delegating AWS permissions in a resource-based policy

If a resource grants permissions to principals in your account, you can then delegate those permissions to specific IAM identities. Identities are users, groups of users, or roles in your account. You delegate permissions by attaching a policy to the identity. You can grant up to the maximum permissions that are allowed by the resource-owning account.

Important

In cross account access, a principal needs an Allow in the identity policy and the resource-based policy.

Assume that a resource-based policy allows all principals in your account full administrative access to a resource. Then you can delegate full access, read-only access, or any other partial access to principals in your AWS account. Alternatively, if the resource-based policy allows only list permissions, then you can delegate only list access. If you try to delegate more permissions than your account has, your principals will still have only list access.

For example, assume that you manage AccountA and AccountB. In AccountA, you have an Amazon SQS Queue named QueueA.

You attach a resource-based policy to QueueA that allows all principals in AccountB to perform SQS:SendMessage Action. They can send message to QueueA

Here we can use AWS::SQS::QueuePolicy or AWS::SQS::QueueInlinePolicy

Amazon SQS Queue Policy

The following sample is a queue policy that allows AWS account 444455556666(AccountA) to send and receive messages on queue queueA. You add the policy to the resources section of your template.
```
SampleSQSPolicy: 
  Type: AWS::SQS::QueuePolicy
  Properties:
        # 444455556666 :- AccountA Id 
    Queues: 
      - "https://sqs:us-east-2.amazonaws.com/444455556666/queueA"
    PolicyDocument: 
      Statement: 
        - Action: 
            - "SQS:SendMessage"
          Effect: "Allow"
          Resource: "arn:aws:sqs:us-east-2:444455556666:queueA"
          Principal:  
            AWS: 
              - "111122223333" # AccountB Id
```
AccountA gives AccountB gives access to QueueA by naming AccountB as a principal in the resource-based policy. As a result, AccountB is authorized to perform SQS:SendMessage action on QueueA, and the AccountB administrator can delegate access to its users in AccountB.
The AccountB root user has all of the permissions that are granted to the account. Therefore, the root user has full access to BucketA.
In AccountB, attach a policy such that any resource(ex. lambda) can perform SQS:SendMessage action.

iamRoleStatements:
    - Effect: "Allow"
      Action:
        - "sqs:SendMessage"
        - "sqs:ReceiveMessage"
      Resource:
         - "arn:aws:sqs:us-east-2:444455556666:queueA"

For more information about complex uses of roles, such as granting access to applications and services, see Common scenarios for roles: Users, applications, and services.

Important

🚨 Give access only to entities you trust, and give the minimum level of access necessary. Whenever the trusted entity is another AWS account, any IAM principal can be granted access to your resource. The trusted AWS account can delegate access only to the extent that it has been granted access; it cannot delegate more access than the account itself has been granted.