--- layout: docs page_title: Storing the Gossip Encryption Key in Vault description: >- Configuring the Consul Helm chart to use a gossip encryption key stored in Vault. --- # Storing Gossip Encryption Key in Vault This topic describes how to configure the Consul Helm chart to use a gossip encryption key stored in Vault. ## Overview Complete the steps outlined in the [Data Integration](/docs/k8s/deployment-configurations/vault/data-integration) section to use a gossip encryption key stored in Vault. Complete the following steps once: 1. Store the secret in Vault. 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](/docs/k8s/deployment-configurations/vault/systems-integration) section of [Vault as a Secrets Backend](/docs/k8s/deployment-configurations/vault). 2. Read the [Data Integration Overview](/docs/k8s/deployment-configurations/vault/data-integration) section of [Vault as a Secrets Backend](/docs/k8s/deployment-configurations/vault). ## Store the Secret in Vault First, generate and store the gossip key in Vault. You will only need to perform this action once: ```shell-session $ vault kv put secret/consul/gossip key="$(consul keygen)" ``` ## Create Vault policy Next, create a policy that allows read access to this secret. The path to the secret referenced in the `path` resource is the same value that you will configure in the `global.gossipEncryption.secretName` Helm configuration (refer to [Update Consul on Kubernetes Helm chart](#update-consul-on-kubernetes-helm-chart)). ```HCL path "secret/data/consul/gossip" { capabilities = ["read"] } ``` Apply the Vault policy by issuing the `vault policy write` CLI command: ```shell-session $ vault policy write gossip-policy gossip-policy.hcl ``` ## Create Vault Authorization Roles for Consul Next, we will create Kubernetes auth roles for the Consul server and client: ```shell-session $ vault write auth/kubernetes/role/consul-server \ bound_service_account_names= \ bound_service_account_namespaces= \ policies=gossip-policy \ ttl=1h ``` ```shell-session $ vault write auth/kubernetes/role/consul-client \ bound_service_account_names= \ bound_service_account_namespaces= \ policies=gossip-policy \ ttl=1h ``` To find out the service account names of the Consul server and client, you can run the following `helm template` commands with your Consul on Kubernetes values file: - Generate Consul server service account name ```shell-session $ helm template --release-name ${RELEASE_NAME} -s templates/server-serviceaccount.yaml hashicorp/consul -f values.yaml ``` - Generate Consul client service account name ```shell-session $ helm template --release-name ${RELEASE_NAME} -s templates/client-serviceaccount.yaml hashicorp/consul -f values.yaml ``` ## Update Consul on Kubernetes Helm chart Now that we've configured Vault, you can configure the Consul Helm chart to use the gossip key in Vault: ```yaml global: secretsBackend: vault: enabled: true consulServerRole: consul-server consulClientRole: consul-client gossipEncryption: secretName: secret/data/consul/gossip secretKey: key ``` Note that `global.gossipEncryption.secretName` is the path of the secret in Vault. This should be the same path as the one you'd include in your Vault policy. `global.gossipEncryption.secretKey` is the key inside the secret data. This should be the same as the key we passed when we created the gossip secret in Vault.