This post will show a very simple KeyVault demo application.
Working with a customer, I needed to show them the simplest Azure KeyVault sample possible so they could easily understand what it does. There is a really good sample published to GitHub (Azure KeyVault .NET Sample Code), but it was still quite a bit verbose for someone seeking a simple Hello World type example. I threw this Console application together to show the bare minimum application.
The scenario is an application that interacts with multiple Azure services such as Redis, DocumentDB, and Storage. Each service has its own key to access the service. We obviously need our application to access the keys, but we don’t want developers to have access to the keys. We also want the ability to centrally update the keys on a regular basis. This is a perfect scenario for KeyVault because you can restrict access to keys and secrets.
To show this, I have a storage account named “kirkedemo”. Once the account is created, I can access its keys.
I copied the key1 value for my storage account and will store that as a secret in KeyVault.
The source code for this project is available at https://github.com/kaevans/keyvaultdemo.
Create a Vault and Secret
I often show people how to start using the portal because it provides a nice visual way to get started. Of course you can do this using scripting and ARM templates, and you should do that for production to ensure consistent provisioning with no configuration drift. I created a vault and named it “demo”. Once the vault is created, I click on Secrets in the portal and create a new secret using the storage account key.
In order to secure access for my application, I need to create a service principal in Azure AD.
Register the Application in Azure AD
In the Azure AD blade, select App Registrations and click the Add button to register a new application. Give it a name, select “Native” as the application type, and provide a URL (doesn’t have to be a real endpoint, just a URL).
Once created, click on your application, view Settings, and click Properties. Copy the Application ID value, this will be the clientID value used to authenticate to KeyVault.
Now click Keys. Create a new key and click Save, then copy the value that was generated.
The key you copied will be the clientSecret value used to authenticate to KeyVault.
Important step! Registering an application using the Azure portal doesn’t (at the time of this writing) create a service principal. Open PowerShell and run the following commands, replacing the ApplicationID value with the value you just created.
Create the Project
In Visual Studio, create a new Console application. Add the following NuGet packages:
Add a reference to System.Configuration.
Edit the app.config file and add the following keys along with the values that you created above.
Here is my configuration file for reference.
Show Me the Code
My favorite part. If you don’t want to read and just want a copy, the source is available at https://github.com/kaevans/keyvaultdemo.
The one weird thing about this code was the KeyVaultClient.AuthenticationCallback function, it expects a function with three string values. The authority is the Azure AD instance that you are working with (public cloud, govt cloud, Germany cloud, etc) plus your tenant ID, and the resource parameter has the value “https://vault.azure.net”. You don’t provide those values, the callback function provides them. You only need to provide the clientID and clientSecret values and the SDK does the rest for you.
Now try hitting F5 to make sure it compiles and runs.
See It In Action
“Huh? I did everything you said, Kirk, and when I hit F5 I get an Access Denied exception from KeyVault!” Good! That means it’s working. We created a secret in KeyVault, and created an application in Azure AD, but we never told KeyVault that the application was allowed to access the secret.
Go back to your KeyVault in the portal and click Access policies. Your application is not listed. Click Add new to add your application.
Note: if you don’t see your application, make sure to run the New-AzureRmADServicePrincipal cmdlet as mentioned above.
Once we’ve selected the principal, we then select the Secret permissions. We will only allow our application get a secret, it cannot list, set, or delete a secret in the KeyVault.
Save your access policy. Now go run the application again. This time everything should work. Go back to your storage account, and you should now have a new queue.
What Just Happened?
We were able to create an application that stores secrets in KeyVault. An administrator would have the ability to set access policies for users and applications. For example, I have a user, “firstname.lastname@example.org”, I can set a policy for that user for keys and secrets.
If I log in as that user and try to view the secrets in my KeyVault, I will see a message telling me that I am not authorized to view the secrets in the vault.
This lets administrators configure which applications and users are able to work with secrets in the vault. Users or applications that have the ability to Set secrets can now update secret values, such as updating the storage account key.
The obvious point that someone will mention is that we have a client ID and client secret in our app.config, that is a secret that is not stored in KeyVault. Great point! What we could have done was to have a *user* log in, use the user’s identity to obtain the key from the keyvault. Another option would be to use a client certificate for the application’s credentials instead of a client ID and client secret. This is exactly what the demo at Azure KeyVault .NET Sample Code does, it uses a client certificate to authenticate the application.
To see how to perform the operations using PowerShell instead of going to the Azure portal, see https://azure.microsoft.com/en-us/documentation/articles/key-vault-get-started/.