2

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?

Mureinik
  • 297,002
  • 52
  • 306
  • 350
Chris
  • 443
  • 1
  • 3
  • 14
  • Does this answer your question? [Protect Azure Pipeline Yaml File from Being Edited](https://stackoverflow.com/questions/60516460/protect-azure-pipeline-yaml-file-from-being-edited) – Matt Oct 28 '20 at 02:44
  • 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 Oct 28 '20 at 13:16
  • 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: https://stackoverflow.com/questions/58689979/how-to-restrict-the-access-on-build-yml-file-from-developers-in-azure-devops-rep – Chris Oct 28 '20 at 13:40

1 Answers1

1

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.

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
  • 1
    It does look like you can set a branch approver policy on *.yml files on a project-wide level, and for all future branches using a wildcard (Project Settings -> Repositories -> Policies -> Branch Policies), so that's a huge step forward. I will give this a shot and see if it handles my edge cases. – Chris Oct 27 '20 at 21:14
  • 1
    Remember that a PR build will use the merged result to run the pipeline. You can protect your environments from accepting such builds by setting a check on the environment level. – jessehouwing Oct 28 '20 at 10:06
  • 1
    I set up a project-wide branch policy on * branches to add 1 automatic required "Build administrator" reviewers for *.yml files, and this had the unfortunate side effect of requiring PRs for every single commit on all our code bases. It seems that the path filter on *.yml files did not work as intended. Back to experimenting... – Chris Oct 28 '20 at 14:28
  • Have you ever found a solution? – roli09 Apr 06 '21 at 21:37