Access repositories, artifacts, and other resources

TFS 2017 | TFS 2015

Note

In Microsoft Team Foundation Server (TFS) 2018 and previous versions, build and release pipelines are called definitions, runs are called builds, service connections are called service endpoints, stages are called environments, and jobs are called phases.

At run-time, each job in a pipeline may access other resources in Azure DevOps. For example, a job may:

• Check out source code from a Git repository
• Add a tag to the repository
• Access a feed in Azure Artifacts
• Upload logs from the agent to the service
• Upload test results and other artifacts from the agent to the service
• Update a work item

Azure Pipelines uses job access tokens to perform these tasks. A job access token is a security token that is dynamically generated by Azure Pipelines for each job at run time. The agent on which the job is running uses the job access token in order to access these resources in Azure DevOps. You can control which resources your pipeline has access to by controlling how permissions are granted to job access tokens.

The token's permissions are derived from (a) job authorization scope and (b) the permissions you set on project or collection build service account.

Job authorization scope

You can set the job authorization scope to be collection or project. By setting the scope to collection, you choose to let pipelines access all repositories in the collection or organization. By setting the scope to project, you choose to restrict access to only those repositories that are in the same project as the pipeline.

YAML

YAML pipelines are not available in TFS.

Classic

Job authorization scope can be set for each pipeline. To set this scope:

• Navigate to the pipeline in the Pipelines page.
• Select Edit to edit the pipeline.
• In the Options tab, select Project collection or Current project for Build job authorization scope.
• Save the build pipeline.

Note

If your pipeline is in a public project, then the job authorization scope is automatically restricted to project no matter what you configure in any setting. Jobs in a public project can access resources such as build artifacts or test results only within the project and not from other projects of the organization.

Scoped build identities

Azure DevOps uses two built-in identities to execute pipelines.

• A collection-scoped identity, which has access to all projects in the collection (or organization for Azure DevOps Services)
• A project-scoped identity, which has access to a single project

These identities are allocated permissions necessary to perform build/release execution time activities when calling back to the Azure DevOps system. There are built-in default permissions, and you may also manage your own permissions as needed.

The collection-scoped identity name has the following format:

• Project Collection Build Service ({OrgName})
• For example, if the organization name is fabrikam-tailspin, this account has the name Project Collection Build Service (fabrikam-tailspin).

The project-scoped identity name has the following format:

• {Project Name} Build Service ({Org Name})
• For example, if the organization name is fabrikam-tailspin and the project name is SpaceGameWeb, this account has the name SpaceGameWeb Build Service (fabrikam-tailspin).

By default, the collection-scoped identity is used, unless configured otherwise as described in the previous Job authorization scope section.

Manage build service account permissions

One result of setting project-scoped access may be that the project-scoped identity may not have permissions to a resource that the collection-scoped one did have.

You may want to change the permissions of job access token in scenarios such as the following:

• You want your pipeline to access a feed that is in a different project.
• You want your pipeline to be restricted from changing code in the repository.
• You want your pipeline to be restricted from creating work items.

To update the permissions of the job access token:

• First, determine the job authorization scope for your pipeline. See the section above to understand job authorization scope. If the job authorization scope is collection, then the corresponding build service account to manage permissions on is Project Collection Build Service (your-collection-name). If the job authorization scope is project, then the build service account to manage permissions on is Your-project-name Build Service (your-collection-name).

• To restrict or grant additional access to Project Collection Build Service (your-collection-name):

  • Select Manage security in the overflow menu on Pipelines page.
  • Under Users, select Project Collection Build Service (your-collection-name).
  • Make any changes to the pipelines-related permissions for this account.
  • Navigate to organization settings for your Azure DevOps organization (or collection settings for your project collection).
  • Select Permissions under Security.
  • Under the Users tab, look for Project Collection Build Service (your-collection-name).
  • Make any changes to the non-pipelines-related permissions for this account.
  • Since Project Collection Build Service (your-collection-name) is a user in your organization or collection, you can add this account explicitly to any resource - for e.g., to a feed in Azure Artifacts.

• To restrict or grant additional access to Your-project-name Build Service (your-collection-name):

  • The build service account on which you can manage permissions will only be created after you run the pipeline once. Make sure that you already ran the pipeline once.
  • Select Manage security in the overflow menu on Pipelines page.
  • Under Users, select Your-project-name Build Service (your-collection-name).
  • Make any changes to the pipelines-related permissions for this account.
  • Navigate to organization settings for your Azure DevOps organization (or collection settings for your project collection).
  • Select Permissions under Security.
  • Under the Users tab, look for Your-project-name build service (your-collection-name).
  • Make any changes to the non-pipelines-related permissions for this account.
  • Since Your-project-name Build Service (your-collection-name) is a user in your organization or collection, you can add this account explicitly to any resource - for e.g., to a feed in Azure Artifacts.