Anchor Link Fixes (#8572)
* update anchor link algorithm * update deps * update content component * fix a lot of broken links
This commit is contained in:
Jeff Escalante
GitHub
parent
236eb7e19f
commit
8af56bd620
|
|
@ -1,8 +1,8 @@
|
|||
{
|
||||
"ignore": {
|
||||
"marked": {
|
||||
"versions": "0.8.0",
|
||||
"reason": "breaks IE"
|
||||
"versions": "0.8.2",
|
||||
"reason": "IE Broken"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -39,7 +39,7 @@
|
|||
}
|
||||
|
||||
& li:before {
|
||||
background: url('/img/icons/alert-triangle.svg');
|
||||
background: url('./img/alert-triangle.svg');
|
||||
height: 20px;
|
||||
margin-top: 3px;
|
||||
width: 20px;
|
||||
|
|
@ -47,7 +47,7 @@
|
|||
}
|
||||
|
||||
& .after li:before {
|
||||
background: url('/img/icons/check-circle.svg');
|
||||
background: url('./img/check-circle.svg');
|
||||
height: 18px;
|
||||
margin-top: 4px;
|
||||
width: 18px;
|
||||
|
|
@ -299,7 +299,7 @@
|
|||
&.vault {
|
||||
& .after {
|
||||
& li:before {
|
||||
background: url('/img/icons/check-circle-blue.svg');
|
||||
background: url('./img/check-circle-blue.svg');
|
||||
height: 19px;
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -24,6 +24,7 @@ export default function ProductSubnav() {
|
|||
currentPath={router.pathname}
|
||||
menuItems={menuItems}
|
||||
menuItemsAlign="right"
|
||||
constrainWidth
|
||||
/>
|
||||
)
|
||||
}
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -6,12 +6,12 @@
|
|||
"dependencies": {
|
||||
"@bugsnag/js": "^6.5.2",
|
||||
"@bugsnag/plugin-react": "^6.5.0",
|
||||
"@hashicorp/nextjs-scripts": "^6.0.0-2",
|
||||
"@hashicorp/nextjs-scripts": "^6.2.0-9",
|
||||
"@hashicorp/react-button": "^2.1.6",
|
||||
"@hashicorp/react-case-study-slider": "^2.0.7",
|
||||
"@hashicorp/react-case-study-slider": "^2.0.10",
|
||||
"@hashicorp/react-consent-manager": "^2.0.6",
|
||||
"@hashicorp/react-content": "^2.2.0",
|
||||
"@hashicorp/react-docs-sidenav": "^3.0.3",
|
||||
"@hashicorp/react-content": "^3.0.0-0",
|
||||
"@hashicorp/react-docs-sidenav": "^3.0.4",
|
||||
"@hashicorp/react-docs-sitemap": "^1.0.0",
|
||||
"@hashicorp/react-footer": "3.1.11",
|
||||
"@hashicorp/react-global-styles": "^4.0.10",
|
||||
|
|
@ -20,9 +20,9 @@
|
|||
"@hashicorp/react-image": "^2.0.1",
|
||||
"@hashicorp/react-inline-svg": "^1.0.0",
|
||||
"@hashicorp/react-mega-nav": "^4.0.1-2",
|
||||
"@hashicorp/react-product-downloader": "^3.0.2",
|
||||
"@hashicorp/react-product-downloader": "^3.0.3",
|
||||
"@hashicorp/react-section-header": "^2.0.0",
|
||||
"@hashicorp/react-subnav": "^2.2.0",
|
||||
"@hashicorp/react-subnav": "^3.0.0",
|
||||
"@hashicorp/react-text-and-content": "^4.0.6",
|
||||
"@hashicorp/react-use-cases": "^1.0.4",
|
||||
"@hashicorp/react-vertical-text-block-list": "^2.0.1",
|
||||
|
|
@ -33,19 +33,19 @@
|
|||
"imagemin-svgo": "^7.1.0",
|
||||
"isomorphic-unfetch": "^3.0.0",
|
||||
"marked": "^0.7.0",
|
||||
"next": "^9.3.0",
|
||||
"next": "^9.3.3",
|
||||
"nprogress": "^0.2.0",
|
||||
"react": "^16.13.0",
|
||||
"react-dom": "^16.13.0",
|
||||
"react": "^16.13.1",
|
||||
"react-dom": "^16.13.1",
|
||||
"slugify": "^1.4.0",
|
||||
"stringify-object": "^3.3.0"
|
||||
},
|
||||
"devDependencies": {
|
||||
"dart-linkcheck": "^2.0.12",
|
||||
"dart-linkcheck": "^2.0.15",
|
||||
"glob": "^7.1.6",
|
||||
"husky": "^4.2.3",
|
||||
"inquirer": "^7.1.0",
|
||||
"prettier": "^1.19.1"
|
||||
"prettier": "^2.0.2"
|
||||
},
|
||||
"husky": {
|
||||
"hooks": {
|
||||
|
|
|
|||
|
|
@ -30,9 +30,9 @@ service principals. Environment variables will override any parameters set in th
|
|||
- `tenant_id` (`string: <required>`) - The tenant id for the Azure Active Directory.
|
||||
This value can also be provided with the AZURE_TENANT_ID environment variable.
|
||||
- `client_id` (`string:""`) - The OAuth2 client id to connect to Azure. This value can also be provided
|
||||
with the AZURE_CLIENT_ID environment variable. See [authentication](#Authentication) for more details.
|
||||
with the AZURE_CLIENT_ID environment variable. See [authentication](/docs/secrets/azure#authentication) for more details.
|
||||
- `client_secret` (`string:""`) - The OAuth2 client secret to connect to Azure. This value can also be
|
||||
provided with the AZURE_CLIENT_ID environment variable. See [authentication](#Authentication) for more details.
|
||||
provided with the AZURE_CLIENT_ID environment variable. See [authentication](/docs/secrets/azure#authentication) for more details.
|
||||
- `environment` (`string:""`) - The Azure environment. This value can also be provided with the AZURE_ENVIRONMENT
|
||||
environment variable. If not specified, Vault will use Azure Public Cloud.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ This endpoint configures shared information for the secrets engine.
|
|||
### Parameters
|
||||
|
||||
- `credentials` (`string:""`) - JSON credentials (either file contents or '@path/to/file')
|
||||
See docs for [alternative ways](/docs/secrets/gcp#passing-credentials-to-vault)
|
||||
See docs for [alternative ways](/docs/secrets/gcp#setup)
|
||||
to pass in to this parameter, as well as the
|
||||
[required permissions](/docs/secrets/gcp#required-permissions).
|
||||
|
||||
|
|
@ -73,7 +73,6 @@ account keys.
|
|||
| :----- | :------------------------ |
|
||||
| `POST` | `/gcp/config/rotate-root` |
|
||||
|
||||
|
||||
### Sample Request
|
||||
|
||||
```
|
||||
|
|
@ -117,7 +116,7 @@ $ curl \
|
|||
| :----- | :------------------- |
|
||||
| `POST` | `/gcp/roleset/:name` |
|
||||
|
||||
This method allows you to create a roleset or update an existing roleset. See [roleset docs](/docs/secrets/gcp#rolesets) for the GCP secrets backend
|
||||
This method allows you to create a roleset or update an existing roleset. See [roleset docs](/docs/secrets/gcp#roleset-bindings) for the GCP secrets backend
|
||||
to learn more about what happens when you create or update a roleset.
|
||||
|
||||
**If you update a roleset's bindings, this will effectively revoke any secrets
|
||||
|
|
|
|||
|
|
@ -13,9 +13,9 @@ see the [Vault Identity documentation](/docs/secrets/identity).
|
|||
|
||||
## API Sections
|
||||
|
||||
- [Entity](entity)
|
||||
- [Entity Alias](entity-alias)
|
||||
- [Group](group)
|
||||
- [Group Alias](group-alias)
|
||||
- [Identity Tokens](tokens)
|
||||
- [Lookup](lookup)
|
||||
- [Entity](/api-docs/secret/identity/entity)
|
||||
- [Entity Alias](/api-docs/secret/identity/entity-alias)
|
||||
- [Group](/api-docs/secret/identity/group)
|
||||
- [Group Alias](/api-docs/secret/identity/group-alias)
|
||||
- [Identity Tokens](/api-docs/secret/identity/tokens)
|
||||
- [Lookup](/api-docs/secret/identity/lookup)
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ update your API calls accordingly.
|
|||
- [Set Signed Intermediate](#set-signed-intermediate)
|
||||
- [Generate Certificate](#generate-certificate)
|
||||
- [Revoke Certificate](#revoke-certificate)
|
||||
- [Create/Update Role](#createupdate-role)
|
||||
- [Create/Update Role](#create-update-role)
|
||||
- [Read Role](#read-role)
|
||||
- [List Roles](#list-roles)
|
||||
- [Delete Role](#delete-role)
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ If Vault is hosted on Azure, Vault can use MSI to access Azure instead of a shar
|
|||
The next sections review how the authN/Z workflows work. If you
|
||||
have already reviewed these sections, here are some quick links to:
|
||||
|
||||
- [Usage](#usage)
|
||||
- [Usage](/docs/secrets/azure/#usage)
|
||||
- [API documentation](/api/auth/azure) docs.
|
||||
|
||||
## Authentication
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ management tool.
|
|||
|
||||
If you are using instance credentials or want to specify credentials via
|
||||
an environment variable, you can skip this step. To learn more, see the
|
||||
[Google Cloud Authentication](#google-cloud-authentication) section below.
|
||||
[Google Cloud Authentication](#authentication) section below.
|
||||
|
||||
1. Create a named role:
|
||||
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ To limit authorization to a set of email addresses:
|
|||
}
|
||||
```
|
||||
|
||||
Bound claims can optionally be configured with globs. See the [API documentation](/auth/jwt/#bound_claims_type) for more details.
|
||||
Bound claims can optionally be configured with globs. See the [API documentation](/api-docs/auth/jwt/#bound_claims_type) for more details.
|
||||
|
||||
### Claims as Metadata
|
||||
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@ for further discussion of available parameters.
|
|||
who successfully authenticate based on their LDAP group membership.
|
||||
Since this is identical to the LDAP auth method, see
|
||||
[Group Membership Resolution](/docs/auth/ldap#group-membership-resolution)
|
||||
and [LDAP Group -> Policy Mapping](/docs/auth/ldap#ldap-group-gt-policy-mapping)
|
||||
and [LDAP Group -> Policy Mapping](/docs/auth/ldap#ldap-group-policy-mapping)
|
||||
for further discussion.
|
||||
|
||||
```text
|
||||
|
|
|
|||
|
|
@ -107,13 +107,13 @@ You will see a response that includes a token with the previously added policy.
|
|||
|
||||
- [Add an API Key](https://docs.cloud.oracle.com/iaas/Content/API/Concepts/apisigningkey.htm) for a user in the console. This user should be part of a group that has previously been added to the Vault admin role.
|
||||
- Create the config file `~/.oci/config` using the user's credentials as detailed in [https://docs.cloud.oracle.com/iaas/Content/API/Concepts/sdkconfig.htm](https://docs.cloud.oracle.com/iaas/Content/API/Concepts/sdkconfig.htm).
|
||||
Ensure that the region in the config matches the region of the compute instance that is running Vault.
|
||||
Ensure that the region in the config matches the region of the compute instance that is running Vault.
|
||||
- Log into Vault using the user API key.
|
||||
|
||||
`vault login -method=oci auth_type=apikey role=vaultadminrole`
|
||||
|
||||
1. Stop Vault and re-start it in the production environment. See [the configuration docs](/docs/configuration/) for more information.
|
||||
1. Repeat all steps in this [Configure the OCI Auth Method](#OnboardingtoOCIAuthMethod-ConfiguretheOCIAuthMethod) section while in the production environment.
|
||||
1. Repeat all steps in this [Configure the OCI Auth Method](#configure-the-oci-auth-method) section while in the production environment.
|
||||
|
||||
### Manage Roles in the OCI Auth method
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ description: |-
|
|||
|
||||
~> **Note:** The Vault CLI interface was changed substantially in 0.9.2+ and may cause
|
||||
confusion while using older versions of Vault with this documentation. Read our
|
||||
[upgrade guide](/guides/upgrading/upgrade-to-0.9.2#backwards-compatible-cli-changes) for more information.
|
||||
[upgrade guide](/docs/upgrading/upgrade-to-0.9.2#backwards-compatible-cli-changes) for more information.
|
||||
|
||||
In addition to a verbose [HTTP API](/api), Vault features a
|
||||
command-line interface that wraps common functionality and formats output. The
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ storage_destination "consul" {
|
|||
The below configuration will migrate away from Consul storage to integrated
|
||||
raft storage. The raft data will be stored on the local filesystem in the
|
||||
defined `path`. `node_id` can optionally be set to identify this node.
|
||||
[cluster_addr](/docs/configuration/#inlinecode-cluster_addr) must be set to the
|
||||
[cluster_addr](/docs/configuration/#cluster_addr) must be set to the
|
||||
cluster hostname of this node. For more configuration options see the [raft
|
||||
storage configuration documentation](/docs/configuration/storage/raft).
|
||||
|
||||
|
|
@ -108,7 +108,7 @@ After migration has completed, the data is stored on the local file system. To
|
|||
use the new storage backend with Vault, update Vault's configuration file as
|
||||
described in the [raft storage configuration
|
||||
documentation](/docs/configuration/storage/raft). Then start and unseal the
|
||||
vault server.
|
||||
vault server.
|
||||
|
||||
### Join additional nodes
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ description: >-
|
|||
|
||||
# `Entropy Augmentation` Seal
|
||||
|
||||
Entropy augmentation enables Vault to sample entropy from external cryptographic modules.
|
||||
Entropy augmentation enables Vault to sample entropy from external cryptographic modules.
|
||||
Sourcing external entropy is done by configuring a supported [Seal](/docs/configuration/seal) type which
|
||||
include: [PKCS11 seal](/docs/configuration/seal/pkcs11), [AWS KMS](/docs/configuration/seal/awskms), and
|
||||
[Vault Transit](/docs/configuration/seal/transit).
|
||||
|
|
@ -22,6 +22,7 @@ A valid Vault Enterprise license is required for Entropy Augmentation
|
|||
|
||||
Additionally, the following software packages and enterprise modules are required for sourcing entropy
|
||||
via the [PKCS11 seal](/docs/configuration/seal/pkcs11):
|
||||
|
||||
- Governance and Policy module
|
||||
- PKCS#11 compatible HSM integration library. Vault targets version 2.2 or
|
||||
higher of PKCS#11. Depending on any given HSM, some functions (such as key
|
||||
|
|
@ -29,7 +30,6 @@ via the [PKCS11 seal](/docs/configuration/seal/pkcs11):
|
|||
- The [GNU libltdl library](https://www.gnu.org/software/libtool/manual/html_node/Using-libltdl)
|
||||
— ensure that it is installed for the correct architecture of your servers
|
||||
|
||||
|
||||
## `entropy` Example
|
||||
|
||||
This example shows configuring entropy augmentation through a PKCS11 HSM seal from Vault's configuration
|
||||
|
|
@ -54,4 +54,4 @@ These parameters apply to the `entropy` stanza in the Vault configuration file:
|
|||
|
||||
- `mode` `(string: <required>)`: The mode determines which Vault operations requiring
|
||||
entropy will sample entropy from the external source. Currently, the only mode supported
|
||||
is `augmentation` which sources entropy for [Critical Security Parameters (CSPs)](</docs/enterprise/entropy-augmentation/index#Critical-Security-Parameters-(CSPs)>).
|
||||
is `augmentation` which sources entropy for [Critical Security Parameters (CSPs)](/docs/enterprise/entropy-augmentation#critical-security-parameters-csps).
|
||||
|
|
|
|||
|
|
@ -145,27 +145,27 @@ These `telemetry` parameters apply to
|
|||
[prometheus](https://prometheus.io).
|
||||
|
||||
- `prometheus_retention_time` `(string: "24h")` - Specifies the amount of time that
|
||||
Prometheus metrics are retained in memory.
|
||||
- `disable_hostname` `(bool: false)` - It is recommended to also enable the option
|
||||
`disable_hostname` to avoid having prefixed metrics with hostname.
|
||||
Prometheus metrics are retained in memory.
|
||||
- `disable_hostname` `(bool: false)` - It is recommended to also enable the option
|
||||
`disable_hostname` to avoid having prefixed metrics with hostname.
|
||||
|
||||
The `/v1/sys/metrics` endpoint is only accessible on active nodes
|
||||
and automatically disabled on standby nodes. You can enable the `/v1/sys/metrics`
|
||||
endpoint on standby nodes by [enabling unauthenticated metrics access][telemetry-tcp].
|
||||
|
||||
Vault does not use the default Prometheus path, so Prometheus must be configured
|
||||
with the path below.
|
||||
Note that using `?format=prometheus` in the path won't work as "?" will be
|
||||
escaped, so it must be specified as a parameter.
|
||||
Vault does not use the default Prometheus path, so Prometheus must be configured
|
||||
with the path below.
|
||||
Note that using `?format=prometheus` in the path won't work as "?" will be
|
||||
escaped, so it must be specified as a parameter.
|
||||
|
||||
A Vault token is required with `capabilities = ["read", "list"]` to
|
||||
/v1/sys/metrics. The Prometheus `bearer_token` or `bearer_token_file` options
|
||||
must be added to the scrape job.
|
||||
A Vault token is required with `capabilities = ["read", "list"]` to
|
||||
/v1/sys/metrics. The Prometheus `bearer_token` or `bearer_token_file` options
|
||||
must be added to the scrape job.
|
||||
|
||||
An example job_name stanza required in the [Prometheus config](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config) is provided below.
|
||||
An example job_name stanza required in the [Prometheus config](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config) is provided below.
|
||||
|
||||
```
|
||||
# prometheus.yml
|
||||
# prometheus.yml
|
||||
scrape_configs:
|
||||
- job_name: 'vault'
|
||||
metrics_path: "/v1/sys/metrics"
|
||||
|
|
@ -179,7 +179,7 @@ scrape_configs:
|
|||
- targets: ['your_vault_server_here:8200']
|
||||
```
|
||||
|
||||
An example telemetry configuration to be added to Vault's configuration file is shown below:
|
||||
An example telemetry configuration to be added to Vault's configuration file is shown below:
|
||||
|
||||
```hcl
|
||||
telemetry {
|
||||
|
|
@ -228,5 +228,4 @@ telemetry {
|
|||
}
|
||||
```
|
||||
|
||||
[telemetry-tcp]: /docs/configuration/listener/tcp#telemetry
|
||||
|
||||
[telemetry-tcp]: /docs/configuration/listener/tcp/#telemetry-parameters
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ referenced from ACL and Sentinel policies in any namespace via the method name
|
|||
and can be tied to a mount accessor in any namespace.
|
||||
|
||||
When using [Sentinel
|
||||
EGPs](/docs/enterprise/sentinel#endpoint-governing-policies-egps-),
|
||||
EGPs](/docs/enterprise/sentinel#endpoint-governing-policies-egps),
|
||||
any MFA configuration specified must be satisfied by all requests affected by
|
||||
the policy, which can be difficult if the configured paths spread across
|
||||
namespaces. One way to address this is to use a policy similar to the
|
||||
|
|
|
|||
|
|
@ -14,12 +14,12 @@ robust backup and restoration process.
|
|||
|
||||
As of Vault 1.4 an integrated storage option is offered. This storage backend
|
||||
does not rely on any third party systems, it implements high availability,
|
||||
supports Enterprise Replication features, and provides backup/restore workflows.
|
||||
supports Enterprise Replication features, and provides backup/restore workflows.
|
||||
|
||||
## Consensus Protocol
|
||||
|
||||
Vault's integrated storage uses a [consensus
|
||||
protocol](https://en.wikipedia.org/wiki/Consensus_(computer_science)) to provide
|
||||
protocol](<https://en.wikipedia.org/wiki/Consensus_(computer_science)>) to provide
|
||||
[Consistency (as defined by CAP)](https://en.wikipedia.org/wiki/CAP_theorem).
|
||||
The consensus protocol is based on ["Raft: In search of an Understandable
|
||||
Consensus Algorithm"](https://raft.github.io/raft.pdf). For a visual explanation
|
||||
|
|
@ -34,35 +34,35 @@ understandable algorithm.
|
|||
|
||||
There are a few key terms to know when discussing Raft:
|
||||
|
||||
* Log - The primary unit of work in a Raft system is a log entry. The problem
|
||||
of consistency can be decomposed into a *replicated log*. A log is an ordered
|
||||
sequence of entries. Entries includes any cluster change: adding nodes, adding
|
||||
services, new key-value pairs, etc. We consider the log consistent if all
|
||||
members agree on the entries and their order.
|
||||
- Log - The primary unit of work in a Raft system is a log entry. The problem
|
||||
of consistency can be decomposed into a _replicated log_. A log is an ordered
|
||||
sequence of entries. Entries includes any cluster change: adding nodes, adding
|
||||
services, new key-value pairs, etc. We consider the log consistent if all
|
||||
members agree on the entries and their order.
|
||||
|
||||
* FSM - [Finite State Machine](https://en.wikipedia.org/wiki/Finite-state_machine).
|
||||
An FSM is a collection of finite states with transitions between them. As new logs
|
||||
are applied, the FSM is allowed to transition between states. Application of the
|
||||
same sequence of logs must result in the same state, meaning behavior must be deterministic.
|
||||
- FSM - [Finite State Machine](https://en.wikipedia.org/wiki/Finite-state_machine).
|
||||
An FSM is a collection of finite states with transitions between them. As new logs
|
||||
are applied, the FSM is allowed to transition between states. Application of the
|
||||
same sequence of logs must result in the same state, meaning behavior must be deterministic.
|
||||
|
||||
* Peer set - The peer set is the set of all members participating in log replication.
|
||||
For Vault's purposes, all server nodes are in the peer set of the local cluster.
|
||||
- Peer set - The peer set is the set of all members participating in log replication.
|
||||
For Vault's purposes, all server nodes are in the peer set of the local cluster.
|
||||
|
||||
* Quorum - A quorum is a majority of members from a peer set: for a set of size `n`,
|
||||
quorum requires at least `(n+1)/2` members. For example, if there are 5 members
|
||||
in the peer set, we would need 3 nodes to form a quorum. If a quorum of nodes is
|
||||
unavailable for any reason, the cluster becomes *unavailable* and no new logs
|
||||
can be committed.
|
||||
- Quorum - A quorum is a majority of members from a peer set: for a set of size `n`,
|
||||
quorum requires at least `(n+1)/2` members. For example, if there are 5 members
|
||||
in the peer set, we would need 3 nodes to form a quorum. If a quorum of nodes is
|
||||
unavailable for any reason, the cluster becomes _unavailable_ and no new logs
|
||||
can be committed.
|
||||
|
||||
* Committed Entry - An entry is considered *committed* when it is durably stored
|
||||
on a quorum of nodes. Once an entry is committed it can be applied.
|
||||
- Committed Entry - An entry is considered _committed_ when it is durably stored
|
||||
on a quorum of nodes. Once an entry is committed it can be applied.
|
||||
|
||||
* Leader - At any given time, the peer set elects a single node to be the leader.
|
||||
The leader is responsible for ingesting new log entries, replicating to followers,
|
||||
and managing when an entry is considered committed. For Vault's purposes, the
|
||||
leader node is also the Active vault node and followers are standby nodes. See
|
||||
the [High Avaibility docs](/docs/internals/high-availability/#design-overview)
|
||||
for more information.
|
||||
- Leader - At any given time, the peer set elects a single node to be the leader.
|
||||
The leader is responsible for ingesting new log entries, replicating to followers,
|
||||
and managing when an entry is considered committed. For Vault's purposes, the
|
||||
leader node is also the Active vault node and followers are standby nodes. See
|
||||
the [High Avaibility docs](/docs/internals/high-availability/#design-overview)
|
||||
for more information.
|
||||
|
||||
Raft is a complex protocol and will not be covered here in detail (for those who
|
||||
desire a more comprehensive treatment, the full specification is available in this
|
||||
|
|
@ -80,7 +80,7 @@ Once a cluster has a leader, it is able to accept new log entries. A client can
|
|||
request that a leader append a new log entry (from Raft's perspective, a log entry
|
||||
is an opaque binary blob). The leader then writes the entry to durable storage and
|
||||
attempts to replicate to a quorum of followers. Once the log entry is considered
|
||||
*committed*, it can be *applied* to a finite state machine. The finite state machine
|
||||
_committed_, it can be _applied_ to a finite state machine. The finite state machine
|
||||
is application specific; in Vault's case, we use
|
||||
[BoltDB](https://github.com/etcd-io/bbolt) to maintain cluster state. Vault's writes
|
||||
block until it is both _committed_ and _applied_.
|
||||
|
|
@ -102,18 +102,18 @@ about peer membership. For example, suppose there are only 2 peers: A and B. The
|
|||
size is also 2, meaning both nodes must agree to commit a log entry. If either A or B
|
||||
fails, it is now impossible to reach quorum. This means the cluster is unable to add
|
||||
or remove a node or to commit any additional log entries. This results in
|
||||
*unavailability*. At this point, manual intervention would be required to remove
|
||||
_unavailability_. At this point, manual intervention would be required to remove
|
||||
either A or B and to restart the remaining node in bootstrap mode.
|
||||
|
||||
A Raft cluster of 3 nodes can tolerate a single node failure while a cluster
|
||||
of 5 can tolerate 2 node failures. The recommended configuration is to either
|
||||
run 3 or 5 Vault servers per cluster. This maximizes availability without
|
||||
greatly sacrificing performance. The [deployment table](#deployment_table) below
|
||||
greatly sacrificing performance. The [deployment table](#deployment-table) below
|
||||
summarizes the potential cluster size options and the fault tolerance of each.
|
||||
|
||||
In terms of performance, Raft is comparable to Paxos. Assuming stable leadership,
|
||||
committing a log entry requires a single round trip to half of the cluster.
|
||||
Thus, performance is bound by disk I/O and network latency.
|
||||
Thus, performance is bound by disk I/O and network latency.
|
||||
|
||||
### Raft in Vault
|
||||
|
||||
|
|
@ -121,7 +121,7 @@ When getting started, a single Vault server is
|
|||
[initialized](/docs/commands/operator/init/#operator-init). At this point the
|
||||
cluster is of size 1 which allows the node to self-elect as a leader. Once a
|
||||
leader is elected, other servers can be added to the peer set in a way that
|
||||
preserves consistency and safety.
|
||||
preserves consistency and safety.
|
||||
|
||||
The join process is how new nodes are added to the vault cluster, it uses an
|
||||
encrypted challenge/answer workflow. To accomplish this, all nodes in a single
|
||||
|
|
@ -129,7 +129,7 @@ raft cluster must share the same seal configuration. If using an Auto Unseal the
|
|||
join process can use the configured seal to automatically decrypt the challenge
|
||||
and respond with the answer. If using a Shamir seal the unseal keys must be
|
||||
provided to the node attempting to join the cluster before it can decrypt the
|
||||
challenge and respond with the decrypted answer.
|
||||
challenge and respond with the decrypted answer.
|
||||
|
||||
Since all servers participate as part of the peer set, they all know the current
|
||||
leader. When an API request arrives at a non-leader server, the request is
|
||||
|
|
@ -146,44 +146,48 @@ server deployment is _**highly**_ discouraged as data loss is inevitable in a
|
|||
failure scenario.
|
||||
|
||||
<table class="table table-bordered table-striped">
|
||||
<tr>
|
||||
<th>Servers</th>
|
||||
<th>Quorum Size</th>
|
||||
<th>Failure Tolerance</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>1</td>
|
||||
<td>1</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>2</td>
|
||||
<td>2</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr class="warning">
|
||||
<td>3</td>
|
||||
<td>2</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>4</td>
|
||||
<td>3</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr class="warning">
|
||||
<td>5</td>
|
||||
<td>3</td>
|
||||
<td>2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>6</td>
|
||||
<td>4</td>
|
||||
<td>2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>7</td>
|
||||
<td>4</td>
|
||||
<td>3</td>
|
||||
</tr>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Servers</th>
|
||||
<th>Quorum Size</th>
|
||||
<th>Failure Tolerance</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>1</td>
|
||||
<td>1</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>2</td>
|
||||
<td>2</td>
|
||||
<td>0</td>
|
||||
</tr>
|
||||
<tr class="warning">
|
||||
<td>3</td>
|
||||
<td>2</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>4</td>
|
||||
<td>3</td>
|
||||
<td>1</td>
|
||||
</tr>
|
||||
<tr class="warning">
|
||||
<td>5</td>
|
||||
<td>3</td>
|
||||
<td>2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>6</td>
|
||||
<td>4</td>
|
||||
<td>2</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>7</td>
|
||||
<td>4</td>
|
||||
<td>3</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -22,4 +22,4 @@ The AWS Marketplace listings can be found below.
|
|||
|
||||
The Vault AMIs listed in the AWS Marketplace are intended to serve as an easy starting point for a Vault installation. Vault AMIs are built on top of a minimal Ubuntu distribution and contain up to date packages for both Vault and the underlying operating system dependencies.
|
||||
|
||||
The Open Source Vault AMI is intended for development and test use cases. This listing will launch a non-HA Vault instance with Vault running and the Vault UI available. For production use cases, please see the [Architecture](/docs/platform/aws-mp/run#Architecture) section of this documentation.
|
||||
The Open Source Vault AMI is intended for development and test use cases. This listing will launch a non-HA Vault instance with Vault running and the Vault UI available. For production use cases, please see the [Architecture](/docs/platform/aws-mp/run/#architecture) section of this documentation.
|
||||
|
|
|
|||
|
|
@ -172,7 +172,7 @@ guide demonstrates using an external Vault within a Kubernetes cluster.
|
|||
|
||||
The Vault UI is enabled but NOT exposed as service for security reasons. The
|
||||
Vault UI can also be exposed via port-forwarding or through a [`ui`
|
||||
configuration value](/docs/platform/k8s/helm#v-ui).
|
||||
configuration value](/docs/platform/k8s/helm/configuration/#ui).
|
||||
|
||||
Expose the Vault UI with port-forwarding:
|
||||
|
||||
|
|
@ -518,14 +518,14 @@ _End-to-End TLS._ Vault should always be used with TLS in production. If
|
|||
intermediate load balancers or reverse proxies are used to front Vault,
|
||||
they should not terminate TLS. This way traffic is always encrypted in transit
|
||||
to Vault and minimizes risks introduced by intermediate layers. See the
|
||||
[official documentation](/docs/platform/k8s/helm#standalone-server-with-tls)
|
||||
[official documentation](/docs/platform/k8s/helm/examples/standalone-tls/)
|
||||
for example on configuring Vault Helm to use TLS.
|
||||
|
||||
_Single Tenancy._ Vault should be the only main process running on a machine.
|
||||
This reduces the risk that another process running on the same machine is
|
||||
compromised and can interact with Vault. This can be accomplished by using Vault
|
||||
Helm's `affinity` configurable. See the
|
||||
[official documentation](/docs/platform/k8s/helm#highly-available-vault-cluster-with-consul)
|
||||
[official documentation](/docs/platform/k8s/helm/examples/ha-with-consul/)
|
||||
for example on configuring Vault Helm to use affinity rules.
|
||||
|
||||
_Enable Auditing._ Vault supports several auditing backends. Enabling auditing
|
||||
|
|
@ -534,7 +534,7 @@ trail in the case of misuse or compromise. Audit logs securely hash any sensitiv
|
|||
data, but access should still be restricted to prevent any unintended disclosures.
|
||||
Vault Helm includes a configurable `auditStorage` option that provisions a persistent
|
||||
volume to store audit logs. See the
|
||||
[official documentation](/docs/platform/k8s/helm#standalone-server-with-audit-storage)
|
||||
[official documentation](/docs/platform/k8s/helm/examples/standalone-audit/)
|
||||
for an example on configuring Vault Helm to use auditing.
|
||||
|
||||
_Immutable Upgrades._ Vault relies on an external storage backend for persistence,
|
||||
|
|
|
|||
|
|
@ -257,5 +257,5 @@ The Azure secrets engine has a full HTTP API. Please see the [Azure secrets engi
|
|||
for more details.
|
||||
|
||||
[api]: /api/secret/azure
|
||||
[config]: /api/secret/azure#configure
|
||||
[config]: /api/secret/azure#configure-access
|
||||
[repo]: https://github.com/hashicorp/vault-plugin-secrets-azure
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ description: |-
|
|||
with the Advanced Data Protection Module.
|
||||
|
||||
The KMIP secrets engine allows Vault to act as a [Key Management
|
||||
Interoperability Protocol](#kmip-spec) (KMIP) server provider and handle
|
||||
Interoperability Protocol](https://docs.oasis-open.org/kmip/kmip-spec/v2.0/os/kmip-spec-v2.0-os.html) (KMIP) server provider and handle
|
||||
the lifecycle of its KMIP managed objects. KMIP is a standardized protocol that allows
|
||||
services and applications to perform cryptographic operations without having to
|
||||
manage cryptographic material, otherwise known as managed objects, by delegating
|
||||
|
|
@ -135,7 +135,7 @@ which will be used when evaluating permissions during a KMIP request.
|
|||
|
||||
### Supported KMIP Operations
|
||||
|
||||
The KMIP protocol supports a wide [variety of operations](#kmip-ops) that can be
|
||||
The KMIP protocol supports a wide variety of operations that can be
|
||||
issued by clients to perform certain actions, such as key management,
|
||||
encryption, signing, etc. The KMIP secrets engine currently supports a subset of
|
||||
KMIP operations.
|
||||
|
|
|
|||
|
|
@ -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/configuration#check_timeout)
|
||||
[documentation](/docs/configuration/storage/consul/#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](/guides/upgrading) this will
|
||||
instructions](/docs/upgrading) this will
|
||||
not be an issue.
|
||||
|
||||
## Health Endpoint Status Code Changes
|
||||
|
|
@ -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/configuration#ha_enabled)
|
||||
[documentation](/docs/configuration#ha_storage)
|
||||
for details.
|
||||
|
||||
If you are already using DynamoDB in an HA fashion and wish to keep doing so,
|
||||
|
|
|
|||
|
|
@ -13,4 +13,4 @@ Due to a rapid release following 0.9.2, there are no version-specific upgrade
|
|||
instructions although any upgrade notices for 0.9.2 apply if you are coming
|
||||
from a previous version.
|
||||
|
||||
Please see the [0.9.2 upgrade guide](/guides/upgrading/upgrade-to-0.9.2) for notes on upgrading to 0.9.3.
|
||||
Please see the [0.9.2 upgrade guide](/docs/upgrading/upgrade-to-0.9.2) for notes on upgrading to 0.9.3.
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ detailed audit logs is almost impossible without a custom solution. This is
|
|||
where Vault steps in.
|
||||
|
||||
Examples work best to showcase Vault. Please see the
|
||||
[use cases](/intro/use-cases).
|
||||
[use cases](/docs/use-cases).
|
||||
|
||||
The key features of Vault are:
|
||||
|
||||
|
|
@ -68,9 +68,9 @@ The key features of Vault are:
|
|||
|
||||
## Next Steps
|
||||
|
||||
See the page on [Vault use cases](/intro/use-cases) to see the
|
||||
See the page on [Vault use cases](/docs/use-cases) to see the
|
||||
multiple ways Vault can be used. Then see
|
||||
[how Vault compares to other software](/intro/vs)
|
||||
[how Vault compares to other software](/docs/vs)
|
||||
to see how it fits into your existing infrastructure. Finally, continue onwards with
|
||||
the [getting started guide](/intro/getting-started) to use
|
||||
the [getting started guide](https://learn.hashicorp.com/vault/getting-started/install) to use
|
||||
Vault to read, write, and create real secrets and see how it works in practice.
|
||||
|
|
|
|||
|
|
@ -416,7 +416,7 @@ If everything looked fine in [Step 2](#step2), you are ready to write some data.
|
|||
|
||||
|
||||
|
||||
You have [verified in the `spring` log](#task-3-examine-the-sprig-container)
|
||||
You have [verified in the `spring` log](#task-3-examine-the-spring-container)
|
||||
that the demo app successfully retrieved a database credential from the Vault
|
||||
server during its initialization.
|
||||
|
||||
|
|
|
|||
|
|
@ -226,7 +226,7 @@ $ vault write auth/approle/role/<ROLE_NAME> [parameters]
|
|||
```
|
||||
|
||||
> There are a number of
|
||||
> [parameters](/api/auth/approle#create-new-approle) that you can set
|
||||
> [parameters](/api/auth/approle#create-update-approle) that you can set
|
||||
> on a role. If you want to limit the use of the generated secret ID, set
|
||||
> `secret_id_num_uses` or `secret_id_ttl` parameter values. Similarly, you can
|
||||
> specify `token_num_uses` and `token_ttl`. You may never want the app token to
|
||||
|
|
@ -295,7 +295,7 @@ $ curl --header "X-Vault-Token: ..." --request POST \
|
|||
```
|
||||
|
||||
> There are a number of
|
||||
> [parameters](/api/auth/approle#create-new-approle) that you can set
|
||||
> [parameters](/api/auth/approle#create-update-approle) that you can set
|
||||
> on a role. If you want to limit the use of the generated secret ID, set
|
||||
> `secret_id_num_uses` or `secret_id_ttl` parameter values. Similarly, you can
|
||||
> specify `token_num_uses` and `token_ttl`. You may never want the app token to
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ During the installation of Vault you should also review and apply the recommenda
|
|||
|
||||
To provide a highly-available single cluster architecture, we recommend Vault be deployed to more than one host, as shown in the [Vault Reference Architecture](/guides/operations/reference-architecture), and connected to a Consul cluster for persistent data storage.
|
||||
|
||||
|
||||
|
||||
|
||||
The below setup steps should be completed on all Vault hosts.
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ replication setup.
|
|||
## Reference Materials
|
||||
|
||||
- [Performance Replication and Disaster Recovery (DR) Replication](/docs/enterprise/replication#performance-replication-and-disaster-recovery-dr-replication)
|
||||
- [DR Replication API](/api/system/replication-dr)
|
||||
- [DR Replication API](/api/system/replication/replication-dr)
|
||||
- [Replication Setup & Guidance](/guides/operations/replication)
|
||||
- [Vault HA guide](/guides/operations/vault-ha-consul)
|
||||
|
||||
|
|
@ -586,8 +586,8 @@ these operations based on experience within their own environments. You can
|
|||
review the available replication APIs at the following links:
|
||||
|
||||
- [Vault Replication API](/api/system/replication)
|
||||
- [DR Replication API](/api/system/replication-dr)
|
||||
- [Performance Replication API](/api/system/replication-performance)
|
||||
- [DR Replication API](/api/system/replication/replication-dr)
|
||||
- [Performance Replication API](/api/system/replication/replication-performance)
|
||||
|
||||
## Next steps
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ cluster that meets your organization's needs.
|
|||
|
||||
- [Replication Setup & Guidance](/guides/operations/replication)
|
||||
walks you through the commands to activate the Vault servers in replication mode.
|
||||
Please note that [Vault Replication](/docs/vault-enterprise/replication)
|
||||
Please note that [Vault Replication](/docs/enterprise/replication)
|
||||
is a Vault Enterprise feature.
|
||||
|
||||
- [Disaster Recovery Replication Setup](/guides/operations/disaster-recovery)
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ control the movement of secrets across their infrastructure.
|
|||
|
||||
- Preparing for GDPR Compliance with HashiCorp Vault [webinar](https://www.hashicorp.com/resources/preparing-for-gdpr-compliance-with-hashicorp-vault)
|
||||
- Preparing for GDPR Compliance with HashiCorp Vault [blog post](https://www.hashicorp.com/blog/preparing-for-gdpr-compliance-with-hashicorp-vault)
|
||||
- [Create Mounts Filter (API)](/api/system/replication-performance#create-mounts-filter)
|
||||
- [Create Mounts Filter (API)](/api/system/replication/replication-performance#create-mounts-filter-deprecated)
|
||||
- [Performance Replication and Disaster Recovery (DR) Replication](/docs/enterprise/replication#performance-replication-and-disaster-recovery-dr-replication)
|
||||
|
||||
## Estimated Time to Complete
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ description: Learn how to set up and manage Vault Enterprise Performance Replica
|
|||
~> **Enterprise Only:** Vault replication feature is a part of _Vault Enterprise_.
|
||||
|
||||
If you're unfamiliar with Vault Replication concepts, please first look at the
|
||||
[general information page](/docs/vault-enterprise/replication). More
|
||||
[general information page](/docs/enterprise/replication). More
|
||||
details can be found in the
|
||||
[replication internals](/docs/internals/replication) document.
|
||||
|
||||
|
|
@ -91,7 +91,7 @@ working with both clusters.
|
|||
|
||||
Vault’s performance replication model is intended to allow horizontally scaling Vault’s
|
||||
functions rather than to act in a strict Disaster Recovery (DR) capacity. For more information on Vault's disaster recovery replication, look at the
|
||||
[general information page](/docs/vault-enterprise/replication).
|
||||
[general information page](/docs/enterprise/replication).
|
||||
|
||||
As a result, Vault performance replication acts on static items within Vault, meaning
|
||||
information that is not part of Vault’s lease-tracking system. In a practical
|
||||
|
|
@ -172,4 +172,4 @@ Local backend mounts are not replicated and their use will require existing DR
|
|||
mechanisms if DR is necessary in your implementation.
|
||||
|
||||
If you need true DR, look at the
|
||||
[general information page](/docs/vault-enterprise/replication) for information on Vault's disaster recovery replication.
|
||||
[general information page](/docs/enterprise/replication) for information on Vault's disaster recovery replication.
|
||||
|
|
|
|||
Loading…
Reference in New Issue