Vault as the Server TLS Certificate Provider on Kubernetes

Vault as the Server TLS Certificate Provider on Kubernetes

Overview

To use Vault as the server TLS certificate provider on Kubernetes, complete a modified version of the steps outlined in the Data Integration section.

Complete the following steps once:

Create a Vault policy that authorizes the desired level of access to the secret.

Repeat the following steps for each datacenter in the cluster:

(Added) Configure allowed domains for PKI certificates
Create Vault Kubernetes auth roles that link the policy to each Consul on Kubernetes service account that requires access.
Update the Consul on Kubernetes helm chart.

Prerequisites

Prior to setting up the data integration between Vault and Consul on Kubernetes, you will need to have:

Read and completed the steps in the Systems Integration section of Vault as a Secrets Backend.
Read the Data Integration Overview section of Vault as a Secrets Backend.
Complete the Bootstrapping the PKI Engine section.

Bootstrapping the PKI Engine

Issue the following commands to enable and configure the PKI Secrets Engine to server TLS certificates to Consul.

Enable the PKI Secrets Engine:
```
$ vault secrets enable pki
```

Tune the engine to enable longer TTL:

$ vault secrets tune -max-lease-ttl=87600h pki

Generate the root CA:

Note: The common_name value is comprised of combining global.datacenter dot global.domain.

$ vault write -field=certificate pki/root/generate/internal \
        common_name="dc1.consul" \
        ttl=87600h

Create Vault policies

To use Vault to issue Server TLS certificates, you will need to create the following:

Create a policy that allows ["create", "update"] access to the certificate issuing URL so the Consul servers can fetch a new certificate/key pair.

The path to the secret referenced in the path resource is the same value that you will configure in the server.serverCert.secretName Helm configuration (refer to Update Consul on Kubernetes Helm chart).

consul-server-policy.hcl
```
path "pki/issue/consul-server" {
  capabilities = ["create", "update"]
}
```
Apply the Vault policy by issuing the vault policy write CLI command:
```
$ vault policy write consul-server consul-server-policy.hcl
```

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.

The path to the secret referenced in the `path` resource is the same value that you will configure in the  `global.tls.caCert.secretName` Helm configuration (refer to [Update Consul on Kubernetes Helm chart](#update-consul-on-kubernetes-helm-chart)).
<CodeBlockConfig filename="ca-policy.hcl">
```HCL
path "pki/cert/ca" {
  capabilities = ["read"]
}
```
</CodeBlockConfig>
```shell-session
$ vault policy write ca-policy ca-policy.hcl
```

Configure allowed domains for PKI certificates.

Next, a Vault role for the PKI engine will set the default certificate issuance parameters:

$ vault write pki/roles/consul-server \
    allowed_domains="<Allowed-domains-string>" \
    allow_subdomains=true \
    allow_bare_domains=true \
    allow_localhost=true \
    max_ttl="720h"

To generate the <Allowed-domains-string> use the following script as a template:

#!/bin/sh
# NAME is set to either the value from `global.name` from your Consul K8s value file, or your $HELM_RELEASE_NAME-consul
export NAME=consulk8s
# NAMESPACE is where the Consul on Kubernetes is installed
export NAMESPACE=consul
# DATACENTER is the value of `global.datacenter` from your Helm values config file
export DATACENTER=dc1
echo allowed_domains=\"$DATACENTER.consul, $NAME-server, $NAME-server.$NAMESPACE, $NAME-server.$NAMESPACE.svc\"

Finally, Kubernetes auth roles need to be created for servers, clients, and components.

Role for Consul servers:

$ vault write auth/kubernetes/role/consul-server \
    bound_service_account_names=<Consul server service account> \
    bound_service_account_namespaces=<Consul installation namespace> \
    policies=consul-server \
    ttl=1h

To find out the service account name of the Consul server, you can run:

$ helm template --release-name ${RELEASE_NAME} --show-only templates/server-serviceaccount.yaml hashicorp/consul -f values.yaml

Role for Consul clients:

$ vault write auth/kubernetes/role/consul-client \
    bound_service_account_names=<Consul client service account>  \
    bound_service_account_namespaces=default \
    policies=ca-policy \
    ttl=1h

To find out the service account name of the Consul client, use the command below.

$ helm template --release-name ${RELEASE_NAME} --show-only templates/client-serviceaccount.yaml hashicorp/consul -f values.yaml

Role for CA components:

$ vault write auth/kubernetes/role/consul-ca \
    bound_service_account_names="*" \
    bound_service_account_namespaces=<Consul installation namespace> \
    policies=ca-policy \
    ttl=1h

The above Vault Roles will now be your Helm values for global.secretsBackend.vault.consulServerRole and global.secretsBackend.vault.consulCARole respectively.

Update Consul on Kubernetes Helm chart

Next, configure the Consul Helm chart to use the server TLS certificates from Vault:

values.yaml

global:
  secretsBackend:
    vault:
      enabled: true
      consulServerRole: consul-server
      consulClientRole: consul-client
      consulCARole: consul-ca
  tls:
    enableAutoEncrypt: true
    enabled: true
    caCert:
      secretName: "pki/cert/ca"
server:
  serverCert:
    secretName: "pki/issue/consul-server"
  extraVolumes:
    - type: "secret"
      name: <vaultCASecret>
      load: "false"

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:

$ kubectl create secret generic vault-ca --from-file vault.ca=/path/to/your/vault/