Learn how Vault can help you build zero trust security on Microsoft Azure with five common use cases and five best practices.
With so many organizations moving to dynamic cloud-based infrastructures, the need for a new paradigm in security and secrets management has become apparent. Instead of trusting anything or anyone inside a network perimeter, the shift towards zero trust in dynamic environments requires mechanisms for passing credentials between ephemeral, dynamic systems. The new approach is zero trust security: assume that the network perimeter is not secure — trust nothing and authenticate and authorize everything.
One of the four key pillars of zero trust is securing machine authentication (authN) and authorization (authZ). Enterprises are now favoring centralized identity brokers and secrets management solutions that can secure machine authentication and authorization throughout their heterogeneous infrastructure assets. For the organizations moving applications to Microsoft Azure, the first solution they might consider is Azure Key Vault. So the first question an Azure user may be asking us is, “Why would I need HashiCorp Vault if I already have Azure Key Vault?”
The first key to answering that question is understanding that HashiCorp and Microsoft have held a partnership for years building integrations that make HashiCorp products work cleanly in tandem with Azure’s native capabilities. Microsoft and HashiCorp both understand that many organizations leverage HashiCorp Vault for centralized secrets management not only on Azure, but other environments that span both cloud and on-premises — where Azure’s native features won’t reach.
How are most of these enterprises with heterogeneous infrastructure using Vault in combination with Azure services? We’ve identified five common use cases.
Below we’ve outlined five of the most common use cases of customers using Vault with Azure to support zero trust security initiatives.
Securing dynamic cloud resources based on identity requires a mechanism for automating secrets management in order to scale effectively and reduce the risk of a breach. Before an application or resource uses Vault to manage or access secrets, it must authenticate to Vault. Vault supports multiple authentication methods (GitHub, LDAP, etc.), including Azure Active Directory (AAD) for system-assigned and user-assigned managed identities. See the Vault authentication overview and Vault’s Azure auth method documentation to get started.
A key component for zero trust security is to reduce secrets sprawl for machine-to-machine authorization. Once a system has authenticated to Vault leveraging trusted identities from AAD, Vault can generate secrets on-demand for Azure systems. For example, when an application needs to access Azure Data Lake, it asks Vault for credentials, and Vault will generate a keypair with valid permissions on demand. After creating these dynamic secrets, Vault will also automatically revoke them after the lease is up. See the Azure Secrets Engine hands-on HashiCorp Learn guide for using dynamic credentials in practice.
Clients and applications require Azure service principals to authenticate and access Azure services, such as Azure Kubernetes Service (AKS), based on assigned identities that stipulate authorization and access policies. The Azure secrets engine dynamically generates service principals that assign resources an identity and permit access to Azure resources. To lower the overhead of managing service principal credentials, Vault’s Azure secrets engine maps Azure group and role assignments to Vault roles, automating a significant portion of service-principal generation and ensuring that resources authenticating with Azure via Vault have the least privilege based on set policies. See the Vault documentation for instructions on how to set up an integration between Azure and Vault’s Azure Secrets Engine.
In many highly regulated industries, organizations are looking for highly secure solutions for key management that solidifies the root of trust for their cloud ecosystem to meet strict regulatory requirements for data encryption, such as GDPR and FINMA. For these instances when organizations need to bring their own key to the cloud, the Vault Key Management secrets engine (KMSE) supports lifecycle management of keys in named Azure Key Vault instances. See the Vault docs for more information on configuring KMSE to generate keys for Azure Key Vault instances.
As organizations look to scale Kubernetes on Azure broadly, securing access to Kubernetes is a top priority. As Kubernetes pods often have short lifespans, giving secrets to applications running on Kubernetes doesn’t scale. HashiCorp Vault can easily deploy centralized secrets management on Azure Kubernetes Services (AKS) via Vault’s Helm chart in just minutes. By leveraging a Vault agent on AKS, users are able to make templates for secrets and automate synchronization with Vault during credential rotation. To learn more about installing Vault as a service on AKS, see the Vault documentation.
We’ve also outlined five best practices seen by our customers running Vault on Azure infrastructure.
Vault initializes in a sealed state to protect Vault from being accessed by untrusted resources. By default, Vault has five unseal keys, three of which are required to unseal the cluster. While you can distribute one key to a trusted operator to ensure that no one person can unseal Vault alone, this can pose operational challenges and is impractical in some environments. If Vault is running on Azure, you can store a master key in Azure Key Vault and leverage a managed service identity to automatically unseal Vault. See the documentation on auto-unseal for Vault on Azure for more information.
Securing communication from Vault using TLS is a best practice for setup on Azure. However, one challenge in setting up TLS on cloud VMs is the initial secret injection of TLS certificates. Using the Azure Key Vault, you can leverage the Trusted Platform Orchestrator model to securely inject TLS certificates into the VMs, and VMs can be bootstrapped with certificates stored in Azure Key Vault.
To enhance an organization’s zero trust posture, it’s important to minimize manual, human controls and automate reliable security processes. Once a VM image for Vault has been created with optimal configurations, you can store the image on Azure Shared Image Gallery to make it available to others within the organization, ensuring that images align with business and security requirements built into role-based access controls (RBACs) of Azure controls, that optimized images can be replicated and deployed easily, and to allow versioning of approved images.
In the process of creating virtual disks for a VM that will use Vault, the best practice is to add an additional security layer by leveraging Azure Key Vault to generate a Key Encryption Key (KEK) to encrypt the virtual disks. Vault will encrypt data before storing it in Hashicorp Consul or another backend storage system. This additional layer of the KEK provides further mitigation against the risk of a breach.
To minimize the impact of an outage, it is a best practice to leverage Azure Availability Zones to deploy a single Vault cluster across three separate datacenters for high availability. When architecting Vault deployment to meet high-availability standards, consider using HashiCorp Consul as the backend storage for Vault. See the Vault documentation on deployment best practices for more information on recommended reference architectures.
Implementing a zero trust security model requires a fundamental shift in how you address identity and roles throughout your infrastructure, networking, and application layers. It doesn’t happen overnight, but together, HashiCorp and Microsoft are committed to helping organizations make zero trust security a reality with identity-based security solutions and practical steps for getting started that lower the risk of a breach and accelerate developer productivity.
Download the HashiCorp and Microsoft Azure: Delivering Zero Trust Security eBook to learn more about identity-based security.
HashiCorp has renewed its SOC II Type II report for HCP Vault and HCP Consul, and obtained ISO 27017 and ISO 27018 certificates for its cloud products.
Learn how to configure HashiCorp Vault’s OIDC auth method to use Azure as an identity provider.
Learn how to achieve user authentication to HashiCorp Vault with OIDC using Microsoft Azure AD as a central identity provider.