I decided to build a proof of concept for some colleagues here at Microsoft to demonstrate how, with minimal code, we could establish secure connections with services in Azure using User Managed identities. Building the POC I realized the information and lessons could be useful as well to others so, here it is.

Why User Managed Identities?

One of the initial questions people might ask is, why would I go with a User Managed Identity instead of a System Assigned Identity. The reason is, I have started to feel like creating a single user managed identity for the application made more sense, in my view. System assigned could certainly work but, it does add a bit of complexity since, in that situation, the App Service has to be created first.

Further, User Managed Identities go with my general motivation to keep application components together.

The Process

Before we get into showing code, let’s walk through the steps. I wrote this POC with an eye on Infrastructure as Code (IaC) and so used Azure Bicep to deploy the resources. Here is the overall flow of this process:

1. Deploy Application Identity
2. Deploy SQL Server database (Server, Database, Administrator, Firewall)
3. Deploy Key Vault w/ Secrets
4. Deploy Azure App Configuration w/ Config Values
5. Deploy Azure App Service w/ Plan

I heavily leveraged Bicep modules for each of these parts where I could, in some cases to overcome current limitations related to Bicep being so new. For example, I deployed the Identity using a module because, identity creation takes time and Bicep has a tendency to not respect this wait period, the module forces it to. Here is the code:

	// deploy.bicep
	module identity 'modules/identity.bicep' = {
	name: 'identityDeploy'
	params: {
	name: 'id-pocapplication-${suffix}'
	location: location
	}
	}
	// identity.bicep
	resource idApplication 'Microsoft.ManagedIdentity/userAssignedIdentities@2018-11-30' = {
	name: name
	location: location
	}

view raw identity.bicep hosted with ❤ by GitHub

As you can see, the module does not really do anything, resource-wise. But by placing it in a module we force dependsOn to actually work. I am not sure if this is a bug but, it underpins a lot of decision we make with what is a module in Bicep.

Let’s Deploy a Database

As we start to deploy Azure resources the first one we want to focus on is Azure SQL. Deploying it using a Serverless SKU is pretty straightforward (reference database.bicep). Where it gets tricky is when we want to enable MSI access into Azure SQL.

The first thing to realize here is, typical SQL users (even the admin) cannot create users linked to AD, only an AD user can. So, the first thing we need to do is link an AD account here as the admin. This should NOT be the User Managed Identity we created for the application. Rather, it should be an actual AD user, perhaps the so-called “break glass” user – you need only provide the ObjectId of the user from Active Directory (you can find it on the User Detail screen in AAD).

We set the admin using the administrators resource:

	resource administrator 'Microsoft.Sql/servers/administrators@2021-05-01-preview' = {
	name: 'ActiveDirectory'
	parent: dbServer
	properties: {
	administratorType: 'ActiveDirectory'
	login: 'appuser'
	sid: administratorPrincipalId
	tenantId: tenant().tenantId
	}
	}

view raw dbadmin.bicep hosted with ❤ by GitHub

Note the appuser name here is not relevant, it should be something that describes the user, it can be whatever you want.

Once the database is created, log into the Query Builder (or connect using SSMS) using that Active Directory user. Next you need to run the follow query to create the user represented by the MSI we created earlier:

	DROP USER IF EXISTS [id-pocapplication-pojm2j]
	GO
	CREATE USER [id-pocapplication-pojm2j] FROM EXTERNAL PROVIDER;
	GO
	ALTER ROLE db_datareader ADD MEMBER [id-pocapplication-pojm2j];
	ALTER ROLE db_datawriter ADD MEMBER [id-pocapplication-pojm2j];
	GRANT EXECUTE TO [id-pocapplication-pojm2j]
	GO

view raw usercreate.sql hosted with ❤ by GitHub

Once this is run, we will be able to use MSI to access the database.

Let’s add a Key Vault

Key Vault is ubiquitous in modern applications as it is an ideal place to store sensitive values. I will often store my Storage Account Access Key values and Database Administrator password here. In addition, for this POC I want to store a “secure” value to show how it can be retrieved using the App Configuration service (which we will be deploying next).

Now, a funny thing about Bicep, at its current stage of development, you cannot return, as an output, a key dictionary based off an array – we would often refer to this as a projection. To mitigate this, I do not recommend using a module for Key Vault. So, you will not see a keyvault.bicep file, instead you will see the key vault operations in the main deploy.bicep file.

Ideally, in a situation such as this we would pass an array of secrets into a module and then, as output, we could return a lookup object where the name of the secret provides us the URI of the secret. This is not currently possible, from an array, in Bicep.

The important secret I want to point out is sensitiveValue we will retrieve this value using App Configuration service next.

But for the access to occur we need to allow a look up to occur using our Managed Identity, we do this with Access Policies – this can be either built-in or using AAD; I am choosing to use the built-in. The key here to remember is the policies are all or nothing. If you grant get secret, the identity can get ANY secret in the vault. This is rarely desirable and thus we use the practice of key vault splitting to mitigate this in complex and shared application scenarios.

App Configuration Service

Despite having been around for almost 2 years at this point, the App Configuration Service is not a commonly used service, which is a shame. It has the ability to manage configuration, link to Key Vaults, and provide a web centric way to manage Feature Flags. For me, it is a common and necessary service because not only does it take the config out of the App Service and enable higher security.

If configuration values are left within the App Service, as Configuration, then we have to be extra diligent that we lock down roles for our users so the values cannot be seen. If we move the values to a different service, we can more easily enforce this sort of deny by default requirement.

App Configuration Service is separated into a template for the main service and then subsequent values. The most interesting of these is the Key Vault requirement, which is not anything super special but we do we use a different content type, here is our value referring back to the sensitiveValue we created with the Key Vault:

	// in deploy.bicep
	module appConfig 'modules/app-config.bicep' = {
	name: 'appConfigDeploy'
	params: {
	name: 'appconfig-pocapplication-${suffix}'
	location: location
	configValues: [
	{
	name: 'searchAddress'
	value: 'hhttps://www.bing.com'
	contentType: 'text/plain'
	}
	{
	name: 'sensitive-value'
	contentType: 'application/vnd.microsoft.appconfig.keyvaultref+json;charset=utf-8'
	value: '{ "uri": "${secret.properties.secretUri}" }'
	}
	{
	name: 'connection-string'
	contentType: 'text/plain'
	value: 'Server=tcp:${database.outputs.serverFqdn};Authentication=Active Directory Managed Identity; User Id=${identity.outputs.principalId}; Database=${database.outputs.databaseName};"'
	}
	]
	applicationIdentityPrincipalId: identity.outputs.principalId
	}
	dependsOn: [
	identity
	]
	}
	// in the module
	resource keyValues 'Microsoft.AppConfiguration/configurationStores/keyValues@2021-03-01-preview' = [for config in configValues: {
	parent: appConfig
	name: config.name
	properties: {
	contentType: config.contentType
	value: config.value
	}
	}]

view raw appconfig.bicep hosted with ❤ by GitHub

One important point that may not be immediately obvious is the lookup of the secret is still done by the invoking client. This means the “host” of the application (App Service in our case) will use its identity to contact Key Vault once it receives the value from App Config service.

Deploy the App Service

The final bit of infrastructure we need to deploy is out App Service + App Service Plan combination and part of this will involve assigning our application identity to the App Service via this definition:

	resource app 'Microsoft.Web/sites@2021-02-01' = {
	name: 'app-${baseName}'
	location: location
	identity: {
	type: 'UserAssigned'
	userAssignedIdentities: {
	'${applicationIdentityResourceId}': {}
	}
	}
	properties: {
	serverFarmId: plan.id
	httpsOnly: false
	siteConfig: {
	linuxFxVersion: 'DOTNETCORE|3.1'
	alwaysOn: true
	}
	}
	}

view raw appservice.bicep hosted with ❤ by GitHub

The final bit here is I am using .NET Core 3.1 which is the last LTS release before .NET 6. The reason for its usage here is due to the circumstances with the POC, its designed to showcase this approach with a .NET Core 3.1 application – the same techniques here can apply to .NET 5 and beyond.

Connect application to App Configuration Service

What I will be summarizing here is the tutorial here: https://docs.microsoft.com/en-us/azure/azure-app-configuration/quickstart-aspnet-core-app?tabs=core5x

The App Configuration Service is connected at application start and injects its values into the IConfiguration dependency you should be using today – for added worth, it overwrites local values and assumes the values coming from the Configuration Service are valid. Here is what my connection looks like:

	public static IHostBuilder CreateHostBuilder(string[] args) =>
	Host.CreateDefaultBuilder(args)
	.ConfigureWebHostDefaults(webBuilder =>
	{
	webBuilder.ConfigureAppConfiguration(config =>
	{
	config.AddAzureAppConfiguration(appConfig =>
	{
	var credential = new ManagedIdentityCredential("93e93c24-c457-4dea-bee3-218b29ae32f1");
	appConfig.Connect(new Uri(AppConfigUrl), credential)
	.ConfigureKeyVault(kvConfig =>
	{
	kvConfig.SetCredential(credential);
	});
	});
	}).UseStartup<Startup>();
	});

view raw appstart.cs hosted with ❤ by GitHub

The other aspect to note here is what we pass to this class, which is the ClientId of the Service Principal (in this case created through the User Managed Identity) within Azure Active Directory. If you recall when we assigned the identity to the App Service we used the Resource Id for the User Managed Identity. This is what allows an App Service to have many identities associated with it, you can use any one you wish so long as it is assigned to the App Service (or whatever service you are using).

Notice also, we call the follow on method ConfigureKeyVault and pass it the same credential. Truthfully, we could specify a different identity here if we so choose, in this case I am not. But it is the credential the underlying SecretClient (or KeyClient) will use when communicating with Key Vault when a Key Vault reference is discovered (this is the purpose of the content type setting).

Azure Configuration Service also supports the use of labels which can be used to differentiate environment or run condition. I dont often recommend using it for environmentalization, as it can lead to complexity and mess plus, you rarely want all of your values in the same service as it means if access is breached all values can potentially be read. Your best bet is to use separate App Config Service instances for each environment. Within those you can support special cases with labels.

Let’s Access the Database

Our final task here was to access the database with MSI. This is not a supported case with Azure.Identity but, thankfully, it is so simple you dont need it. As shown here: https://blog.johnnyreilly.com/2021/03/10/managed-identity-azure-sql-entity-framework/#connection-string-alone

Yes, you can literally do this with JUST the connection string, I used the fourth example to make it work, I only needed to provide the Object/Principal Id of my identity. Obviously, you want to be careful about sharing this since, without networking rules anyone could technically access your database server if they have the ObjectId.

Lessons Learned

Bicep is a wonderful language and, as someone who distanced himself from ARM templates due to their difficulty and favored Terraform, I am very excited at what the future holds. That said, and I have mentioned this before, even to colleagues at Microsoft, Bicep is great until you get into more complex and nuanced cases – I am working on some shareable modules and have had difficulty, especially with array and outputs.

I wanted to prove that you could do the entire process using Bicep and Infrastructure as Code and I was able to accomplish that. Part of what made this easier was the use of a User Managed Identity which allowed tighter control over the identity.

Source Code: https://github.com/xximjasonxx/SecureConfigPoc