Keeping Secrets with Azure Key Vault

//Keeping Secrets with Azure Key Vault

In today’s world of managing source code and DevOps across developer machines and ALM systems, it has become an absolute must to secure access to sensitive data. Items such as passwords, certificates, and cryptographic Keys. Managing the access to these assets on your own can be tricky at best and catastrophically insecure at worst. Luckily there are options out there to assist with this task. One of those is Azure Key Vault.

Simply put, Azure Key Vault is a logical container that holds cryptographic keys and “secrets” that are backed by an HSM (Hardware Security Module). This container can be managed by the security officer of an organization where they can grant access to keys and secrets on a per application or per user basis. There are several concepts in that previous statement, so let’s break it down a bit to get a better understanding of what Azure Key Vault does for you.

Keys and Secrets

The first two key words are “Keys” and “Secrets” (see what I did there). Inside an Azure Key Vault (AKV), a “Key” represents a cryptographic key that is used to encrypt and decrypt data. The value that AKV provides is that once a cryptographic key has been added to the vault, it can never be directly accessed by applications or users. Encryption, decryption, and signing is handled by Azure Key Vault on the application’s behalf. Think of it like the Hotel California for cryptography keys. The keys can be be checked out (i.e. used), but they can never leave.

On the other hand, “Secrets” are things that can be directly accessed by authorized applications and users. They are typically items like connection strings or API passwords to services like azure blob storage or a Redis database.

Managing the Azure Key Vault Container

An organization will typically have a security officer that is responsible for managing access to sensitive data. This person would be responsible for creating the Azure Key Vault and granting access to applications or individual users. The benefit is two-fold. First, developers don’t have direct access to secrets and keys and therefore cannot inadvertently add these items to source control. Second, the centralization of the assets makes granting and revoking access much easier since the Azure Key Vault is an abstraction around all of this sensitive data. This abstraction comes in the form of Azure PowerShell, the Azure CLI, or the Azure portal.

Quick Create of an Azure Key Vault Container

Creating an Azure Key Vault is done by adding it to an Azure Resource Group. As mentioned above there are three ways to setup and manage the AKV: Azure PowerShell, Azure CLI, and the Azure Portal. I’ll show a high level way to get started using the Azure portal.

The first thing I like to do when I know I’ll be managing a new part of Azure is to setup a shortcut in the navigation bar so I can gain quick access. The way to do that is as follows:

  1. In the Azure portal, at the bottom of the navigation bar, click “More Services”
  2. Inside the search, type in “Key Vault”
  3. Click the star to pin that shortcut in your navigation bar
  4. Adjust the location of the item by drag-and-drop
Animated Gif of adding Azure Key Vault shortcut to the Azure portal navigation bar

Click to see animated gif

Once you’re on the Key Vault section, go ahead and click the “Add” button to start the process of creating an individual Vault. This process is as follows:

  1. Click on the “Add” button
  2. Enter the name of the Vault
  3. Connect to an existing resource group or create a new resource group
  4. Choose the location of the Key Vault
  5. Choose your pricing tier
  6. Leave the access policy as-is for now (it defaults to your user having full access)
  7. Select the advanced access policies for how different Azure services can interact with your Key Vault. Typically you would want these services to be able to interact with the vault
Animated gif of creating an Azure Key Vault

Click to see animated gif of creating a key vault

Granting Access

Once again, the assets inside the individual vaults can be granted access to users as well as applications. This means that if you don’t want users to have direct access to an asset, you can set permissions to only allow applications to have this access. This is done through Azure Active Directory.

Something to keep in mind is that Azure Key Vault can only be granted access through Azure Active Directory.

Each application that needs access will be required to have a service principal created in Azure Active Directory. This means that a global administrator or a user with User Management authorization will need to create the service principal for that application prior to granting it access to the Key Vault.

Creating the service principal is a bit outside the scope of this blog post but detailed instructions can be found here.

Once you’ve created the service principal for the application, you can add it to the list of Principals for your vault. The high-level process to accomplish this is as follows:

  1. Select the Access Policies menu item (under the “Settings” section)
    Azure Key Vault Access Policies menu item 
  2. Select the “Add New” button
    Add New Access Policy Principal 
  3. Choose the service principal from your Azure Active Directory
    Select Service Principal      Choose Service Principal 
  4. Choose the Key Permissions to grant to the application
    Choose Key Permissions
    Permission options for keys
  5. Choose the permissions granted to Secrets
    Select permissions for secrets
    Permission options for secrets
  6. Click OK to finish

Something that is very important to consider is the fact that the permissions applied to the service principal are across the entire vault. There is currently no way to assign permissions to individual keys or secrets. This is easily overcome by creating separate vaults that will allow you to segregate the permissions across assets more easily. Vaults cost nothing to create, only the assets held within.

How Applications Can Access Secrets

Often times we see organizations putting sensitive data like connection strings directly in a config file or app settings file which then get committed to source control. This can be avoided with the use of Azure Key Vault. Developers can be given credentials for the service principal as well as URI’s for the “secrets”. These two items allow them to fetch those connection strings at the startup of an application and keep around in memory until the application is shut down.

The credentials for the service principal would have to come from the global administrator or user manager when they setup the service principal. The URI for each “secret” comes from each secret inside the vault.

Start Today

As you can see, there are lots of benefits that leveraging Azure Key Vault can provide. Of course, Azure allows for other more advanced scenarios which leverage Azure Key Vault which can be found in their documentation or by simply taking it for a spin yourself. There’s no time like the present to get started with this service. Feel free to reach out to us here at Nebbia Technology to help you with creating these scenarios.

By |2017-03-14T10:32:23+00:00March 14th, 2017|

About the Author: