As an increasing number of customers move to the cloud, including multi-cloud and hybrid environments, securing infrastructure at scale emerges as one of the key challenges. There are many components to working securely in cloud environments, with one of key aspects being properly managing access to services deployed and ensuring these services stay secure as infrastructure needs accelerate exponentially.

HashiCorp Vault integration with Azure Active Directory (AAD), available in Vault 0.10, gives you a way to leverage identity information stored in AAD to control access to secrets stored in Vault. When combined with Managed Service Identity, a feature of AAD, this integration gives Azure customers an easy way to bootstrap identity and access to secrets in the HashiCorp Vault. You can learn more about HashiCorp Vault and all the powerful features it provides at vaultproject.io.

Configuring AAD Authentication for Vault

For resources running in Azure, Vault AAD Authentication offers the most benefit when combined with the Managed Service Identity (MSI) feature of Azure Active Directory since Vault treats AAD as a trusted third party. AAD authentication tokens provided by MSI enable integrated authentication to Vault.

To enable AAD Authentication for Vault, make sure you are running Vault version 0.10 or later, then issue the following command:

Vault can use the MSI of the machine that it’s running on to perform calls into Azure, as illustrated below. Alternatively, you can configure separate credentials that the plugin will use, as described in the configuration section of Vault AAD Auth API documentation.

Finally, you should create a set of Vault roles to properly constrain access to the secrets in Vault.

For detailed guidance on configuring Vault AAD Authentication, visit Vault AAD integration documentation.

Using AAD Authentication with Vault

After configuring Vault AAD authentication, services running in Azure can start using Vault to store and retrieve application secrets. Azure services authenticate themselves to Vault via a call to the login API method and passing the required jwt and role parameters. If you used bound_subscription_id and bound_resource_groups parameters during configuration (as in the example above) to further restrict access to Vault information, you must supply those to the login call along with the name of the Virtual Machine. AAD Managed Service Identity provides the jwt token parameter for services running in Microsoft Cloud. You can obtain subscription id, resource group and other parameters by calling into the Instance Metadata Service in Azure.

After logging into Vault, Azure services read and write Vault secrets in the usual manner, using vault write and vault read commands, as illustrated below.

To infinity and beyond

With AAD authentication integration for Vault now available, applications and services running in Azure can store and access secrets in a secure and scalable way. As an example, virtual machine instances in Virtual Machine Scale Sets in Azure can now let the Vault AAD Authentication handle access to secrets needed for these instances while automatically verifying their identity. This eliminates the need for any human/process interaction.

This new feature of Vault will allow customers to easily scale services to Azure while allowing them to use the services that they are familiar with, accelerating their cloud adoption efforts.