Vault as the Service Mesh Certificate Provider on Kubernetes

Note: This feature requires Consul 1.11 or higher. As of v1.11, Consul allows using Kubernetes auth methods to configure Connect CA. This allows for automatic token rotation once the renewal is no longer possible.

In order to create Vault auth roles for the Consul servers for this feature, ensure that the Vault Kubernetes auth method is enabled as described in Vault Kubernetes Auth Method.

To configure Vault as the provider for the Consul service certificates, you will first need to decide on the type of policy that is suitable for you. To see the permissions that Consul would need in Vault, please see Vault ACL policies documentation.

Once you have a policy, you will need to link that policy to the Consul server service account.

  1. $ vault write auth/kubernetes/role/consul-server \
  2.     bound_service_account_names=<Consul server service account> \
  3.     bound_service_account_namespaces=<Consul installation namespace> \
  4.     policies=<Connect CA policy> \
  5.     ttl=1h

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

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

Now you can configure the Consul Helm chart to use Vault as the Connect CA provider:

  1. global:
  2.   secretsBackend:
  3.     vault:
  4.       enabled: true
  5.       consulServerRole: consul-server
  6.       consulClientRole: consul-client
  7.       consulCARole: consul-ca
  8.       connectCA:
  9.         address: <the address of the Vault server>
  10.         rootPKIPath: <the path to root PKI>
  11.         intermediatePKIPath: <the path to intermediate PKI>
  12.       ca:
  13.         secretName: <vaultCASecret>

Service Mesh Certificates - 图1

values.yaml

The address you provide to the connectCA configuration can be a Kubernetes DNS address if the Vault cluster is running the same Kubernetes cluster. The rootPKIPath and intermediatePKIPath should be the same as the ones defined in your Connect CA policy. Behind the scenes, Consul will authenticate to Vault using a Kubernetes service account using the Kubernetes auth method and will use the Vault token for any API calls to Vault. If the Vault token can not be renewed, Consul will re-authenticate to generate a new Vault token.

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:

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

Secondary Datacenters

To configure Vault as the Connect CA in secondary datacenters, you need to make sure that the Root CA path is the same, but the intermediate is different for each datacenter. In the connectCA Helm configuration for a secondary datacenter, you can specify a intermediatePKIPath that is, for example, prefixed with the datacenter for which this configuration is intended (e.g. dc2/connect-intermediate).