diff --git a/website/content/docs/k8s/installation/vault/connect-ca.mdx b/website/content/docs/k8s/installation/vault/connect-ca.mdx index 7a96e9b083..bf0c707cfd 100644 --- a/website/content/docs/k8s/installation/vault/connect-ca.mdx +++ b/website/content/docs/k8s/installation/vault/connect-ca.mdx @@ -37,8 +37,6 @@ $ helm template --release-name ${RELEASE_NAME} --show-only templates/server-serv Now you can configure the Consul Helm chart to use Vault as the Connect CA provider: - - ```yaml @@ -59,8 +57,6 @@ global: - - 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 diff --git a/website/content/docs/k8s/installation/vault/gossip.mdx b/website/content/docs/k8s/installation/vault/gossip.mdx index aff1a4d8ce..184bb2d2e4 100644 --- a/website/content/docs/k8s/installation/vault/gossip.mdx +++ b/website/content/docs/k8s/installation/vault/gossip.mdx @@ -24,8 +24,6 @@ $ vault kv put secret/consul/gossip key="$(consul keygen)" Next, we will need to create a policy that allows read access to this secret: - - ```HCL @@ -36,8 +34,6 @@ path "secret/data/consul/gossip" { - - ```shell-session $ vault policy write gossip-policy gossip-policy.hcl ``` @@ -80,8 +76,6 @@ you can run the following `helm template` commands with your Consul on Kubernete Now that we've configured Vault, you can configure the Consul Helm chart to use the gossip key in Vault: - - ```yaml @@ -98,8 +92,6 @@ global: - - 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 diff --git a/website/content/docs/k8s/installation/vault/index.mdx b/website/content/docs/k8s/installation/vault/index.mdx index 1d9dd1caf1..f759ce6d3f 100644 --- a/website/content/docs/k8s/installation/vault/index.mdx +++ b/website/content/docs/k8s/installation/vault/index.mdx @@ -30,11 +30,15 @@ At a high level, there are two points of integration with Vault: A minimal valid installation of Vault Kubernetes must include the Agent Injector which is utilized for accessing secrets from Vault. Vault servers could be deployed external to Vault on Kubernetes as described via the [`externalvaultaddr`](https://www.vaultproject.io/docs/platform/k8s/helm/configuration#externalvaultaddr) value in the Vault Helm Configuration + + ```yaml injector: enabled: "true" ``` + + ### Vault Kubernetes Auth Method Prior to creating Vault auth roles for the Consul servers and clients, ensure that the Vault Kubernetes auth method is enabled: diff --git a/website/content/docs/k8s/installation/vault/server-tls.mdx b/website/content/docs/k8s/installation/vault/server-tls.mdx index 4f07f7b265..d669d97b90 100644 --- a/website/content/docs/k8s/installation/vault/server-tls.mdx +++ b/website/content/docs/k8s/installation/vault/server-tls.mdx @@ -22,25 +22,25 @@ which also uses an intermediate signing authority. * Enable the PKI Secrets Engine: -```shell-session -$ vault secrets enable pki -``` + ```shell-session + $ vault secrets enable pki + ``` * Tune the engine to enable longer TTL: -```shell-session -$ vault secrets tune -max-lease-ttl=87600h pki -``` + ```shell-session + $ vault secrets tune -max-lease-ttl=87600h pki + ``` * Generate the root CA -```shell-session -$ vault write -field=certificate pki/root/generate/internal \ - common_name="dc1.consul" \ - ttl=87600h -``` + ```shell-session + $ vault write -field=certificate pki/root/generate/internal \ + common_name="dc1.consul" \ + ttl=87600h + ``` --> **Note:** Where `common_name` is comprised of combining `global.datacenter` dot `global.domain`. + -> **Note:** Where `common_name` is comprised of combining `global.datacenter` dot `global.domain`. ### Create Vault Policies for the Server TLS Certificates @@ -48,8 +48,6 @@ Next we will create a policy that allows `["create", "update"]` access to the [certificate issuing URL](https://www.vaultproject.io/api/secret/pki#generate-certificate) so the Consul servers can fetch a new certificate/key pair. - - ```HCL @@ -60,8 +58,6 @@ path "pki/issue/consul-server" { - - ```shell-session $ vault policy write consul-server consul-server-policy.hcl ``` @@ -73,9 +69,6 @@ $ vault policy write consul-server consul-server-policy.hcl Next, we will create a policy that allows `["read"]` access to the [CA URL](https://www.vaultproject.io/api/secret/pki#read-certificate), this is required for the Consul components to communicate with the Consul servers in order to fetch their auto-encryption certificates. - - - ```HCL @@ -86,8 +79,6 @@ path "pki/cert/ca" { - - ```shell-session $ vault policy write ca-policy ca-policy.hcl ``` @@ -181,8 +172,6 @@ The above Vault Roles will now be your Helm values for `global.secretsBackend.va Now that we've configured Vault, you can configure the Consul Helm chart to use the Server TLS certificates from Vault: - - ```yaml @@ -209,8 +198,6 @@ server: - - 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