Introduction

In previous blog posts such as this one, I’ve shown you how to create http triggers within Function apps in Azure to do magic with Intune managed devices, however in my examples for brevity I used secrets, and pointed out that the more secure method is to use Azure Key Vault. In this blog post I’ll show you how to set that up so that your triggers are more secure. But first, let’s see what Microsoft describes Azure key vault as and explains why it’s important.

Azure Key Vault is a cloud service used to manage keys, secrets, and certificates. Key Vault eliminates the need for developers to store security information in their code. It allows you to centralize the storage of your application secrets which greatly reduces the chances that secrets may be leaked. Key Vault also allows you to securely store secrets and keys backed by Hardware Security Modules or HSMs. The HSMs used are Federal Information Processing Standards (FIPS) 140-2 Level 2 validated. In addition, key vault provides logs of all access and usage attempts of your secrets so you have a complete audit trail for compliance.

In this blog post the scenario we are going to use is basically how to replace previously created app registration secrets used within your http triggers with Azure key vault secrets.

Step 1. Create or reuse a resource group

As we’ll base this guide upon a previously created solution, we’ll re-use our previously created resource group, but if you want you can go ahead and create a new one for this purpose. Resource groups are a way of grouping resources within Azure and to protect secrets within that resource group you’ll use key vault.

Below I’m highlighting the previously created PC Buyback resource group which we will reuse in the next step.

 

Step 2. Create a key vault

Now that we have a resource group, let’s go ahead and create out Key Vault. In https://portal.azure.com search for key vaults, select the service from the list of services displayed.

 

Next, click on + Create to create a key vault. In the UI that appears, the first screen is dedicated to the Basics or general information about your key vault. You’ll need to select a valid Azure subscription and then select a previously created resource group (or create new). In this example we’ll reuse the PC Buyback resource group. You also need to assign the key vault a name, so give it something descriptive (you cannot use spaces).

Next select the region where this will be used, and that should match your Resource Group region. Finally select the pricing tier, in my example Standard is fine, you’ll only need to use Premium if you need to avail of HSM capabilities (Hardware Security Module), for more info on the pricing plans see here.

There are some additional options available relating to how long to key keep vaults after they are deleted and the default settings are good enough for us here.

 

Click Next to see the Access Configuration screen. In here you can once again choose the defaults, as we’ll be using RBAC (role based access control) in a later step.

 

Click Next to proceed to the Networking screen. In the Networking screen you have the option to use All networks to allow access from your PowerShell scripts and more, or if in a locked down environment you can select Selected networks which may involve you setting up a virtual network with it’s own private endpoint connection. In this example however we’ll use the All networks setting.

Note: These settings can be changed later in the Key Vaults Networking settings and some of the settings may be disallowed by your own internal policy if an initiative of Public network access should be disabled for PAAS services is enabled in your ARM policy.

 

Click next through the Tags screen and review and create your key vault.

After the deployment is complete, select it to see the properties.

 

Step 3. Assign role permissions

In your newly completed key vault, click on the secrets section highlighted below, and take note of the permissions error.

So even though I’m a Global Admin in Azure I’m not authorized to review those secrets. To resolve this we need to click on Access control (IAM) and assign some roles. You could simplify things and assign the Key Vault Administrator role to your chosen user or group which would give you the access you need to create secrets, keys and certificates, but as we only care about secrets in this blog post we’ll assign the following role.

• Key Vault Secrets Officer

To assign these roles in Access control (IAM) clcik on + Add and select Add role assignment from the drop down.

 

Next search for key vault in the search field, and select Key Vault Secrets Officer from the list.

Click Next and then click on + Select Members and browse to your chosen user

Finally click on Select and then select Review and Assign.

At this point you can now select the Secrets option in your key vaults Objects node and no longer get permission errors. It will state that there are no secrets available but we’ll get to that shortly.

 

Next select Key Vault Security User from the list and repeat as above (add role assignment).

 

Step 4. Create a key, secret or certificate

Now that you’ve configured your key vault, it’s time to create your first resource, this can be a key, secret or certificate.

Note: As we are replacing previously created App registrations secrets with azure key vault secrets we’ll select that option for this blog post.

Therefore, you’ll need to know your previously created secrets when you created them back in the PC Buyback tutorial, steps 7 and 8 here.

In key vaults secrets, click on + Generate/Import to start that process.

 

Give the secret a suitable name and paste in the value from the previously created app registration secret. We can see that secret taken from a http trigger within my PC Buyback functionapp. The contents are blurred.

and paste in that value into your key vault secret creation. You should also configure the activation and expiration date and make the expiration date to one day before the actual secret expires to allow you time to recreate a new one. Below you can see the app registrations secret expiry details.

and that is reflected (minus 1 day) in the key vault secret creation.

after creation, your secret is listed in the key vault.

Step 5. Grant functionapp permissions to consume the key vault

Next we’ll grant permissions to our previously create functionapp to allow it to consume the key vault. To do that, open up the PC Buyback functionapp and click on the Settings drop down, select Identity and change the Status to On.

After clicking Save you’ll get the following message. Click Yes to proceed.

After clicking Yes the results are displayed.

 

 

Step 6. Grant the key vault permission

Next open your key vault and browse again to Access control (IAM). In the role assignments click on Add and add the Key Vault Secrets User role.

 

Click Next and select Managed identity, then in the wizard that appears select function app from the managed identity field and select your PC Buyback function app.

once done, click Select and your PC Buyback function app is added. Don’t forget to click on Review + Assign.

 

Step 7. Configure function app environment variables

Open up the previously created PC Buyback function app and expand Settings, select Environment variables and click on + Add, give it a suitable name such as var_pcbuybackappregistration.

 

paste in the following string in the value line

@Microsoft.KeyVault(VaultName=mykeyvault;SecretName=mysecret)

edit the VaultName and SecretName values to match your environment…

click on Apply when done.

 

and click Apply again once the environment variable is added.

At this point you’ll need to confirm the change as it needs to restart the function app.

Step 8. edit the http triggers

Now you are finally ready to apply the key vault secret variable to your previously created http triggers, so let’s do that. Select a trigger and review the contents, find the line that pointed to the Access Secret and replace the with the new environment variable, like so:

$env:var_pcbuybackappregistration

when $env:var… is your environment variable created above.

Below is the result, and after saving the code and doing a Test/Run we can see it’s working just fine using Azure Key Vault,

Summary

Using app registration secrets in your http triggers is a bad idea, use Azure key vault to protect those resources, this blog post helps you to to just that. See you in the next one !