0

I'm managing secrets by dotnet user-secrets init/set command (as documented here). Now, as I'll be deploying to Azure, I want to use the key vault (as documented here) configured by az keyvault create/set.

Naturally, what I want is that the locally set secret created like this:

dotnet user-secrets set "Foot:Left" "Stinks"
dotnet user-secrets set "Foot:Right" "Stinks2"

will in Azure pick the values set by the following:

az keyvault secret set --vault-name "kv-shhh" --name "Foot--Left" --value "Stinks"
az keyvault secret set --vault-name "kv-shhh" --name "Foot--Right" --value "Stinks2"

What I can't see in the docs is the infromation on how the code will know which key vault to use. In my case, I only have a single one, the kv-hush-hush but there might be other key vaults in another resource groups. They may in fact, be key vaults in my resource group.

A colleague suggested that the strategy may be to only pick secrets from within the resource group the application is served from (and if there are multiple ones, they values would impose onto each other somehow). However, looking for any confirmation or refutal of that theory, we found nothing.

How do I tell the application to use the values from the key vault once I serve it from the cloud?

I've seen solutions like this one but that's relying on the key vault for both local development and hosted production. I'd prefer to have my secrets on my machine so I don't rely on the internet connection.

edit

Based on the comments and docs for AddAzureKeyVault(...), I added the following sample to my Program.cs.

string vaultName = "kv-name-on-my-vault";
string vaultUri = $"https://{vaultName}.vault.azure.net/";
builder.Configuration.AddAzureKeyVault(
  new Uri(vaultUri),
  new DefaultAzureCredential());

However, I'm pretty certain that it won't let me get the keys. Otherwise, anybody with the valutName would be able to. What am I missing?

I'm sensing that it's controlled by the Access policies section in the properties of the key vault. However, I feel unsure how to explain to the vault that my application (or, possibly, any application in its resource group) is trusted to read the vault. Also, I feel totally lost how I'd explain than my local application should be let into the vault.

I suspect that the docs cover that but I'm not seeing it due to lack of experience with the Azure key vaults.

Konrad Viltersten
  • 36,151
  • 76
  • 250
  • 438
  • I don't think there is anything that would automatically pick up a Key Vault. You have to explicitly add a Key Vault configuration provider, in which you set the Key Vault URI. – juunas May 13 '23 at 21:25
  • @juunas Thanks for the info. I still feel confused, although in another way now. So I added the Azure key vault to my *Program.cs*, provided the name and, seemingly, no exception occurred (sample in edit to my question). But now, how does the vault know to let my application get the info?! What stops **you** from using the same name and access the vault yourself, hence getting all my secrets? – Konrad Viltersten May 14 '23 at 05:14

1 Answers1

1

As the image below shows, you can add many configuration sources to your ASP.NET Application, and when you add AKV, it is added to this configuration setup. In this case, the AKV based configuration will be imposed at the end, after command line arguments (the principle of latest addition being most significant).

enter image description here

Regarding security, by default, it gets your Azure credentials using the DefaultAzureCredential Class, and it will look around your machine for your Azure Credentials and uses it to allow you access to AKV.

Only users with the correct credentials can access it.

If enabled, then

DefaultAzureCredential will search these sources (in order):

  • EnvironmentCredential
  • WorkloadIdentityCredential
  • ManagedIdentityCredential
  • AzureDeveloperCliCredential
  • SharedTokenCacheCredential
  • VisualStudioCredential
  • VisualStudioCodeCredential
  • AzureCliCredential
  • AzurePowerShellCredential
  • InteractiveBrowserCredential
Konrad Viltersten
  • 36,151
  • 76
  • 250
  • 438
Tore Nestenius
  • 16,431
  • 5
  • 30
  • 40
  • Awesome! Now I get why it lets me get to the key vault from my local environment "without" credentials (i.e. with no **explicit** credentials). FUQ: the pedagogic chart of how the settings aggregate explains the order. However, where in that order does the AKV get imposed? Is it **instead of** user secrets? Or maybe **as part of** environment variables? – Konrad Viltersten May 14 '23 at 08:04
  • I should probably add, so you know I'm not lazily expecting support, that I checked the `builder.Configuration.Sources`. In there, I see at position 4-6: *appsettings*, *appsettings.Development* and *secrets*. Then, as the last one at position 9: something about AKV. Is the order in that list significant and reliable? – Konrad Viltersten May 14 '23 at 08:19
  • the code in my image is from the ASP.NET Core itself, see https://github.com/dotnet/aspnetcore/blob/3ff3207c6f6bfa5cd7ba118c237eb0c582f5c23a/src/DefaultBuilder/src/WebHost.cs#L177 – Tore Nestenius May 14 '23 at 09:33
  • When you add AKV as a configuration source, then that is added at the bottom of the boxes to the right in my image and the ordering is important and reliable, the latest added wins. So, you can have the same setting name in different places. and the last config source wins. – Tore Nestenius May 14 '23 at 09:34
  • I always do! Just checking if there's some FUQs arising from my deeper understanding. I'll take the liberty of adding the extra piece if knowledge you just provided. Feel free to retract if you object. – Konrad Viltersten May 14 '23 at 10:07
  • You should create a specific app registration in Azure AD for your specific client that should access Azure Key Vault and give only the access that it needs. – Tore Nestenius May 14 '23 at 10:40
  • Yes, I agree. I'm actually trying to work out how to do that programmatically from Azure CLI. It seems that I can set policies for users but not actual applications. I don't want to create an actual AD user for my application (it's not a user as such, right)? I'm trying to get the app in the *Application* section of the accesses. I even asked a question about that, since it won't let me specify the app's name as a parameter to set the policy for. – Konrad Viltersten May 14 '23 at 11:00
  • I use this to create access (but not for AKV specifically) # create the service principal az ad sp create-for-rbac --name "$appname" --role contributor --years 2100 --scopes /subscriptions/b78d216b-d714-4664-b39a-xxxxxxxxx/resourceGroups/$rgname --sdk-auth true – Tore Nestenius May 14 '23 at 11:50
  • You might want to paste that [here](https://stackoverflow.com/questions/76247096/unable-to-set-access-policy-to-key-vault-for-an-application-in-azure-cli). That's where I asked the question that you may have a great input to (which you usually do). – Konrad Viltersten May 14 '23 at 12:27