I have been recently looking at one of the biggest pains to operational IT; PKI, Certification, and re-certification of resources. I bet you did not know that HashiCorp Vault can help with this?
But first a little back story about why Security is important in today’s world filled with Ransomware, state-sponsored hacking and other nefarious methods of gaining control of systems for illegal purposes, Businesses have, by necessity, become untrusting. One of the favourite concepts running through boardrooms and Security teams is that of “Zero Trust Security Model.” The concept of “Zero Trust” has taken over from the former buzzword bingo term “Defence in Depth“. These terms relate to security being multi-layered rather than concentrated on the perimeter. The “Defence in Depth” concept is modelled on a military concept of protecting critical assets. So rather than just placing all your troops at the front line and being overrun by a company of paratroopers being dropped directly on your headquarters because your anti-aircraft battery couldn’t hit the enemy transport planes. Or, in technical terms, finding all your servers locked down with encryption because your firewall had a critical zero-day vulnerability which has not been patched. “Zero Trust” goes one step further and dictates that nothing is trusted. Layers of protection and everything verified, logged and auditable, together with the principle of lowest privileges required to get the task done, is the day’s order.
This is a soulless and untrustworthy world.
True “Zero Trust” is very challenging to achieve, and I believe a bit of trust is necessary in this world.
One of the key providers of proof or trustability in IT is focused on PKI or Public Key Infrastructure; deploying and managing PKI, however, is a dark art that even Wizards of the calibre of Voldemort and Dumbledore will attempt to steer clear off. “Pubilc Key Infrastructure” is used to prove the trustability of a machine, end user or a piece of code by providing an encrypted identity card that can be proven to have been created by a trusted entity.
A Quick Overview
PKI provides a method to verify the identity of a domain, organisation, piece of code, user, or device. PKI uses the principles of a trusted path, “I trust you and believe you to be trustworthy, and you trust them, so I will also trust them,” and encryption in the way of digital signature, also called certificates, to prove you are whom you say you are.
A PKI can generate three main types of certificates these are:
- SSL/TLS certificate: Used to provide a trusted validation of Domains and Organisations.
- Code Signing Certificates: Used to provide a digital signature to verify software ownership.
- Client Certificates: Used to provide validation of an end user or device.
For a deeper overview of PKI’s dark arts, read the following articles.
- 3 types of PKI certificates and their use cases
- Public Key Infrastructure: PKI explained in simple terms
There are two main methods of creating a trust path for your certificates::
- Trusted third-party root Cert: Your Root Authority is backed up by a signed certificate from a leading trusted authority provider like Digicert, Entrust, Thawte or VeriSign. Using one of these providers to provide backing for your Root Cert will improve global acceptance.
- Self-signed certs: These certificates will use a Certificate created from an internal Root Certificate. These certificates are perfectly safe to use for internal-facing devices and users but can cause issues when placed on external-facing resources, as the Root key used to create the certificate is not trusted by the receiving end device. An example of an self-signed cert provider is when a company uses the Internal Microsoft Certificate Authority to provide Root Certificates, Intermediate and end-use certificates.
One of the main operational challenges with Certificates is renewals; all certificates have a renewal date, 1-2-3 or 5 years, for example. After which, the device will become untrusted unless the certificate is updated with a new expiry date. Certificate renewal is not a trivial task. This post will focus on using HashiCorp Vault to provide an automated method of renewing certificates.
In our earlier articles on Vault, we used the open-source version to provide a one-time use assumed identity to manage HCP securely. To review that work review the following articles:
How simple Terraform plans make hybrid and multi-cloud a reality: an introduction
Deploying a LAMP Stack with Terraform – AMIs, network & security
Deploying a LAMP Stack with Terraform – Databases & Webservers
How to create resilient Terraform code
Deploying and configuring HashiCorp Vault to service Terraform
Deploying a LAMP Stack with Terraform Modules
Migrating Terraform from AWS to Azure: credentials & secrets – Amazic
Migrating Terraform from AWS to Azure: changing the provider code – Amazic
Building images and VMs in Azure with Terraform – Amazic
Building auto-scaling groups in Azure with Terraform – Amazic
Create cache, databases and DDoS protection in Azure with Terraform – Amazic
Today, we start to configure Vault to provide Certificate services. However, instead of using the opensource product, we will introduce “Vault on HCP” and use this product as the basis for this and the ongoing articles.
NOTE: HCP Vault currently utilises AWS to provide its infrastructure, and this has a usage cost associated with it. It is important to remember that all incurred costs are the responsibility of the reader. However, at the time of writing, there is a free option as HCP on Azure is currently in Beta and as you will be testing the product for them, any consumption usage does not have any costs applied, however, you are limited to Development and test.
To keep any costs associated with this project low, we will use the HCP Azure Beta infrastructure to build out the Vault Infrastructure.
Building a Vault Cluster on HCP
We will assume that you already have an account to access HCP; the signup process is not onerous. After your successful login, you will be presented with the following:
You will notice that there is more than the Vault product in HCP. You can review these at your leisure.
Click on the Deploy Vault link to start deploying your Vault cluster. The first section of the form defines the location the environment is to be deployed into; we have chosen Azure. Unfortunately, Azure is still in Beta, you cannot change the Deployment type from Development.
NOTE: it is essential to note that at the time of writing, HCP Vault on Azure is not to be used for Production workloads.
There are two options, create from a template (key-value secrets) or Scratch build; we will choose the second option, “Scratch-build“, as it provides a couple of extra options.
Like the vault tier, the cluster size is not currently configurable. We are not changing the Network ID, but it is recommended to consider changing this to something more appropriate for your environment. Due to my location, I have chosen UK South as my deployment location. There are other locations, but these are currently limited in number.
Unless you only allow private access directly into your private resources, it is simpler to let Hashicorp manage your CIDR block. If Private access is required, we suggest speaking to your network department to provide a safe address range. For ease, and because we will be destroying this instance, we are going to provide public access.
Finally, choose a name for your Vault cluster.
Once you are satisfied with the configuration, press Create Cluster; after about 15 minutes, you will receive a similar response as shown below.
Click on the Cluster name under the ID column. You will be passed to the following page, now this is a very busy page with a lot of information and options.
Before you access your Cluster for the first time, you will need to generate an Admin Token. To carry out this task, click on the Generate token link. Then, after the Token has been created, click the resultant copy link to save the Token into your cache. You will need this for your subsequent logins. However, unlike the unseal tokens that are used with the open-source product; this Token has to be regenerated inside of your HCP instance each time access is required and does not need to be securely stored.
NOTE: if you suspect an intrusion of your vault cluster, you can always click the big red button API Lock; this action will immediately seal your Cluster.
To interactively access your vault instance, you click the Public link in the Access web UI box.
Enter your recently captured Token, and click sign in. After a successful login, you will be presented with a page like the below.
As a part of this article, we discussed, at a high-level, PKI infrastructure and certificates, together with the types and their use cases. The final part of the article focused on creating a vault cluster on Hashicorp’s HCP product. We will create the Vault-based Certificate server in the following article in this series.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to email@example.com.