This post shows how an Azure Key Vault can be protected inside an Azure virtual network. The deployment is setup so that only applications in the same VNET can access the Key Vault. To implement this, the access to the Key Vault is restricted to the VNET and secondly, the applications accessing the Key Vault requires an access policy. Managed Identities can be used for this. In the deployment, an Azure Function uses the secret from the Key Vault.

Code: https://github.com/damienbod/AzureFunctionsSecurity

Blogs in the series

• Securing Azure Functions using API Keys
• Securing Azure Functions using Certificate authentication
• Securing Azure Functions using an Azure Virtual Network
• Securing Azure Key Vault inside a VNET and using from an Azure Function
• Securing Azure Functions using Azure AD JWT Bearer token authentication for user access tokens

Azure Deployment

The application deployment is setup so that the Azure Key is not accessible from the internet. Only applications inside the VNET can used the Key Vault.

Creating the Deployment

A new Azure Key Vault can be created and added to the required resource group.

Add the Key Vault to your Virtual network. Select the subnet where the Azure Function is deployed. The Azure Function was added to the VNET in this post.

The Azure Key Vault should be configured to use the Virtual network subnets now.

The secrets can only be configured or used from inside the VNET. If you require to view, add or update secrets, you would need to configure the Key Vault Firewall to allow your IP to access the secrets.

The Access policies must be configured for the applications which require access. Add only the required policies, at the least GET and list secrets to read the secrets.

The Azure Functions need to be setup to use the Key Vault need. See the post for the details.

In the setup, the web application is connected to the internet. The Web application use the Azure Function to get data. In the Azure Function the secret is used and returned in the API call.

public class RandomStringFunction
{
	private readonly ILogger _log;
	private readonly MyConfigurationSecrets _myConfigurationSecrets;

	public RandomStringFunction(ILoggerFactory loggerFactory,
		IOptions<MyConfigurationSecrets> myConfigurationSecrets)
	{
		_log = loggerFactory.CreateLogger<RandomStringFunction>();
		_myConfigurationSecrets = myConfigurationSecrets.Value;
	}

	[FunctionName("RandomString")]
	public IActionResult RandomString(
		[HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = null)] HttpRequest req)
	{
		_log.LogInformation("C# HTTP trigger RandomStringAuthLevelAnonymous processed a request.");

		return new OkObjectResult($"{_myConfigurationSecrets.MySecret}  {GetEncodedRandomString()}");
	}

When the application is called, the secret is displayed in the web application as a proof of concept.

If the Azure Function is called directly, the access is denied. This was configured in the previous post.

Now it looks like everything is working as planned. To test if the Key Vault is not accessible from the internet, the Azure Functions can be run locally and configured to use the Key Vault. When the Functions are started, the application tries to access the Vault and a 403 is returned.

If we want to run locally, the Azure Key Vault Firewall needs to allow the IP of the host connecting to it, or the client app needs to be deployed inside the VNET.

Now we have deployed the applications secured using network security. The next step would be to add application security like authentication and authorization and session protection.

Links:

https://docs.microsoft.com/en-us/azure/azure-functions/security-concepts

https://docs.microsoft.com/en-us/azure/virtual-network/

https://docs.microsoft.com/en-us/azure/virtual-network/tutorial-restrict-network-access-to-resources

https://docs.microsoft.com/en-us/azure/virtual-network/quickstart-create-nat-gateway-portal

http://www.subnet-calculator.com/

Using Key Vault and Managed Identities with Azure Functions

https://docs.microsoft.com/en-us/azure/key-vault/