docs: Formatting Consul K8s Vault docs (#12148)
* Update index.mdx * Update gossip.mdx * Update install-cli.mdx * Update gossip.mdx * Update website/content/docs/k8s/installation/vault/gossip.mdx Co-authored-by: Bryce Kalow <bkalow@hashicorp.com> * fix MDX formatting * local changes * adding formatting changes * Update website/content/docs/k8s/installation/vault/connect-ca.mdx Co-authored-by: mrspanishviking <kcardenas@hashicorp.com> * adding shell-session to service mesh certs Co-authored-by: Bryce Kalow <bkalow@hashicorp.com> Co-authored-by: mrspanishviking <kcardenas@hashicorp.com>
This commit is contained in:
David Yu
GitHub
parent
8990d383e8
commit
adf030a634
|
|
@ -17,7 +17,7 @@ These instructions describe how to install the latest version of the CLI dependi
|
|||
|
||||
<Tab heading="MacOS">
|
||||
|
||||
The [Homebrew](https://brew.sh) package manager is required to complete the following installation instructions. The Homebrew formulae will always install the latest version of a binary. If you are looking to install a specific version of the CLI please follow [Install a specific version of Consul K8s CLI](#install-a-specific-version-of-consul-k8s-cli).
|
||||
The [Homebrew](https://brew.sh) package manager is required to complete the following installation instructions. The Homebrew formulae will always install the latest version of a binary. If you are looking to install a specific version of the CLI please follow [Install a specific version of Consul K8s CLI](#install-a-specific-version-of-the-cli).
|
||||
|
||||
1. Install the HashiCorp `tap`, which is a repository of all Homebrew packages for HashiCorp:
|
||||
```shell-session
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ documentation.
|
|||
Once you have a policy, you will need to link that policy to the Consul server service account.
|
||||
|
||||
```shell-session
|
||||
vault write auth/kubernetes/role/consul-server \
|
||||
$ vault write auth/kubernetes/role/consul-server \
|
||||
bound_service_account_names=<Consul server service account> \
|
||||
bound_service_account_namespaces=<Consul installation namespace> \
|
||||
policies=<Connect CA policy> \
|
||||
|
|
@ -32,10 +32,14 @@ To find out the service account name of the Consul server,
|
|||
you can run:
|
||||
|
||||
```shell-session
|
||||
$ helm template --release-name <your release name> --show-only templates/server-serviceaccount.yaml hashicorp/consul
|
||||
$ helm template --release-name ${RELEASE_NAME} --show-only templates/server-serviceaccount.yaml hashicorp/consul
|
||||
```
|
||||
|
||||
Now we can configure the Consul Helm chart to use Vault as the Connect CA provider:
|
||||
Now you can configure the Consul Helm chart to use Vault as the Connect CA provider:
|
||||
|
||||
<CodeTabs>
|
||||
|
||||
<CodeBlockConfig filename="values.yaml">
|
||||
|
||||
```yaml
|
||||
global:
|
||||
|
|
@ -53,6 +57,10 @@ global:
|
|||
secretName: <vaultCASecret>
|
||||
```
|
||||
|
||||
</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
|
||||
|
|
@ -62,8 +70,8 @@ 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:
|
||||
|
||||
```
|
||||
kubectl create secret generic vault-ca --from-file vault.ca=/path/to/your/vault/ca
|
||||
```shell-session
|
||||
$ kubectl create secret generic vault-ca --from-file vault.ca=/path/to/your/vault/ca
|
||||
```
|
||||
|
||||
### Secondary Datacenters
|
||||
|
|
|
|||
|
|
@ -18,20 +18,28 @@ To use a gossip encryption key stored in Vault we need the following:
|
|||
First, generate and store the gossip key in Vault:
|
||||
|
||||
```shell-session
|
||||
vault kv put secret/consul/gossip key="$(consul keygen)"
|
||||
$ vault kv put secret/consul/gossip key="$(consul keygen)"
|
||||
```
|
||||
|
||||
Next, we will need to create a policy that allows read access to this secret:
|
||||
|
||||
```shell-session
|
||||
# gossip-policy.hcl
|
||||
|
||||
<CodeTabs>
|
||||
|
||||
<CodeBlockConfig filename="gossip-policy.hcl">
|
||||
|
||||
```HCL
|
||||
path "secret/data/consul/gossip" {
|
||||
capabilities = ["read"]
|
||||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
</CodeTabs>
|
||||
|
||||
```shell-session
|
||||
vault policy write gossip-policy gossip-policy.hcl
|
||||
$ vault policy write gossip-policy gossip-policy.hcl
|
||||
```
|
||||
|
||||
Prior to creating Vault auth roles for the Consul servers and clients, ensure that the Vault Kubernetes auth method is enabled as described in [Vault Kubernetes Auth Method](/docs/k8s/installation/vault#vault-kubernetes-auth-method).
|
||||
|
|
@ -39,7 +47,7 @@ Prior to creating Vault auth roles for the Consul servers and clients, ensure th
|
|||
Next, we will create Kubernetes auth roles for the Consul server and client:
|
||||
|
||||
```shell-session
|
||||
vault write auth/kubernetes/role/consul-server \
|
||||
$ vault write auth/kubernetes/role/consul-server \
|
||||
bound_service_account_names=<Consul server service account> \
|
||||
bound_service_account_namespaces=<Consul installation namespace> \
|
||||
policies=gossip-policy \
|
||||
|
|
@ -47,7 +55,7 @@ vault write auth/kubernetes/role/consul-server \
|
|||
```
|
||||
|
||||
```shell-session
|
||||
vault write auth/kubernetes/role/consul-client \
|
||||
$ vault write auth/kubernetes/role/consul-client \
|
||||
bound_service_account_names=<Consul client service account> \
|
||||
bound_service_account_namespaces=<Consul installation namespace> \
|
||||
policies=gossip-policy \
|
||||
|
|
@ -57,18 +65,25 @@ vault write auth/kubernetes/role/consul-client \
|
|||
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
|
||||
helm template --release-name <your release name> -s templates/server-serviceaccount.yaml hashicorp/consul
|
||||
# Generate Consul client service account name
|
||||
helm template --release-name <your release name> -s templates/client-serviceaccount.yaml hashicorp/consul
|
||||
```
|
||||
- Generate Consul server service account name
|
||||
```shell-session
|
||||
$ helm template --release-name ${RELEASE_NAME} -s templates/server-serviceaccount.yaml hashicorp/consul
|
||||
```
|
||||
|
||||
- Generate Consul client service account name
|
||||
```shell-session
|
||||
$ helm template --release-name ${RELEASE_NAME} -s templates/client-serviceaccount.yaml hashicorp/consul
|
||||
```
|
||||
|
||||
## Deploying the Consul Helm chart
|
||||
|
||||
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
|
||||
global:
|
||||
secretsBackend:
|
||||
|
|
@ -81,8 +96,11 @@ global:
|
|||
secretKey: key
|
||||
```
|
||||
|
||||
</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
|
||||
as the key we passed when we created the gossip secret in Vault.
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,9 @@ At a high level, there are two points of integration with Vault:
|
|||
|
||||
### Vault Helm Config
|
||||
|
||||
A minimal valid installation of Vault must include the Agent Injector:
|
||||
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"
|
||||
|
|
@ -83,7 +85,7 @@ which bootstrap Vault Auth roles and Policies for Consul to use. For the support
|
|||
guides and ensure to, when combining the secrets, append the Vault Policies to your Vault Kube Auth Roles via a comma separated value (i.e. `policies=gossip-policy,consul-ca,consul-server,custom-policy`).
|
||||
Ex:
|
||||
```shell-session
|
||||
vault write auth/kubernetes/role/consul-server \
|
||||
$ vault write auth/kubernetes/role/consul-server \
|
||||
bound_service_account_names=<Consul server service account> \
|
||||
bound_service_account_namespaces=<Consul installation namespace> \
|
||||
policies=gossip-policy,consul-ca,consul-server \
|
||||
|
|
|
|||
|
|
@ -48,13 +48,20 @@ 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.
|
||||
|
||||
```shell-session
|
||||
# consul-server-policy.hcl
|
||||
<CodeTabs>
|
||||
|
||||
<CodeBlockConfig filename="consul-server-policy.hcl">
|
||||
|
||||
```HCL
|
||||
path "pki/issue/consul-server" {
|
||||
capabilities = ["create", "update"]
|
||||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
</CodeTabs>
|
||||
|
||||
```shell-session
|
||||
$ vault policy write consul-server consul-server-policy.hcl
|
||||
```
|
||||
|
|
@ -66,13 +73,21 @@ $ 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.
|
||||
|
||||
```shell-session
|
||||
# ca-policy.hcl
|
||||
|
||||
<CodeTabs>
|
||||
|
||||
<CodeBlockConfig filename="ca-policy.hcl">
|
||||
|
||||
```HCL
|
||||
path "pki/cert/ca" {
|
||||
capabilities = ["read"]
|
||||
}
|
||||
```
|
||||
|
||||
</CodeBlockConfig>
|
||||
|
||||
</CodeTabs>
|
||||
|
||||
```shell-session
|
||||
$ vault policy write ca-policy ca-policy.hcl
|
||||
```
|
||||
|
|
@ -84,7 +99,7 @@ $ vault policy write ca-policy ca-policy.hcl
|
|||
Next, a Vault role for the PKI engine will set the default certificate issuance parameters:
|
||||
|
||||
```shell-session
|
||||
vault write pki/roles/consul-server \
|
||||
$ vault write pki/roles/consul-server \
|
||||
allowed_domains="<Allowed-domains-string>" \
|
||||
allow_subdomains=true \
|
||||
allow_bare_domains=true \
|
||||
|
|
@ -125,7 +140,7 @@ To find out the service account name of the Consul server,
|
|||
you can run:
|
||||
|
||||
```shell-session
|
||||
$ helm template --release-name <your release name> --show-only templates/server-serviceaccount.yaml hashicorp/consul
|
||||
$ helm template --release-name ${RELEASE_NAME} --show-only templates/server-serviceaccount.yaml hashicorp/consul
|
||||
```
|
||||
|
||||
-> **Note:** Should you enable other supported features such as gossip-encryption be sure to append additional policies to
|
||||
|
|
@ -143,7 +158,7 @@ $ vault write auth/kubernetes/role/consul-client \
|
|||
|
||||
To find out the service account name of the Consul client, use the command below.
|
||||
```shell-session
|
||||
$ helm template --release-name <your release name> --show-only templates/client-serviceaccount.yaml hashicorp/consul
|
||||
$ helm template --release-name ${RELEASE_NAME} --show-only templates/client-serviceaccount.yaml hashicorp/consul
|
||||
```
|
||||
|
||||
-> **Note:** Should you enable other supported features such as gossip-encryption, ensure you append additional policies to
|
||||
|
|
@ -166,6 +181,10 @@ 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
|
||||
global:
|
||||
secretsBackend:
|
||||
|
|
@ -188,8 +207,12 @@ server:
|
|||
load: "false"
|
||||
```
|
||||
|
||||
</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:
|
||||
|
||||
```
|
||||
kubectl create secret generic vault-ca --from-file vault.ca=/path/to/your/vault/
|
||||
```shell-session
|
||||
$ kubectl create secret generic vault-ca --from-file vault.ca=/path/to/your/vault/
|
||||
```
|
||||
|
|
|
|||
Loading…
Reference in New Issue