consul/website/content/docs/k8s/deployment-configurations/vault/data-integration/connect-ca.mdx

---
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

This topic describes how to configure the Consul Helm chart to use TLS certificates issued by Vault for Consul service mesh communication.

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

~> **Compatibility note:** If you use Vault 1.11.0+ as Consul's service mesh 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.

## Overview

To use Vault as the service mesh certificate provider on Kubernetes, you will complete a modified version of the steps outlined in the [Data Integration](/consul/docs/k8s/deployment-configurations/vault/data-integration) section.

Complete the following steps once:
  1. Create a Vault policy that authorizes the desired level of access to the secret.

Repeat the following steps for each datacenter in the cluster:
  1. Create Vault Kubernetes auth roles that link the policy to each Consul on Kubernetes service account that requires access.
  1. 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:  
1. Read and completed the steps in the [Systems Integration](/consul/docs/k8s/deployment-configurations/vault/systems-integration) section of [Vault as a Secrets Backend](/consul/docs/k8s/deployment-configurations/vault).
2. Read the [Data Integration Overview](/consul/docs/k8s/deployment-configurations/vault/data-integration) section of [Vault as a Secrets Backend](/consul/docs/k8s/deployment-configurations/vault).

## Create Vault policy

To configure [Vault as the provider](/consul/docs/connect/ca/vault) for the Consul service mesh 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](/consul/docs/connect/ca/vault#vault-acl-policies)
documentation.

## Create Vault Authorization Roles for Consul

Next, you will create Kubernetes auth roles for the Consul servers:

```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=<service mesh CA policy> \
    ttl=1h
```

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

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

## Update Consul on Kubernetes Helm chart
Now you can configure the Consul Helm chart to use Vault as the service mesh (connect) CA provider:

<CodeBlockConfig filename="values.yaml">

```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>
```

</CodeBlockConfig>

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 service mesh CA policy. Behind the scenes, Consul will authenticate to Vault using a Kubernetes
service account using the [Kubernetes auth method](/vault/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:

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

### Secondary Datacenters

To configure Vault as the service mesh (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`).