Azure DevOps permissions primer

• October 11, 2019
• 413 words
• 3 min

I often join Azure DevOps projects some time after they were started and can almost guarantee I'll find... questionable... permissions have been applied.

If you search for e.g. "azure devops permissions" you'll get pages like this which only tell half the story, so here's a quick primer...

There are a multitude of places where permissions can be set in Azure DevOps which can be roughly categorised into 4 places:

• On the Project Collection permissions
  • e.g. https://dev.azure.com/<organisationname>/_settings/groups
  • These are mostly super-user permissions granting access to all projects - use with care.
• On the Project permissions
  • e.g. https://dev.azure.com/<organisationname>/<projectname>/_settings/permissions
  • Split into teams & groups
    • Each team gets a new set of boards for work item management
    • Team Administrators (see below) can invite new users to their team without requiring Project Administrators assistance & maybe a few extras on work item boards.
      • This is the perfect permission for traditional project managers/scrum masters etc.
    • Use a group if you don't need either of the above.
    • Groups are nestable and can include AAD groups... don't add single users everywhere individually!
• On specific sections' permissions within the project
  • e.g. "Branch Security", "build security" for all builds or security of a specific build/release pipeline.
  • Defaults are pretty sane - Reader & Contributor groups already added as required for most projects.
  • If you find yourself wanting to add an individual somewhere, stop. There's likely a better way of doing it and it likely involves adding them to an existing group or creating a new one and granting that group the permission.
• Weird one-off's with nothing else quite like them
  • e.g. "Team Administrators" at https://dev.azure.com/<organisationname>/<projectname>/_settings/teams?teamId=<uuid> accessed through project settings -> teams

The difference between adding users to Project Collection groups & Project groups is reasonably straight forward but I often see users added as Project Administrators without much thought and this is a terrbile idea. Remember that Project Administrators will be granted access to everything...

• Manage (& delete!) work items
• Manage (& delete!!) git commits
• Manage (& trigger!!!) pipelines

While it's access to managing work items or adding new users that I often see people (e.g. Project Managers) added as Project Administrators for, it is often not understood or realised that doing so grants full access to pipelines.

Are you happy with your Project Manager being able to trigger a release to production?