Introduction

Keeping secrets is hard! And if those secrets are of sensitive nature, like those of a database application connection string for instance, then even more so! Interestingly enough, lately as I was diving into Azure Key Vault to gain a greater personal understanding of the technology, I saw that .NET Rocks actually had Sumedh Barde as a guest speaker on their show Azure Key Vault with Sumedh Barde
It was an excellent show and I enjoyed quite a bit learning more about keeping and managing secrets securely in the cloud. If I could capture the show in one phrase that set the tone for me that would be: "Do you know where all your secrets are?" If your answer to the question is yes, then awesome! For the rest of us I would recommend you listen to the show and continue reading this post. :)

Managing Secrets

I am basing this post partly on the information covered in the official Microsoft documentation: Getting Started With Key Vault. However, I personally found the available information not as clear as I would have liked, so I am writing this post to hopefully help someone else that is just getting started with Azure Key Vault. Also, because I assume that this may be your first time using Azure Key Vault and its related technologies, I will try to be as specific as possible in most instances.

Prerequisites

In order to follow along, you will need to have the following:

• An Azure Subscription.
• PowerShell 5, the scripts might work with version 4 although I have not tested them with that version.
• Azure PowerShell, simplest way to get this is by installing the Web Platform Installer and selecting the 'Microsoft Azure PowerShell' product installation
• Windows 10 is the OS version I am using, therefore please note that some of the PowerShell scripts mentioned in this post will require PowerShell version 5 and Windows 8.1 or later.
• The sample Key Vault application provided by Microsoft which will be mentioned later in subsequent posts as code reference. You can download the sample application from here.

Setting Up Your Environment

The first thing you probably want to do is check that you have the right version of PowerShell in order to successfully follow along. Judging from how popular this topic is in StackOverflow you probably already know how to do this, in any case, the easiest way to check the PowerShell version is simply by launching a new command window and running the following:

$PSVersionTable.PSVersion

You should see something similar to this:

Now, login to your Azure Subscription using the following PowerShell script

Login-AzureRmAccount

If you have multiple subscriptions then you need to set the current subscription that you will use during this session. The Microsoft tutorial mentioned earlier already talks about this, but I am adding this piece here for completion. First, list out all of the subscriptions associated with your account:

Get-AzureRmSubscription

You will see a list of all your active/inactive Azure subscriptions:

Then simply copy from the PowerShell output the value (GUID) for the specific SubscriptionId that you want to utilize in your session and then run the following PS command:

Set-AzureRmContext -SubscriptionId 40ce2612-d16c-4229-892b-77ea8088dec8

You can streamline this last step even further by simply providing the name of the subscription you want to connect to, assigning that result to a variable and then setting the context all at once without any manual steps:
$mySubscription = Get-AzureRmSubscription -SubscriptionName 'Your Azure Subscription Name' Set-AzureRmContext -SubscriptionId $mySubscription.SubscriptionId

Once you have successfully established a connection to your Azure Subscription via PowerShell, you will now need to create a new Azure resource group. In case you have not used Azure Resource Groups before and you would like to know more, you can read about them in this short intro and in the official Microsoft ARM documentation. This is how you can create a resource group in PowerShell:

New-AzureRmResourceGroup –Name 'KeyVaultResourceGroupTest' –Location 'Central US'

Once the command runs successfully you should see the new details about the resource including the new ResourceId and you should be ready to create your Key Vault:

Creating The Key Vault

To create a new Key Vault via PowerShell you run the following command from PowerShell:

New-AzureRmKeyVault -VaultName 'TheContosoKeyVault' -ResourceGroupName 'KeyVaultResourceGroupTest' -Location 'Central US'

The command requires that you pass in the name of the resource group you created in the previous steps, the desired name for your new Key Vault and the Azure data center geographical location of your choice.

Once your Key Vault is created successfully through PowerShell, you should something like the following in your console output window:

On an interesting note you should know that your Key Vault can also be viewed and managed via the Azure Portal:

You can even create the Key Vault using the Azure Portal if you like, however, we will stick to PowerShell for the time being since that's a bit faster, simpler to automate and more fun than clicking buttons.

Adding Secrets and Keys to your Key Vault

So what kind of fun things can you add to your Key Vault? At a high level there are a few distinct assets that you can securely store in your Key Vault (if you are interested in a more in-depth definition list, please see the article About Keys, secrets and certificates):

• Keys: These are essentially RSA keys, which can either be securely generated by Key Vault or imported by the user
• Secrets: These are things such as connection strings to a database or blob storage that you keep securely in Key Vault and only access them in memory by requesting them from Key Vault at runtime
• Certificates Key Vault can be used to import and manage your current certificates or create certificates within Key Vault which requires further setup

In this case, since we are just getting started with Key Vault, we will create a Secret in our Key Vault and then review its contents in the Azure Portal. This will give us the sense of how things work without getting into much detail just yet:

$mySecretValue = ConvertTo-SecureString 'SuperSecretDatabasePassword' -AsPlainText -Force $secret = Set-AzureKeyVaultSecret -VaultName 'TheContosoKeyVault' -Name 'SQLPassword' -SecretValue $mySecretValue

Now if you want to look at the properties of your new secret you can access them by simply calling the $secret variable:

Notice that the 'Id' property of the $secret is an actual URL which can be used to retrieve the original secret value. This URL would be the value of the key that you would add to an application configuration file that Key Vault would use at runtime to retrieve the actual secret. If you are an admin on the Azure Portal for the Key Vault account where the secret is hidden, you can actually navigate to the portal and view the secret value:

Keep in mind that only the administrator should have access to the production secrets that are used for deployment. You would then give access to an auditor that would log the usage of the keys, using something like this dashboard for example:

Conclusion

Azure Key Vault offers a compelling solution for managing all your keys, secrets and certificates securely and at scale. Azure Key Vault builds upon the secure foundation of Azure AD to provide a manageable and automated option for keeping your secrets secure in the cloud. If you are still keeping all your secrets in plain text configuration files or storing your certificates in 'secured' network folders then perhaps is time to take a look at how Azure Key Vault can help you plug those security holes and lock down further your cloud environments.

This was just a very high level introduction but hopefully it was useful if you are just getting started with Key Vault. In my next post I will go over the Microsoft code sample for Key Vault and what it does to retrieve secrets from Key Vault that can be referenced at runtime.

Until next time, keep your secrets...well...secret, and stay secure!