I see a lot of blogs and examples on the internet that shows you how to connect to environments using a username and password. This is all well and good for testing, but I believe it is bad for real world scenarios.
I’m a contractor, and my time at the job is defined, after I leave the contract and move onto the next one, the company should disable my account. What happens next? Everything I have built using a username/password, stops working. Yes, I could argue, it ensures I get a call back, but most contracts I’ve been involved in have a clause that any bugs found will be fixed for free up to 3-6 months after the job is done. Also, I like to leave a place with them thinking “That guy is awesome, lets get him back for the next project!“.
This post is going to show you how to set up a Service Principal for your Azure Devops CI/CD. At the end, I will give a very basic deployment that creates a Resource Group in Azure.
- Go into your project.
- At the bottom left of your screen click Project Settings
- Within Project settings, underneath Pipelines click Service connections*. If you have a star next to the Service connections word, it means that you are viewing the preview version. I’m going to show the following screens using a preview version.
- Click Create service connection
- Select Azure Resource Manager, click Next
- Ensure you have Service Principal Authentication selected. Give your connection name a title to identify where this is going to connect to. If you are using an account that doesn’t have Owner access to the subscription, then they will not show in the Subscription dropdown. In the production environment, I am not an owner. Therefore, I will need an owner on hand to help me. I will continue the next few steps where I’m not an owner. To do this, click on the link highlighted below. “Use the full version of the service connection dialog”
- Grab the Subscription ID from your Azure environment, and the Tenant ID. Enter them into the form as shown below. I also pasted the Subscription name for reference. If you click Verify connection at this point you will get a failed connection. Now click, “use the automated version of the service connection dialog”. This might seem strange, as it reverts the page back to the original form, but the subscription part is filled in correctly now.
- I’ve selected “Allow all pipelines to use this connection” as I will want all pipelines in this project to use this connection. Then click OK.
- As you click OK, a login dialog will appear. This is where you will require the owner of the Azure Subscription to sign in for you. This authenticates that a user allows the service principal to be created.
The Service Principal is now connected. To see what this looks like within the tenant that you have connected to, log into Azure Portal, and head towards the App Registration section. The name of the Service Principal will be [Dev-Ops Organisation Name]-[Project Name]-[SubscriptionID/Randomguid]. The Service Principal has contribute access on the subscription.
You can also add API permissions, such as Graph, and then make direct calls to Graph API using PowerShell within the pipeline.
Proving that Service Principal connections works.
Within your Dev Ops project, click on Pipelines and select releases. We are going to create a Resource Group within our subscription.
- Click on New Pipeline, and select empty job.
- Close the stage window. We don’t need any artifacts for this as I’m going to write AZ CLI code inline. Click on 1 Job, 0 task.
- Add an Azure CLI task.
Task version: 2* (preview) – This allows us to use inline Powershell script.
Azure Subscription: Pick the subscription you have created in the previous section.
Script Type: Powershell
Script Location: Inline Script
az group create –name "Demo-rg" –location uksouth
- Click Save and create a release. After the release has run, and you have received success, an empty resource group should have been created within the subscription.