Azure DevOps Hosted Build Agent MSI

8
votes

I have an ASP.Net Core 2.1 project with a test project that contains some integration tests that require/need Azure Managed Service Identity access to run successfully (getting secrets from KeyVault). I am using an Azure DevOps VS2017 Hosted Build Agent to build the project for deployment to Azure App Service. The issue I am running into is that when the tests run after the build pipeline they fail since MSI access is not available on the hosted build agent. How can I go about setting the appropriate MSI access needed for the hosted build agent? Is it possible to do so via a Powershell task or something equivalent?

Thanks!

1
azureazure-devopsazure-active-directoryazure-pipelinesazure-managed-identity
Looks like the same issue as this: stackoverflow.com/questions/52827004/… – Damovisa

1 Answers

2
votes

To take a step back, you may already know this, but just to explain my thought process:

Think of Managed Service Identities are simply Service Principals (i.e. service accounts) which you don't know the password and further than that the user is created for you and managed by Microsoft.

So in that sense, as long as you grant a service principal access via a keyvault access policy that your hosted agent can assume the identity of, you are sorted.

There's good news and bad news. The good news is that hosted agents at least when using an Azure PowerShell Task come primed with a service principal, much like MSI you don't know the password (unless you add a secret), but they come pre-logged in for you.

And in the "phase" settings, you can enable "Allow Script Access To OAuth Token" which enables subsequent bespoke connectivity to Azure RM.

The bad news is that the Microsoft.Azure.Services.AppAuthentication library, which I presume you are using if you are using MSI, doesn't have a connection string that allows an access token, it only has client secret.

So a couple of options, you could find the deployment agent service principal and add another pre-shared client secret and use that in your connection string, being careful that you pass this as a secure variable so it is not retrievable.

The weakness being that you now have a position where your deployment agent service principal now has a password which someone knows, which previously it was just voodoo between Azure DevOps and Active Directory.

Or, what I would recommend is to [create a service principal] dedicated for integration testing keyvault 2, and use the client secret as a secret variable in your pipeline. Using a dedicated service principal lessens the attack vector than if your deployment agent service principal was compromised.

You can set the AppAuthentication libraries via connection strings stored in environmental settings, meaning no need to change your code: https://docs.microsoft.com/en-us/azure/key-vault/service-to-service-authentication#connection-string-support