aws / aws/containers-roadmap

[ECS] [request]: Support cross-account clusters

Open
#2,140 0 comments 7 reactions 0 assignees View on GitHub
ECS Proposed
Dominant language
Shell
Stars
5.4k
Forks
334
PR merge metrics
No merged PRs in 30d

Description

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**

I would like a solution to cross-account sharing of compute resources in ECS. In particular, I think it would make sense to provide an "overlay cluster" concept that exists in another account but are backed but an underlying "capacity cluster". This overlay cluster could be extended to enforce rules like resource quotas, placement restrictions, and perhaps task definition mutations (i.e. sidecar injection). Because these clusters and the resources (services, tasks) exist in an overlay cluster in the service teams account, permissions for CRUD operations on ECS as well as those like `iam:passRole` work in a consistent manner to single account clusters.

**Which service(s) is this request for?**
ECS

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
AWS makes it straightforward for me to share a number of root resources, like VPC subnets, so that many accounts can easily share in a common network. However, with ECS I cannot easily do them same with my capacity, as I can either

* have a single that contains all deployments, with perhaps cross-account permissions for images and some hackery to make iam roles work
* have each account own its cluster, diluting utilization and forcing teams to maintain their own capacity

Ideally, I'd have the third option of everyone having access to a single cluster, but then there's problems of

* what resources should be visible to which accounts
* What resources are owned by which accounts
* what restrictions I as an Admin can place on an account
* General IAM permissions issues when bringing in third-party resources like target groups and roles

To solve this, it would make sense to not share the cluster resource directly but define a delegation resource called an "overlay cluster" that operates equivalent to a normal cluster, save for APIs related to underlying cluster resources like container instances. Each "overlay cluster" could optionally be extended with

* resource quotas that the overlay cluster needs to stay under
* placement strategies that are enforced on top of user-supplied placement strategies
* task definition constraints/extensions that are applied to all task definitions run in the capacity cluster

From the capacity cluster, the admin account would have describe/list/delete access to resources, but not create/update

**Are you currently working around this issue?**
Running sparse clusters

**Additional context**
No

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the ECS cross-account resource-sharing and IAM constraints described in the request, including cluster ownership, CRUD permissions, iam:passRole, quotas, placement restrictions, and task-definition extensions. There are no files, tests, or entry points named. Done would require a defined and accepted design for overlay and capacity clusters, rather than an isolated repository change.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws
Domain
authorization, cloud, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
18/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.