1228100 - Reduce scopes available to client-id:tc-queue

Status: RESOLVED FIXED

(Taskcluster :: Services, defect)

Description

[Dustin J. Mitchell [:dustin] (he/him)]

This role currently has *.  Because it's used to issue temp creds to the worker for each task, it needs to have scopes that satisfy task.scopes for all tasks.  That's quite a lot, but probably not *.

I think we could look at this in two ways.

1. What do we never want a task to do?  `auth:*` comes to mind, along with `hooks:*`.

2. How could we build this client's scopes up from a set of roles which, taken collectively, satisfy all tasks?  `assume:repo:*` is a decent start, along with `assume:hook-id:*`, but that would still preclude users injecting non-repo-based tasks that happened to want permissions not given to a hook or a repo.\

Maybe a mix of the two??

Comment 1

[Jonas Finnemann Jensen (:jonasfj)]

The queue is a uniquely central component to taskcluster.
For this reason I would advice '*'.

There are auth: end-points that could be used by tasks. The two granting access to azure table storage or s3 STS creds immediately springs to mind.

Also the scope delegation concept sort of falls apart with this. We can do less than * for most other components that delegates scopes, but queue is an acceptable exception to me.

For others like hooks, provisioner we delegate scopes using roles. So it's sane, but for queue I think this is sane.
Unless we replace task.scopes with task.role. but that is very inflexible...

Comment 2

[Dustin J. Mitchell [:dustin] (he/him)]

I should have been more explicit: the queue doesn't need scopes like auth:reset-access-token:*, or hooks:create-hook:*, as no task should be resetting access tokens or creating hooks.

But all of those would merely be stepping stones to escalate privileges to those contained in task.scopes -- so you're probably right that `*` is practically the best we can do.