Kamil Mrzygłód's personal blog

When a Web App is published to Azure for the first time, publish profile is being generated containing basic information regarding what, where and how should be deployed. After you've automated your CI/CD pipeline, those informations are somehow lost. But what if I need to incorporate them in my build or release process? Fortunately there's an easy way to download all the data and use it for our purpose.

Azure CLI for the rescue!

To be honest, there's a few Powershell commands, which could help us here at least like:

Get-AzureWebsite

Get-AzureRMWebApp

Get-AzureRMWebAppPublishProfile

The first one is designed for Azure Classic and won't work e.g. when a connection type in VSTS is set to Azure Resource Manager. However it allows you to get credentials really easily:

Get-AzureRMWebApp is a command, which is designed for working with Resource Manager. It's very similar to Get-AzureRMWebAppPublishProfile, the difference comes from the amount of information it returns. Since in this post we're focusing on getting deployment credentials, we'll skip the former and consider the latter only. When Get-AzureRMWebAppPublishProfile is called, it returns XML content, similar to .PublishSettings file which can be downloaded from Azure Portal. To fetch both a username and a password, you can use following script:

With those credentials, you can automate your CI/CD pipeline even more(e.g. they are needed when accessing Kudu for a master key for Azure Function). The only thing you have to remember, is to select the right version of the command, depending on the deployment model.

This post is an extension to the post written by Marek Grabarz here. If you haven't got a chance to read, I strongly recommend you to do so - it presents a bit more general approach to automate Azure Functions and can act as baseline when it comes to build your custom solution.

The problem

You have an ARM template and full CI/CD pipeline prepared. All works smoothly and with easy. You're just about to grab a beer and celebrate success when suddenly you realizes, that you haven't put functions' keys to the output. After searching multiple pages you finally finds Marek's post, which explains in detail what is needed to obtain a secret from a function.

Unfortunately using Azure Active Directory Authentication Library (aka ADAL) with VSTS results with the following error:

Apparently the way how VSTS authenticates itself is different than doing it locally(when you check logs, you'll see, that it doesn't call Login-AzureRMAccount - instead Add-AzureRMAccount -ServicePrincipal, what could be the reason, why ADAL is problematic in this particular scenario). We have to find another way to get the token for authentication.

2. You should see the endpoint defined for VSTS. From here you can click on Manage Service Principal

You'll be forwarded to the old portal. Now go to the Configure tab - from here you can copy client_id needed for the API. You can also find the Keys section which is the last thing we need here - just add another key and copy its value(remember that once you leave this page, you won't be able to retrieve it). Once we're armed with additional data, we can use it to get our token:

Summary

Integrating multiple resources in Azure and VSTS can be a little tricky sometimes, but as you can see it still doesn't require much work to get it working. With a simple Powershell script and one call to the API you can authenticate requests from your VSTS instance and make it work with most components available in Azure.