2022-10-18 15:56:38 +00:00
---
2020-08-13 21:29:59 +00:00
layout: docs
2022-09-14 22:48:49 +00:00
page_title: Configure Certificate Authority (CA) for Consul on Kubernetes
description: >-
2022-09-16 15:28:32 +00:00
Consul includes a built-in CA, but when bootstrapping a cluster on k8s, you can configure your service mesh to use a custom certificate provider instead. Learn how to configure Vault as an external CA in primary and secondary datacenters and manually rotate Vault tokens.
2022-10-18 15:56:38 +00:00
---
2020-08-13 21:29:59 +00:00
2022-10-18 15:56:38 +00:00
# Configure Certificate Authority for Consul on Kubernetes
2020-08-13 21:29:59 +00:00
2023-01-25 16:52:43 +00:00
If `connect` is enabled, the built-in Consul certificate authority (CA) is automatically enabled for the service mesh CA. You can use different CA providers with Consul service mesh. Refer to [Connect Certificate Management](/consul/docs/connect/ca) for supported providers.
2020-08-13 21:29:59 +00:00
2022-10-18 15:56:38 +00:00
## Overview
2020-08-13 21:29:59 +00:00
2023-01-25 16:52:43 +00:00
You should only complete the following instructions during the initial cluster bootstrapping procedure with Consul K8s CLI 0.38.0 or later. To update the Consul service mesh CA provider on an existing cluster or to update any provider properties, such as tokens, refer to [Update CA Configuration Endpoint](/consul/api-docs/connect/ca#update-ca-configuration).
2022-10-18 15:56:38 +00:00
To configure an external CA provider using the Consul Helm chart, complete the following steps:
2020-08-13 21:29:59 +00:00
1. Create a configuration file containing your provider information.
1. Create a Kubernetes secret containing the configuration file.
2023-01-25 16:52:43 +00:00
1. Reference the Kubernetes secret in the [`server.extraVolumes`](/consul/docs/k8s/helm#v-server-extravolumes) value in the Helm chart.
2020-08-13 21:29:59 +00:00
2023-01-25 16:52:43 +00:00
To configure the Vault service mesh provider, refer to [Vault as the Service Mesh Certificate Provider on Kubernetes](/consul/docs/k8s/deployment-configurations/vault/data-integration/connect-ca).
2020-08-13 21:29:59 +00:00
2021-12-15 18:59:36 +00:00
## Configuring Vault as a Connect CA (Consul K8s 0.37.0 and earlier)
2020-08-13 21:29:59 +00:00
2022-11-17 16:51:43 +00:00
2022-12-19 18:32:25 +00:00
If you use Vault 1.11.0+ as Consul's Connect CA, versions of Consul released before Dec 13, 2022 will develop an issue with Consul control plane or service mesh communication ([GH-15525](https://github.com/hashicorp/consul/pull/15525)). Use or upgrade to a [Consul version that includes the fix](https://support.hashicorp.com/hc/en-us/articles/11308460105491#01GMC24E6PPGXMRX8DMT4HZYTW) to avoid this problem.
2022-11-17 16:51:43 +00:00
2022-10-18 16:14:26 +00:00
The following instructions are only valid for Consul K8s CLI 0.37.0 and prior. It describes how to configure Vault as the Connect CA. You can configure other providers during initial bootstrap of the cluster by providing the appropriate [`ca_config`] and [`ca_provider`] values for your provider.
2022-10-18 15:56:38 +00:00
2023-01-25 16:52:43 +00:00
-> **Auto-renewal:** If using Vault as your Connect CA, we strongly recommend Consul 1.8.5 or later, which includes support for token auto-renewal. If the Vault token is [renewable](/vault/api-docs/auth/token#renewable), then Consul automatically renews the token periodically. Otherwise, you must [manually rotate](#manually-rotating-vault-tokens) the Vault token before it expires.
2020-10-13 23:18:19 +00:00
2020-08-13 21:29:59 +00:00
### Primary Datacenter
To configure Vault as a CA provider for Consul Connect,
first, create a provider configuration JSON file.
2023-01-25 16:52:43 +00:00
Please refer to [Vault as a Connect CA](/consul/docs/connect/ca/vault) for the configuration options.
2020-08-13 21:29:59 +00:00
You will need to provide a Vault token to the `token` property.
2023-01-25 16:52:43 +00:00
Please refer to [these docs](/consul/docs/connect/ca/vault#token) for the permissions that the token needs to have.
This token should be [renewable](/vault/api-docs/auth/token#renewable).
2020-10-13 23:18:19 +00:00
2020-08-13 21:29:59 +00:00
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:
```shell-session
kubectl create secret generic vault-ca --from-file vault.ca=/path/to/your/vault/ca
```
And then reference it like this in the provider configuration:
2021-12-18 06:26:17 +00:00
<CodeBlockConfig filename="vault-config.json" highlight="10">
```json
2020-08-13 21:29:59 +00:00
{
"connect": [
{
"ca_config": [
{
"address": "https://vault:8200",
"intermediate_pki_path": "dc1/connect-intermediate",
"root_pki_path": "connect-root",
"token": "s.VgQvaXl8xGFO1RUxAPbPbsfN",
"ca_file": "/consul/userconfig/vault-ca/vault.ca"
}
],
"ca_provider": "vault"
}
]
}
```
2021-12-18 06:26:17 +00:00
</CodeBlockConfig>
2020-08-13 21:29:59 +00:00
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 `ca_file` 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,
2023-01-25 16:52:43 +00:00
such as shown in [Standalone Server with TLS](/vault/docs/platform/k8s/helm/examples/standalone-tls),
2020-08-13 21:29:59 +00:00
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.
```shell-session
$ kubectl create secret generic vault-config --from-file=config=vault-config.json
```
We will provide this secret and the Vault CA secret, to the Consul server via the
`server.extraVolumes` Helm value.
2022-09-09 20:56:33 +00:00
<CodeBlockConfig filename="values.yaml" highlight="4-13">
2021-12-18 06:26:17 +00:00
2021-12-15 18:59:36 +00:00
```yaml
global:
name: consul
server:
extraVolumes:
- type: secret
name: vault-config
load: true
items:
- key: config
path: vault-config.json
- type: secret
name: vault-ca
load: false
connectInject:
enabled: true
```
2021-07-31 01:37:33 +00:00
2021-12-18 06:26:17 +00:00
</CodeBlockConfig>
2023-01-25 16:52:43 +00:00
Finally, [install](/consul/docs/k8s/installation/install#installing-consul) the Helm chart using the above config file:
2020-08-13 21:29:59 +00:00
```shell-session
2022-09-09 20:56:33 +00:00
$ helm install consul --values values.yaml hashicorp/consul
2020-08-13 21:29:59 +00:00
```
Verify that the CA provider is set correctly:
```shell-session
2022-01-12 23:05:01 +00:00
$ kubectl exec consul-server-0 -- curl --silent http://localhost:8500/v1/connect/ca/configuration\?pretty
2020-08-13 21:29:59 +00:00
{
"Provider": "vault",
"Config": {
"Address": "https://vault:8200",
"CAFile": "/consul/userconfig/vault-server-tls/vault.ca",
"IntermediateCertTTL": "8760h",
"IntermediatePKIPath": "connect-intermediate",
"LeafCertTTL": "72h",
"RootPKIPath": "connect-root",
"Token": "s.VgQvaXl8xGFO1RUxAPbPbsfN"
},
"State": null,
"ForceWithoutCrossSigning": false,
"CreateIndex": 5,
"ModifyIndex": 5
}
```
### Secondary Datacenters
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.
2021-12-18 06:26:17 +00:00
<CodeBlockConfig highlight="7">
2020-08-13 21:29:59 +00:00
```json
{
"connect": [
{
"ca_config": [
{
"address": "https://vault:8200",
"intermediate_pki_path": "dc2/connect-intermediate",
"root_pki_path": "connect-root",
"token": "s.VgQvaXl8xGFO1RUxAPbPbsfN",
"ca_file": "/consul/userconfig/vault-ca/vault.ca"
}
],
"ca_provider": "vault"
}
]
}
```
2021-12-18 06:26:17 +00:00
</CodeBlockConfig>
2020-08-13 21:29:59 +00:00
Note that all secondary datacenters need to have access to the same Vault instance as the primary.
2020-10-13 23:18:19 +00:00
### Manually Rotating Vault Tokens
2023-01-25 16:52:43 +00:00
If running Consul < 1.8.5 or using a Vault token that is not [renewable](/vault/api-docs/auth/token#renewable)
2020-10-13 23:18:19 +00:00
then you will need to manually renew or rotate the Vault token before it expires.
#### Rotating Vault Token
2020-08-13 21:29:59 +00:00
2021-12-18 06:26:17 +00:00
The [`ca_config`] and [`ca_provider`] options defined in the Consul agent
configuration are only used when initially bootstrapping the cluster. 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.
2020-08-13 21:29:59 +00:00
2023-01-25 16:52:43 +00:00
To update any settings under these keys, you must use Consul's [Update CA Configuration](/consul/api-docs/connect/ca#update-ca-configuration) API or the [`consul connect ca set-config`](/consul/commands/connect/ca#set-config) command.
2020-10-13 23:18:19 +00:00
#### Renewing Vault Token
2023-01-25 16:52:43 +00:00
To renew the Vault token, use the [`vault token renew`](/vault/docs/commands/token/renew) CLI command
2020-10-13 23:18:19 +00:00
or API.
2021-12-18 06:26:17 +00:00
2023-01-25 16:52:43 +00:00
[`ca_config`]: /consul/docs/agent/config/config-files#connect_ca_config
[`ca_provider`]: /consul/docs/agent/config/config-files#connect_ca_provider