Set pipeline permissions

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

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.

Pipeline permissions and roles help you securely manage your pipelines. You can set hierarchical permissions at the organization, project, and object levels for all pipelines in a project or for an individual pipeline. You can update pipeline permissions with security groups or by adding individual users.

Pipeline permissions and roles help you securely manage your pipelines. You can set hierarchical permissions at the organization, server, project, and object levels for all pipelines in a project or for an individual pipeline. You can update pipeline permissions with security groups or by adding individual users.

Object-level permissions are more granular than organization-level permissions, so you can increase the security of your pipeline. For example, a user could have access to your Azure Repos repository thanks to their organization-level permissions. However, that same user could be prevented from running a pipeline manually because of that object/pipeline's permissions.

In this article, we break down the permissions to the following levels of permissions:

For more information, see Get started with permissions, access, and security groups, Securing Azure Pipelines, and Verify permissions for contributors.

Prerequisites

  • To manage permissions and add users to Azure Pipelines for project-level groups, you must be a Project Administrator. For more information, see Project-level group permissions.
  • To manage permissions for collection groups, you must be a Project Collection Administrator. For more information, see collection-level group permissions.
  • Keep the following information in mind when you're setting pipeline permissions.
    • In many cases, you might want to set Delete build pipeline to Allow. Otherwise, these team members can't delete their own build pipelines.
    • Without the Delete builds permission, users can't delete their own completed builds. However, they can automatically delete old unneeded builds with retention policies.
    • We recommend that you don't grant permissions directly to a user. A better practice is to add the user to the build administrator group or another group, and manage permissions for that group.

For more information and best practices, see Securing Azure Pipelines.

Default permissions assigned to built-in security groups

Build

Task Readers Contributors Build Admins Project Admins
View builds ✔️ ✔️ ✔️ ✔️
View build pipeline ✔️ ✔️ ✔️ ✔️
Administer build permissions ✔️ ✔️
Delete or edit build pipeline ✔️ ✔️ ✔️
Delete or destroy builds ✔️ ✔️
Edit build quality ✔️ ✔️ ✔️
Manage build qualities ✔️ ✔️
Manage build queue ✔️ ✔️
Override check-in validation by build ✔️
Queue builds ✔️ ✔️ ✔️
Retain indefinitely ✔️ ✔️ ✔️ ✔️
Stop builds ✔️ ✔️
Update build information ✔️

Release

Task Stakeholders Readers Contributors Project Admins Release Admins
Approve releases ✔️ ✔️ ✔️ ✔️
View releases ✔️ ✔️ ✔️ ✔️ ✔️
View release pipeline ✔️ ✔️ ✔️ ✔️
Administer release permissions ✔️ ✔️
Delete release pipeline or stage ✔️ ✔️ ✔️
Delete releases ✔️ ✔️ ✔️
Edit release pipeline ✔️ ✔️
Edit release stage ✔️ ✔️ ✔️
Manage deployments ✔️ ✔️
Manage release approvers ✔️ ✔️ ✔️
Manage releases ✔️ ✔️

Task groups

Task Readers Contributors Build Admins Project Admins Release Admins
Administer task group permissions ✔️ ✔️ ✔️
Delete task group ✔️ ✔️ ✔️
Edit task group ✔️ ✔️ ✔️

Default permissions assigned to built-in security groups

Build

Task

Readers

Contributors

Build
Admins

Project Admins

View builds

✔️

✔️

✔️

✔️

View build definition

✔️

✔️

✔️

✔️

Administer build permissions

✔️

✔️

Delete or Edit build definitions

✔️

✔️

✔️

Delete or Destroy builds

✔️

✔️

Edit build quality

✔️

✔️

✔️

Manage build qualities

✔️

✔️

Manage build queue

✔️

✔️

Override check-in validation by build

✔️

Queue builds

✔️

✔️

✔️

Retain indefinitely

✔️

✔️

Stop builds

✔️

✔️

Update build information

✔️

Release

Task

Readers

Contributors

Project Admins

Release
Admins

Approve releases

✔️

✔️

✔️

View releases

✔️

✔️

✔️

✔️

View release definition

✔️

✔️

✔️

✔️

Administer release permissions

✔️

✔️

Delete release definition or release stage

✔️

✔️

✔️

Delete releases

✔️

✔️

✔️

Edit release definition

✔️

✔️

Edit release stage

✔️

✔️

✔️

Manage deployments

✔️

✔️

Manage release approvers

✔️

✔️

✔️

Manage releases

✔️

✔️

Set project-level pipeline permissions

Do the following steps to set project-level permissions for all pipelines.

  1. Sign in to your organization (https://dev.azure.com/{yourorganization}).

  2. From within your project, select Pipelines > Pipelines.

    Screenshot showing ordered Pipelines menu selections.

  3. Select More actions > Manage security.

    Screenshot showing ordered selections to Manage security for all pipelines in a project.

  4. Modify the permissions associated with an Azure DevOps group, for example, Build Administrators, or for an individual user.

  5. Select Allow or Deny for the permission for a security group or an individual user, and then exit the screen.

Your project-level pipelines permissions are set.

Build and YAML pipeline permissions follow a hierarchical model. You can set defaults for all permissions at the project-level and override permissions for an individual build pipeline.

To set the permissions at project-level for all pipelines in a project, choose Security from the action bar on the main page of Builds hub.

Set individual pipeline permissions

Do the following steps to set permissions for an individual pipeline.

  1. From within your project, select Pipelines > Pipelines.

    Screenshot showing Pipelines ordered menu selections.

  2. Select an individual pipeline, and then select More actions > Manage security.

    Screenshot showing selected Manage security option from an individual pipeline's more actions menu.

  3. Set permissions, and then Save your changes.

To set or override the permissions for an individual pipeline, choose Security from the context menu of the individual pipeline.

Pipeline permissions reference

You can set the following permissions for all pipelines in a project or for an individual pipeline. Default values are set for project collections and project groups. For example, Project Collection Administrators, Project Administrators, and Build Administrators have all these permissions by default.

Permission Description
Administer build permissions Can change any of the other permissions listed here.
Delete build pipeline Can delete build pipeline(s).
Delete builds Can delete builds for a pipeline. Deleted builds are retained in the Deleted tab for a period before they're destroyed.
Destroy builds Can delete builds from the Deleted tab.
Edit build pipeline Can create pipelines and save any changes to a build pipeline, including configuration variables, triggers, repositories, and retention policy.
Edit build quality Can add tags to a build.
Manage build qualities Only applies to XAML builds
Manage build queue Only applies to XAML builds
Override check-in validation by build Applies to TFVC gated check-in builds. Doesn't apply to pull request builds.
Queue builds Can queue new builds.
Retain indefinitely Can toggle the retain indefinitely flag on a build.
Stop builds Can stop builds queued by other team members or by the system.
Update build information It is recommended to leave this alone. It's intended to enable service accounts, not team members.
View build pipeline Can view build pipeline(s).
View builds Can view builds belonging to build pipeline(s).

All team members are members of the Contributors group. This group permission allows you to define and manage builds and releases. The most common built-in groups include Readers, Contributors, and Project Administrators.

For more information, see the following articles:

Set release permissions

Permissions for release pipelines follow a hierarchical model. You can set default permissions at the project-level, and you can override these permissions on an individual release pipeline.

Set all release permissions

Do the following steps to update permissions for all releases.

  1. Select the file view.

    Screenshot showing selection of the all files view.

  2. Select the All pipelines folder.

    Screenshot showing selection of all pipelines folder.

  3. Select More actions and select Security.

  4. Set permissions, and then Save your changes.

Set individual release permissions

Do the following steps to update permissions for an individual release.

  1. Select the release you want to modify.

  2. Select More actions > Security.

  3. Set permissions, and then Save your changes.

To set permissions at project-level for all release definitions in a project, open the shortcut menu from the drop-down list

To set or override the permissions for a specific release pipeline, open the shortcut menu from the drop-down list icon next to that pipeline name. Then choose Security to open the Permissions dialog.

To specify security settings for individual stages in a release pipeline, open the Permissions dialog by choosing Security on the shortcut menu that opens from More actions on a stage in the release pipeline editor.

Release permissions reference

The following table defines permissions for releases. The scope column explains whether the permission can be set at the project, release pipeline, or stage level.

Permission Description
Administer release permissions Can change any of the other permissions listed here.
Scopes: Project, Release pipeline, Stage
Create releases Can create new releases.
Scopes: Project, Release pipeline
Delete release pipeline Can delete release pipeline(s).
Scopes: Project, Release pipeline
Delete release stage Can delete stage(s) in release pipeline(s).
Scopes: Project, Release pipeline, Stage
Delete releases Can delete releases for a pipeline.
Scopes: Project, Release pipeline
Edit release pipeline Can save any changes to a release pipeline, including configuration variables, triggers, artifacts, and retention policy as well as configuration within a stage of the release pipeline. To update a specific stage in a release pipeline, the user also needs Edit release stage permission.
Scopes: Project, Release pipeline
Edit release stage Can edit stage(s) in release pipeline(s). To save the changes to the release pipeline, the user also needs Edit release pipeline permission. This permission also controls whether a user can edit the configuration inside the stage of a specific release instance. The user also needs Manage releases permission to save the modified release.
Scopes: Project, Release pipeline, Stage
Manage deployments Can initiate a deployment of a release to a stage. This permission is only for deployments that are manually initiated by selecting the Deploy or Redeploy actions in a release. If the condition on a stage is set to any type of automatic deployment, the system automatically initiates deployment without checking the permission of the user that created the release. If the condition is set to start after some stage, manually initiated deployments do not wait for those stages to be successful.
Scopes: Project, Release pipeline, Stage
Manage release approvers Can add or edit approvers for stage(s) in release pipeline(s). This permission also controls whether a user can edit the approvers inside the stage of a specific release instance.
Scopes: Project, Release pipeline, Stage
Manage releases Can edit the configuration in releases. To edit the configuration of a specific stage in a release instance (including variables marked as settable at release time), the user also needs Edit release stage permission.
Scopes: Project, Release pipeline
View release pipeline Can view release pipeline(s).
Scopes: Project, Release pipeline
View releases Can view releases belonging to release pipeline(s).
Scopes: Project, Release pipeline

Default values for all permissions are set for team project collections and project groups. For example, Project Collection Administrators, Project Administrators, and Release Administrators are given all the previously listed permissions by default. Contributors are given all permissions except Administer release permissions. By default, Readers are denied all permissions except View release pipeline and View releases.

Set task group permissions

Use task groups to combine a sequence of tasks already defined in a pipeline into a single, reusable task.

Task group permissions follow a hierarchical model. You can set default permissions at the project-level, and you can override these permissions on an individual task group pipeline.

Set project-level task group permissions

Do the following steps to update permissions for project-level task groups.

Note

Task groups aren't supported in YAML pipelines, but templates are. For more information, see YAML schema reference.

  1. From your project, select Pipelines > Task groups.

    Find task group menu item.

  2. Select Security.

    Select the Security option for a task group.

  3. Select Allow or Deny for the permission for a security group or an individual user.

Set pipeline-level task group permissions

Do the following steps to update permissions for pipeline-level task groups.

  1. From your project, select Pipelines > Task groups.

    Find task group menu item.

  2. Select a task group.

  3. Select More actions > Security.

  4. Select Allow or Deny for the permission for a security group or an individual user.

Task group permissions reference

Permission Description
Administer task group permissions Can add and remove users or groups to task group security.
Delete task group Can delete a task group.
Edit task group Can create, modify, or delete a task group.

Set agent pool permissions

You can use predefined roles to configure security on agent pools in a hierarchical manner for all pools, or for an individual pool. Do the following steps to set agent pool permissions for all pools.

Set all agent pool permissions

Do the following steps to update permissions for all agent pools.

  1. From your project, select Project settings > Agent pools.

  2. Select Security.

    Configure agent pool security.

  3. Set permissions, and then Save your changes.

Set individual agent pool permissions

Do the following steps to set permissions for an individual agent pool.

  1. From the agent pool, select the agent.

  2. Select Security.

    Set security for one agent pool.

  3. Set permissions, and then Save your changes.

Set library permissions

Use a variable group to store values that you want to make available across multiple build and release pipelines. Define roles to help you configure security on shared library entities. You can also configure the inheritance of roles.

Do the following steps to manage permissions for library artifacts, such as variable groups and secure files.

  1. From your project, select Pipelines > Library.

    Open the Library menu option.

  2. Select Security.

    Security option in Library.

  3. Set permissions for everything in your library or for an individual variable group or secure file, and then Save your changes.

Library permissions reference

Role Description
Administrator Can edit/delete and manage security for library items.
Creator Can create library items.
Reader Can only read library items.
User Can consume library items in pipelines.

Set service connection permissions

Configure permissions for all service connections or for an individual connection.

Set all service connection permissions

Do the following steps to configure permissions for all service connections.

  1. From within your project, select Project settings .
  2. Select Service connections under Pipelines.
  3. Set permissions, and then Save your changes.

Set individual service connection permissions

Do the following steps to configure permissions for an individual service connection.

  1. From within your project, open a service connection.

  2. Select More actions > Security.

  3. Set permissions, and then Save your changes.

    Select security service connection option.

Add users to the following roles from the project-level admin context, Services page. For more information about how to create and manage these resources, see Service connections for build and release.

If you're having trouble with permissions and service connections, see Troubleshoot Azure Resource Manager service connections.

Service connection permissions reference

Role Description
User Can use the endpoint when authoring build or release pipelines.
Administrator Can manage membership of all other roles for the service connection as well as use the endpoint to author build or release pipelines. The system automatically adds the user that created the service connection to the Administrator role for that pool.

Set deployment pool permissions

You can set default security roles for all deployment groups and manage security roles for an individual deployment group.

Set all deployment pool permissions

  1. From within your project, select Project settings .

  2. Select Deployment groups under Pipelines.

  3. Set permissions, and then Save your changes.

    Select Security to manage default deployment group permissions.

Set individual deployment group permissions

  1. From within your project, open a deployment pool.
  2. Select More actions > Security.
  3. Set permissions, and then Save your changes.

Deployment pool permissions reference

Role Description
Reader Can only view deployment pools.
Service Account Can view agents, create sessions, and listen for jobs from the agent pool.
User Can view and use the deployment pool for creating deployment groups.
Administrator Can administer, manage, view and use deployment pools.

Set environment permissions

You can use roles and user permissions to control who can create, view, and manage environments. Apply a hierarchy of roles to all environments or one environment.

Set all environment permissions

  1. From within your project, select Project settings .

  2. Select Environments under Pipelines.

  3. Set permissions, and then Save your changes.

    Select Environments.

Set individual environment permissions

Select Security from More actions to change permissions for all environment.

  1. From within your project, open an environment.
  2. Select More actions > Security.
  3. Set permissions, and then Save your changes.

Environment permissions reference

Important

When you create an environment in a YAML, contributors and project administrators have the administrator role. When you create an environment through the UI, only the creator has the administrator role.

Role Description
Creator Global role, available from environments hub security option. Members of this role can create the environment in the project. Contributors are added as members by default. Required to trigger a YAML pipeline when the environment does not already exist.
Reader Members of this role can view the environment.
User Members of this role can use the environment when creating or editing YAML pipelines.
Administrator In addition to using the environment, members of this role can manage membership of all other roles for the environment. Creators are added as members by default.

FAQs

See the following frequently asked questions (FAQs) about pipeline permissions.

Q: Why can't I create a new pipeline?

A: You need Edit build pipeline permissions to create a new pipeline. To add permission, open the security settings for all pipelines and verify that Edit build pipeline is set to Allow for your security group.

If you still can't create a pipeline, check to see if your access level is set to Stakeholder. If you have stakeholder access, change your access to Basic.

Q: Why do I see the message that I need to authorize a resource before the run can continue?

A: You need to authorize resources before you can use them. The exception to this rule is when you create a pipeline for the first time and all the resources referenced in the YAML file are automatically authorized. The resources are authorized for the pipeline as long as the user running the pipeline has access to the resource.

To authorize All pipelines to access a resource like an agent pool, do the following steps.

  1. From your project, select Settings > Pipelines > Agent Pools.

  2. Select Security for a specific agent pool, and then update permissions to grant access to all pipelines.

    Grant permissions to all pipelines.

    For more information, see Resources in YAML.