What is HashiCorp Vault?
Author: John 'JJ' Jarvis
Release Date: 21/02/2023
By now, you’ve probably heard about HashiCorp, or at least their flagship product: Terraform, which automates the provisioning of infrastructure through what’s dubbed Infrastructure as Code, or IaC, for short. But HashiCorp offers a number of solutions in this automation space, collectively called the Cloud Operating Model, and chief amongst these is HashiCorp Vault.
In a nutshell, HashiCorp Vault is an identity based secrets management solution. That is, Vault brokers and deeply integrates with trusted identities to automate access to secrets, data, and systems. As this implies, there are common use cases outside strict secrets management — e.g., passwords, certificates, tokens, etc. — including encryption services and (cryptographic) key management, to name but a few.
Today, we’ll focus on Vault’s functionality around application and machine identity, and how Somerford leveraged this to secure workloads across dozens of application teams with a multinational client recently. Specifically, we’ll look at how Vault helped secure applications and systems with machine identity and automate credential issuance, rotation, etc.; and the lynchpin of this solution was Vault’s AppRole authentication method (or auth method, for short).
What is AppRole?
In a typical use case, to consume secrets, an application must first log in to Vault and obtain a short lived token. The process is usually dependent on either the platform where the application is deployed (e.g., AWS, GCP, Azure, Kubernetes, OIDC, etc.) or the workflow used to deploy it (e.g., continuous integration tools such as Jenkins or CircleCI). HashiCorp Vault’s AppRole auth method allows machines or apps to authenticate with Vault-defined roles. The open design of AppRole enables a varied set of workflows and configurations to handle large numbers of apps; this flexibility means that a complete description of the method is outside the scope of this blog post, however, in general, Figure 1 outlines the process.
(Note that Fig. 1 is lifted from the HashiCorp Learn tutorial on AppRole; we’d highly recommend taking a look at all the tutorials there, as they are continually refreshed to ensure the content is accurate and relevant).
As a final teaser on AppRole, one of its more powerful features is the ability to separate out the credentials as a Role ID and a Secret ID. Since the Role ID needn’t be kept secret, this facilitates automating machine / app authentication; that is, by allowing it to be embedded in machine images, which applications can use to securely request (and securely receive!) the Secret ID.
(Note that Fig. 2 is lifted from the HashiCorp blog post entitled How (and Why) to use AppRole Correctly in HashiCorp Vault, which we would highly recommend reading for a deeper understanding of this auth method, and its potential).
Case Study: Securing Jenkins workloads with HashiCorp’s Vault
In the context of this case study, HashiCorp’s AppRole can provide a platform-agnostic means of securely delivering these credentials to a Jenkins CI/CD pipeline.
In Figure 3, above:
• The Vault operator configures AppRole such that each application team has its own ‘role’ in Vault;
• The Vault operator then enters the Role and Secret IDs in the Jenkins folder configuration, one for each app team;
• An application team fires up a pipeline for an AWS related workload, under their Jenkins folder;
• That pipeline then logs in to Vault using AppRole, and,
• A Vault token is returned, with Vault policies attached for any number of accesses, including, in this example, team specific instances of an AWS secrets engine, which can be used to generate dynamic, short lived credentials for that platform
• The pipeline then uses these AWS credentials for its work on that platform
All the while, the client’s security team is assured that these workloads are audited and properly attributed to individual application teams. In addition, all the associated credentials are expired and invalidated after a configurable period of time, without intervention of any sort, seamlessly.
In our case study, the client was happy to refresh the Secret IDs associated with the many application teams on a periodic basis. There are, however, many other ways of implementing this solution, including, for example, allowing a client process to do that refresh instead: check out the second example in this gist by our colleague, Kawsar Kamal.
More Resources like this one:
How to use Public Key Infrastructure (PKI) with HashiCorp Vault | HashiCorp Vault 101
(VAP) for HashiCorp Vault
