1273096 - Use the accessToken generated by login.taskcluster.net to interact with Taskcluster APIs

Status: RESOLVED FIXED

(Tree Management :: Treeherder, defect, P3)

Description

[Ed Morley [:emorley]]

Currently when a Treeherder user retriggers a Taskcluster job, the request is sent via Pulse and Treeherder includes the user's email address, asserting that it does belong to the user who initiated the request.

Due to the microservices nature of Taskcluster, the individual APIs themselves are unable to map from this email address to the list of scopes, so currently pulse_actions has to just whitelist *@mozilla.com addresses. This excludes contributors (who then have to be manually added to the whitelist) as well as undermines the whole point of having fine-grained scopes.

In order to resolve this, requests to Taskcluster's APIs should use the user's clientId/accessToken/certificate, so the APIs can determine if they have sufficient permissions.

Once bug 1273034 has Treeherder using login.taskcluster.net as a SSO solution, we can use the accessToken it generates, via either:

1) Storing the accessToken/... in localStorage (like tools.taskcluster.net does) and making the Taskcluster API requests client side.

2) Storing the accessToken/... in the Django user table, and making requests to Taskcluster's API server side.

There are obviously pros/cons of each approach. It's also worth noting that since we're using login.taskcluster.net for login, we're going to have to pass the accessToken to the Treeherder backend either way (for verification), even if we don't end up storing it in the DB.

(This bug is essentially what bug 1032163 was originally filed for.)

Comment 2

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

Worth noting that, rather than passing the accessToken to the backend, you could just use it to make a Hawk request to the backend, and verify that request using auth.authenticateHawk, which will give you the user's set of scopes.

Comment 3

[Armen [:armenzg]]

> In order to resolve this, requests to Taskcluster's APIs should use the user's 
> clientId/accessToken /certificate, so the APIs can determine if they have sufficient permissions.

When I experimented with this the user credentials were lacking the treeherder scopes.

Also, users want and need to be able to interact pushes that they have not pushed.
We can restrict repositories to users depending on their commit scm level.

Works for you?

Comment 4

[Ed Morley [:emorley]]

(In reply to Armen Zambrano [:armenzg] - Engineering productivity from comment #3)
> Works for you?

Anything works for me really - this bug is more for to try and "do the right thing", whatever that may be. (I have no stake in the TC parts, other than obviously not wanting to contribute to a security issue.)

Comment 5

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

I think we should give users the treeherder routes, rather than work around that.

Comment 6

[Armen [:armenzg]]

(In reply to Dustin J. Mitchell [:dustin] from comment #5)
> I think we should give users the treeherder routes, rather than work around
> that.

That would be great. Want me to file a bug?

Comment 7

[Armen [:armenzg]]

dustin: ^ (I would use NI but it not is allowed)

Comment 8

[GitHub Autolander Bot]

Attachment: [treeherder] imbstack:bug-1273096 > mozilla:master

Comment 9

[Cameron Dawson [:camd]]

Comment on attachment 8823368 [details] [review]
[treeherder] imbstack:bug-1273096 > mozilla:master

Looks good.  Thanks!!

Comment 10

[Treeherder GitHub Bugbot]

Commit pushed to master at https://github.com/mozilla/treeherder

https://github.com/mozilla/treeherder/commit/b1af249f1b049bb5f54342ad6fea37b5bd62f568
Bug 1273096 - Interact with taskcluster directly (#2057) (#2057)

Add taskcluster credentials to local storage for use against
taskcluster api directly, rather than via pulse messages and
pulse_actions. This only ports backfilling for now, but eventually
all actions should be possible with this setup.