We’ve all been there, out of convenience you auto generate a service principal to connect a Azure DevOps project to your Azure subscriptions. As long as IAM (Identity and Access Management) is configured correctly within your subscription, it’s so easy to just click, create, go and never look back. However, there can be implications in doing this, some I’ve identified below:

• duplicate service principals with the same access rights;
• access to resources that shouldn’t be accessible;
• duplicate display names causing mismanagement.

These can cause a knock on effect whereby security is impacted or pipeline disruption caused by user error. This post will address how we can go about cleaning up after ourselves and implement best practices when creating service principals for use with Azure DevOps.

To make any changes, you will need:

• to be a Project Administrator or hold permissions within a project to manage service principals;
• the right amount of permissions within a subscription to manage IAM;
• Azure Active Directory permissions to manage App registrations.

Identifying duplicate service principals

To identify if there are duplicate service principals within DevOps, you first need to go into a project where you are using them. Once within a project, select Project Settings from the bottom left of the screen and then Service connections under the heading Pipelines. From here you should be able to see the list of service principals connected to your project, select each service principal that connects to Azure and select the Edit button. You will see the details of the subscription this service connection is connected to and if it's connected to a resource group.

If the resource group field is blank, this can mean the service principal has contributor permissions on the subscription and all resources. Repeat these steps to go into each service principal to identify if any are configured to the same subscription and/or resource group.

To dig deeper into the permissions of the service principal, cancel out of the edit window and select Manage service connection roles under the Details heading. This will lead you to the IAM of the subscription or resource group where you can identify what permissions have been set.

Is a service principal in use

Within the Service connections page under Project Settings, select a service principal and select Usage history. From here you can identify what pipelines have used the service principal and the dates. You should be able to identify if the service principal is no longer needed based on it's usage.

You may want to consult those who have utilised the service principal in the past for their pipelines to see if they are going to be used again in the future or if they are using another connection.

Renaming duplicate display names in Azure Active Directory and Devops

When you auto generate a service principal within DevOps to the same subscription multiple times, you will notice the display name will be in the exact same format. There are two places where you need to rename service principals so they are identifiable within DevOps and Azure AD. First, within the Service connections page, you can select the Edit option within a service principals configuration page and enter a new display name within the field Service connection name.

The second place to rename is within Azure AD. You will need to select Manage Service Principal within the service principal connection page.

Once the page loads, select Branding in the left side menu and enter the display name within the Name field (remember to click save once completed).

Set who can use service principals within DevOps

Open the service principal from within the Service connections page and select the three dotted icon in the top right of the screen and select Security.

From within this window, you can specify who can manage or use the connection, what pipelines are allowed to use the service principal and what other projects can use the connection.

Before creating any new service principals

1. Check you don’t have a service principal already created with the access requirements you need;
2. Identify what level of access you need for the service principal to complete the work. You can edit the default contributor permissions so they have stricter access;
3. Consider who should have permissions to manage the service principal and who can use it. The smaller the list, the more secure your environment is;
4. Remove the option “Grant access permission to all pipelines”, and manually configure which pipelines should have access to use the service principal.