1140647 - attach additional scopes to try tasks for pushers with more scopes

Status: RESOLVED WONTFIX

(Taskcluster :: Services, defect)

Description

[James Lal [:lightsofapollo]]

As part of locking down scopes for try we have some legal considerations around what we can run... The short version is mozilla employees have access to some bits others do not (we have no control to change this)...

Currently those bits are accessed by the "flame-kk" worker type and in the future by the worker type that runs our bitbar jobs... Basically anything that touches the phone builds.

Try would get reduced scopes to only a subset of worker-types.
Try+ would receive additional scopes (based on worker type likely) if the email address associated with the pushlog (I verified the pushlog data is trustworthy) is an @mozilla.com address...

---

The initial workflow will simply fail to generate a graph if scopes are insufficient. Given we know scopes up front we could improve this UX later on...

Comment 1

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

Since the task scheduling part of mozilla-taskcluster component is being replaced by the new vcs scheduler in bug 1158272, I'm marking this bug as hanging off that one.

Since bug 1158272 is being worked on by RelEng, I'm removing this from the TaskCluster team 2015/Q3 deliverables.

Technically this bug doesn't need to be completed before 1158272, so doesn't need to be a dependency. I just put it there for now since it maybe makes sense to implement at the same time. Feel free to remove the dependency though if it is preferred to do it later.

Comment 2

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

Erm, actually as I made this bug dependent on 1158272, this bug should be completed *after* 1158272, which is more logical. No point doing it before we have the new vcs scheduler. :)

Comment 3

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

I'm vaguely uncomfortable with this idea in general :)

Filtering on @mozilla.com doesn't make a lot of sense here.  However, we could have mozilla-taskcluster do an LDAP lookup of the pusher's LDAP or mozillians groups, and attach some corresponding roles to the task-graph permissions in that case.  I don't think those should be the *same* roles, though: for example, if I have the `nda` group, that doesn't mean my tasks should have access to everything that NDA allows me to read; it means my tasks should have access to various bits of INTERNAL data.

This is somewhat important as it addresses a gap between people with scm_level_1 access (who can push to try) and people with nda access (who can legitimately access the "INTERNAL" data such as Android NDK/SDK which is required to build Android in try).  But since at this point that INTERNAL data is available directly from Google for the price of signing an agreement, I can't see anyone bothering to write a malicious try job to download it from us instead.

Comment 4

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

I'm way more uncomfortable with this now.  It's difficult to reason about from a security standpoint, which means we're likely to open up a route for privilege escalation, or at least confuse users into doing silly things.  And I have a hard time seeing how one try job would "know" it has more privileges and do something more than another try job with fewer privileges.  Does that person with fewer privileges just not get the same test coverage?  How can they confidently land a patch?  How does all of this interact with autolander -- do we trust autolander to correctly authenticate someone, record that in a trustworthy fashion in the try tree, and then reflect that accurately into task scopes?  Yikes!

I don't see any great upside here, either, that would justify tasking the risk and adding the complexity.