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.


Colons : 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:


rather than:



We grant scopes to clients and roles. These are defined in the ci-configuration repo; view the README.

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 (

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

Scriptworker scopes are similar, but each *script will also define script-specific scopes, like project:releng:signing:format:signcode.

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.

Restricted scopes

We define Chain of Trust cot_restricted_scopes in scriptworker. These are scopes that can only run on specific allowlisted trees or tasks_for.