Pipeline resources

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Azure Pipelines offers security beyond just protecting the YAML file and source code. When YAML pipelines run, access to resources goes through a system called checks. Checks can suspend or even fail a pipeline run in order to keep resources safe. A pipeline can access two types of resources, protected and open.

Protected resources

Your pipelines often have access to secrets. For instance, to sign your build, you need a signing certificate. To deploy to a production environment, you need a credential to that environment. Azure Pipelines requires the Administrator role when opening up access to a resource to all pipelines for all protected resources except for Environments. For Environments, you'll need the Creator role. Learn more about resource protection.
In Azure Pipelines, all of the following are considered protected resources in YAML pipelines:

• Agent pools
• Secret variables in variable groups
• Secure files
• Service connections
• Environments
• Repositories

"Protected" means:

• They can be made accessible to specific users and specific pipelines within the project. They can't be accessed by users and pipelines outside of a project.
• You can run other manual or automated checks every time a YAML pipeline uses one of these resources. To learn more about protected resources, see About pipeline resources.

Protecting repository resources

Repositories can optionally be protected. At the organization or project level, you may choose to limit the scope of the Azure Pipelines access token to mentioned repositories. When you do this, Azure Pipelines will add two more protections:

• The access token given to the agent for running jobs will only have access to repositories explicitly mentioned in the resources section of the pipeline.
• Repositories added to the pipeline will have to be authorized by someone with contribute access to the repository the first time that pipeline uses the repository.

This setting is on by default for all organizations created after May 2020. Organizations created before that should enable it in Organization settings.

Open resources

All the other resources in a project are considered open resources. Open resources include:

• Artifacts
• Pipelines
• Test plans
• Work items

You'll learn more about which pipelines can access what resources in the section on projects.

User permissions

The first line of defense for protected resources is user permissions. In general, ensure that you only give permissions to users who require them. All protected resources have a similar security model. A member of user role for a resource can:

• Remove approvers and checks configured on that resource
• Grant access to other users or pipelines to use that resource

Pipeline permissions

When you use YAML pipelines, user permissions aren't enough to secure your protected resources. You can easily copy the name of a protected resource (for example, a service connection for your production environment) and include that in a different pipeline. Pipeline permissions protect against such copying. For each of the protected resources, ensure that you've disabled the option to grant access to "all pipelines". Instead, explicitly granted access to specific pipelines that you trust.

Checks

In YAML, a combination of user and pipeline permissions isn't enough to fully secure your protected resources. Pipeline permissions to resources are granted to the whole pipeline. Nothing prevents an adversary from creating another branch in your repository, injecting malicious code, and using the same pipeline to access that resource. Even without malicious intent, most pipelines need a second set of eyes look over changes (especially to the pipeline itself) before deploying to production. Checks allow you to pause the pipeline run until certain conditions are met:

• Manual approval check. Every run that uses a project protected resource is blocked for your manual approval before proceeding. Manual protection gives you the opportunity to review the code and ensure that it's coming from the right branch.
• Protected branch check. If you have manual code review processes in place for some of your branches, you can extend this protection to pipelines. Configure a protected branch check on each of your resources. This will automatically stop your pipeline from running on top of any user branches.
• Protected resource check You can add checks to environments, service connections, repositories, variable groups, agent pools, variable groups, and secure files to specify conditions that must be satisfied before a stage in any pipeline can consume a resource. Learn more about checks and approvals.

Next steps

Next, consider how you group resources into a project structure.