0
votes

I am currently setting up an AWS architecture based on https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations.

As a starting point I have a root organization with a few organizational units named Infrastructure, Workloads and Deployments.

I want multiple environments, e.g. Staging and Production, in my problem, let's assume I only have Staging.

So based on the best practices, I have the following accounts with services:

OU: Infrastructure, Account: InfrastructureStaging

  • VPC: Network with Subnets, Internet Gateways, etc.
  • ALB: Application Load Balancer with Target Groups, Listeners etc.

OU: Workloads, Account: WorkloadStaging

  • ECS: Elastic Container Service with Fargate Cluster, Task Definitions and Services

As described in the best practies, this architecture should separate concerns, e.g. the infrastructure team (account) can manage the VPC, and multiple workload accounts can manage their workload.

Now to my Problem: When I create a ECS Service, I have to create a service-linked role as described here: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using-service-linked-roles.html

This role exists in the WorkloadStaging account and gives the ECS access to manage required resources, but ONLY in the WorkloadStaging account. My Load Balancer target groups, etc. however are in another account (InfrastructureStaging).

Usually granting access to cross-account resources is done via roles, where I would create a e.g. ecs role in the InfrastructureStaging account, give access to resources attaching policies to it, and then tell an external user to assume that role.

But I can not do that with a service-linked role, can I?

So to summarize:

  • I have two accounts A and B
  • B has a resource I want to access from A
  • A wants to access this resource in B using a service-linked role (ECS)
  • How can I do this?
1

1 Answers

0
votes

In (Account A) ECS task is running in ECS and it assumes the ECS role by creating a unique instance of that role, which it cannot be a target of a principal statement, so it is a temporary permissions that can't assume other roles. To work around this you may programmatically assume the role from an ECS task, for example using botos python see the following link: https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/sts.html