1375228 - Remove scopes from workerTypes

Status: RESOLVED WONTFIX

(Taskcluster :: Services, enhancement)

Description

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

If I'm reading the code correctly, a worker type definition's `scopes` is never consulted -- the set of scopes a worker gets is derived from the workerType.

So let's omit that field from all workerTypes and remove it from the schema, thus removing any temptation to use it :)

Comment 1

[Pete Moore [:pmoore][:pete]]

I think you could be right; the provisioner provides temporary credentials to each worker it spawns with the following two scopes:

assume:worker-id:*
assume:worker-type:aws-provisioner-v1/<workerType>

Therefore I think probably the worker type definitions' scopes fields are never consulted. John will know for sure.

Related: in bug 1374978 I'm proposing we stop requiring "assume:worker-id:<workerGroup>/<workerId>" in:

  * queue.claimTask
  * queue.reclaimTask
  * queue.reportCompleted
  * queue.reportFailed
  * queue.reportException
  * queue.createArtifact

And at that point this scope assignment in the provisioner can be reduced to just "assume:worker-type:aws-provisioner-v1/<workerType>".

Comment 2

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

(In reply to Pete Moore [:pmoore][:pete] from comment #1)
> And at that point this scope assignment in the provisioner can be reduced to
> just "assume:worker-type:aws-provisioner-v1/<workerType>".

True, but as I said in that bug, that would mean we can't prevent workers from messing with other workers' tasks, and we would like to do so (and indeed, we do so in some circumstances, just not in AWS).

Comment 3

[John Ford [:jhford] CET/CEST Berlin Time]

https://github.com/taskcluster/aws-provisioner/blob/master/src/api-v1.js#L566-L573

We allow scopes to be set in the workerType only for backwards compatibility reasons.  The credentials we actually issue are limited to:

assume:worker-id:*
assume:worker-type:aws-provisioner-v1/<workerType>

Though the response body does include the list of scopes specified in the worker type definition.  I can see how this might be confusing, so I've created https://github.com/taskcluster/aws-provisioner/pull/151 which includes the actual list of scopes included in the issued credentials.

I can start issuing real worker-id based scopes as soon as someone can tell me how to generate a valid worker id, and where that worker id needs to come from.

Maybe a better thing is using task-scopes to prevent tasks from touching other tasks?  couldn't a single worker-id technically run more than one task?

Comment 4

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

The PR just deletes the field -- but it's not landed yet.  Let's clean that up.  The specific-worker-id thing is harder and, IMHO, out of scope for this bug.

Comment 5

[Chris Cooper [:coop] (he/him)]

This will go away with aws-provisioner.