luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity

docs: Vault Secrets Backend K8s, remove code tabs (#12156) 

* Update connect-ca.mdx

* Update gossip.mdx

* Update index.mdx

* Update server-tls.mdx
This commit is contained in:
David Yu 2022-01-21 11:28:38 -08:00 committed by GitHub
parent adf030a634
commit 0013727d80
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 16 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
website/content/docs/k8s/installation/vault/connect-ca.mdx
View File

@ -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:
<CodeTabs>
<CodeBlockConfig filename="values.yaml">
```yaml
@ -59,8 +57,6 @@ global:
</CodeBlockConfig>
</CodeTabs>
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

8
website/content/docs/k8s/installation/vault/gossip.mdx
View File

@ -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:
<CodeTabs>
<CodeBlockConfig filename="gossip-policy.hcl">
```HCL
@ -36,8 +34,6 @@ path "secret/data/consul/gossip" {
</CodeBlockConfig>
</CodeTabs>
```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:
<CodeTabs>
<CodeBlockConfig filename="values.yaml">
```yaml
@ -98,8 +92,6 @@ global:
</CodeBlockConfig>
</CodeTabs>
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

4
website/content/docs/k8s/installation/vault/index.mdx
View File

@ -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
<CodeBlockConfig filename="values.yaml">
```yaml
injector:
enabled: "true"
```
</CodeBlockConfig>
### 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:

37
website/content/docs/k8s/installation/vault/server-tls.mdx
View File

@ -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.
<CodeTabs>
<CodeBlockConfig filename="consul-server-policy.hcl">
```HCL
@ -60,8 +58,6 @@ path "pki/issue/consul-server" {
</CodeBlockConfig>
</CodeTabs>
```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.
<CodeTabs>
<CodeBlockConfig filename="ca-policy.hcl">
```HCL
@ -86,8 +79,6 @@ path "pki/cert/ca" {
</CodeBlockConfig>
</CodeTabs>
```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:
<CodeTabs>
<CodeBlockConfig filename="values.yaml">
```yaml
@ -209,8 +198,6 @@ server:
</CodeBlockConfig>
</CodeTabs>
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