Vault Integration Patterns with Venafi: Part 2
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 cloud platforms and 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 for Security teams to get the visibility, intelligence, and policy enforcement they require to protect the business.
This blog is the second part of a series that explores the integration methods currently available between Vault and Venafi.
As businesses operate in multi-cloud or hybrid models, they require a set of standard, common services to achieve consistency, agility, and speed. Venafi and HashiCorp together, aim to provide a consistent platform that enables teams to move fast and safely, while providing freedom of choice and agility over where applications run.
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). In the first part of this series the vault-pki-monitor-venafi plugin was demonstrated. That plugin allows Vault issued certificates to be governed by Venafi policy. This post focuses on the vault-pki-backend-venafi plugin.
Both plugins provide visibility and policy enforcement from the Venafi platform for SSL/TLS certificates that serve as machine identities while providing common Vault APIs to developers requesting certificates. To help you determine which plugin is appropriate, here is a brief overview of the benefits of each plugin.
The vault-pki-backend-venafi plugin should be considered when organizations are using cloud deployments as an extension of their datacenter. This will typically involve IaaS services coupled to existing datacenters with VPN connections that may be unidirectional or bidirectional. This will allow organizations to use their existing internal PKI and continue to trust the existing machine identities. The vault-pki-backend-venafi plugin enables developers to obtain both publicly trusted and private SSL/TLS certificates through any of Venafi’s Certificate Authority integrations like DigiCert, Entrust, Microsoft, etc. using native Vault commands.
The vault-pki-monitor-venafi plugin should be considered when running in a cloud environment that has limited access to existing corporate data centers or when cloud environments need to operate in a disconnected or isolated way. This will typically require the use of a new issuing authority (as described in the previous blog) that will limit trust between cloud resources and on-premise resources. The plugin monitors Vault-issued certificates when Vault operates as an intermediate or root CA and enables PKI policies, which can restrict allowed values of certificate fields like common_name and organization to be centrally defined in Venafi, downloaded to Vault during plugin setup, and enforced during the certificate generation request. This plugin should be considered when high speed issuance is a major design consideration.
The focus of this blog is to demonstrate the vault-pki-backend-venafi for Vault which allows certificate requests to be fulfilled directly by Venafi on behalf of 40+ certificate authorities (CAs). This provides seamless access to publicly-trusted and private SSL/TLS certificates using native Vault commands. In this model, Vault provides the common API for DevOps teams to perform certificate requests while the Venafi platform fulfills the request. Security teams maintain constant visibility and policy enforcement through Venafi.
Additional details about the workflows between Vault and Venafi can be found in this whitepaper. The previous blog in this series may be referenced if your use case requires the vault-pki-monitor-venafi plugin.
Let’s get started!
Working with the vault-pki-backend-venafi plugin:
Prerequisites:
- Venafi Trust Protection Platform
- HashiCorp Vault
This guide will offer a script for running Vault locally for testing. Optionally, an existing Vault development environment may be used. When deploying to production, it is recommended to follow HashiCorp’s Vault Deployment Guide.
Venafi Configuration
This section will describe three tasks to configure in Venafi Trust Protection Platform. First, a user must be granted access to the Venafi API. Second, a Certificate Authority template must be created in Venafi. Third, a policy folder will be created and configured to allow publicly trusted certificates to be requested from within Vault and fulfilled via Venafi on behalf of CAs.
Step 1: Grant API Access to Venafi TPP
Grant a user access to the Venafi API. In this example, we are using the AD user hashicorp_svc. Navigate to Identity -> Identity Providers -> VenafiDemo (our AD provider) -> Users & Groups. Search for the user that will be granted API access. Click on the hashicorp_svc user to show the details, check Allow WebSDK Access, and save the change.
Step 2: Create a CA Template in Venafi
Navigate to the Policy view and select the folder for certificate authority templates. (1) Right click Policy\Administration\Certificate Authorities -> Add -> CA Template -> DigiCert. (2) Name the template DigiCert 1 Year TLS. (3) Select the API Key credential. (4) validate the connection. Select an appropriate template for your use case. In this example, we are using the Multi-Domain SSL template. Save the template when finished.
Step 3: Create a Venafi Policy Folder
Navigate to the Policy view and select Certificates Folder. In the previous blog, we had already created the folder Policy\Certificates\HashiCorp Vault, so we will create a sub folder called DigiCert to control the policy for certificates issued against this template. Note: DigiCert is being used as an example here, but any of 40+ CAs could be used instead. (1) Right click on Policy\Certificates\HashiCorp Vault -> Add -> Policy (2) Name the folder DigiCert and use the remaining screenshots as guidance for configuring this policy.
Set Management Type: Enrollment and lock the value.
Set the CSR Generation: User Provided CSR and lock the value.
Set Subject DN values to match your organization’s policy and lock each value.
Optionally set Allowed Domains to ensure only allowed domains can be requested from Vault.
Set Key Strength and Key Algorithm as necessary.
Set the CA Template. In this example, we are using the template we created above called \VED\Policy\Administration\Certificate Authorities\DigiCert_1_Year_TLS. Note that DigiCert could be replaced with any of 40+ CAs that Venafi integrates with. Lock this value.
Disable SSL/TLS Validation to ensure validation does not run for certificates requested by Vault. Lock this value.
From the General -> Permissions tab, set up hashicorp_svc to access this folder with the following permissions: View, Read, Write, Create, Delete, Rename, Associate, Revoke, and Private Key Write.
Vault Configuration
Step 1: Download, unzip and install the Vault plugin for the desired operating system here along with its checksum.
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. If you choose to run the script, the root token and unseal keys will be sent to the screen as well as saved in init.out. In production, it is common to use one of the autounseal methods as discussed here. This step can be skipped if Vault is already running.
Step 4: Install the vault-pki-backend-venafi plugin
Step 5: Enable the plugin and configure a role.
Set the following environment variables with your Venafi credentials prior to running the script.
export TPP_ADDR=https://example.venafi.com/vedsdk
export TPP_USER=serviceaccountuser
export TPP_PASS=serviceaccountpassword
export TPP_ZONE=”Certificates\\\\HashiCorp Vault\\\\Internal PKI”
export VAULT_ADDR=http://127.0.0.1:8200
The Vault read command can be used to verify configuration.
Step 6: Test Plugin: enroll certificate and sign CSR
Configuration is now complete and certificates may be requested from Venafi via Vault. In the example below hashicorpvault.se.venafi.com is allowed by policy and is visible in Venafi TPP after the request is completed.
In the example below fail.venafi.com is not allowed by Venafi policy.
Conclusion
This blog post has shown how the the vault-pki-backend-venafi plugin allows organizations to use Vault and Venafi together so that SSL/TLS certificate requests can be sent to Vault but fulfilled directly by Venafi on behalf of 40+ certificate authorities.
