Vault Integration Patterns with Venafi
Written by Jeremy Gerson of HashiCorp, Ben Rogers and Ryan Treat of Venafi
Overview: HashiCorp Vault is a security platform that addresses the complexity of managing secrets across distributed infrastructure. The current state at many organizations is referred to as “secret sprawl,” where secret material is stored in a combination of point solutions, confluence, files, post-it notes, etc. Vault is a solution for eliminating the sprawl, while providing a common API and flexible authentication methods for cloud-native and legacy workflows. Some common use cases for Vault are storage of existing database credentials, app credentials, ssh keys, cloud access keys, etc. Vault also supports dynamic creation of secrets on demand for the cloud, databases, and can act as a Certificate Authority providing dynamic short-lived PKI certificates.
In the same way that Vault has become a standard in the world of secrets management, Venafi has become a standard platform for providing centralized policy control, visibility and automation for the lifecycle of machine identities including public and private SSL/TLS certificates.
Together Venafi and HashiCorp make it easy for DevOps teams to go fast and Security teams to get the visibility, intelligence, and policy enforcement they require to protect the business.
This blog is the first one in a series that will explore the integration methods currently available between Vault and Venafi. To learn about the second pattern, check out part 2.
The Solution:
The integration options for Vault and Venafi appear in the form of Vault plugins: Venafi Secrets Engine (vault-pki-backend-venafi) and Venafi Monitor Engine (vault-pki-monitor-venafi).
The pki-backend is a plugin for Vault which allows certificate requests to be fulfilled directly by Venafi on behalf of 40+ CA’s. In this model, Vault provides the common API for DevOps teams to perform certificate requests, while the Venafi platform fulfills the requests. Since each request for a certificate is fulfilled by Venafi, latency between the platforms should be considered.
The pki-monitor is another plugin for Vault which allows Vault issued certificates to be governed by Venafi policy and is the focus of this guide. The plugin can monitor Vault issued certificates when Vault operates as an intermediate or root CA. For this discussion, Vault will function as an intermediate CA from an internal root Microsoft CA. Note that Microsoft CA is being used as an example only and could be replaced with another certificate authority. If you are familiar with the native pki engine in Vault, the workflow to setup and operate the pki-monitor plugin is similar. The added benefit with this approach is that PKI policy is centrally defined in Venafi, downloaded to Vault during plugin setup, and enforced during the certificate generation request to Vault without the added latency of Venafi fulfilling the request. PKI security policies are rules defined in Venafi which dictate the allowed values of each field on the certificate, like common_name, organization, etc. Auditability and visibility is maintained via Venafi on any certificate generated by Vault.
Additional details about the workflows between Vault and Venafi can be found in this whitepaper https://www.hashicorp.com/resources/protecting-machine-identities-blueprint-for-the-cloud-operating-model.
Let’s get started!
Working with the vault-pki-monitor-venafi plugin:
Prerequisites:
- Venafi Trust Protection Platform
- HashiCorp Vault
This guide will offer a script for running Vault locally for testing. When deploying to production it is recommended to follow HashiCorp’s deployment guide https://learn.hashicorp.com/vault/operations/ops-deployment-guide. Optionally, an existing Vault development environment may be used.
Venafi Configuration
Step 1:
Access the Microsoft PKI and create a sub authority template. This template allows Venafi to ask for a sub authority to be created and issued through the Microsoft PKI. Note that Microsoft is being used as an example only.
Step 2:
Access Venafi and create the template which allows Venafi to issue a subordinate CA through the Microsoft PKI. In the example below, the template is called “Vault SubCA Template.” Template definition parameters such as validity period and renewal period may be adjusted as required.
Step 3
Create folders in Venafi to house the Vault related use cases.
Create the HashiCorp Vault folder
Create the folder Policy\Certificates\HashiCorp Vault.
This folder contains all relevant policy controls for Vault and all certificates issued by or through Vault. A hashicorp_svc user is created for Vault which should be granted View and Read Permissions for this folder.
Create the Vault Issued folder
Create the folder \Policy\Certificates\HashiCorp Vault\Vault Issued. All certificates that the Vault SubCA creates will live in this folder. The hashicorp_svc user should be granted View, Read, Write, and Create permissions here.
Set and lock the policy to Monitoring.
Ensure that CSR generation is Unlocked.
Specify Subject DN information and lock any values set.
Apply Allowed Domains and configure whether to allow Wildcard certificates in this policy. Note that today Venafi cannot enforce the “Allow Duplicate Common and Subject Alternative Name” within Vault so this value has no effect.
Set the key parameters as required. In this example, we are requiring RSA 2048 bit keys.
Disable SSL/TLS Validation and lock the value to Yes.
Create the VaultSubCA Folder
Create the folder \Policy\Certificates\HashiCorp Vault\VaultSubCA.
Optionally, this folder can be configured with a Stage 500 issuance approval or an adaptable workflow in order to limit the ability to create a SubCA. In this example we will not have a workflow applied to this folder.
This folder houses the Vault SubCA certificate. Vault will be connecting to Venafi Trust Protection Platform (TPP) and downloading the Venafi Policy values and applying them to a Vault Role for issuing certificates in subsequent steps. The hashicorp_svc user should have View, Read, Write, Create, Rename, and Revoke permissions on this folder.
Choose Contacts, Approvers, and Set the Management Type to Enrollment. Lock each of these values.
Set and lock the CSR Generation to User Provided CSR.
Set and lock Subject DN information according to your organization policies.
Set and lock key size requirements for the Issuing CA.
Set and lock the CA Template to the Vault SubCA Template.
Turn off Network Validation by setting Disable SSL/TLS Validation to Yes. Lock this value.
The Venafi configuration is now complete.
Vault Configuration
Step 1: Download, unzip and install the Vault plugin for the desired operating system from https://github.com/Venafi/vault-pki-monitor-venafi/releases/ along with its checksum for the binary. There are two versions of binaries, optional and strict. The “optional” version allows certificates to be issued by the Vault CA when there is no Venafi policy applied whereas the “strict” will return an error when there is no Venafi policy applied, “policy data is nil”.
Step 2: Prepare and start Vault on a suitable system. This step can be skipped if Vault is already running.
Step 3: Initialize, Unseal and login to Vault. This example uses Shamir’s Secret Sharing for unsealing. In production it is common to use one of the autounseal methods as discussed here https://www.vaultproject.io/docs/configuration/seal/index.html. This step can be skipped if Vault is already running.
Step 4: Install vault-pki-monitor plugin
Step 5: Initialize SubCA, generate CSR towards Venafi and define roles in Vault. During the SubCA initialization process, policy is downloaded from Venafi which specifies the allows values for the SubCA.
Set the following environment variables with Venafi credentials prior to running the script.
export TPP_ADDR=https://example.venafi.com/vedsdk
export TPP_USER=serviceaccountuser
export TPP_PASS=serviceaccountpassword
Set the following environment variable with an address of the Vault server which can be reached by Venafi in order to publish a CRL.
export PUBLIC_VAULT_ADDR=http://test.mylocalvault.com:8200
Be sure to change the hostname in the example below to the Vault instance URL. Venafi will use this information to check revocation during the nightly revocation check process.
The following policy which is downloaded from Venafi and applied to the subca role enforces the fields values which may be requested on each certificate.
Step 6: Test SubCA
Configuration is complete, and certificates may be requested from Vault. In the example below alpha.venafi.example, beta.venafi.example, and delta.venafi.example are allowed by policy.
The request for a certificate with delta.venafis.example is rejected due to policy (venafis spelled incorrectly).
A list of certificates generated by Vault can be viewed, and certificates can be revoked as needed. Venafi checks Vault’s CRL endpoint once every 24 hours.
The Venafi Platform is aware of any certificate generated by Vault, “alpha.venafi.example”, “beta.venafi.example”, “delta.venafi.example”, as well as the history of any certificate generated multiple times, such as “delta.venafi.example” in the second screenshot below. Any certificate which was not allowed due to Venafi policy which was previously downloaded is blocked at Vault, and Venafi will not be aware of it.
Conclusion
Venafi is the platform for enforcing policy and providing a common auditing platform for all types of certificates. This guide leveraged Venafi to impose policy on Vault and monitor the certificates generated by Vault as a SubCA.
