How do I protect azure-pipelines.yml pipeline file in Azure Devops

2
votes

Maybe I'm approaching this entirely in the wrong way, but there seems to be a rather large security hole in Azure Devops Pipelines.

Our devops team has historically managed our builds, all the way back to on-prem TFS and through our journey to CI/CD. This is done so that we can standardize our builds and releases, track environment and toolset upgrades, because devops folks have better domain knowledge in this area, and to generally make life easier for developers. This is all good practice.

Now with Azure Devops and yaml pipelines, we have the ability to template out our builds (a wonderful thing, about time Microsoft caught up to this). But even with templating, "extends" templates, and security restrictions preventing developers from creating their own pipelines, the root file of it all (azure-pipelines.yml) is still stored in the application's source code repository.

So a developer isn't allowed to create a new pipeline, but they can edit the azure-pipelines.yml file all they want, which means erasing the templating/extends code our devops team wrote, and potentially injecting nefarious or otherwise unmanaged changes. Or even deleting the file altogether and ruining the pipeline. This is coconuts.

And before you say, "well, slap some branch policies on there and force code reviews/pull requests," that is entirely goofball for 2 reasons:

  1. The dev ops team should not have to approve every single change in the branch, because code changes are not their domain. They should only need to approve the azure-pipelines.yml file and be left off the rest.
  2. This would require a branch policy created manually on all our dozens of repos, not to mention every single branch inside those repos. Devs can also create their own branches, which completely circumvents any policies we may have.

And yea, we may have change history now, but that only helps after the fact. Not before a build environment gets destroyed.

In short, by inserting pipeline definitions into application repositories and not providing any way to smartly protect them, Azure YAML Pipelines allows developers free reign to wreak havoc in the devops' world.

Am I missing something here? How have people gone about keeping their yaml pipelines protected and managed? Surely there are strategies for organizations who have separate devops teams that need to protect their work. How do we protect/secure azure-pipelines.yml?

1
azure-devopsazure-pipelinesdevopsazure-pipelines-yaml
Does this answer your question? Protect Azure Pipeline Yaml File from Being Edited – Matt
Not quite... that one talked about setting per-branch policies, and/or setting file path validation, which is only half the answer. I tried setting a project-wide branch policy similar to described in that link but it forced every commit to be approved by administrators, even though a path filter was set for only yml files. So it led me in a direction, but that direction didn't work properly. – Chris
This one is similar, talks about implementing a PR policy for sub-folders, but not on a project-wide basis. I may be able to combine techniques: stackoverflow.com/questions/58689979/… – Chris

1 Answers

0
votes

You can enforce pull requests on the important branches and require reviewers when the pipeline is being changed. Such branch policy can be enforced for a whole team project using branch policies with wildcards

https://jessehouwing.net/azure-repos-git-configuring-standard-policies-on-repositories/

Though I'm personally against such a strong split between accountabilities. Standardization is one thing, but the protection it gives is thin vernier. In the end it's much better to drive an awareness program.

Optionally protect the target environment to require a pipeline template and making sure the template injects itself in the target pipeline, not the pipeline opting in to a template. In Azure Pipeline Environments you can set a policy to require specific templates to be used.