Consider overriding role policies in addition to roles themselves
- Dominant language
- Shell
- Stars
- 5.4k
- Forks
- 334
- PR merge metrics
- No merged PRs in 30d
Description
Currently, the only way to override role _policies_ within a task is to define a _new role_ and provide it via `overrides.taskRoleArn` in `runTask`/`startTask` calls.
However, some applications may require a more fine-grained approach, where one may need to override (scope down) individual _policies_, much like what's already possible with an `AssumeRole` call for other APIs. In addition, there's a default maximum limit of 250 roles per account, which seems restrictive if one needs to run many instances of a particular task definition with a larger number of uniform variations in role policies (e.g. each task could have access only to a certain prefix in a particular S3 bucket). In addition, it gets harder to manage these roles because we'd need to define and remove them dynamically, while there are no "families" of roles that would signify slight variations between one over-arching role.
It seems that implementing a "role _policy_ overrides" parameter could be done while preserving compatibility with existing APIs.
Contributor guide
Research direction
Start by reviewing how overrides.taskRoleArn is handled in the runTask and startTask APIs, then compare the requested policy-scoping behavior with AssumeRole. Done means defining a backward-compatible policy override parameter that supports per-task policy variations without requiring a new role for each variation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws
- Domain
- authorization
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100