status-im
/
consul
mirror of https://github.com/status-im/consul.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

website: add Vault CA provider doc sections

This commit is contained in:
Kyle Havlovitz 2018-06-19 17:51:21 -07:00 committed by Jack Pearkes
parent 050da22473
commit 8e028b7dc6
2 changed files with 76 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
website/source/docs/agent/options.html.md
View File

@ -679,9 +679,9 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
servers in the cluster in order for Connect to function properly. Defaults to false.
* <a name="connect_ca_provider"></a><a href="#connect_ca_provider">`ca_provider`</a> Controls
which CA provider to use for Connect's CA. Currently only `consul` is supported. This is only
used when initially bootstrapping the cluster. For an existing cluster, use the [Update CA
Configuration Endpoint](/api/connect/ca.html#update-ca-configuration).
which CA provider to use for Connect's CA. Currently only the `consul` and `vault` providers
are supported. This is only used when initially bootstrapping the cluster. For an existing
cluster, use the [Update CA Configuration Endpoint](/api/connect/ca.html#update-ca-configuration).
* <a name="connect_ca_config"></a><a href="#connect_ca_config">`ca_config`</a> An object which
allows setting different config options based on the CA provider chosen. This is only
@ -690,7 +690,7 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
The following providers are supported:
### Consul CA Provider
#### Consul CA Provider (`ca_provider = "consul"`)
* <a name="consul_ca_private_key"></a><a href="#consul_ca_private_key">`private_key`</a> The
PEM contents of the private key to use for the CA.
@ -703,6 +703,25 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
duration value such as `720h`. Only applies in the case where the private key or root certificate are
left blank. Defaults to `2160h` (90 days).
#### Vault CA Provider (`ca_provider = "vault"`)
* <a name="vault_ca_address"></a><a href="#vault_ca_address">`address`</a> The address of the Vault
server to connect to.
* <a name="vault_ca_token"></a><a href="#vault_ca_token">`token`</a> The Vault token to use.
* <a name="vault_ca_root_pki"></a><a href="#vault_ca_root_pki">`root_pki_path`</a> The
path to use for the root CA pki backend in Vault. This can be an existing backend with a CA already
configured, or a blank/unmounted backend in which case Connect will automatically mount/generate the CA.
The Vault token given above must have `sudo` access to this backend, as well as permission to mount
the backend at this path if it is not already mounted.
* <a name="vault_ca_intermediate_pki"></a><a href="#vault_ca_intermediate_pki">`intermediate_pki_path`</a>
The path to use for the temporary intermediate CA pki backend in Vault. *Connect will overwrite any data
at this path in order to generate a temporary intermediate CA*. The Vault token given above must have
`write` access to this backend, as well as permission to mount the backend at this path if it is not
already mounted.
* <a name="connect_proxy"></a><a href="#connect_proxy">`proxy`</a> This object allows setting options for the Connect proxies. The following sub-keys are available:
* <a name="connect_proxy_allow_managed_registration"></a><a href="#connect_proxy_allow_managed_registration">`allow_managed_api_registration`</a> Allows managed proxies to be configured with services that are registered via the Agent HTTP API. Enabling this would allow anyone with permission to register a service to define a command to execute for the proxy. By default, this is false to protect against arbitrary process execution.

55
website/source/docs/connect/ca.html.md
View File

@ -193,6 +193,57 @@ $ curl localhost:8500/v1/connect/ca/roots
The old root certificate will be automatically removed once enough time has elapsed
for any leaf certificates signed by it to expire.
### External CA (Certificate Authority) Providers (Vault)
### External CA (Certificate Authority) Providers
TODO
#### Vault
Currently, the only supported external CA (Certificate Authority) provider is Vault. The
Vault provider can be used by setting the `ca_provider = "vault"` field in the Connect
configuration:
```hcl
connect {
enabled = true
ca_provider = "vault"
ca_config {
address = "http://localhost:8200"
token = "..."
root_pki_path = "connect-root"
intermediate_pki_path = "connect-intermediate"
}
}
```
The `root_pki_path` can be set to either a new or existing PKI backend; if no CA has been
initialized at the path, a new root CA will be generated. From this root PKI, Connect will
generate an intermediate CA at `intermediate_pki_path`. This intermediate CA is used so that
Connect can manage its lifecycle/rotation - it will never touch or overwrite any existing data
at `root_pki_path`. The intermediate CA is used for signing leaf certificates used by the
services and proxies in Connect to verify identity.
To update the configuration for the Vault provider, the process is the same as for the Consul CA
provider above: use the [Update CA Configuration endpoint](/api/connect/ca.html#update-ca-configuration)
or the `consul connect ca set-config` command:
```bash
$ cat ca_config.json
{
"Provider": "vault",
"Config": {
address = "http://localhost:8200"
token = "..."
root_pki_path = "connect-root-2"
intermediate_pki_path = "connect-intermediate"
}
}
$ consul connect ca set-config -config-file=ca_config.json
...
[INFO] connect: CA rotated to new root under provider "vault"
```
If the PKI backend at `connect-root-2` in this case has a different root certificate (or if it's
unmounted and hasn't been initialized), the rotation process will be triggered, as described above
in the [Root Certificate Rotation](#root-certificate-rotation) section.