How to access an azure keyvault from an non registeres app (.net framework webapp)

Viewed 857

I am trying to access my azure keyvault i have setup from my web app which due to legacy cannot be registered in azure.

I have for now via connected services "connected" the application with key vault, which then modified the web.config and installed a bunch a nuget files.

When I now try to get the secret i have stored in my azure key vault via

   var secret = ConfigurationManager.AppSettings["ApiKey"];

I seem to get this error when I run the site

 Microsoft.Azure.Services.AppAuthentication.AzureServiceTokenProviderException: Parameters: Connectionstring: [No connection string specified], Resource: https://vault.azure.net, Authority: https://login.windows.net/311a22fd-9576-40ab-977e-a2f0a4d2cd36. Exception Message: Tried the following 4 methods to get an access token, but none of them worked.
Parameters: Connectionstring: [No connection string specified], Resource: https://vault.azure.net, Authority: https://login.windows.net/311a22fd-9576-40ab-977e-a2f0a4d2cd36. Exception Message: Tried to get token using Managed Service Identity. Unable to connect to the Managed Service Identity (MSI) endpoint. Please check that you are running on an Azure resource that has MSI setup.
Parameters: Connectionstring: [No connection string specified], Resource: https://vault.azure.net, Authority: https://login.windows.net/311a22fd-9576-40ab-977e-a2f0a4d2cd36. Exception Message: Tried to get token using Visual Studio. Access token could not be acquired. Visual Studio Token provider file not found at "C:\Users\local.temp.page\AppData\Local\.IdentityService\AzureServiceAuth\tokenprovider.json"
Parameters: Connectionstring: [No connection string specified], Resource: https://vault.azure.net, Authority: https://login.windows.net/311a22fd-9576-40ab-977e-a2f0a4d2cd36. Exception Message: Tried to get token using Azure CLI. Access token could not be acquired. ERROR: Please run 'az login' to setup account.

Parameters: Connectionstring: [No connection string specified], Resource: https://vault.azure.net, Authority: https://login.windows.net/311a22fd-9576-40ab-977e-a2f0a4d2cd36. Exception Message: Tried to get token using Active Directory Integrated Authentication. Access token could not be acquired. unknown_user_type: Unknown User Type

and what it states is correct, I don't have an excplicit connection string to the key vault - but should "connecting" the service to the key vault not have handled this? and would having connection string versioned in git not be counter intutive in relation to storing the password?

So how do i access my connected services, without actually storing the credentials of accessing the azure key vault?

And how do i manage two key vaults within one solution (one for dev env and one for prod env)?

1 Answers

You have a .net framework application which is running on premise. You need some secret from KeyVault available to your application but can't fetch it from your application code when you need it. You also don't want to put the actual secret into your web.config in git (which is good). You further have the issue of multiple environments.

Given all of this, I would first suggest that instead of having a connection string in you web.config, you just add a token for it. This is totally fine to put into your Git repository.

<configuration>
  <appSettings>
    <add key="ApiKey" value="API_KEY" />

You then build your application as you would today, resulting in a publish folder containing the web.config file. You can call this your build phase.

Before you run the actual deployment to IIS, you need to replace the token with the actual value from KeyVault. For this, your deployment process will need access to KeyVault (but not your application). The way you do it depends on how you deploy the application. It could be just a Powershell script that fetches the secret and modifies the web.config. If you use Azure Pipelines, you can link variables directly to KeyVault. If you deploy to the production environment, you simply fetch the secret from a different KeyVault. This also ensures that you can use the same build artifact for multiple environments, just with different configuration.

Related