1218549 - Limit scopes for testdroid-worker clientId

Status: RESOLVED FIXED

(Taskcluster :: Services, defect)

Description

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

This clientId (XsQX5) has a star scope.  I have no idea what it does, but certainly that's too much!

Greg, any pointers?

Comment 1

[Greg Arndt [:garndt]]

Doh! Thanks for catching that.  I'll refresh my memory about all the things the testdroid client needs access to, and update the scopes here for review.  It definitely can be a lot less than *.

Comment 2

[Greg Arndt [:garndt]]

Reflagging the ni? so it stays in my queue so i get your answer.

Comment 3

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

I'm curious how it's used, too -- does the docker-worker use the credential?  Some notes in the clientId description might be useful.

Comment 4

[Greg Arndt [:garndt]]

I will update the description.  The credentials are used by the testdroid-proxy for creating a signed url for a private artifact.  This signed URL is passed to bitbar (our remote device lab) so that their stuff can download the phone build and flash a phone with it.

That should be the only scope that it requires if I recall correctly.

Comment 5

[Greg Arndt [:garndt]]

Actually, I retract what I have previously stated about that client ID....it appears that we pass in the worker's credentials to the proxy.  I will investigate.

Comment 6

[Greg Arndt [:garndt]]

Ok, now I remember what this is used for.  These are creds that we are harding coding into the flame-kk-sim-* worker types instead of using temp credentials from the provisioner.

The reasoning for this is because with the temp creds, we need to also use the certificate.  When creating a signed url using temp creds+cert, the URL is far too long for a limitation that Bitbar imposes on their build URL for flashing phones.

I have updated the description and will also keep this in mind when I'm composing a list of credentials that are needed for a given worker type.  There was another bug related to limiting the scopes on worker type creds.

Comment 7

[Greg Arndt [:garndt]]

s/harding coding/hard coded/ (/me shakes his head)

Comment 8

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

TaskDroid basically allows tasks to define what device they want, build URL, how many sims (0-2), and memory config, and then flashes and starts such a device at bitbar.

Tasks call out to the service via the testdroid proxy.  The proxy docker image has the credentials, and uses them to create signed URLs to a private artifact for the build.  Those are Hawk-signed, so containing a bewit.  With temporary credentials, the bewit was too long for the bitbar service, so the fix was to fall back to permacreds which are much shorter.

The credentials are used for all worker operations, instead of the temporary credentials provided by the AWS provisioner.

It seems like the best fix here is:
 - use the temp credentials from the provisioner for all operations except creating this signed URL
 - limit the testdroid creds to ONLY `queue:get-artifact:private/whatever/foo.img`

per irc, greg will work on that.

Comment 9

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

In the interim, I'm going to limit this client to:
  queue:get-artifact:private/*
  assume:worker-type:aws-provisioner-v1/testdroid-device

which should get all of the permissions otherwise afforded to that worker type, plus the get-artifact permission that the testdroid URL needs to sign.

Comment 10

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

It's dead, jim.