Set different levels of pipeline permissions

TFS 2017 | TFS 2015

Pipeline permissions are the permissions associated with pipelines in an Azure DevOps project. Permissions in Azure DevOps are hierarchical and can be set at the organization, server (for on-premises), project, and object levels.

Object-level permissions are designed to be more granular than organization-level permissions. 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 pipeline's permissions.

You can increase the security of your pipeline by fine-tuning the object-level permissions associated with your pipeline. To learn more about best practices for pipeline security, see Security Azure Pipelines.

To learn more about how Azure DevOps permissions work overall, including how the permissions hierarchy, see Get started with permissions, access, and security groups.

Prerequisites

• To manage permissions for project-level groups, you'll need to be a Project Administrator. Learn more about project-level group permissions. You'll need to be a member of the Project Administrators group to add users to Azure Pipelines.
• To manage permissions for collection groups, you'll need to be a Project Collection Administrator. Learn more about collection-level group permissions.

Build

Release

Set pipeline permissions

You can update pipeline permissions with security groups or by adding individual users. To learn how to add a user to Azure Pipelines, see Add users to Azure Pipelines.

When it comes to security, there are different best practices and levels of permissiveness.

• In many cases, you probably also want to set Delete build pipeline to Allow. Otherwise these team members can't delete even their own build pipelines.

• Without Delete builds permission, users cannot delete even their own completed builds. However, keep in mind that they can automatically delete old unneeded builds using retention policies.

• We recommend that you do not grant these permissions directly to a person. A better practice is to add the person to the build administrator group or another group, and manage permissions on that group.

Build and YAML pipeline permissions follow a hierarchical model. Defaults for all the permissions can be set at the project level and can be overridden on 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.

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

The following permissions are defined for pipelines. All of these can be set at both the levels.

Pipeline permissions reference

These permissions are defined for pipelines. All of these permissions can be set for both all pipelines in a project or for an individual pipeline.

To learn more about how permissions are set, including inheritance, see About permissions and inheritance. To learn how inheritance is supported for role-based membership, see About security roles

Default values for these permissions are set for team project collections and project groups. For example, Project Collection Administrators, Project Administrators, and Build Administrators are given all of the above permissions by default.

Once you've been added as a team member, you're a member 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 on default permissions, see Default permissions and access quick reference.

Set release permissions

Permissions for release pipelines follow a hierarchical model. Defaults for all the permissions can be set at the project level and can be overridden on an individual release pipeline.

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

To set or override the permissions for a specific release pipeline, open the shortcut menu from the 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 permissions are defined for releases. The scope column explains whether the permission can be set at the project, release pipeline, or stage level.

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

Set task group permissions

You can use task groups to combine a sequence of tasks already defined in a pipeline into a single, reusable task. Task groups are defined in the Task groups tab for Azure Pipelines.

Task group permissions follow a hierarchical model. Defaults for all the permissions can be set at the project level and can be overridden on an individual task group pipeline.

Task group permissions reference

Set agent pool permissions

You can use predefined roles to configure security on agent pools. You can configure this in a hierarchical manner either for all pools, or for an individual pool.

Set library permissions

Permissions for library artifacts, such as variable groups and secure files, are managed by roles. You can use a variable group to store values that you want to make available across multiple build and release pipelines. Roles are also defined to help you configure security on shared library entities such as variable groups. You can configure these roles hierarchically.

Library permissions reference

Set service connection permissions

You add users to the following roles from the project-level admin context, Services page. 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

Set deployment pool permissions

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

Deployment pool permissions reference

Related notes

• Set build and release permissions
• Default permissions and access
• Permissions and groups reference
• Troubleshoot Azure Resource Manager service connections

FAQ

Why can't I create a new pipeline?

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

If you're still unable to create a pipeline after updating this permission, check to see if your access level is set to Stakeholder. If you have stakeholder access, change your access to Basic.