About resources for Azure Pipelines
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
A resource is anything used by a pipeline that lives outside the pipeline.
Resources offer the following benefits:
- Ways to share something such as a secure file or password across pipelines.
- Examples of using resources for sharing are variable groups, secure files, and service connections. In all cases, you're using a resource as a way for a pipeline to access and consume something.
- A tool for enhancing security through access checks and other restrictions.
- For example, you can limit a service connection to only run on one pipeline. You could also make sure that a repository can only be accessed from a pipeline after a manual approval check.
- Ways to improve traceability for your pipeline and make it easier to troubleshoot environments.
- For example, you can see the number of the last run that was deployed to an environment.
Share resources across pipelines
Share resources across pipelines by configuring them within the pipelines UI. Then, reference those resources in a task. You can also access some shared resources with the resources YAML pipeline syntax.
Examples of sharing resources with the pipelines UI include secure files, variable groups, and service connections. With the resources syntax, examples include accessing pipelines themselves, repositories, and packages.
How a resource gets used in a pipeline depends on the type of pipeline and type of resource.
For YAML pipelines:
- Service connections and secure files are directly used as inputs to tasks and don't need to be predeclared.
- Variable groups use the
groupsyntax. - Pipelines and repositories use the
resourcessyntax.
For example, to use variable groups in a pipeline, add your variables at Pipelines > Library. Then, you can reference the variable group in your YAML pipeline with the variables syntax.
variables:
- group: my-variable-group
To call a second pipeline from your pipeline with the resources syntax, reference pipelines.
resources:
pipelines:
- pipeline: SmartHotel-resource # identifier for the resource (used in pipeline resource variables)
source: SmartHotel-CI # name of the pipeline that produces an artifact
Use resources to enhance security
You can enhance your pipeline's security with resources by identifying how the resource gets consumed, and how to prevent unauthorized access.
For YAML pipelines only, set resources as protected or open. When a resource is protected, you can apply approvals and checks to limit access to specific users and YAML pipelines. Protected resources include service connections, agent pools, environments, repositories, variable groups, and secure files.
| Resource | How is it consumed? | How do you prevent an unintended pipeline from using this? |
|---|---|---|
| service connections | Consumed by tasks in a YAML file that use the service connection as an input. | Protected with checks and pipeline permissions. Checks and pipeline permissions are controlled by service connection users. A resource owner can control which pipelines can access a service connection. You can also use pipeline permissions to restrict access to particular YAML pipelines and all classic pipelines. |
| secret variables in variable groups | A special syntax exists for using variable groups in a pipeline or in a job. A variable group gets added like a service connection. | Protected with checks and pipeline permissions. Checks and pipeline permissions are controlled by variable group users. A resource owner can control which pipelines can access a variable group. You can also use pipeline permissions to restrict access to particular YAML pipelines and all classic pipelines. |
| secure files | Secure files are consumed by tasks (example: Download Secure File task). | Protected with checks and pipeline permissions. Checks and pipeline permissions are controlled by secure files users. A resource owner can control which pipelines can access secure files. You can also use pipeline permissions to restrict access to particular YAML pipelines and all classic pipelines. |
| agent pools | There's a special syntax to use an agent pool to run a job. | Protected with checks and pipeline permissions. Checks and pipeline permissions are controlled by agent pool users. A resource owner can control which pipelines can access an agent pool. You can also use pipeline permissions to restrict access to particular YAML pipelines and all classic pipelines. |
| environments | There's a special syntax to use an environment in a YAML. | Protected with checks and pipeline permissions that are controlled by environment users. You can also use pipeline permissions to restrict access to a particular environment. |
| repositories | A script can clone a repository if the job access token has access to the repo. | Protected with checks and pipeline permissions controlled by repository contributors. A repository owner can restrict ownership. |
| artifacts, work items, pipelines | Pipeline artifacts are resources, but Azure Artifacts aren't. A script can download artifacts if the job access token has access to the feed. A pipeline artifact can be declared as a resource in the resources section – primarily for the intent of triggering the pipeline when a new artifact is available, or to consume that artifact in the pipeline. | Artifacts and work items have their own permissions controls. Checks and pipeline permissions for feeds aren't supported. |
| containers, packages, webhooks | These live outside the Azure DevOps ecosystem and access is controlled with service connections. There's a special syntax for using all three types in YAML pipelines. | Protected with checks and pipeline permissions controlled by service connection users. |
Use resources for traceability
Environments support the following resource types: