Scopes are effectively permissioning, or ACLs, for Taskcluster. The official definition of scopes is here. They’re essentially strings; if your set of scopes or scope patterns match the required scopes, you have the required scopes.
For example, if you have the scopes:
And the required scopes are:
Then you have the required scopes. However, if you need
a-little-bit-secret/something-else, you don’t have the required scopes.
: are delimiters for the official platform defined scopes and scope prefixes. We also use dashes
- and slashes
/ as word delimiters in the user-defined portions of the scope strings. (Also, periods
. for index delimiters.) If you define a scope pattern with a trailing asterisk
*, it’s best practice to append the asterisk after a word delimiter:
The ci-configuration repo also contains the ci-admin management tool which we use to test, diff, and apply the configuration changes.
Groups / teams¶
We try to tie most user scope grants to LDAP. Grants to
mozilla-group:GROUP will assign the scopes to users that belong to that MoCo ldap group. Grants to
mozillians-group:GROUP will grant scopes to users that belong to that Mozillians group (people.mozilla.org).
We also define
ci-group roles like
project:releng:ci-group:team_moco in this block.
Levels in scopes match the Firefox commit levels. Level 1 is Try and pull requests; contributors can easily get this level of access. Level 2 is projects and l10n, and isn’t used everywhere. Level 3 is release level, and requires a higher bar to gain this level of access. Ideally contributors will be able to get everything done at level 1 unless they become a trusted member of a project.
We encode levels in workerType/workerPool names, and in other scopes that should be restricted by repo and commit level. For example, the
gecko-1/decision worker is the decision worker for Try.
gecko-3/decision is the trusted decision worker for release trains and autoland.
Docker- and Generic-Worker scopes¶
The scopes for docker- and generic-worker workers should be minimal, just enough to register as a given workerType and claim tasks from the queue. They will be granted temporary scopes for each task that they run.
Scriptworker scopes are similar, but each
*script will also define script-specific scopes, like
In addition, until we fix Issue #426 (use temp queue to download artifacts), we also need to grant private artifact scopes to the clientId as well as the task.
We define Chain of Trust cot_restricted_scopes in scriptworker. These are scopes that can only run on specific allowlisted trees or