website: content updates for developer (#17035)
* Chore (dev portal): update learn nav data links (#15515) * Update docs-nav-data.json * Update docs-nav-data.json * website: fixes internal redirects (#15750) * chore: remove duplicate overview item (#15805) * Use `badge` for `<sup>` tags in nav data JSON files (#15928) * Replacing <sup> tags with badge * Adding type and color to badges * fix broken links in vault docs (#15976) * website: Update old learn links to redirect locations (#16047) * update previews to render developer UI * update redirects * adjust content so it is backwards compat Co-authored-by: HashiBot <62622282+hashibot-web@users.noreply.github.com> Co-authored-by: Kendall Strautman <36613477+kendallstrautman@users.noreply.github.com> Co-authored-by: Ashlee M Boyer <43934258+ashleemboyer@users.noreply.github.com>
This commit is contained in:
Bryce Kalow
GitHub
parent
fa8f7c793f
commit
dfc3ad015a
|
|
@ -13,7 +13,8 @@ DOCKER_RUN_FLAGS=-it \
|
|||
--volume "$(PWD)/redirects.js:/app/redirects.js" \
|
||||
--volume "next-dir:/app/website-preview/.next" \
|
||||
--volume "$(PWD)/.env:/app/.env" \
|
||||
-e "REPO=vault"
|
||||
-e "REPO=vault" \
|
||||
-e "PREVIEW_MODE=io"
|
||||
|
||||
# Default: run this if working on the website locally to run in watch mode.
|
||||
.PHONY: website
|
||||
|
|
|
|||
|
|
@ -303,7 +303,7 @@ Obtain an authorization URL from Vault to start an OIDC login flow.
|
|||
- `role` `(string: <optional>)` - Name of the role against which the login is being
|
||||
attempted. Defaults to configured `default_role` if not provided.
|
||||
- `redirect_uri` `(string: <required>)` - Path to the callback to complete the login. This will be
|
||||
of the form, "https://.../oidc/callback" where the leading portion is dependent on your Vault
|
||||
of the form, "https://.../oidc/callback" where the leading portion is dependent on your Vault
|
||||
server location, port, and the mount of the JWT plugin. This must be configured with Vault and the
|
||||
provider. See [Redirect URIs](/docs/auth/jwt#redirect-uris) for more information.
|
||||
- `client_nonce` `(string: <optional>)` - Optional client-provided nonce that
|
||||
|
|
|
|||
|
|
@ -196,7 +196,7 @@ To retrieve the help for any API within Vault, including mounted backends, auth
|
|||
methods, etc. then append `?help=1` to any URL. If you have valid permission to
|
||||
access the path, then the help text will be return a markdown-formatted block in the `help` attribute of the response.
|
||||
|
||||
Additionally, with the [OpenAPI generation](/api/system/internal-specs-openapi) in Vault, you will get back a small
|
||||
Additionally, with the [OpenAPI generation](/api-docs/system/internal-specs-openapi) in Vault, you will get back a small
|
||||
OpenAPI document in the `openapi` attribute. This document is relevant for the path you're looking up and any paths under it - also note paths in the OpenAPI document are relative to the initial path queried.
|
||||
|
||||
Example request:
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ description: Short list of third-party tools that work with or are related to Va
|
|||
|
||||
## Hashicorp Tools
|
||||
|
||||
- The [Terraform Vault provider](https://www.terraform.io/docs/providers/vault/index.html) can read from, write to, and configure Vault from [HashiCorp Terraform](https://www.terraform.io/)
|
||||
- The [Terraform Vault provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) can read from, write to, and configure Vault from [HashiCorp Terraform](https://www.terraform.io/)
|
||||
- [consul-template](https://github.com/hashicorp/consul-template) is a template renderer, notifier, and supervisor for HashiCorp Consul and Vault data
|
||||
- [envconsul](https://github.com/hashicorp/envconsul) allows you to read and set environmental variables for processes from Consul and Vault data
|
||||
- The [vault-ssh-helper](https://github.com/hashicorp/vault-ssh-helper) can be used to enable one-time passwords for SSH authentication via Vault
|
||||
|
|
@ -31,7 +31,6 @@ The following list of tools is maintained by the community of Vault users; Hashi
|
|||
- [Docker credential helper](https://github.com/morningconsult/docker-credential-vault-login) - A program that automatically reads Docker credentials from your Vault server and passes them to the Docker daemon to authenticate to your Docker registry when pulling an image
|
||||
- [Cruise Daytona](https://github.com/cruise-automation/daytona) - An alternative implementation of the Vault client CLI for services and containers. Its core features are the ability to automate authentication, fetching of secrets, and automated token renewal. Support for AWS, GCP, & Kubernetes Vault Auth Backends.
|
||||
- [Vault-CRD](https://vault.koudingspawn.de/) - Synchronize secrets stored in HashiCorp Vault to Kubernetes Secrets for better GitOps without secrets stored in git manifest files.
|
||||
- [nc-vault-env](https://github.com/namecheap/nc-vault-env) - JS CLI tool that fetches secrets in parallel, puts them into the environment and then `exec`s the process that needs them. Supports auth token renewal, multiple auth backends, verbose logging and dummy mode.
|
||||
- [vsh](https://github.com/fishi0x01/vsh) - Interactive shell with tab-completion. Allows recursive operations on paths. Allows migration of secrets between both KV versions.
|
||||
- [HashiBox](https://github.com/nunchistudio/hashibox) - Vagrant environment to simulate highly-available cloud with Consul, Nomad, Vault, and optional support for Waypoint. OSS & Enterprise supported.
|
||||
- [vkv](https://github.com/FalcoSuessgott/vkv) - Recursively list key-values entries from Vaults KV2 engine in various formats.
|
||||
|
|
|
|||
|
|
@ -360,7 +360,7 @@ $ vault read azure/creds/my-role
|
|||
|
||||
## Revoking/Renewing Secrets
|
||||
|
||||
See docs on how to [renew](/api/system/leases#renew-lease) and [revoke](/api/system/leases#revoke-lease) leases.
|
||||
See docs on how to [renew](/api/system/leases#renew-lease) and [revoke](/api-docs/system/leases#revoke-lease) leases.
|
||||
|
||||
[docs]: /docs/secrets/azure
|
||||
[roles]: /docs/secrets/azure#roles
|
||||
|
|
|
|||
|
|
@ -11,12 +11,12 @@ description: This is the API documentation for the Vault Cassandra secrets engin
|
|||
~> **Deprecation Note:** This backend is deprecated in favor of the
|
||||
combined databases backend added in v0.7.1. See the API documentation for
|
||||
the new implementation of this backend at
|
||||
[Cassandra database plugin HTTP API](/api/secret/databases/cassandra).
|
||||
[Cassandra database plugin HTTP API](/api-docs/secret/databases/cassandra).
|
||||
|
||||
This is the API documentation for the Vault Cassandra secrets engine. For
|
||||
general information about the usage and operation of the Cassandra backend,
|
||||
please see the
|
||||
[Vault Cassandra backend documentation](/docs/secrets/cassandra).
|
||||
[Vault Cassandra backend documentation](/docs/secrets/databases/cassandra).
|
||||
|
||||
This documentation assumes the Cassandra backend is mounted at the `/cassandra`
|
||||
path in Vault. Since it is possible to enable secrets engines at any location,
|
||||
|
|
@ -197,7 +197,7 @@ $ curl \
|
|||
|
||||
This endpoint deletes the role definition.
|
||||
|
||||
| Method | Path |
|
||||
| Method | Path | |
|
||||
| :------- | :----------------------- | --------------- |
|
||||
| `DELETE` | `/cassandra/roles/:name` | `204 (no body)` |
|
||||
|
||||
|
|
|
|||
|
|
@ -160,11 +160,11 @@ To create a client token with service identities attached:
|
|||
- `token_type` <sup>DEPRECATED (1.11)</sup> `(string: "client")` - Specifies the type of token to create
|
||||
when using this role. Valid values are `"client"` or `"management"`. If a `"management"`
|
||||
token, the `policy` parameter is not required. Defaults to `"client`". [Deprecated from Consul as of 1.4 and
|
||||
removed as of Consul 1.11.](https://www.consul.io/api/acl/legacy)
|
||||
removed as of Consul 1.11.](https://www.consul.io/api-docs/acl/legacy)
|
||||
|
||||
- `policy` <sup>DEPRECATED (1.11)</sup> `(string: "")` – Specifies the base64-encoded ACL policy.
|
||||
This is required unless the `token_type` is `"management"`. [Deprecated from Consul as of 1.4 and
|
||||
removed as of Consul 1.11.](https://www.consul.io/api/acl/legacy)
|
||||
removed as of Consul 1.11.](https://www.consul.io/api-docs/acl/legacy)
|
||||
|
||||
- `policies` <sup>DEPRECATED (1.11)</sup> `(list: <policy or policies>)` - Same as `consul_policies`.
|
||||
Deprecated in favor of using `consul_policies`.
|
||||
|
|
|
|||
|
|
@ -173,7 +173,7 @@ $ curl \
|
|||
Statements are configured during role creation and are used by the plugin to
|
||||
determine what is sent to the database on user creation, renewing, and
|
||||
revocation. For more information on configuring roles see the [Role
|
||||
API](/api/secret/databases#create-role) in the database secrets engine docs.
|
||||
API](/api-docs/secret/databases#create-role) in the database secrets engine docs.
|
||||
|
||||
### Parameters
|
||||
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@ $ curl \
|
|||
Statements are configured during role creation and are used by the plugin to
|
||||
determine what is sent to the database on user creation, renewing, and
|
||||
revocation. For more information on configuring roles see the [Role
|
||||
API](/api/secret/databases#create-role) in the database secrets engine docs.
|
||||
API](/api-docs/secret/databases#create-role) in the database secrets engine docs.
|
||||
|
||||
### Parameters
|
||||
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ $ curl \
|
|||
Statements are configured during role creation and are used by the plugin to
|
||||
determine what is sent to the database on user creation, renewing, and
|
||||
revocation. For more information on configuring roles see the [Role
|
||||
API](/api/secret/databases#create-role) in the database secrets engine docs.
|
||||
API](/api-docs/secret/databases#create-role) in the database secrets engine docs.
|
||||
|
||||
### Parameters
|
||||
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ $ curl \
|
|||
Statements are configured during role creation and are used by the plugin to
|
||||
determine what is sent to the database on user creation, renewing, and
|
||||
revocation. For more information on configuring roles see the [Role
|
||||
API](/api/secret/databases#create-role) in the database secrets engine docs.
|
||||
API](/api-docs/secret/databases#create-role) in the database secrets engine docs.
|
||||
|
||||
### Parameters
|
||||
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ $ curl \
|
|||
Statements are configured during role creation and are used by the plugin to
|
||||
determine what is sent to the database on user creation, renewing, and
|
||||
revocation. For more information on configuring roles see the [Role
|
||||
API](/api/secret/databases#create-role) in the database secrets engine docs.
|
||||
API](/api-docs/secret/databases#create-role) in the database secrets engine docs.
|
||||
|
||||
### Parameters
|
||||
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ $ curl \
|
|||
Statements are configured during role creation and are used by the plugin to
|
||||
determine what is sent to the database on user creation, renewing, and
|
||||
revocation. For more information on configuring roles see the [Role
|
||||
API](/api/secret/databases#create-role) in the database secrets engine docs.
|
||||
API](/api-docs/secret/databases#create-role) in the database secrets engine docs.
|
||||
|
||||
### Parameters
|
||||
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ $ curl \
|
|||
|
||||
Statements are configured during Vault role creation and are used by the plugin to
|
||||
determine what is sent to MongoDB Atlas upon user creation, renewal, and
|
||||
revocation. For more information on configuring roles see the [Role API](/api/secret/databases#create-role)
|
||||
revocation. For more information on configuring roles see the [Role API](/api-docs/secret/databases#create-role)
|
||||
in the Database Secrets Engine docs.
|
||||
|
||||
### Parameters
|
||||
|
|
|
|||
|
|
@ -109,7 +109,7 @@ $ curl \
|
|||
Statements are configured during role creation and are used by the plugin to
|
||||
determine what is sent to the database on user creation, renewing, and
|
||||
revocation. For more information on configuring roles see the [Role
|
||||
API](/api/secret/databases#create-role) in the database secrets engine docs.
|
||||
API](/api-docs/secret/databases#create-role) in the database secrets engine docs.
|
||||
|
||||
### Parameters
|
||||
|
||||
|
|
|
|||
|
|
@ -144,7 +144,7 @@ $ curl \
|
|||
Statements are configured during role creation and are used by the plugin to
|
||||
determine what is sent to the database on user creation, renewing, and
|
||||
revocation. For more information on configuring roles see the [Role
|
||||
API](/api/secret/databases#create-role) in the database secrets engine docs.
|
||||
API](/api-docs/secret/databases#create-role) in the database secrets engine docs.
|
||||
|
||||
### Parameters
|
||||
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@ $ curl \
|
|||
Statements are configured during role creation and are used by the plugin to
|
||||
determine what is sent to the database on user creation, renewing, and
|
||||
revocation. For more information on configuring roles see the [Role
|
||||
API](/api/secret/databases#create-role) in the database secrets engine docs.
|
||||
API](/api-docs/secret/databases#create-role) in the database secrets engine docs.
|
||||
|
||||
### Parameters
|
||||
|
||||
|
|
|
|||
|
|
@ -147,7 +147,7 @@ for more information. Below are two small examples.
|
|||
Statements are configured during role creation and are used by the plugin to
|
||||
determine what is sent to the database on user creation, renewing, and
|
||||
revocation. For more information on configuring roles see the [Role
|
||||
API](/api/secret/databases#create-role) in the database secrets engine docs.
|
||||
API](/api-docs/secret/databases#create-role) in the database secrets engine docs.
|
||||
|
||||
### Parameters
|
||||
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ $ curl \
|
|||
Statements are configured during role creation and are used by the plugin to
|
||||
determine what is sent to the database on user creation, renewing, and
|
||||
revocation. For more information on configuring roles see the [Role
|
||||
API](/api/secret/databases#create-role) in the database secrets engine docs.
|
||||
API](/api-docs/secret/databases#create-role) in the database secrets engine docs.
|
||||
|
||||
### Parameters
|
||||
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ $ curl \
|
|||
Statements are configured during role creation and are used by the plugin to
|
||||
determine what is sent to the database on user creation, renewing, and
|
||||
revocation. For more information on configuring roles see the [Role
|
||||
API](/api/secret/databases#create-role) in the database secrets engine docs.
|
||||
API](/api-docs/secret/databases#create-role) in the database secrets engine docs.
|
||||
|
||||
### Parameters
|
||||
|
||||
|
|
|
|||
|
|
@ -594,5 +594,5 @@ $ curl \
|
|||
|
||||
## Revoking/Renewing Secrets
|
||||
|
||||
See docs on how to [renew](/api/system/leases#renew-lease) and [revoke](/api/system/leases#revoke-lease) leases.
|
||||
See docs on how to [renew](/api/system/leases#renew-lease) and [revoke](/api-docs/system/leases#revoke-lease) leases.
|
||||
Note this only applies to service account keys.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ description: >-
|
|||
This endpoint defines an MFA method of type Duo.
|
||||
|
||||
| Method | Path |
|
||||
| :----- |:-------------------------------|
|
||||
| :----- | :----------------------------- |
|
||||
| `POST` | `/identity/mfa/method/duo/:id` |
|
||||
|
||||
### Parameters
|
||||
|
|
@ -26,7 +26,9 @@ This endpoint defines an MFA method of type Duo.
|
|||
- `api_hostname` `(string: <required>)` - API hostname for Duo.
|
||||
|
||||
- `push_info` `(string)` - Push information for Duo.
|
||||
|
||||
-
|
||||
|
||||
- `use_passcode` `(bool: false)` - If true, the user is reminded to use the passcode upon MFA validation.
|
||||
|
||||
### Sample Payload
|
||||
|
|
@ -64,7 +66,7 @@ This endpoint queries the MFA configuration of Duo type for a given method
|
|||
ID.
|
||||
|
||||
| Method | Path |
|
||||
| :----- |:-------------------------------|
|
||||
| :----- | :----------------------------- |
|
||||
| `GET` | `/identity/mfa/method/duo/:id` |
|
||||
|
||||
### Parameters
|
||||
|
|
@ -101,10 +103,10 @@ $ curl \
|
|||
## Delete Duo MFA Method
|
||||
|
||||
This endpoint deletes a Duo MFA method. MFA methods can only be deleted if they're not currently in use
|
||||
by a [login enforcement](/api/secret/identity/mfa/login-enforcement).
|
||||
by a [login enforcement](/api-docs/secret/identity/mfa/login-enforcement).
|
||||
|
||||
| Method | Path |
|
||||
| :------- |:-------------------------------|
|
||||
| :------- | :----------------------------- |
|
||||
| `DELETE` | `/identity/mfa/method/duo/:id` |
|
||||
|
||||
### Parameters
|
||||
|
|
@ -126,7 +128,7 @@ $ curl \
|
|||
This endpoint lists Duo MFA methods that are visible in the current namespace or in parent namespaces.
|
||||
|
||||
| Method | Path |
|
||||
|:-------|:---------------------------|
|
||||
| :----- | :------------------------- |
|
||||
| `LIST` | `/identity/mfa/method/duo` |
|
||||
|
||||
### Sample Request
|
||||
|
|
|
|||
|
|
@ -9,18 +9,18 @@ description: >-
|
|||
|
||||
## Supported MFA types.
|
||||
|
||||
- [TOTP](/api/secret/identity/mfa/totp)
|
||||
- [TOTP](/api-docs/secret/identity/mfa/totp)
|
||||
|
||||
- [Okta](/api/secret/identity/mfa/okta)
|
||||
- [Okta](/api-docs/secret/identity/mfa/okta)
|
||||
|
||||
- [Duo](/api/secret/identity/mfa/duo)
|
||||
- [Duo](/api-docs/secret/identity/mfa/duo)
|
||||
|
||||
- [PingID](/api/secret/identity/mfa/pingid)
|
||||
- [PingID](/api-docs/secret/identity/mfa/pingid)
|
||||
|
||||
## Other
|
||||
|
||||
- [Login Enforcement](/api/secret/identity/mfa/login-enforcement)
|
||||
- [MFA Validate](/api/system/mfa/validate)
|
||||
- [Login Enforcement](/api-docs/secret/identity/mfa/login-enforcement)
|
||||
- [MFA Validate](/api-docs/system/mfa/validate)
|
||||
|
||||
While the above endpoints are available in both the open source and Enterprise versions of Vault,
|
||||
they are namespace aware. MFA methods and login enforcements created in one namespace are separate from other
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ description: >-
|
|||
This endpoint defines an MFA method of type Okta.
|
||||
|
||||
| Method | Path |
|
||||
| :----- |:--------------------------------|
|
||||
| :----- | :------------------------------ |
|
||||
| `POST` | `/identity/mfa/method/okta/:id` |
|
||||
|
||||
### Parameters
|
||||
|
|
@ -61,7 +61,7 @@ This endpoint queries the MFA configuration of Okta type for a given method
|
|||
name.
|
||||
|
||||
| Method | Path |
|
||||
| :----- |:--------------------------------|
|
||||
| :----- | :------------------------------ |
|
||||
| `GET` | `/identity/mfa/method/okta/:id` |
|
||||
|
||||
### Parameters
|
||||
|
|
@ -96,10 +96,10 @@ $ curl \
|
|||
## Delete Okta MFA Method
|
||||
|
||||
This endpoint deletes a Okta MFA method. The MFA methods can only be deleted if they're not currently in use
|
||||
by a [login enforcement](/api/secret/identity/mfa/login-enforcement).
|
||||
by a [login enforcement](/api-docs/secret/identity/mfa/login-enforcement).
|
||||
|
||||
| Method | Path |
|
||||
| :------- |:--------------------------------|
|
||||
| :------- | :------------------------------ |
|
||||
| `DELETE` | `/identity/mfa/method/okta/:id` |
|
||||
|
||||
### Parameters
|
||||
|
|
@ -121,7 +121,7 @@ $ curl \
|
|||
This endpoint lists Okta MFA methods that are visible in the current namespace or in parent namespaces.
|
||||
|
||||
| Method | Path |
|
||||
|:-------|:----------------------------|
|
||||
| :----- | :-------------------------- |
|
||||
| `LIST` | `/identity/mfa/method/okta` |
|
||||
|
||||
### Sample Request
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ description: >-
|
|||
This endpoint defines an MFA method of type PingID.
|
||||
|
||||
| Method | Path |
|
||||
| :----- |:----------------------------------|
|
||||
| :----- | :-------------------------------- |
|
||||
| `POST` | `/identity/mfa/method/pingid/:id` |
|
||||
|
||||
### Parameters
|
||||
|
|
@ -54,7 +54,7 @@ This endpoint queries the MFA configuration of PingID type for a given method
|
|||
name.
|
||||
|
||||
| Method | Path |
|
||||
| :----- |:----------------------------------|
|
||||
| :----- | :-------------------------------- |
|
||||
| `GET` | `/identity/mfa/method/pingid/:id` |
|
||||
|
||||
### Parameters
|
||||
|
|
@ -90,10 +90,10 @@ $ curl \
|
|||
## Delete PingID MFA Method
|
||||
|
||||
This endpoint deletes a PingID MFA method. MFA methods can only be deleted if they're not currently in use
|
||||
by a [login enforcement](/api/secret/identity/mfa/login-enforcement).
|
||||
by a [login enforcement](/api-docs/secret/identity/mfa/login-enforcement).
|
||||
|
||||
| Method | Path |
|
||||
| :------- |:----------------------------------|
|
||||
| :------- | :-------------------------------- |
|
||||
| `DELETE` | `/identity/mfa/method/pingid/:id` |
|
||||
|
||||
### Parameters
|
||||
|
|
@ -115,7 +115,7 @@ $ curl \
|
|||
This endpoint lists PingID MFA methods that are visible in the current namespace or in parent namespaces.
|
||||
|
||||
| Method | Path |
|
||||
|:-------|:------------------------------|
|
||||
| :----- | :---------------------------- |
|
||||
| `LIST` | `/identity/mfa/method/pingid` |
|
||||
|
||||
### Sample Request
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ description: >-
|
|||
This endpoint defines an MFA method of type TOTP.
|
||||
|
||||
| Method | Path |
|
||||
| :----- |:--------------------------------|
|
||||
| :----- | :------------------------------ |
|
||||
| `POST` | `/identity/mfa/method/totp/:id` |
|
||||
|
||||
### Parameters
|
||||
|
|
@ -65,7 +65,7 @@ This endpoint queries the MFA configuration of TOTP type for a given method
|
|||
ID.
|
||||
|
||||
| Method | Path |
|
||||
| :----- |:--------------------------------|
|
||||
| :----- | :------------------------------ |
|
||||
| `GET` | `/identity/mfa/method/totp/:id` |
|
||||
|
||||
### Parameters
|
||||
|
|
@ -104,10 +104,10 @@ $ curl \
|
|||
## Delete TOTP MFA Method
|
||||
|
||||
This endpoint deletes a TOTP MFA method. MFA methods can only be deleted if they're not currently in use
|
||||
by a [login enforcement](/api/secret/identity/mfa/login-enforcement).
|
||||
by a [login enforcement](/api-docs/secret/identity/mfa/login-enforcement).
|
||||
|
||||
| Method | Path |
|
||||
| :------- |:--------------------------------|
|
||||
| :------- | :------------------------------ |
|
||||
| `DELETE` | `/identity/mfa/method/totp/:id` |
|
||||
|
||||
### Parameters
|
||||
|
|
@ -129,7 +129,7 @@ $ curl \
|
|||
This endpoint lists TOTP MFA methods that are visible in the current namespace or in parent namespaces.
|
||||
|
||||
| Method | Path |
|
||||
|:-------|:--------------------------------|
|
||||
| :----- | :-------------------------- |
|
||||
| `LIST` | `/identity/mfa/method/totp` |
|
||||
|
||||
### Sample Request
|
||||
|
|
@ -162,7 +162,7 @@ doesn't exist already, using the configuration stored under the given MFA
|
|||
method ID.
|
||||
|
||||
| Method | Path |
|
||||
|:-------|:-------------------------------------|
|
||||
| :----- | :----------------------------------- |
|
||||
| `POST` | `/identity/mfa/method/totp/generate` |
|
||||
|
||||
### Parameters
|
||||
|
|
@ -205,7 +205,7 @@ API which stores the generated secret on the entity ID of the calling token,
|
|||
the `admin-generate` API stores the generated secret on the given entity ID.
|
||||
|
||||
| Method | Path |
|
||||
| :----- |:-------------------------------------------------|
|
||||
| :----- | :----------------------------------------- |
|
||||
| `POST` | `/identity/mfa/method/totp/admin-generate` |
|
||||
|
||||
### Parameters
|
||||
|
|
@ -255,7 +255,7 @@ and the `generate` or `admin-generate` APIs should be used to regenerate a new
|
|||
secret.
|
||||
|
||||
| Method | Path |
|
||||
| :----- |:------------------------------------------|
|
||||
| :----- | :---------------------------------------- |
|
||||
| `POST` | `/identity/mfa/method/totp/admin-destroy` |
|
||||
|
||||
### Parameters
|
||||
|
|
|
|||
|
|
@ -10,6 +10,6 @@ This backend can be run in one of two versions. Each of which have a distinct AP
|
|||
Choose the version below you are running. For more information on the KV secrets
|
||||
engine see the [Vault kv documentation](/docs/secrets/kv).
|
||||
|
||||
- [KV Version 1 API](/api/secret/kv/kv-v1)
|
||||
- [KV Version 1 API](/api-docs/secret/kv/kv-v1)
|
||||
|
||||
- [KV Version 2 API](/api/secret/kv/kv-v2)
|
||||
- [KV Version 2 API](/api-docs/secret/kv/kv-v2)
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ This endpoint retrieves the secret at the specified location. The metadata
|
|||
fields `created_time`, `deletion_time`, `destroyed`, and `version` are version
|
||||
specific. The `custom_metadata` field is part of the secret's key metadata and
|
||||
is included in the response whether or not the calling token has `read` access to
|
||||
the associated [metadata endpoint](/api/secret/kv/kv-v2#read-secret-metadata).
|
||||
the associated [metadata endpoint](/api-docs/secret/kv/kv-v2#read-secret-metadata).
|
||||
|
||||
| Method | Path |
|
||||
| :----- | :------------------------------------------- |
|
||||
|
|
|
|||
|
|
@ -188,7 +188,7 @@ updated attributes.
|
|||
|
||||
- `policies` `(string: "")` – Comma separated list of Nomad policies the token is going to be created against. These need to be created beforehand in Nomad.
|
||||
|
||||
- `global` `(bool: "false")` – Specifies if the token should be global, as defined in the [Nomad Documentation](https://www.nomadproject.io/guides/acl#acl-tokens).
|
||||
- `global` `(bool: "false")` – Specifies if the token should be global, as defined in the [Nomad Documentation](https://learn.hashicorp.com/collections/nomad/access-control#acl-tokens).
|
||||
|
||||
- `type` `(string: "client")` - Specifies the type of token to create when
|
||||
using this role. Valid values are `"client"` or `"management"`.
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@ with the `/rotate-role` endpoint.
|
|||
|
||||
Please see the [Terraform Cloud API
|
||||
Token documentation for more
|
||||
information](https://www.terraform.io/docs/cloud/users-teams-organizations/api-tokens.html).
|
||||
information](https://www.terraform.io/cloud-docs/users-teams-organizations/api-tokens).
|
||||
|
||||
| Method | Path |
|
||||
| :----- | :---------------------- |
|
||||
|
|
|
|||
|
|
@ -1606,4 +1606,4 @@ $ curl \
|
|||
},
|
||||
```
|
||||
|
||||
[sys-plugin-reload-backend]: /api/system/plugins-reload-backend#reload-plugins
|
||||
[sys-plugin-reload-backend]: /api-docs/system/plugins-reload-backend#reload-plugins
|
||||
|
|
|
|||
|
|
@ -13,13 +13,13 @@ behaviors in Vault Enterprise MFA.
|
|||
|
||||
## Supported MFA types
|
||||
|
||||
- [TOTP](/api/system/mfa/totp)
|
||||
- [TOTP](/api-docs/system/mfa/totp)
|
||||
|
||||
- [Okta](/api/system/mfa/okta)
|
||||
- [Okta](/api-docs/system/mfa/okta)
|
||||
|
||||
- [Duo](/api/system/mfa/duo)
|
||||
- [Duo](/api-docs/system/mfa/duo)
|
||||
|
||||
- [PingID](/api/system/mfa/pingid)
|
||||
- [PingID](/api-docs/system/mfa/pingid)
|
||||
|
||||
## Step-up Enterprise MFA
|
||||
|
||||
|
|
|
|||
|
|
@ -199,7 +199,7 @@ $ curl \
|
|||
|
||||
This endpoint disables the mount point specified in the URL.
|
||||
|
||||
| Method | Path |
|
||||
| Method | Path | |
|
||||
| :------- | :------------------ | ------------------ |
|
||||
| `DELETE` | `/sys/mounts/:path` | `204 (empty body)` |
|
||||
|
||||
|
|
@ -224,7 +224,7 @@ simple as increasing the timeout (in the event of timeout errors).
|
|||
|
||||
For recovery situations where the secret was manually removed from the
|
||||
secrets backing service, one can force a secrets engine disable in Vault by
|
||||
performing a [force revoke](https://www.vaultproject.io/api/system/leases#revoke-force)
|
||||
performing a [force revoke](/api-docs/system/leases)
|
||||
on the mount prefix, followed by a secrets disable when that completes.
|
||||
If the underlying secrets were not manually cleaned up, this method might result
|
||||
in dangling credentials. This is meant for extreme circumstances.
|
||||
|
|
@ -237,7 +237,6 @@ This endpoint returns the configuration of a specific secret engine.
|
|||
| :----- | :------------------ |
|
||||
| `GET` | `/sys/mounts/:path` |
|
||||
|
||||
|
||||
### Sample Request
|
||||
|
||||
```shell-session
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ cluster by default, and to performance/DR secondaries for Vault Enterprise clust
|
|||
Before enabling an audit device, ensure that all nodes within the cluster(s)
|
||||
will be able to successfully log to the audit device to avoid Vault being
|
||||
blocked from serving requests.
|
||||
An audit device can be limited to only within the node's cluster with the [`local`](/api/system/audit#local) parameter.
|
||||
An audit device can be limited to only within the node's cluster with the [`local`](/api-docs/system/audit#local) parameter.
|
||||
|
||||
When an audit device is disabled, it will stop receiving logs immediately.
|
||||
The existing logs that it did store are untouched.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ workloads, user-assigned identities are recommended.
|
|||
## Prerequisites:
|
||||
|
||||
The following documentation assumes that the method has been
|
||||
[mounted](/docs/plugin) at `auth/azure`.
|
||||
[mounted](/docs/plugins) at `auth/azure`.
|
||||
|
||||
- A configured [Azure AD application](https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-integrating-applications) which is used as the resource for generating MSI access tokens.
|
||||
- Client credentials (shared secret) for accessing the Azure Resource Manager with read access to compute endpoints. See [Azure AD Service to Service Client Credentials](https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-service-to-service)
|
||||
|
|
|
|||
|
|
@ -140,15 +140,20 @@ EOF
|
|||
```
|
||||
|
||||
- Monitor Vault's log output. Important information about OIDC validation failures will be emitted.
|
||||
|
||||
- Ensure Redirect URIs are correct in Vault and on the provider. They need to match exactly. Check:
|
||||
http/https, 127.0.0.1/localhost, port numbers, whether trailing slashes are present.
|
||||
|
||||
- Start simple. The only claim configuration a role requires is `user_claim`. After authentication is
|
||||
known to work, you can add additional claims bindings and metadata copying.
|
||||
|
||||
- `bound_audiences` is optional for OIDC roles and typically not required. OIDC providers will use
|
||||
the client_id as the audience and OIDC validation expects this.
|
||||
|
||||
- Check your provider for what scopes are required in order to receive all
|
||||
of the information you need. The scopes "profile" and "groups" often need to be
|
||||
requested, and can be added by setting `oidc_scopes="profile,groups"` on the role.
|
||||
|
||||
- If you're seeing claim-related errors in logs, review the provider's docs very carefully to see
|
||||
how they're naming and structuring their claims. Depending on the provider, you may be able to
|
||||
construct a simple `curl` implicit grant request to obtain a JWT that you can inspect. An example
|
||||
|
|
@ -161,6 +166,7 @@ EOF
|
|||
be helpful when debugging provider setup and verifying that the received claims are what you expect.
|
||||
Since claims data is logged verbatim and may contain sensitive information, this option should not be
|
||||
used in production.
|
||||
|
||||
- Azure requires some additional configuration when a user is a member of more
|
||||
than 200 groups, described in [Azure-specific handling
|
||||
configuration](/docs/auth/jwt/oidc-providers/azuread#optional-azure-specific-configuration)
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ An unseal key may be provided directly on the command line as an argument to the
|
|||
command. If key is specified as "-", the command will read from stdin. If a TTY
|
||||
is available, the command will prompt for text.
|
||||
|
||||
Please see the [generate root guide](/guides/operations/generate-root) for
|
||||
Please see the [generate root guide](https://learn.hashicorp.com/tutorials/vault/generate-root) for
|
||||
step-by-step instructions.
|
||||
|
||||
## Examples
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ An unseal key may be provided directly on the command line as an argument to the
|
|||
command. If key is specified as "-", the command will read from stdin. If a TTY
|
||||
is available, the command will prompt for text.
|
||||
|
||||
Please see the [rotating and rekeying](/guides/operations/rekeying-and-rotating) for
|
||||
Please see the [rotating and rekeying](https://learn.hashicorp.com/tutorials/vault/rekeying-and-rotating) for
|
||||
step-by-step instructions.
|
||||
|
||||
## Examples
|
||||
|
|
@ -154,7 +154,7 @@ flags](/docs/commands) included on all commands.
|
|||
- `-backup` `(bool: false)` - Store a backup of the current PGP encrypted unseal
|
||||
keys in Vault's core. The encrypted values can be recovered in the event of
|
||||
failure or discarded after success. See the -backup-delete and
|
||||
-backup-retrieve options for more information. This option only applies when
|
||||
\-backup-retrieve options for more information. This option only applies when
|
||||
the existing unseal keys were PGP encrypted.
|
||||
|
||||
- `-backup-delete` `(bool: false)` - Delete any stored backup unseal keys.
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ Although client counts have been available via the usage metrics UI since Vault
|
|||
- Changed the non-entity token computation logic to deduplicate non-entity tokens, reducing the overall client count. Moving forward, non-entity tokens, where there is no entity to map tokens, Vault will use the contents of the token to generate a unique client identifier based on the namespace ID and associated policies. The clientID will prevent duplicating the same token in the overall client count when the token is used again during the billing period.
|
||||
- Changed the tracking of non-entity tokens to complete on access instead of creation.
|
||||
- Changed the computation logic to not include root tokens in the client count aggregate.
|
||||
- Changed the local auth mount computation logic such that local auth mounts count towards clients but not as non-entity tokens. Prior to Vault 1.9, local auth mounts counted towards non-entity tokens. Refer to the [What is a Client?](docs/concepts/client-count) documentation to learn more.
|
||||
- Changed the local auth mount computation logic such that local auth mounts count towards clients but not as non-entity tokens. Prior to Vault 1.9, local auth mounts counted towards non-entity tokens. Refer to the [What is a Client?](/docs/concepts/client-count) documentation to learn more.
|
||||
- Added ability to display clients per namespace (top 10, descending order) in the UI and export data for all namespaces. Prior to Vault 1.9, you could not view view the split of clients per namespace on the UI, nor could you export this data via the UI.
|
||||
- Added ability to display clients earlier than a month (within ten minutes of enabling the feature) in the UI. Prior to Vault 1.9, after enabling the counting of clients, you had to wait for a month to view the client aggregates in the UI.
|
||||
- Changed functionality to disallow creating two aliases from the same auth mount under a single entity. For more information, refer to the question [Starting in Vault 1.9, Vault does not allow creating two aliases from the same auth mount under a single entity. What changed and how does this impact client counting?](#q-starting-in-vault-1-9-vault-does-not-allow-creating-two-aliases-from-the-same-auth-mount-under-a-single-entity-what-changed-and-how-does-this-impact-client-counting)
|
||||
|
|
@ -257,7 +257,7 @@ However, creating a new token across a parent/child namespace boundary could res
|
|||
|
||||
### Q: How does the Nomad Vault integration affect client counts?
|
||||
|
||||
The [Nomad Vault integration](https://www.nomadproject.io/docs/integrations/vault-integration#token-role-based-integration) uses [token roles](https://www.nomadproject.io/docs/integrations/vault-integration#vault-token-role-configuration). A single token role creates tokens for many Nomad jobs. If no [explicit identity aliases](/api-docs/auth/token#entity_alias) are provided (which is not currently supported in the integration), this would create a non-entity token for every running instance of a Nomad job.
|
||||
The [Nomad Vault integration](https://www.nomadproject.io/docs/integrations/vault-integration#token-role-based-integration) uses [token roles](https://www.nomadproject.io/docs/integrations/vault-integration#vault-token-role-configuration#vault-token-role-configuration). A single token role creates tokens for many Nomad jobs. If no [explicit identity aliases](/api-docs/auth/token#entity_alias) are provided (which is not currently supported in the integration), this would create a non-entity token for every running instance of a Nomad job.
|
||||
Prior to Vault 1.9, the Nomad Vault integration caused duplicate clients, resulting in an elevated client count. Post Vault 1.9, with the introduction of the deduplication logic, the number of clients created by the integration is reduced. For more information on improvements made to client count in Vault 1.9, refer to the question [Which version of Vault reflects the most accurate count of clients with Vault?](#q-which-vault-version-reflects-the-most-accurate-client-counts).
|
||||
|
||||
### Q: Starting in Vault 1.7, Vault does not allow creating two aliases from the same auth mount under a single entity. What changed and how does this impact client counting?
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ flags or by specifying a configuration file):
|
|||
|
||||
The dev server should be used for experimentation with Vault features, such
|
||||
as different auth methods, secrets engines, audit devices, etc.
|
||||
If you're new to Vault, you may want to pick up with [Your First Secret](/intro/getting-started/first-secret) in our getting started guide.
|
||||
If you're new to Vault, you may want to pick up with [Your First Secret](https://learn.hashicorp.com/vault/getting-started/first-secret) in our getting started guide.
|
||||
|
||||
In addition to experimentation, the dev server is very easy to automate
|
||||
for development environments.
|
||||
|
|
|
|||
|
|
@ -67,7 +67,6 @@ behavior. Autopilot gets initialized with the following default values.
|
|||
|
||||
- `server_stabilization_time` - `10s`
|
||||
|
||||
|
||||
~> **Note**: Autopilot in Vault does similar things to what autopilot does in
|
||||
[Consul](https://www.consul.io/). However, the configuration in these 2 systems
|
||||
differ in terms of default values and thresholds; some additional parameters
|
||||
|
|
@ -110,4 +109,3 @@ Refer to the following tutorials to learn more.
|
|||
- [Integrated Storage Autopilot](https://learn.hashicorp.com/tutorials/vault/raft-autopilot)
|
||||
- [Fault Tolerance with Redundancy Zones](https://learn.hashicorp.com/tutorials/vault/raft-redundancy-zones)
|
||||
- [Automate Upgrades with Vault Enterprise](https://learn.hashicorp.com/tutorials/vault/raft-upgrade-automation)
|
||||
|
||||
|
|
|
|||
|
|
@ -181,10 +181,10 @@ also match `"secret/foobar"`. Specifically, when there are potentially multiple
|
|||
matching policy paths, `P1` and `P2`, the following matching criteria is applied:
|
||||
|
||||
1. If the first wildcard (`+`) or glob (`*`) occurs earlier in `P1`, `P1` is lower priority
|
||||
2. If `P1` ends in `*` and `P2` doesn't, `P1` is lower priority
|
||||
3. If `P1` has more `+` (wildcard) segments, `P1` is lower priority
|
||||
4. If `P1` is shorter, it is lower priority
|
||||
5. If `P1` is smaller lexicographically, it is lower priority
|
||||
1. If `P1` ends in `*` and `P2` doesn't, `P1` is lower priority
|
||||
1. If `P1` has more `+` (wildcard) segments, `P1` is lower priority
|
||||
1. If `P1` is shorter, it is lower priority
|
||||
1. If `P1` is smaller lexicographically, it is lower priority
|
||||
|
||||
For example, given the two paths, `"secret/*"` and `"secret/+/+/foo/*"`, the first
|
||||
wildcard appears in the same place, both end in `*` and the latter has two wildcard
|
||||
|
|
@ -264,7 +264,7 @@ injected, and currently the `path` keys in policies allow injection.
|
|||
### Parameters
|
||||
|
||||
| Name | Description |
|
||||
| :------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------- |
|
||||
| :------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------ |
|
||||
| `identity.entity.id` | The entity's ID |
|
||||
| `identity.entity.name` | The entity's name |
|
||||
| `identity.entity.metadata.<metadata key>` | Metadata associated with the entity for the given key |
|
||||
|
|
@ -614,8 +614,8 @@ $ curl \
|
|||
|
||||
For more information, please read:
|
||||
|
||||
- [Production Hardening](/guides/operations/production)
|
||||
- [Generating a Root Token](/guides/operations/generate-root)
|
||||
- [Production Hardening](https://learn.hashicorp.com/tutorials/vault/production-hardening)
|
||||
- [Generating a Root Token](https://learn.hashicorp.com/tutorials/vault/generate-root)
|
||||
|
||||
## Managing Policies
|
||||
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ components of that plan.
|
|||
Backups and restores are ideally performed while Vault is offline. If offline
|
||||
backups are not feasible, we recommend using a storage backend that supports
|
||||
atomic snapshots (such as
|
||||
[Consul](https://www.consul.io/docs/commands/snapshot.html) or [Integrated
|
||||
[Consul](https://www.consul.io/commands/snapshot) or [Integrated
|
||||
Storage](/docs/commands/operator/raft#snapshot)).
|
||||
|
||||
~> If your storage backend does not support atomic snapshots, we recommend only
|
||||
|
|
@ -93,7 +93,7 @@ other storage backends, follow the documentation of that backend for taking and
|
|||
restoring backups.
|
||||
|
||||
- Integrated Storage [snapshots](/docs/commands/operator/raft#snapshot)
|
||||
- Consul [snapshots](https://www.consul.io/docs/commands/snapshot.html)
|
||||
- Consul [snapshots](https://www.consul.io/commands/snapshot)
|
||||
|
||||
#### Backing up Multiple Clusters
|
||||
|
||||
|
|
|
|||
|
|
@ -60,9 +60,9 @@ there are only three ways to create root tokens:
|
|||
|
||||
1. The initial root token generated at `vault operator init` time -- this token has no
|
||||
expiration
|
||||
2. By using another root token; a root token with an expiration cannot create a
|
||||
1. By using another root token; a root token with an expiration cannot create a
|
||||
root token that never expires
|
||||
3. By using `vault operator generate-root` ([example](/guides/operations/generate-root))
|
||||
1. By using `vault operator generate-root` ([example](https://learn.hashicorp.com/tutorials/vault/generate-root))
|
||||
with the permission of a quorum of unseal key holders
|
||||
|
||||
Root tokens are useful in development but should be extremely carefully guarded
|
||||
|
|
@ -91,10 +91,10 @@ Often this behavior is not desired, so users with appropriate access can create
|
|||
token tree. These orphan tokens can be created:
|
||||
|
||||
1. Via `write` access to the `auth/token/create-orphan` endpoint
|
||||
2. By having `sudo` or `root` access to the `auth/token/create`
|
||||
1. By having `sudo` or `root` access to the `auth/token/create`
|
||||
and setting the `no_parent` parameter to `true`
|
||||
3. Via token store roles
|
||||
4. By logging in with any other (non-`token`) auth method
|
||||
1. Via token store roles
|
||||
1. By logging in with any other (non-`token`) auth method
|
||||
|
||||
Users with appropriate permissions can also use the `auth/token/revoke-orphan`
|
||||
endpoint, which revokes the given token but rather than revoke the rest of the
|
||||
|
|
@ -108,9 +108,9 @@ accessor is a value that acts as a reference to a token and can only be used to
|
|||
perform limited actions:
|
||||
|
||||
1. Look up a token's properties (not including the actual token ID)
|
||||
2. Look up a token's capabilities on a path
|
||||
3. Renew the token
|
||||
4. Revoke the token
|
||||
1. Look up a token's capabilities on a path
|
||||
1. Renew the token
|
||||
1. Revoke the token
|
||||
|
||||
The token _making the call_, _not_ the token associated with the accessor, must
|
||||
have appropriate permissions for these functions.
|
||||
|
|
@ -159,11 +159,11 @@ 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
|
||||
1. The max TTL set on a mount using [mount
|
||||
tuning](/api-docs/system/mounts). 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 auth method that issued the token. This
|
||||
1. A value suggested by the auth method that issued the token. This
|
||||
might be configured on a per-role, per-group, or per-user basis. This value
|
||||
is allowed to be less than the mount max TTL (or, if not set, the system max
|
||||
TTL), but it is not allowed to be longer.
|
||||
|
|
@ -194,8 +194,8 @@ can be created in a few ways:
|
|||
|
||||
1. By having `sudo` capability or a `root` token with the `auth/token/create`
|
||||
endpoint
|
||||
2. By using token store roles
|
||||
3. By using an auth method that supports issuing these, such as
|
||||
1. By using token store roles
|
||||
1. By using an auth method that supports issuing these, such as
|
||||
AppRole
|
||||
|
||||
At issue time, the TTL of a periodic token will be equal to the configured
|
||||
|
|
|
|||
|
|
@ -238,4 +238,4 @@ The following parameters are only used with Vault Enterprise
|
|||
[telemetry]: /docs/configuration/telemetry
|
||||
[sentinel]: /docs/configuration/sentinel
|
||||
[high-availability]: /docs/concepts/ha
|
||||
[plugins]: /docs/plugin
|
||||
[plugins]: /docs/plugins
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ The sentinel stanza currently supports only one parameter, `additional_enabled_m
|
|||
- `additional_enabled_modules` `(string array: [])`` - This parameter specifies a list of imports (modules)
|
||||
to allow in Sentinel policies.
|
||||
|
||||
Vault currently enables all of Sentinel's [standard imports](https://docs.hashicorp.com/sentinel/imports/)
|
||||
Vault currently enables all of Sentinel's [standard imports](https://docs.hashicorp.com/sentinel/imports)
|
||||
except the "http" import, which has performance and security implications. In the future, if any new Sentinel
|
||||
imports are not automatically enabled by Vault, users could enable them in this stanza.
|
||||
Note that this setting cannot be used to load custom import plugins.
|
||||
|
|
|
|||
|
|
@ -101,7 +101,7 @@ connection. You can read more about encrypting Consul connections on the
|
|||
|
||||
- `tls_key_file` `(string: "")` – Specifies the path to the private key for
|
||||
Consul communication. This should be set according to the
|
||||
[`key_file`](https://www.consul.io/docs/agent/options.html#key_file) setting
|
||||
[`key_file`](https://www.consul.io/docs/agent/config/config-files#key_file) setting
|
||||
in Consul.
|
||||
|
||||
- `tls_min_version` `(string: "tls12")` – Specifies the minimum TLS version to
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ environment variable will take precedence over values in the configuration
|
|||
file.
|
||||
|
||||
[consul]: https://www.consul.io/
|
||||
[consul-discovery]: https://www.consul.io/discovery.html
|
||||
[consul-discovery]: https://www.consul.io/
|
||||
[storage-backend]: /docs/configuration/storage
|
||||
[consul-backend]: /docs/configuration/storage/consul
|
||||
[raft-backend]: /docs/configuration/storage/raft
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ Consul.
|
|||
| Data location | Data is on disk. | All data is in memory. |
|
||||
| System requirements | [System requirements](https://learn.hashicorp.com/tutorials/vault/raft-reference-architecture#system-requirements) | [System requirements](https://learn.hashicorp.com/tutorials/vault/reference-architecture#hardware-sizing-for-vault-servers) |
|
||||
| Snapshots | Normal data backup strategy of your organization. | More frequent snapshots are necessary since data is in memory. |
|
||||
| Max message size | 1 MiB (Configurable using the [`max_entry_size`](/docs/configuration/storage/raft#max_entry_size) parameter) | 512 KiB (Configurable using the [`kv_max_value_size`](https://www.consul.io/docs/agent/options#kv_max_value_size) parameter) |
|
||||
| Max message size | 1 MiB (Configurable using the [`max_entry_size`](/docs/configuration/storage/raft#max_entry_size) parameter) | 512 KiB (Configurable using the [`kv_max_value_size`](https://www.consul.io/docs/agent/config/config-files#kv_max_value_size) parameter) |
|
||||
|
||||
If you have a Vault cluster using Consul as its storage backend and wish to
|
||||
migrate to Integrated Storage, read the following tutorials:
|
||||
|
|
|
|||
|
|
@ -125,7 +125,7 @@ It is not necessary to remove the stored license entry. That will occur automati
|
|||
|
||||
1. Use the command `vault license get -signed` to retrieve the license from storage of your running cluster.
|
||||
2. Put the license on disk
|
||||
3. Configure license auto-loading by specifying the [`license_path`](/docs/configuration#license_path) config option or setting the [`VAULT_LICENSE`](/docs/commands#vault_license) or [`VAULT_LICENSE_PATH`](o/docs/commands#vault_license_path) environment variable.
|
||||
3. Configure license auto-loading by specifying the [`license_path`](/docs/configuration#license_path) config option or setting the [`VAULT_LICENSE`](/docs/commands#vault_license) or [`VAULT_LICENSE_PATH`](/docs/commands#vault_license_path) environment variable.
|
||||
|
||||
### Q: What is the path for customers who want to downgrade/rollback from Vault 1.11 or later (auto-loaded license mandatory) to a pre-Vault 1.11 (auto-loading not mandatory, stored license supported)?
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ This FAQ section contains frequently asked questions about the Server Side Consi
|
|||
|
||||
~> **Note**: This features requires Vault Enterprise.
|
||||
|
||||
Vault has an [eventual consistency](docs/enterprise/consistency) model where only the leader can write to Vault's storage. When using performance standbys with Integrated Storage, there are sequences of operations that don't always yield read-after-write consistency, which may pose a challenge for some use cases.
|
||||
Vault has an [eventual consistency](/docs/enterprise/consistency) model where only the leader can write to Vault's storage. When using performance standbys with Integrated Storage, there are sequences of operations that don't always yield read-after-write consistency, which may pose a challenge for some use cases.
|
||||
|
||||
Several client-based mitigations were added in Vault version 1.7, which depended on some modifications to clients (provide the appropriate response header per request) so they can specify state. This may not be possible to do in some environments.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,4 +5,4 @@ page_title: Documentation
|
|||
|
||||
# Documentation
|
||||
|
||||
Welcome to the Vault documentation! This documentation is more of a reference guide for all available features and options of Vault. If you're just getting started with Vault, please start with the [introduction](/docs/what-is-vault) instead, and work your way up to the [Getting Started](/intro/getting-started/install) guide.
|
||||
Welcome to the Vault documentation! This documentation is more of a reference guide for all available features and options of Vault. If you're just getting started with Vault, please start with the [introduction](/docs/what-is-vault) instead, and work your way up to the [Getting Started](https://learn.hashicorp.com/tutorials/vault/getting-started-install) guide.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ by that backend.
|
|||
|
||||
For the Consul storage backend, the default limit imposed by Consul is
|
||||
512 KiB. This may be configured via Consul’s
|
||||
[`kv_max_value_size`](https://www.consul.io/docs/agent/options#kv_max_value_size) parameter, introduced in version 1.5.3.
|
||||
[`kv_max_value_size`](https://www.consul.io/docs/agent/config/config-files#kv_max_value_size) parameter, introduced in version 1.5.3.
|
||||
|
||||
For the integrated storage backend, the default limit (introduced in
|
||||
Vault 1.5.0) is 1 MiB. This may be configured via `max_entry_size` in
|
||||
|
|
|
|||
|
|
@ -501,7 +501,7 @@ indicate flapping leadership.
|
|||
|
||||
## Integrated Storage (Raft) Automated Snapshots
|
||||
|
||||
These metrics related to the Enterprise feature [Raft Automated Snapshots](/docs/enterprise/automated-raft-snapshots).
|
||||
These metrics related to the Enterprise feature [Raft Automated Snapshots](/docs/enterprise/automated-integrated-storage-snapshots).
|
||||
|
||||
| Metric | Description | Unit | Type |
|
||||
| :------------------------------------------ | :-------------------------------------------------------------------------------------------- | :--------- | :------ |
|
||||
|
|
@ -531,25 +531,47 @@ These metrics related to the Enterprise feature [Raft Automated Snapshots](/docs
|
|||
| `snapshot_config_name` | For automated snapshots, the name of the configuration | `config1` |
|
||||
|
||||
[secrets-engines]: /docs/secrets
|
||||
|
||||
[storage-backends]: /docs/configuration/storage
|
||||
|
||||
[telemetry-stanza]: /docs/configuration/telemetry
|
||||
|
||||
[cubbyhole-secrets-engine]: /docs/secrets/cubbyhole
|
||||
|
||||
[kv-secrets-engine]: /docs/secrets/kv
|
||||
|
||||
[ldap-auth-backend]: /docs/auth/ldap
|
||||
|
||||
[token-auth-backend]: /docs/auth/token
|
||||
|
||||
[azure-storage-backend]: /docs/configuration/storage/azure
|
||||
|
||||
[cassandra-storage-backend]: /docs/configuration/storage/cassandra
|
||||
|
||||
[cockroachdb-storage-backend]: /docs/configuration/storage/cockroachdb
|
||||
|
||||
[consul-storage-backend]: /docs/configuration/storage/consul
|
||||
|
||||
[couchdb-storage-backend]: /docs/configuration/storage/couchdb
|
||||
|
||||
[dynamodb-storage-backend]: /docs/configuration/storage/dynamodb
|
||||
|
||||
[etcd-storage-backend]: /docs/configuration/storage/etcd
|
||||
|
||||
[gcs-storage-backend]: /docs/configuration/storage/google-cloud-storage
|
||||
|
||||
[spanner-storage-backend]: /docs/configuration/storage/google-cloud-spanner
|
||||
|
||||
[mssql-storage-backend]: /docs/configuration/storage/mssql
|
||||
|
||||
[mysql-storage-backend]: /docs/configuration/storage/mysql
|
||||
|
||||
[postgresql-storage-backend]: /docs/configuration/storage/postgresql
|
||||
|
||||
[s3-storage-backend]: /docs/configuration/storage/s3
|
||||
|
||||
[swift-storage-backend]: /docs/configuration/storage/swift
|
||||
|
||||
[zookeeper-storage-backend]: /docs/configuration/storage/zookeeper
|
||||
|
||||
[integrated-storage]: /docs/configuration/storage/raft
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Vault is an Identity-based security solution that leverages trusted sources of i
|
|||
|
||||
Vault has a secure [plugin](/docs/plugins) architecture. Vault’s plugins are completely separate, standalone applications that Vault executes and communicates with over RPC. This means the plugin process does not share the same memory space as Vault and therefore can only access the interfaces and arguments given to it.
|
||||
|
||||
Vault plugins can be built-in and bundled with the Vault binary, or be external that has to be manually mounted. Built-in plugins are developed by HashiCorp, while external plugins can be developed by HashiCorp, technology partners, or the community. There is a curated collection of all plugins, both built-in and external, located on the [Plugin Portal](/docs/plugin-portal).
|
||||
Vault plugins can be built-in and bundled with the Vault binary, or be external that has to be manually mounted. Built-in plugins are developed by HashiCorp, while external plugins can be developed by HashiCorp, technology partners, or the community. There is a curated collection of all plugins, both built-in and external, located on the [Plugin Portal](/docs/plugins/plugin-portal).
|
||||
|
||||
The diagram below depicts the key Vault integration categories and types.
|
||||
|
||||
|
|
@ -32,7 +32,7 @@ Main Vault categories for partners to integrate with include:
|
|||
|
||||
HSM (Hardware Security Module) are specific types of runtime integrations and provide an added level of security and compliance. The HSM communicates with Vault using the PKCS#11 protocol, thereby resulting in the integration to primarily involve verification of the operation of the functionality. You can find more information about Vault's HSM support [here](/docs/enterprise/hsm).
|
||||
|
||||
-> **Note:** Integrations related Vault’s [storage](/docs/concepts/storage) backend, [auto auth](/docs/agent/autoauth), and [auto unseal](/docs/concepts/seal#auto-unseal) functionality are not encouraged. Please reach out to [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com) for any questions related to this.
|
||||
\-> **Note:** Integrations related Vault’s [storage](/docs/concepts/storage) backend, [auto auth](/docs/agent/autoauth), and [auto unseal](/docs/concepts/seal#auto-unseal) functionality are not encouraged. Please reach out to [technologypartners@hashicorp.com](mailto:technologypartners@hashicorp.com) for any questions related to this.
|
||||
|
||||
**Audit/Monitoring & Compliance**: Audit/Monitoring and Compliance are components in Vault that keep a detailed log of all requests and responses to Vault. Because every operation with Vault is an API request/response, the audit log contains every authenticated interaction with Vault, including errors. Vault supports multiple audit devices to support your business use case. You can find more information about Vault Audit Devices [here](/docs/audit/).
|
||||
|
||||
|
|
@ -68,11 +68,11 @@ The Vault integration development process is divided into six steps. By followin
|
|||
|
||||
|
||||
1. Engage: Initial contact between vendor and HashiCorp
|
||||
2. Enable: Information and articles to aid with the development of the integration
|
||||
3. Develop and Test: Integration development and testing process
|
||||
4. Review: HashiCorp verification of integration (iterative process)
|
||||
5. Release: Verified integration made available and listed on the HashiCorp website once the HashiCorp technology partnership agreement has been executed
|
||||
6. Support: Ongoing maintenance and support of the integration by the partner.
|
||||
1. Enable: Information and articles to aid with the development of the integration
|
||||
1. Develop and Test: Integration development and testing process
|
||||
1. Review: HashiCorp verification of integration (iterative process)
|
||||
1. Release: Verified integration made available and listed on the HashiCorp website once the HashiCorp technology partnership agreement has been executed
|
||||
1. Support: Ongoing maintenance and support of the integration by the partner.
|
||||
|
||||
### 1. Engage
|
||||
|
||||
|
|
@ -125,7 +125,7 @@ Please remember that all integrations should have the appropriate documentation
|
|||
|
||||
**HCP Vault**
|
||||
|
||||
The process to spin up a testing instance of HCP Vault is very [straightforward](https://learn.hashicorp.com/tutorials/cloud/get-started-vault). HCP has been designed as a turn-key managed service so configuration is minimal. Furthermore, HashiCorp provides all new users an initial credit which lasts for a couple of months when using the [development](https://cloud.hashicorp.com/pricing/vault) cluster. Used in conjunction with AWS free tier resources, there should be no cost beyond the time spent by the designated tester.
|
||||
The process to spin up a testing instance of HCP Vault is very [straightforward](https://learn.hashicorp.com/tutorials/cloud/get-started-vault). HCP has been designed as a turn-key managed service so configuration is minimal. Furthermore, HashiCorp provides all new users an initial credit which lasts for a couple of months when using the [development](https://cloud.hashicorp.com/products/vault/pricing) cluster. Used in conjunction with AWS free tier resources, there should be no cost beyond the time spent by the designated tester.
|
||||
|
||||
There are a couple of items to consider when determining if the integration will work with HCP Vault.
|
||||
|
||||
|
|
@ -150,7 +150,7 @@ Once the integration has been verified, the partner is requested to sign the Has
|
|||
|
||||
At this stage, it is expected that the integration is fully complete, the necessary documentation has been written, and HashiCorp has reviewed the integration.
|
||||
|
||||
For Auth or Secret Engine plugins specifically, once the plugin has been validated by HashiCorp, it is recommended the plugin be hosted on Github so it can more easily be downloaded and installed within Vault. We also encourage partners to list their plugin on the [Vault Plugin Portal](/docs/plugin-portal). This is in addition to the listing of the plugin on the technology partners’ dedicated HashiCorp partner page. To have the plugin listed on the portal page, please do a pull request via the “edit in GitHub” link on the bottom of the page and add the plugin in the partner section.
|
||||
For Auth or Secret Engine plugins specifically, once the plugin has been validated by HashiCorp, it is recommended the plugin be hosted on Github so it can more easily be downloaded and installed within Vault. We also encourage partners to list their plugin on the [Vault Plugin Portal](/docs/plugins/plugin-portal). This is in addition to the listing of the plugin on the technology partners’ dedicated HashiCorp partner page. To have the plugin listed on the portal page, please do a pull request via the “edit in GitHub” link on the bottom of the page and add the plugin in the partner section.
|
||||
|
||||
For HCP Vault validations, the partner will be issued an HCP Vault Verified badge and will have this displayed on their partner page.
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ properly installed and configured with your Kubernetes cluster.
|
|||
|
||||
Helm must be installed and configured on your machine. Please refer to the [Helm
|
||||
documentation](https://helm.sh/) or the [Vault Installation to Minikube via
|
||||
Helm](https://learn.hashicorp.com/tutorials/vault/kubernetes-minikube) tutorial.
|
||||
Helm](https://learn.hashicorp.com/tutorials/vault/kubernetes-minikube-consul) tutorial.
|
||||
|
||||
To use the Helm chart, add the Hashicorp helm repository and check that you have
|
||||
access to the chart:
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ resource "helm_release" "vault" {
|
|||
</CodeBlockConfig>
|
||||
</CodeTabs>
|
||||
|
||||
The values file can also be used directly in the Terraform configuration with the [`values` directive](https://registry.terraform.io/providers/hashicorp/helm/latest/docs/resources/release#values).
|
||||
The values file can also be used directly in the Terraform configuration with the [`values` directive](https://registry.terraform.io/providers/hashicorp/helm/latest/docs/resources/release#values#values).
|
||||
|
||||
## Further Examples
|
||||
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ Any external database plugins that want to adopt multiplexing support will have
|
|||
|
||||
### Consul Secrets Engine enhancements
|
||||
|
||||
Consul has supported [namespace](https://www.consul.io/docs/enterprise/namespaces), [admin partitions](https://www.consul.io/docs/enterprise/admin-partitions) and [ACL roles](https://www.consul.io/commands/acl/role) for some time now. In this release we have added enhancements to the Consul Secrets engine to support [namespace]() awareness and add admin partition and role support for Consul ACL tokens. This significantly simplifies the integrations for customers who want to achieve a zero trust security posture with both Vault and Consul.
|
||||
Consul has supported [namespace](https://www.consul.io/docs/enterprise/namespaces), [admin partitions](https://www.consul.io/docs/enterprise/admin-partitions) and [ACL roles](https://www.consul.io/commands/acl/role) for some time now. In this release we have added enhancements to the Consul Secrets engine to support [namespace](<>) awareness and add admin partition and role support for Consul ACL tokens. This significantly simplifies the integrations for customers who want to achieve a zero trust security posture with both Vault and Consul.
|
||||
|
||||
### Using sessionStorage instead of localStorage for the Vault UI
|
||||
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ This [feature](/docs/concepts/namespace-api-lock) allows namespace administrator
|
|||
|
||||
### Vault Terraform Provider v3
|
||||
|
||||
We have upgraded the [Vault Terraform Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) to the latest version of the [Terraform Plugin SDKv2](https://www.terraform.io/docs/extend/sdkv2-intro.html) to leverage new features.
|
||||
We have upgraded the [Vault Terraform Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) to the latest version of the [Terraform Plugin SDKv2](https://www.terraform.io/plugin/sdkv2) to leverage new features.
|
||||
|
||||
### Azure Secrets Engine
|
||||
|
||||
|
|
@ -110,7 +110,7 @@ The following section details breaking changes introduced in Vault 1.9.
|
|||
### Removal of HTTP request counters
|
||||
|
||||
In Vault 1.9, the [internal HTTP Request count API](https://www.vaultproject.io/api-docs/system/internal-counters#http-requests) was removed from the product. Calls to the endpoint will result in a **404 error** with a message stating that functionality on this path has been removed.
|
||||
Please refer to the [upgrade guide](/docs/upgrading/upgrade-to-1.9.0) for more information.
|
||||
Please refer to the [upgrade guide](/docs/upgrading/upgrade-to-1.9.x) for more information.
|
||||
|
||||
As called out in the documentation, Vault does not make backwards compatible guarantees on internal APIs (those prefaced with `sys/internal`). They are subject to change and may disappear without notice.
|
||||
|
||||
|
|
|
|||
|
|
@ -197,4 +197,4 @@ The Consul secrets engine has a full HTTP API. Please see the
|
|||
[Consul secrets engine API](/api-docs/secret/consul) for more
|
||||
details.
|
||||
|
||||
[consul-mgmt-token]: https://www.consul.io/docs/agent/http/acl.html#acl_create
|
||||
[consul-mgmt-token]: https://www.consul.io/api-docs/acl#acl_create
|
||||
|
|
|
|||
|
|
@ -177,7 +177,7 @@ the proper permission, it can generate credentials.
|
|||
|
||||
## API
|
||||
|
||||
The full list of configurable options can be seen in the [Elasticsearch database plugin API](/api-docs/secret/databases/elasticdb.html) page.
|
||||
The full list of configurable options can be seen in the [Elasticsearch database plugin API](/api-docs/secret/databases/elasticdb) page.
|
||||
|
||||
For more information on the database secrets engine's HTTP API please see the
|
||||
[Database secrets engine API](/api-docs/secret/databases) page.
|
||||
|
|
|
|||
|
|
@ -222,9 +222,9 @@ disable_escaping="true"
|
|||
## Tutorial
|
||||
Refer to the following step-by-step tutorials for more information:
|
||||
|
||||
- [Secrets as a Service: Dynamic Secrets](https://learn.hashicorp.com/vault/secrets-management/sm-dynamic-secrets)
|
||||
- [Database Root Credential Rotation](https://learn.hashicorp.com/vault/secrets-management/db-root-rotation)
|
||||
- [Database Static Roles and Credential Rotation](https://learn.hashicorp.com/vault/secrets-management/db-creds-rotation)
|
||||
- [Secrets as a Service: Dynamic Secrets](https://learn.hashicorp.com/tutorials/vault/database-secrets)
|
||||
- [Database Root Credential Rotation](https://learn.hashicorp.com/tutorials/vault/database-root-rotation)
|
||||
- [Database Static Roles and Credential Rotation](https://learn.hashicorp.com/tutorials/vault/database-creds-rotation)
|
||||
|
||||
## API
|
||||
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ $ vault write database/config/my-mysql-database \
|
|||
```
|
||||
|
||||
For a guide in root credential rotation, see [Database Root Credential
|
||||
Rotation](/guides/secret-mgmt/db-root-rotation).
|
||||
Rotation](https://learn.hashicorp.com/vault/secrets-management/db-root-rotation).
|
||||
|
||||
## API
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ to talk to Vault. Once enabled, Vault will act as the bridge to other identity p
|
|||
its existing authentication methods. Client applications can also obtain identity information
|
||||
for their end-users by leveraging custom templating of Vault identity information.
|
||||
|
||||
-> **Note**: For more detailed information on the configuration resources and OIDC endpoints,
|
||||
\-> **Note**: For more detailed information on the configuration resources and OIDC endpoints,
|
||||
please visit the [OIDC provider](/docs/concepts/oidc-provider) concepts page.
|
||||
|
||||
## Setup
|
||||
|
|
@ -52,7 +52,7 @@ Any Vault auth method may be used within the OIDC flow. For simplicity, enable t
|
|||
This user will authenticate to Vault through a client application, otherwise known as
|
||||
an OIDC [relying party](https://openid.net/specs/openid-connect-core-1_0.html#Terminology).
|
||||
|
||||
3. Create a client application:
|
||||
2. Create a client application:
|
||||
|
||||
```text
|
||||
$ vault write identity/oidc/client/my-webapp \
|
||||
|
|
@ -70,7 +70,7 @@ Any Vault auth method may be used within the OIDC flow. For simplicity, enable t
|
|||
To allow all Vault entities to authenticate, the built-in [allow_all](/docs/concepts/oidc-provider#assignments)
|
||||
assignment is provided.
|
||||
|
||||
4. Read client credentials:
|
||||
2. Read client credentials:
|
||||
|
||||
```text
|
||||
$ vault read identity/oidc/client/my-webapp
|
||||
|
|
@ -90,7 +90,7 @@ Any Vault auth method may be used within the OIDC flow. For simplicity, enable t
|
|||
The `client_id` and `client_secret` are the client application's credentials. These
|
||||
values are typically required when configuring an OIDC relying party.
|
||||
|
||||
5. Read OIDC discovery configuration:
|
||||
2. Read OIDC discovery configuration:
|
||||
|
||||
```text
|
||||
$ curl -s http://127.0.0.1:8200/v1/identity/oidc/provider/default/.well-known/openid-configuration
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ Success! Data written to: nomad/config/lease
|
|||
```
|
||||
|
||||
For a quick start, you can use the SecretID token provided by the [Nomad ACL bootstrap
|
||||
process](https://www.nomadproject.io/guides/acl.html#generate-the-initial-token), although this
|
||||
process](https://learn.hashicorp.com/collections/nomad/access-control#generate-the-initial-token), although this
|
||||
is discouraged for production deployments.
|
||||
|
||||
```shell-session
|
||||
|
|
@ -54,7 +54,7 @@ Modify Index = 7
|
|||
```
|
||||
|
||||
The suggested pattern is to generate a token specifically for Vault, following the
|
||||
[Nomad ACL guide](https://www.nomadproject.io/guides/acl.html)
|
||||
[Nomad ACL guide](https://learn.hashicorp.com/collections/nomad/access-control)
|
||||
|
||||
Next, we must configure Vault to know how to contact Nomad.
|
||||
This is done by writing the access information:
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ root CA (which may be a second mount of the `pki` secrets engine).
|
|||
### Managed Keys
|
||||
|
||||
Since 1.10, Vault Enterprise can access private key material in a
|
||||
[_managed key_](../enterprise/managed-keys). In this case, Vault never sees the
|
||||
[_managed key_](/docs/enterprise/managed-keys). In this case, Vault never sees the
|
||||
private key, and the external KMS or HSM performs certificate signing operations.
|
||||
Managed keys are configured by selecting the `kms` type when generating a root
|
||||
or intermediate.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ This page will show a quick start for this backend. For detailed documentation
|
|||
on every path, use `vault path-help` after mounting the backend.
|
||||
|
||||
~> **Terraform Enterprise Support:** this secret engine supports both Terraform
|
||||
Cloud ([app.terraform.io](https://app.terraform.io)) as well as on-prem
|
||||
Cloud ([app.terraform.io](https://app.terraform.io/session)) as well as on-prem
|
||||
Terraform Enterprise. Any version requirements will be documented alongside the
|
||||
features that require them, if any.
|
||||
|
||||
|
|
@ -55,7 +55,7 @@ management tool.
|
|||
and manages the lifecycle of that API token. You will need to know the User
|
||||
ID in order to generate User API tokens for that user. You can use the
|
||||
Terraform Cloud [Account
|
||||
API](https://www.terraform.io/docs/cloud/api-docs/account.html) to find the
|
||||
API](https://www.terraform.io/cloud-docs/api-docs/account) to find the
|
||||
desired User ID.
|
||||
|
||||
```shell-session
|
||||
|
|
@ -94,7 +94,7 @@ however there are important differences to be aware of.
|
|||
The Terraform Cloud API limits both Organization and Team roles to **one active
|
||||
token at any given time**. Generating a new Organization or Team API token by
|
||||
reading the credentials in Vault or otherwise generating them on
|
||||
[app.terraform.io](https://app.terraform.io) will effectively revoke **any**
|
||||
[app.terraform.io](https://app.terraform.io/session) will effectively revoke **any**
|
||||
existing API token for that Organization or Team.
|
||||
|
||||
Due to this behavior, Organization and Team API tokens created by Vault will be
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ The key features of Vault are:
|
|||
- **Secure Secret Storage**: Arbitrary key/value secrets can be stored
|
||||
in Vault. Vault encrypts these secrets prior to writing them to persistent
|
||||
storage, so gaining access to the raw storage isn't enough to access
|
||||
your secrets. Vault can write to disk, [Consul](https://www.consul.io),
|
||||
your secrets. Vault can write to disk, [Consul](https://www.consul.io/),
|
||||
and more.
|
||||
|
||||
- **Dynamic Secrets**: Vault can generate secrets on-demand for some
|
||||
|
|
|
|||
|
|
@ -1,8 +1,4 @@
|
|||
[
|
||||
{
|
||||
"title": "Overview",
|
||||
"path": "index"
|
||||
},
|
||||
{
|
||||
"title": "Client Libraries",
|
||||
"path": "libraries"
|
||||
|
|
@ -190,7 +186,12 @@
|
|||
]
|
||||
},
|
||||
{
|
||||
"title": "Key Management <sup>ENTERPRISE</sup>",
|
||||
"title": "Key Management",
|
||||
"badge": {
|
||||
"text": "ENTERPRISE",
|
||||
"type": "outlined",
|
||||
"color": "neutral"
|
||||
},
|
||||
"routes": [
|
||||
{
|
||||
"title": "Overview",
|
||||
|
|
@ -228,7 +229,12 @@
|
|||
]
|
||||
},
|
||||
{
|
||||
"title": "KMIP <sup>ENTERPRISE</sup>",
|
||||
"title": "KMIP",
|
||||
"badge": {
|
||||
"text": "ENTERPRISE",
|
||||
"type": "outlined",
|
||||
"color": "neutral"
|
||||
},
|
||||
"path": "secret/kmip"
|
||||
},
|
||||
{
|
||||
|
|
@ -268,7 +274,12 @@
|
|||
"path": "secret/totp"
|
||||
},
|
||||
{
|
||||
"title": "Transform <sup>ENTERPRISE</sup>",
|
||||
"title": "Transform",
|
||||
"badge": {
|
||||
"text": "ENTERPRISE",
|
||||
"type": "outlined",
|
||||
"color": "neutral"
|
||||
},
|
||||
"path": "secret/transform"
|
||||
},
|
||||
{
|
||||
|
|
@ -353,7 +364,12 @@
|
|||
"path": "auth/userpass"
|
||||
},
|
||||
{
|
||||
"title": "App ID <sup>DEPRECATED</sup>",
|
||||
"title": "App ID",
|
||||
"badge": {
|
||||
"text": "DEPRECATED",
|
||||
"type": "outlined",
|
||||
"color": "neutral"
|
||||
},
|
||||
"path": "auth/app-id"
|
||||
}
|
||||
]
|
||||
|
|
@ -490,8 +506,13 @@
|
|||
"path": "system/loggers"
|
||||
},
|
||||
{
|
||||
"title": "<code>/sys/managed-keys <sup>ENT</sup></code>",
|
||||
"path": "system/managed-keys"
|
||||
"title": "<code>/sys/managed-keys</code>",
|
||||
"path": "system/managed-keys",
|
||||
"badge": {
|
||||
"text": "ENT",
|
||||
"type": "outlined",
|
||||
"color": "neutral"
|
||||
}
|
||||
},
|
||||
{
|
||||
"title": "<code>/sys/metrics</code>",
|
||||
|
|
|
|||
|
|
@ -249,7 +249,12 @@
|
|||
"path": "configuration/seal/ocikms"
|
||||
},
|
||||
{
|
||||
"title": "HSM PKCS11 <sup>ENT</sup>",
|
||||
"title": "HSM PKCS11",
|
||||
"badge": {
|
||||
"text": "ENT",
|
||||
"type": "outlined",
|
||||
"color": "neutral"
|
||||
},
|
||||
"path": "configuration/seal/pkcs11"
|
||||
},
|
||||
{
|
||||
|
|
@ -393,11 +398,21 @@
|
|||
"path": "configuration/log-requests-level"
|
||||
},
|
||||
{
|
||||
"title": "<code>Entropy Augmentation</code> <sup>ENT</sup>",
|
||||
"title": "<code>Entropy Augmentation</code>",
|
||||
"badge": {
|
||||
"text": "ENT",
|
||||
"type": "outlined",
|
||||
"color": "neutral"
|
||||
},
|
||||
"path": "configuration/entropy-augmentation"
|
||||
},
|
||||
{
|
||||
"title": "<code>kms_library</code> <sup>ENT</sup>",
|
||||
"title": "<code>kms_library</code>",
|
||||
"badge": {
|
||||
"text": "ENT",
|
||||
"type": "outlined",
|
||||
"color": "neutral"
|
||||
},
|
||||
"path": "configuration/kms-library"
|
||||
}
|
||||
]
|
||||
|
|
@ -1040,7 +1055,12 @@
|
|||
]
|
||||
},
|
||||
{
|
||||
"title": "Key Management <sup>ENTERPRISE</sup>",
|
||||
"title": "Key Management",
|
||||
"badge": {
|
||||
"text": "ENTERPRISE",
|
||||
"type": "outlined",
|
||||
"color": "neutral"
|
||||
},
|
||||
"routes": [
|
||||
{
|
||||
"title": "Overview",
|
||||
|
|
@ -1078,7 +1098,12 @@
|
|||
]
|
||||
},
|
||||
{
|
||||
"title": "KMIP <sup>ENTERPRISE</sup>",
|
||||
"title": "KMIP",
|
||||
"badge": {
|
||||
"text": "ENTERPRISE",
|
||||
"type": "outlined",
|
||||
"color": "neutral"
|
||||
},
|
||||
"path": "secrets/kmip"
|
||||
},
|
||||
{
|
||||
|
|
@ -1160,7 +1185,12 @@
|
|||
"path": "secrets/totp"
|
||||
},
|
||||
{
|
||||
"title": "Transform <sup>ENTERPRISE</sup>",
|
||||
"title": "Transform",
|
||||
"badge": {
|
||||
"text": "ENTERPRISE",
|
||||
"type": "outlined",
|
||||
"color": "neutral"
|
||||
},
|
||||
"routes": [
|
||||
{
|
||||
"title": "Overview",
|
||||
|
|
@ -1171,7 +1201,12 @@
|
|||
"path": "secrets/transform/ff3-tweak-details"
|
||||
},
|
||||
{
|
||||
"title": "Tokenization Transform <sup>ENTERPRISE</sup>",
|
||||
"title": "Tokenization Transform",
|
||||
"badge": {
|
||||
"text": "ENTERPRISE",
|
||||
"type": "outlined",
|
||||
"color": "neutral"
|
||||
},
|
||||
"path": "secrets/transform/tokenization"
|
||||
}
|
||||
]
|
||||
|
|
@ -1337,7 +1372,12 @@
|
|||
"divider": true
|
||||
},
|
||||
{
|
||||
"title": "App ID <sup>DEPRECATED</sup>",
|
||||
"title": "App ID",
|
||||
"badge": {
|
||||
"text": "DEPRECATED",
|
||||
"type": "outlined",
|
||||
"color": "neutral"
|
||||
},
|
||||
"path": "auth/app-id"
|
||||
}
|
||||
]
|
||||
|
|
|
|||
|
|
@ -6,6 +6,8 @@ PREVIEW_DIR=website-preview
|
|||
CLONE_DIR=website-preview
|
||||
# The product for which we are building the deploy preview
|
||||
PRODUCT=vault
|
||||
# Preview mode, controls the UI rendered (either the product site or developer). Can be `io` or `developer`
|
||||
PREVIEW_MODE=io
|
||||
|
||||
from_cache=false
|
||||
|
||||
|
|
@ -28,4 +30,4 @@ fi
|
|||
cd "$PREVIEW_DIR"
|
||||
|
||||
# Run the build:deploy-preview start script
|
||||
REPO=$PRODUCT DEV_IO=$PRODUCT IS_CONTENT_PREVIEW=true HASHI_ENV=project-preview npm run build:deploy-preview
|
||||
PREVIEW_MODE=$PREVIEW_MODE REPO=$PRODUCT HASHI_ENV=project-preview npm run build:deploy-preview
|
||||
|
|
|
|||
|
|
@ -4,6 +4,8 @@ REPO_TO_CLONE=dev-portal
|
|||
PREVIEW_DIR=website-preview
|
||||
# The product for which we are building the deploy preview
|
||||
PRODUCT=vault
|
||||
# Preview mode, controls the UI rendered (either the product site or developer). Can be `io` or `developer`
|
||||
PREVIEW_MODE=io
|
||||
|
||||
should_pull=true
|
||||
|
||||
|
|
@ -22,4 +24,4 @@ if [ "$should_pull" = true ]; then
|
|||
fi
|
||||
|
||||
# Run the dev-portal content-repo start script
|
||||
REPO=$PRODUCT PREVIEW_DIR="$PREVIEW_DIR" npm run start:local-preview
|
||||
REPO=$PRODUCT PREVIEW_MODE=$PREVIEW_MODE npm run start:local-preview
|
||||
|
|
|
|||
Loading…
Reference in a new issue