How do I access resources in another account from an Amazon ECS task?

Resolution

Note: If you receive errors when you run AWS Command Line Interface (AWS CLI) commands, then see Troubleshooting errors for the AWS CLI. Also, make sure that you're using the most recent AWS CLI version.

To set up cross-account access for an Amazon ECS task, use AWS Identity and Access Management (IAM) roles and cross-account role assumption.

This resolution uses the following configurations:

• Account A is the resource owner account.
• Account B is the account with the Amazon ECS task.

Prerequisite: The Amazon ECS task definition in Account B must have an IAM task role. After you create the IAM task role, update the Amazon ECS task definition to include the task role ARN.

Configure Account A

Complete the following steps:

1. Create an IAM role to access the resource, and enter the following trust relationship for the custom trust policy:

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "AWS": "arn:aws:iam::Account_B_ID:role/ECS_Task_Role_Name"
               },
               "Action": "sts:AssumeRole"
           }
       ]
   }

   Note: Replace Account_B_ID with the account ID for Account B, and ECS_Task_Role_Name with name of the Amazon ECS task role for Account B.
2. Attach an inline policy to the new IAM role with the required permissions to access the resource. The following example policy allows the IAM role to send messages to an Amazon Simple Queue Service (Amazon SQS) queue:

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "sqs:SendMessage"
               ],
               "Resource": "arn:aws:sqs:region:Account_A_ID:QueueName"
           }
       ]
   }

   Note: If your task runs on AWS Fargate, then make sure that the IAM role has ECS Exec permissions.

Configure Account B

Attach an inline policy to the Amazon ECS task role in the task definition that allows the task to assume the IAM role in Account A:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::Account_A_ID:role/cross-account-role"
        }
    ]
}

Note: Replace Account_A_ID with the account ID for Account A.

Make sure that the task's container in Account B can access the resource in Account A

Complete the following steps:

1. If you're running the task on Amazon Elastic Compute Cloud (Amazon EC2), then use the docker exec command from within the task's container instance. For more information, see Run docker exec on a running container on the Docker Docs website. Then, proceed to step 3.
   If you're running the task on Fargate, then turn on ECS Exec for your standalone task or service.
   Note: In the following commands, replace cluster-name with your cluster name, your-task-definition with the task definition in Account B, and region-name with your AWS Region. Also, replace FARGATE with your launch type.
   For a standalone task, run the following run-task command:

   aws ecs run-task --cluster cluster-name --task-definition your-task-definition:revision --enable-execute-command --network-configuration "awsvpcConfiguration={subnets=[subnet-12345678],securityGroups=[sg-12345678]}" --launch-type FARGATE

   For a service, run the following update-service command:

   aws ecs update-service --service service-name --cluster cluster-name --enable-execute-command --region region-name --force-new-deployment

2. To use ECS Exec to remotely connect to the container instance, run the following execute-command command:

   aws ecs execute-command --cluster cluster-name --task taskID --container container-name --interactive --command "/bin/bash"

   Note: Replace cluster-name with your cluster name, taskID with your task ID, and container-name with your container name.

3. Inside the container, run the following command to create a cross-account profile in the configuration file:

   bash-4.2# mkdir /root/.aws
   bash-4.2# cat <<EOF > /root/.aws/config
   [profile cross-account]
   role_arn = arn:aws:iam::Account_A_ID:role/cross-account-role
   credential_source = EcsContainer
   EOF

   Note: Replace Account_A_ID with the account ID for Account A.

4. To check the role that the container assumes, run the following command:

   bash-4.2# aws sts get-caller-identity

   In the output, verify that the role is the task role in Account B.
   Example output:

   {
       "Account": "Account_B_ID", 
       "UserId": "AROATCLZDNI7EB3PZGY56:8db9330e660542b7b55595b06fef82cd", 
       "Arn": "arn:aws:sts::Account_B_ID:assumed-role/task-role/8db9330e660542b7b55595b06fef82cd"
   }

5. To confirm that the container can assume the cross-account role, run the following command:

   bash-4.2# aws sts get-caller-identity --profile cross-account

   Example output:

   {
       "Account": "Account_A_ID", 
       "UserId": "AROA4T5UFR272UVSKSA2Y:botocore-session-1736260779", 
       "Arn": "arn:aws:sts::Account_A_ID:assumed-role/cross-account-role/botocore-session-1736260779"
   }

6. Check whether you can access the resource in Account A from Account B. The following example command accesses an SQS queue:

   bash-4.2# aws sqs send-message --queue-url https://sqs.region.amazonaws.com/Account_A_ID/QueueName --message-body "Test message from ECS Task in Account B" --profile cross-account

   Note: Replace region with your Region, Account_A_ID with the account ID for Account A, and QueueName with the name of your SQS queue.
   Example output:

   {
       "MD5OfMessageBody": "2b9297ac831d0f8aa655f41e6782898d", 
       "MessageId": "4d5baf64-abb0-4f06-af95-d602a45326d2"
   }

   The output confirms that the Amazon ECS task in Account B can send messages to the SQS queue in Account A.

Related information

How do I configure my Amazon ECS task to assume an IAM role in another AWS account?

IAM tutorial: Delegate access across AWS accounts using IAM roles

Using an IAM role in the AWS CLI