Securing Azure Pipelines
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020
Azure Pipelines poses unique security challenges. You can use a pipeline to run scripts or deploy code to production environments. But you want to ensure your CI/CD pipelines don't become avenues to run malicious code. You also want to ensure only code you intend to deploy is deployed. Security must be balanced with giving teams the flexibility and power they need to run their own pipelines.
Azure Pipelines is one among a collection of Azure DevOps Services, all built on the same secure infrastructure in Azure. To understand the main concepts around security for all of Azure DevOps Services, see Azure DevOps Data Protection Overview and Azure DevOps Security and Identity.
Traditionally, organizations implemented security through draconian lock-downs. Code, pipelines, and production environments had severe restrictions on access and use. In small organizations with a few users and projects, this stance was relatively easy to manage. However, that's not the case in larger organizations. Where many users have contributor access to code, one must "assume breach". Assuming breach means behaving as if an adversary has contributor access to some (if not all) of the repositories.
The goal in this case is to prevent that adversary from running malicious code in the pipeline. Malicious code may steal secrets or corrupt production environments. Another goal is to prevent lateral exposure to other projects, pipelines, and repositories from the compromised pipeline.
This series of articles outlines recommendations to help you put together a secure YAML-based CI/CD pipeline. It also covers the places where you can make trade-offs between security and flexibility. The series also assumes familiarity with Azure Pipelines, the core Azure DevOps security constructs, and Git.
Submit and view feedback for