Links
This commit is contained in:
Seth Vargo
parent
66321cdb76
commit
6931bbd091
|
|
@ -151,7 +151,7 @@ of the header should be "X-Vault-Token" and the value should be the token.
|
|||
<span class="param-flags">optional</span>
|
||||
The TTL period of the token, provided as "1h", where hour is
|
||||
the largest suffix. If not provided, the token is valid for the
|
||||
[default lease TTL](/docs/config/index.html), or
|
||||
[default lease TTL](/docs/configuration/index.html), or
|
||||
indefinitely if the root policy is used.
|
||||
</li>
|
||||
<li>
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ You can tell if a data store supports high availability mode ("HA") by starting
|
|||
the server and seeing if "(HA available)" is output next to the data store
|
||||
information. If it is, then Vault will automatically use HA mode. This
|
||||
information is also available on the
|
||||
[Configuration](https://www.vaultproject.io/docs/config/index.html) page.
|
||||
[Configuration](https://www.vaultproject.io/docs/configuration/index.html) page.
|
||||
|
||||
To be highly available, one of the Vault server nodes grabs a lock within the
|
||||
data store. The successful server node then becomes the active node; all other
|
||||
|
|
@ -142,7 +142,7 @@ variable, which takes precedence.
|
|||
|
||||
Currently there are several backends that support high availability mode,
|
||||
including Consul, ZooKeeper and etcd. These may change over time, and the
|
||||
[configuration page](/docs/config/index.html) should be referenced.
|
||||
[configuration page](/docs/configuration/index.html) should be referenced.
|
||||
|
||||
The Consul backend is the recommended HA backend, as it is used in production
|
||||
by HashiCorp and its customers with commercial support.
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ used for just enough initial setup (usually, setting up authentication backends
|
|||
and policies necessary to allow administrators to acquire more limited tokens)
|
||||
or in emergencies, and are revoked immediately after they are no longer needed.
|
||||
If a new root token is needed, the `generate-root` command and associated [API
|
||||
endpoint](/api/sys-generate-root.html) can be
|
||||
endpoint](/api/system/generate-root.html) can be
|
||||
used to generate one on-the-fly.
|
||||
|
||||
It is also good security practice for there to be multiple eyes on a terminal
|
||||
|
|
@ -149,7 +149,7 @@ token's information is looked up. It is based on a combination of factors:
|
|||
1. The system max TTL, which is 32 days but can be changed in Vault's
|
||||
configuration file
|
||||
2. The max TTL set on a mount using [mount
|
||||
tuning](/api/sys-mounts.html). This value
|
||||
tuning](/api/system/mounts.html). This value
|
||||
is allowed to override the system max TTL -- it can be longer or shorter,
|
||||
and if set this value will be respected.
|
||||
3. A value suggested by the authentication backend that issued the token. This
|
||||
|
|
|
|||
|
|
@ -51,5 +51,5 @@ If using the Consul HA storage backend, Vault will now automatically register
|
|||
itself as the `vault` service and perform its own health checks/lifecycle
|
||||
status management. This behavior can be adjusted or turned off in Vault's
|
||||
configuration; see the
|
||||
[documentation](/docs/config/index.html#check_timeout)
|
||||
[documentation](/docs/configuration/index.html#check_timeout)
|
||||
for details.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ carefully.
|
|||
|
||||
Once an active node is running 0.6.1, only standby nodes running 0.6.1+ will be
|
||||
able to form an HA cluster. If following our [general upgrade
|
||||
instructions](/docs/install/upgrade.html) this will
|
||||
instructions](/docs/guides/upgrading/index.html) this will
|
||||
not be an issue.
|
||||
|
||||
## Health Endpoint Status Code Changes
|
||||
|
|
@ -39,7 +39,7 @@ each status code (including `500`).
|
|||
|
||||
Root tokens (tokens with the `root` policy) can no longer be created except by
|
||||
another root token or the
|
||||
[`generate-root`](/api/sys-generate-root.html)
|
||||
[`generate-root`](/api/system/generate-root.html)
|
||||
endpoint or CLI command.
|
||||
|
||||
## PKI Backend Certificates Will Contain Default Key Usages
|
||||
|
|
@ -57,7 +57,7 @@ details.
|
|||
|
||||
If using DynamoDB and want to use HA support, you will need to explicitly
|
||||
enable it in Vault's configuration; see the
|
||||
[documentation](/docs/config/index.html#ha_enabled)
|
||||
[documentation](/docs/configuration/index.html#ha_enabled)
|
||||
for details.
|
||||
|
||||
If you are already using DynamoDB in an HA fashion and wish to keep doing so,
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ for Vault 0.6.2. Please read it carefully.
|
|||
|
||||
In 0.6.1 this feature was in beta and required opting-in, but is now enabled by
|
||||
default. This can be disabled via the `"disable_clustering"` parameter in
|
||||
Vault's [config](/docs/config/index.html), or
|
||||
Vault's [config](/docs/configuration/index.html), or
|
||||
per-request with the `X-Vault-No-Request-Forwarding` header.
|
||||
|
||||
## AppRole Role Constraints
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ effect when using Vault with an HSM.
|
|||
|
||||
Normally, Vault uses a single set of unseal keys to perform both decryption of
|
||||
the cryptographic barrier and to authorize recovery operations, such as the
|
||||
[`generate-root`](/api/sys-generate-root.html)
|
||||
[`generate-root`](/api/system/generate-root.html)
|
||||
functionality.
|
||||
|
||||
When using an HSM, because the HSM automatically unseals the barrier but
|
||||
|
|
@ -40,7 +40,7 @@ rather than change parameters set by an operator.)
|
|||
Vault does not currently support rekeying the master key when protected by an
|
||||
HSM; however, it _does_ continue to support rotation of the underlying data
|
||||
encryption key that the master key protects via the
|
||||
[`/sys/rotate`](/api/sys-rotate.html) API
|
||||
[`/sys/rotate`](/api/system/rotate.html) API
|
||||
endpoint.
|
||||
|
||||
## Recovery Key
|
||||
|
|
@ -58,7 +58,7 @@ keys for this purpose, rather than the barrier unseal keys, is automatic.
|
|||
|
||||
When initializing, the split is performed according to the following CLI flags
|
||||
and their API equivalents in the
|
||||
[/sys/init](/api/sys-init.html) endpoint:
|
||||
[/sys/init](/api/system/init.html) endpoint:
|
||||
|
||||
* `recovery-shares`: The number of shares into which to split the recovery
|
||||
key. This value is equivalent to the `recovery_shares` value in the API
|
||||
|
|
@ -83,6 +83,6 @@ this is performed by using the `-recovery-key=true` flag to `vault rekey`.
|
|||
|
||||
Via the API, the rekey operation is performed with the same parameters as the
|
||||
[normal `/sys/rekey`
|
||||
endpoint](/api/sys-rekey.html); however, the
|
||||
endpoint](/api/system/rekey.html); however, the
|
||||
API prefix for this operation is at `/sys/rekey-recovery-key` rather than
|
||||
`/sys/rekey`.
|
||||
|
|
|
|||
|
|
@ -99,7 +99,7 @@ file.
|
|||
```
|
||||
|
||||
For guidance on dealing with this issue, see the discussion of
|
||||
`disable_mlock` in [Server Configuration](/docs/config/index.html).
|
||||
`disable_mlock` in [Server Configuration](/docs/configuration/index.html).
|
||||
|
||||
## Initializing the Vault
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue