Storing Server TLS certificates in Vault
To use Vault to issue Server TLS certificates the following will be needed:
- Bootstrap the Vault PKI engine and bootstrap it with any configuration required for your infrastructure.
- Create Vault Policies that will allow the Consul server to access the certificate issuing url.
- Create Vault Policies that will allow the Consul components, e.g. ingress gateways, controller, to access the CA url.
- Create Kubernetes auth roles that link these policies to the Kubernetes service accounts of the Consul components.
Bootstrapping the PKI Engine
First, we need to bootstrap the Vault cluster by enabling and configuring the PKI Secrets Engine to be able to serve TLS certificates to Consul. The process can be as simple as the following, or more complicated such as in this example which also uses an intermediate signing authority.
Enable the PKI Secrets Engine:
Tune the engine to enable longer TTL:
Generate the root CA
Note: Where
common_name
is comprised of combiningglobal.datacenter
dotglobal.domain
.
Create Vault Policies for the Server TLS Certificates
Next we will create a policy that allows ["create", "update"]
access to the
certificate issuing URL so the Consul servers can
fetch a new certificate/key pair.
Note: The PKI secret path referenced by the above Policy will be your server.serverCert.secretName
Helm value.
Create Vault Policies for the CA URL
Next, we will create a policy that allows ["read"]
access to the CA URL,
this is required for the Consul components to communicate with the Consul servers in order to fetch their auto-encryption certificates.
Note: The PKI secret path referenced by the above Policy will be your global.tls.caCert.secretName
Helm value.
Create Vault Roles for the PKI engine, Consul servers and components
Next, a Vault role for the PKI engine will set the default certificate issuance parameters:
To generate the <Allowed-domains-string>
use the following script as a template:
Prior to creating Vault auth roles for the Consul server and the Consul components, ensure that the Vault Kubernetes auth method is enabled as described in Vault Kubernetes Auth Method.
Finally, three Kubernetes auth roles need to be created, one for the Consul servers, one for the Consul clients, and one for the Consul components.
Role for Consul servers:
To find out the service account name of the Consul server, you can run:
Note: Should you enable other supported features such as gossip-encryption be sure to append additional policies to
the Kube auth role in a comma separated value e.g. policies=consul-server,consul-gossip
Role for Consul clients:
To find out the service account name of the Consul client, use the command below.
Note: Should you enable other supported features such as gossip-encryption, ensure you append additional policies to
the Kube auth role in a comma separated value e.g. policies=ca-policy,consul-gossip
Role for CA components:
The above Vault Roles will now be your Helm values for global.secretsBackend.vault.consulServerRole
and
global.secretsBackend.vault.consulCARole
respectively.
Deploying the Consul Helm chart
Now that we've configured Vault, you can configure the Consul Helm chart to use the Server TLS certificates from Vault:
The vaultCASecret
is the Kubernetes secret that stores the CA Certificate that is used for Vault communication. To provide a CA, you first need to create a Kubernetes secret containing the CA. For example, you may create a secret with the Vault CA like so: