75 lines
3.4 KiB
Plaintext
75 lines
3.4 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: Vault as the Service Mesh Certificate Provider on Kubernetes
|
|
description: >-
|
|
Using Vault as the provider for the Service Mesh certificates on Kubernetes.
|
|
---
|
|
|
|
# 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](/docs/k8s/installation/vault#vault-kubernetes-auth-method).
|
|
|
|
To configure [Vault as the provider](/docs/connect/ca/vault) 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](/docs/connect/ca/vault#vault-acl-policies)
|
|
documentation.
|
|
|
|
Once you have a policy, you will need to link that policy to the Consul server service account.
|
|
|
|
```shell-session
|
|
vault write auth/kubernetes/role/consul-server \
|
|
bound_service_account_names=<Consul server service account> \
|
|
bound_service_account_namespaces=<Consul installation namespace> \
|
|
policies=<Connect CA policy> \
|
|
ttl=1h
|
|
```
|
|
|
|
To find out the service account name of the Consul server,
|
|
you can run:
|
|
|
|
```shell-session
|
|
$ helm template --release-name <your release name> --show-only templates/server-serviceaccount.yaml hashicorp/consul
|
|
```
|
|
|
|
Now we can configure the Consul Helm chart to use Vault as the Connect CA provider:
|
|
|
|
```yaml
|
|
global:
|
|
secretsBackend:
|
|
vault:
|
|
enabled: true
|
|
consulServerRole: consul-server
|
|
consulClientRole: consul-client
|
|
consulCARole: consul-ca
|
|
connectCA:
|
|
address: <the address of the Vault server>
|
|
rootPKIPath: <the path to root PKI>
|
|
intermediatePKIPath: <the path to intermediate PKI>
|
|
ca:
|
|
secretName: <vaultCASecret>
|
|
```
|
|
|
|
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](https://www.vaultproject.io/docs/auth/kubernetes) 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:
|
|
|
|
```
|
|
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`).
|