Azure DevOps. Getting to grips with permissions
One of the key principles of DevOps is the union of people, processes and technology, but this brings its own unique challenges when managing permissions across traditional team structures. Often responsibility lies with a non-DevOps user, so in this blog I’m going to run through the basics on how permissions work in Azure DevOps.
Before managing permissions, we should understand that without the right pre-requisite license users aren’t’ getting very far. Browsing to organisational settings | general | users within Azure DevOps and you will see the access levels granted.
This access level dictates the available features to the user, so make sure it lines up with your user requirements. In most cases you’ll want to have basic or above which relies on a Visual Studio Subscription, but you can review the finer details here (Complexity warning!)
To begin with you should focus on two key levels, organisations and projects. Repositories will inherit permissions from the project level so will mostly be taken care of this way. However, if you are responsible for managing repo permissions you will need a more advanced understanding of GIT processes and an internal discussion to set out branching policies (A subject for another blog!).
An organisation is also referred to as a collection (important to remember!) It represents a group of related projects.
An organisation is typically tied into Azure AD allowing the use of existing identities for authentication. However, if you find your company is using Microsoft/live accounts, it could mean DevOps is not connected to Azure AD and a migration is in order. Microsoft outlines this process here.
When an organisation is created the system creates ‘Collection-level groups’ that can’t be deleted. The key group here is the ‘Project Collection Administrators’ which contains the organisation owner and allows other members to perform all actions within the collection. By default, this is the only group with rights to create new projects.
Management for Collection-level groups can be found under ‘permissions’ in organisational settings
• Keep members of the Project Collection Administrators group thin on the ground and try to channel project creation through a central team for oversight
A project defines a collaboration space and security context for access to features, such as repos. They can include the development of an entire application or a just one part of it. When used with infrastructure-as-code the same applies.
Inside of a project exists ‘Teams’ which help manage access to features such as boards and security where separation is required. If you have a large organisation and have multiple applications being developed within a project this can be useful, however, most smaller teams opt to separate this at the project level for simplicity.
When a project is created a default project ‘Team’ is also created alongside it. Any members added to the project will by default go into this team and therefore inherit any assigned permissions. This is what it looks like by default.
The most important aspect here is that eventually permissions are applied via membership to the contributor group. This group is used throughout DevOps to set permissions. For example, within the Azure Pipelines security page we can see the following permissions granted to the default team via the contributor group.
From this we can see the contributor’s group will be able to edit pipelines but not administer permissions.
And again, if we look at the repository…
From this we can see the contributor’s group will be allowed to create branches and pull requests.
• Only add users to the project administrators’ group that require rights to alter permissions
• If you see ‘bypass policies when pushing’ or ‘force push’ permissions granted for explicit entries then that user/group/team will have rights to ‘force’ code into the repository without review (not great practice) this may or may not be intended
• Use the reader project group for users that have not been granted an access level but require visibility to a project
One of the most regular tasks in Azure DevOps is creating a service connection that grants pipeline access to a required scope, be it an Azure subscription or resource group.
By default, only project admins can create these connections and ideally this is the way you should keep it. If your running through the wizard within DevOps using the ‘Automatic’ method, then the user adding the service connection will also need owner access to the scope (subscription/resource group). This only reinforces the fact that requests for this should be controlled and passed to a designated team.
If you’ve just getting started with managing Azure DevOps permissions my advice is to focus on the three key groups and the roles they offer.
• Project collection administrators – Can create new projects
– Allocate this to the DevOps security team
• Project Admins – Manage project settings including user access and service connections
– Allocate this to the project lead/manager
• Default project team – Contribute to the project pipelines, repositories etc
– Allocate this to technical users who add to the code and project delivery
Hopefully that will help you get to grips with permissions in Azure DevOps!
Azure DevOps and more. How can we help?
Silversands is a Microsoft Gold Partner of over 30 years standing, which specialises in Microsoft 365 delivered across cloud (Azure) and hybrid IT infrastructures. We provide consultancy, support and user adoption services. We are running a series of webinars this quarter, but specifically related to Azure we have a governance webinar on 5th May. Click on the banner below to find out more and register.
If you need help and would like to have a chat about how Silversands might be able to help you, please complete the form below: