แชร์ผ่าน

Access repositories, artifacts, and other resources

  • บทความ

TFS 2018

Note

Microsoft Visual Studio Team Foundation Server 2018 and earlier versions have the following differences in naming:

  • Pipelines for build and release are called definitions
  • Runs are called builds
  • Service connections are called service endpoints
  • Stages are called environments
  • 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.

If you use Azure DevOps Server 2019, then all YAML jobs run with the job authorization scope set to collection. In other words, these jobs have access to all repositories in your project collection. You cannot change this in Azure DevOps Server 2019.

YAML pipelines are not available in TFS.

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.

FAQ

How do I determine the job authorization scope of my classic build pipeline?

  • Open the editor for the pipeline and navigate to the Options tab.
    • If the Build job authorization scope is Current project, then scope is project.
    • Otherwise, scope is collection.

How do I determine the job authorization scope of my classic release pipeline?

Classic release pipelines in Azure DevOps Server 2020 and below run with collection scope.