Configuring a Connect CA Provider

    Consul has support for different certificate authority (CA) providers to be used with the Consul Service Mesh. Please see Connect Certificate Management for the information on the providers we currently support.

    Generally, to configure a provider via the Consul Helm chart, you need to follow three steps:

    1. Create a configuration file containing your provider information.
    2. Create a Kubernetes secret containing the configuration file.
    3. Reference the Kubernetes secret in the value in the Helm chart.

    Below we will go over this process for configuring Vault as the Connect CA. However, other providers can be configured similarly by providing the appropriate and ca_provider values for the provider you’re using.

    NOTE: If using Vault as your Connect CA, it’s highly recommended to run a Consul version >= 1.8.5 that supports token auto-renewal. With this feature, if the Vault token is renewable then Consul will automatically renew the token periodically. Without this feature, you will need to the Vault token before it expires.

    To configure Vault as a CA provider for Consul Connect, first, create a provider configuration JSON file. Please refer to Vault as a Connect CA for the configuration options. You will need to provide a Vault token to the token property. Please refer to for the permissions that the token needs to have. This token should be renewable.

    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. $ cat vault-config.json
    2. {
    3.   "connect": [
    4.     {
    5.       "ca_config": [
    6.         {
    7.           "address": "https://vault:8200",
    8.           "intermediate_pki_path": "dc1/connect-intermediate",
    9.           "root_pki_path": "connect-root",
    10.           "ca_file": "/consul/userconfig/vault-ca/vault.ca"
    11.         }
    12.       ],
    13.       "ca_provider": "vault"
    14.     }
    15.   ]
    16. }

    This example configuration file is pointing to a Vault instance running in the same Kubernetes cluster, which has been deployed with TLS enabled. Note that the is pointing to the file location based on the Kubernetes secret for the Vault CA that we have created before. We will provide that secret later in the Helm values for our Consul cluster.

    NOTE: If you have used Kubernetes CA to sign Vault’s certificate, such as shown in , you don’t need to create a Kubernetes secret with Vault’s CA and can reference the CA directly by setting ca_file to /var/run/secrets/kubernetes.io/serviceaccount/ca.crt.

    Next, create a Kubernetes secret with this configuration file.

    We will provide this secret and the Vault CA secret, to the Consul server via the server.extraVolumes Helm value.

    1. global:
    2.   name: consul
    3. server:
    4.   extraVolumes:
    5.     - type: secret
    6.       name: vault-config
    7.       load: true
    8.       items:
    9.         - key: config
    10.           path: vault-config.json
    11.     - type: secret
    12.       load: false
    13. connectInject:
    14.   enabled: true

    config.yaml

    Verify that the CA provider is set correctly:

    1. $ kubectl exec consul-server-0 -- curl -s http://localhost:8500/v1/connect/ca/configuration | jq .
    3.   "Provider": "vault",
    4.   "Config": {
    5.     "Address": "https://vault:8200",
    6.     "CAFile": "/consul/userconfig/vault-server-tls/vault.ca",
    7.     "IntermediateCertTTL": "8760h",
    8.     "IntermediatePKIPath": "connect-intermediate",
    9.     "LeafCertTTL": "72h",
    10.     "RootPKIPath": "connect-root",
    11.     "Token": "s.VgQvaXl8xGFO1RUxAPbPbsfN"
    12.   },
    13.   "State": null,
    14.   "ForceWithoutCrossSigning": false,
    15.   "CreateIndex": 5,
    16. }

    To configure Vault as the Connect CA in secondary datacenters, you need to make sure that the Root CA is the same, but the intermediate is different for each datacenter. In the connect configuration for a secondary datacenter, you can specify a intermediate_pki_path that is, for example, prefixed with the datacenter for which this configuration is intended. You will similarly need to create a Vault token and a Kubernetes secret with Vault’s CA in each secondary Kubernetes cluster.

    Note that all secondary datacenters need to have access to the same Vault instance as the primary.

    If running Consul < 1.8.5 or using a Vault token that is not renewable then you will need to manually renew or rotate the Vault token before it expires.

    Rotating Vault Token

    Once the cluster is running, subsequent changes to the ca_provider config are ignored–even if consul reload is run or the servers are restarted.

    To update any settings under this key, you must use Consul’s Update CA Configuration API or the command.

    Renewing Vault Token