When you code an App Service or Azure Function, Azure Key Vault Reference is a great way to improve security and avoid problems like redeploying code to pick up new service secret keys. All you need is this simple syntax to retrieve a key secret:
@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/)
But Azure Key Vault Reference is for App Service and Azure Function. Many companies still have lots of on-prem legacy systems and hybrid environments that sometimes require interaction with an Azure resource.
For that case, there is the “Azure Key Vault Secret client library”. It requires a bit more syntax but is still much better than direct references to secrets stored on the app settings
You can check the syntax here : Quickstart – Azure Key Vault secrets client library for .NET (version 4) | Microsoft Docs
I simplified the sample code to create and retrieve a secret. The idea is to compare the effort of using the Azure Key Vault Secret client library vs using Azure Key Vault Reference. I expected a little more complexity but this worked straight away when debugging (of course I created a vault policy and logged in to Azure using the CLI):
You can accomplish something similar with 2 lines of code:
var client = new SecretClient(new Uri([your Azure Vault uri]), new DefaultAzureCredential());
await client.SetSecretAsync(secretName, secretValue);
So, this is not exactly as short and sweet like the key vault reference but pretty similar.
You may have seen similar solution with the class ‘KeyVaultClient’ on Version 3 of Microsoft.Azure.KeyVault
I created the Vault Policy using the same username I use to log in with Azure CLI:
Regarding Authentication, Managed Identity is the supported approach for azure serverless , azure containers and azure VMs. (More here).
Further will discuss using Service Principal. I have not found anything explicitly commenting on how to deploy this to a on-premise host, but two possible solutions are:
- Deploy the code to a Azure VM
- Keep on-premise but use a Service Principal to authenticate.
Running the Visual Studio Debugger worked straight away, so let’s try the executable since the goal is to eventually deploy this on some server:
And the secret is created (Noticed I’m running this on-premise on a machine logged into azure with CLI):
If you prefer to deploy it using Service Principal, you just need to tweak it a little :
More about different auths here: Azure Identity client library for .NET | Azure SDK for Net (windows.net)
Conclusion:
You don’t need to add secrets direct on your code. Be an azure app or on-prem app, there are simple ways to add reference to the azure vault.
The Azure Key Vault Secret client library requires a little more syntax but similar. Still worthy to keep the code without hard coded secrets.
Authentication can be a little tricky for on-prem hosted apps but you can create a service principal if you prefer.
Leave a Reply