Disable creation of classic pipelines
YAML pipelines offer the best security for your Azure Pipelines. In contrast to classic build and release pipelines, YAML pipelines:
- Can be code reviewed. YAML pipelines are no different from any other piece of code. You can prevent malicious actors from introducing malicious steps in your pipelines by enforcing the use of Pull Requests to merge changes. Branch policies make it easy for you to set this up.
- Provide resource access management. Resource owners decide if a YAML pipeline can access a resource or not. This prevents attacks like stealing another repository. Approvals and checks provide access control that works for each pipeline run.
- Support runtime parameters. Runtime parameters help you avoid a host of security issues related to variables, such as Argument Injection.
This is why many of you who are security-conscious choose to only use YAML pipelines. Alas, as long as your engineers can choose to use classic pipelines, you will have to continue worrying about their security.
We’ve launched a new feature that allows you to disable creation of classic pipelines. When you enable it, no classic build pipeline, classic release pipeline, task groups, and deployment groups can be created. Thus, there won’t be any (new) classic pipelines to worry about.
Enable the feature
You can disable creation of classic pipelines by turning on a toggle at either organization level or project level.
To turn it on at organization level, navigate to your Organization settings, then under the Pipelines section choose Settings. In the General section, toggle on Disable creation of classic build and classic release pipelines.
When you turn it on at organization level, it is on for all projects in that organization. If you leave it off, you can choose for which projects you wish to turn it on.
To turn on the toggle on at organization level, you need Project Collection Administrator rights, while for a project, you need Project Administrator rights.
How the feature works
If you turned on the toggle to Disable creation of classic build and classic release pipelines, then no classic build pipeline, classic release pipeline, task groups, and deployment groups can be created.
The user interface will not show the Releases, Task groups, and Deployment groups left-side menu items if you have none of them.
When creating a new build pipeline, you’ll no longer be able to choose Other Git or Subversion as pipeline repository.
REST APIs related to creating classic build pipeline, classic release pipeline, task groups, and deployment groups will not work anymore.
Existing classic pipelines
If you have classic build pipelines, classic release pipelines, task groups, or deployment groups, you’ll still be able to edit and run them. The Pipelines left-side menu will continue to show the corresponding menu items. However, the buttons to create new ones will be disabled.
The following screenshot shows the experience when attempting to create a new release pipeline.
Rollout
The feature is available to all customers and is turned off by default. This means there are no changes to your pipelines behavior. We do not plan to automatically turn on the feature for existing organizations.
We plan to have the feature turned on by default for organizations created after March 2023. This means new organizations will be, by default, YAML-only.
FAQ
Are classic pipelines going away?
No. Classic pipelines, both build and release, will continue to work in the future as well.
I can’t turn on Disable creation of classic build and classic release pipelines. Why?
To turn on the Disable creation of classic build and classic release pipelines toggle at organization level, you need to have Project Collection Administrators rights.
To turn on the Disable creation of classic build and classic release pipelines toggle at project level, you need to have Project Administrators rights.
Where can I learn more about securing my YAML pipelines?
Read our Securing Azure Pipelines walkthrough for recommendations to help you put together a secure YAML-based CI/CD pipeline.
Light
Dark
28 comments
Thank you. The option to disable use of TFVC repos and remove existing repos would be welcome as well.
Sorry they do not. Consider an org that has to keep pipelines between each repo consistent. Sticking the build definition in the repo not only creates churn in the same way bumping version numbers does but it also means that any of the committers can alter the pipeline. This can be anywhere from desirable when the committers are skilled in this area (rare IME) to disastrous like when they are getting inconsistent results for unit tests and rather than fix the code they turn off the unit tests. Or when some step is taking too long so they disable it and cause bigger problems later.
You can say its different from “Classic Pipelines” but you cannot say that it is more secure when its easier to negatively affect the team’s output. Classic Pipelines can use membership in the Build Administrators group or other ways to prevent tampering. I dont even think you can say YAML pipelines are “better” than “Classic” when they havent reached feature parity.
Whomever started calling them “Classic” was clearly not around for the two generations of Windows Workflow Foundation style builds that preceded them, or the tfsbuild.proj style builds that preceded the WWF ones. None of those were easy to maintain or to work with. The thing you call “classic” and are so eager to throw in the fire along with so many other great inventions is still the easiest to learn and use – and it keeps build and packaging concerns out of the program code repo.
Is there is roadmap for classic features being migrated to the new system?