Article

Vault Integration Patterns with Venafi as a Service

By Ben Rogers

Posted on June 4, 2021

Topics

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 applications. 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 (CA), 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 first part of a series that explores the integration methods currently available between Vault and Venafi as a Service (formerly called Venafi Cloud).

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 agility and freedom of choice 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). Vault integrates with the Venafi Platform (see blog 1 and blog 2) and Venafi as a Service. 

  • The Venafi Platform is well suited for organizations that need enterprise scalability, workflow and integration options both on-premise and in the cloud.
     
  • Venafi as a Service is Venafi’s SaaS offering that allows DevOps teams to quickly obtain policy compliant certificates from your organization’s approved CA without requiring you to install or manage software.

This post explores using the vault-pki-backend-venafi with Venafi as a Service, which serves the targeted use case of connecting trusted third-party certificate authorities to Vault, enabling developers to use native Vault commands to request certificates from leading CAs such as GlobalSign and DigiCert.

Additional details about the workflows between Vault and Venafi can be found in this whitepaper.

Let’s get started!

Working with the vault-pki-backend-venafi plugin: 

Prerequisites: 

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 and Vault Production Hardening Guide.

Need a blueprint for cloud operating models? Read the HashiCorp white paper.

Venafi Configuration

This section will describe tasks to configure in Venafi as a Service. First, a CA account must be added to Venafi as a Service. A CA account is a connection to a Certificate Authority API. Second, an issuing template must be created. An issuing template allows you to select a CA account and apply rules that enforce certificate attributes. Third, a project must be created in Venafi as a Service. A project is an area in Venafi as a Service that will enable Vault to request certificates. Each project contains a zone. Lastly, you can retrieve the credentials and configuration that will be used by the Venafi Vault Secrets Engine from the Zone view.

Step 1: Configure CA account

Login to Venafi as a Service as an administrator. On the left-hand side navigate to Configuration -> CA Accounts. Any existing CA account will be displayed here. Select Add New Account, provide a name, then select a CA and provide a credentials file. Next, click Authenticate. If successful, the authorized domains and policy will be retrieved from the public CA. Click Add Account and the newly added CA account will appear in the UI.

Note that in this example GlobalSign will be used to demonstrate retrieval of publicly trusted certificates. Venafi as a Service also supports DigiCert for public certificate retrieval as well as a Venafi-provided CA for internal certificates.

Step 2: Create an Issuing Template

On the left-hand side navigate to Configuration -> Issuing Templates. Any existing template will be displayed here. Select Create New Template, provide a template name, then select a CA account. In this example GlobalSign will be used to demonstrate retrieval of publicly trusted certificates. After selecting GlobalSign, the issuing rules will be filled based on the policy retrieved from the public CA in the previous step. Click Save.

Step 3: Create a New Project

On the left-hand side navigate to Projects. Any existing projects will be displayed here. Select Create A New Project on the right-hand side of the screen. Give the project a name and description, and then click Create A New Zone. Give the zone a name, assign the Certificate Issuing Template which you created in the last step, and then click Save. In the DevOps User field, add any user accounts which should have access to this zone and click Save. This blog post leverages a single user account for administration as well as for the end user workflow. Note that as a best practice you should use a lower privileged user account with the ‘DevOps User’ role assigned to link with Vault so proper separation of duties is maintained.

Step 4: Retrieve Venafi as a Service Credentials

From the Projects menu, select the project which was just created by clicking on the project name. The project provides authentication instructions for common platform like K8s, Terraform and Vault. Select the Venafi Secrets Engine to retrieve the configuration and credentials for Vault. Make a note of the api key and zone as they will be needed when configuring Vault below. Note that the credentials have been removed from this screenshot.

Vault Configuration

Step 1: Download, unzip and install the Vault plugin, vault-pki-backend-venafi, for the desired operating system here along with its checksum.

1_prepare_plugin.sh


Step 2: Prepare and start Vault on a suitable system. This step can be skipped if Vault is already running.

2_start_over.sh


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 auto-unseal methods as discussed here. This step can be skipped if Vault is already running.

3_init_vault.sh

Step 4: Install the vault-pki-backend-venafi plugin

4_install plugin.sh

Step 5: Enable the plugin and configure a role.

5_configure_plugin.sh

Set the following environment variables with your Venafi as a Service credentials, zone and list of allowed domains prior to running the script.

export API_KEY=“<enter api key here>”

export VC_ZONE=“<enter zone name here>”

export ALLOWED_DOMAINS=“<enter allowed domains here>”

If you choose to execute the commands interactively rather than running the script, Venafi as a Service provides a configuration snippet that you can copy/paste directly into your terminal. See step 4 above for more details.

The Vault read command can be used to verify the configuration.

Step 6: Test Plugin: request certificate

6_test_plugin.sh

The Vault configuration is now complete, and certificates from third-party CAs may be requested from Venafi as a Service via Vault. When a valid certificate request is honored, Venafi sends an email notification to the requestor and Vault outputs the certificate, chain and private key. In the example below test.thehotelcook.com is allowed by policy and is visible in Venafi as a Service after the request is completed, which is done by navigating to Projects -> *your project name* -> View certificate requests. Certificates that were successfully generated as permitted by policy will be highlighted in green, while requests which failed due to policy enforced by the CA will be highlighted in red. In order to view the details of the certificates that were generated, navigate to Projects -> *your project name* -> View issued certificates.

Conclusion

This blog post has shown how the vault-pki-backend-venafi plugin allows organizations to use Vault and Venafi as a Service together so that SSL/TLS certificate requests can be sent to Vault but fulfilled directly by Venafi as a Service on behalf of third-party certificate authorities or its built-in CA. This alleviates the need for manual approval workflows thus allowing organizations to move faster while remaining compliant.

Find out how HashiCorp and Venafi integrate security with speed in the HashiCorp DevOps Lifecycle. HashiCorp CTA Armon Dadgar explains.

This site uses cookies to offer you a better experience. If you do not want us to use cookies, please update your browser settings accordingly.
Find out more on how we use cookies.