|
| 1 | +# RFC 175 - Restricted Roles for Github Pull Requests |
| 2 | + |
| 3 | +# Summary |
| 4 | + |
| 5 | +Assume different roles for Github Pull Requests based on the PR author's association to the project. |
| 6 | + |
| 7 | +## Motivation |
| 8 | + |
| 9 | +Currently Taskcluster's [pullRequest policy][0] is very basic. It can either generate graphs for |
| 10 | +everyone, or only for collaborators. If a project has a task that can access secrets or perform |
| 11 | +actions that shouldn't be triggered publicly, then the only recourse is to not generate *any* graph |
| 12 | +so long as the author is not at least a collaborator. |
| 13 | + |
| 14 | +However, projects commonly have non-sensitive tasks that *could* otherwise be run publicly. Having |
| 15 | +distinct roles based on author association would allow projects to generate graphs for public pull |
| 16 | +requests, while simultaneously blocking these graphs from running sensitive tasks via scopes. |
| 17 | + |
| 18 | +The motivations for this RFC overlap with [RFC 168][1]. |
| 19 | + |
| 20 | +# Details |
| 21 | + |
| 22 | +A new `pullRequest` policy called `public_restricted` will be invented. When used, Taskcluster |
| 23 | +Github will inspect the author association of the pull request to determine whether or not they are |
| 24 | +a collaborator. If they are determined to be a collaborator, the current [pull-request][2] role will |
| 25 | +be assumed. So far this behavior is identical to the `collaborators` policy. |
| 26 | + |
| 27 | +However if the author is not a collaborator, a new role called `repo:github.com/${ |
| 28 | +payload.organization }/${ payload.repository }:pull-request-untrusted` will be assumed instead. |
| 29 | + |
| 30 | +To allow projects to tell whether a pull request was created by a collaborator or not, a new |
| 31 | +`tasks_for` value of `github-pull-request-untrusted` will be used to evaluate the |
| 32 | +`.taskcluster.yml` file. |
| 33 | + |
| 34 | +## Using the `public_restricted` policy |
| 35 | + |
| 36 | +Using the `public_restricted` policy will require that both the Taskcluster instance and the project |
| 37 | +are configured properly. While the details around this configuration are out of scope for this RFC, |
| 38 | +it's worth providing a brief example to help illustrate how the feature might be used. |
| 39 | + |
| 40 | +### Instance Configuration |
| 41 | + |
| 42 | +Taskcluster administrators will need to ensure the `pull-request-untrusted` roles exist for any |
| 43 | +projects that use the `public_restricted` policy. They'll also need to ensure that scopes are |
| 44 | +properly assigned to block running any sensitive tasks on untrusted pull requests. |
| 45 | + |
| 46 | +### Task Configuration |
| 47 | + |
| 48 | +Projects that use the `public_restricted` policy will need to make sure they don't try to run |
| 49 | +trusted tasks on untrusted PRs, otherwise they'll get a scope expression error. They'll be able to |
| 50 | +accomplish this by inspecting the `tasks_for` field that Taskcluster Github now passes down to the |
| 51 | +JSON-e context and checking for a value of `github-pull-request-untrusted`. |
| 52 | + |
| 53 | +In the case of a plain `.taskcluster.yml` file, this value could be used in a JSON-e conditional |
| 54 | +statement. In the case of Taskgraph, this could be passed in via a new parameter. |
| 55 | + |
| 56 | +[0]: https://docs.taskcluster.net/docs/reference/integrations/github/taskcluster-yml-v1#pull-requests |
| 57 | +[1]: https://github.com/taskcluster/taskcluster-rfcs/blob/main/rfcs/0168-Trigger-Tests-Based-on-PR-Comments.md |
| 58 | +[2]: https://github.com/taskcluster/taskcluster/blob/b31b890043847059c2d09dc7e2428814b9b51c0b/services/github/src/tc-yaml.js#L184 |
0 commit comments