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 662fb1b919
commit c69b05ca55
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 16 additions and 37 deletions

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

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

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:

View File

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