luxolus
/
open-vault
2
0
Fork 0
Code Issues 1 Pull Requests Releases Activity

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 2022-09-22 10:11:04 -05:00 committed by GitHub
parent fa8f7c793f
commit dfc3ad015a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
72 changed files with 390 additions and 298 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
website/Makefile
View File

@ -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

2
website/content/api-docs/auth/jwt.mdx
View File

@ -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&#x3A;//.../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

2
website/content/api-docs/index.mdx
View File

@ -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:

3
website/content/api-docs/relatedtools.mdx
View File

@ -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.

2
website/content/api-docs/secret/azure.mdx
View File

@ -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

6
website/content/api-docs/secret/cassandra.mdx
View File

@ -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)` |

4
website/content/api-docs/secret/consul.mdx
View File

@ -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`.

2
website/content/api-docs/secret/databases/cassandra.mdx
View File

@ -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

2
website/content/api-docs/secret/databases/couchbase.mdx
View File

@ -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

2
website/content/api-docs/secret/databases/elasticdb.mdx
View File

@ -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

2
website/content/api-docs/secret/databases/hanadb.mdx
View File

@ -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

2
website/content/api-docs/secret/databases/influxdb.mdx
View File

@ -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

2
website/content/api-docs/secret/databases/mongodb.mdx
View File

@ -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

2
website/content/api-docs/secret/databases/mongodbatlas.mdx
View File

@ -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

2
website/content/api-docs/secret/databases/mssql.mdx
View File

@ -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

2
website/content/api-docs/secret/databases/mysql-maria.mdx
View File

@ -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

2
website/content/api-docs/secret/databases/oracle.mdx
View File

@ -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

2
website/content/api-docs/secret/databases/postgresql.mdx
View File

@ -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

2
website/content/api-docs/secret/databases/redshift.mdx
View File

@ -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

2
website/content/api-docs/secret/databases/snowflake.mdx
View File

@ -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

2
website/content/api-docs/secret/gcp.mdx
View File

@ -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.

12
website/content/api-docs/secret/identity/mfa/duo.mdx
View File

@ -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

12
website/content/api-docs/secret/identity/mfa/index.mdx
View File

@ -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
website/content/api-docs/secret/identity/mfa/okta.mdx
View File

@ -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
website/content/api-docs/secret/identity/mfa/pingid.mdx
View File

@ -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

20
website/content/api-docs/secret/identity/mfa/totp.mdx
View File

@ -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
@ -128,8 +128,8 @@ $ curl \
This endpoint lists TOTP MFA methods that are visible in the current namespace or in parent namespaces.
| Method | Path |
|:-------|:--------------------------------|
| 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
@ -204,8 +204,8 @@ This endpoint can be used to generate a TOTP MFA secret. Unlike the `generate`
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 |
| :----- |:-------------------------------------------------|
| 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

4
website/content/api-docs/secret/kv/index.mdx
View File

@ -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)

2
website/content/api-docs/secret/kv/kv-v2.mdx
View File

@ -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 |
| :----- | :------------------------------------------- |

2
website/content/api-docs/secret/nomad.mdx
View File

@ -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"`.

2
website/content/api-docs/secret/terraform.mdx
View File

@ -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 |
| :----- | :---------------------- |

2
website/content/api-docs/secret/transit.mdx
View File

@ -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

8
website/content/api-docs/system/mfa/index.mdx
View File

@ -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

5
website/content/api-docs/system/mounts.mdx
View File

@ -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

2
website/content/docs/audit/index.mdx
View File

@ -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.

2
website/content/docs/auth/azure.mdx
View File

@ -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)

72
website/content/docs/auth/jwt/index.mdx
View File

@ -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)
@ -231,46 +237,46 @@ Auth methods must be configured in advance before users or machines can
authenticate. These steps are usually completed by an operator or configuration
management tool.
1. Enable the JWT auth method. Either the "jwt" or "oidc" name may be used. The
backend will be mounted at the chosen name.
1. Enable the JWT auth method. Either the "jwt" or "oidc" name may be used. The
backend will be mounted at the chosen name.
```text
$ vault auth enable jwt
or
$ vault auth enable oidc
```
```text
$ vault auth enable jwt
or
$ vault auth enable oidc
```
1. Use the `/config` endpoint to configure Vault. To support JWT roles, either local keys, a JWKS URL, or an OIDC
Discovery URL must be present. For OIDC roles, OIDC Discovery URL, OIDC Client ID and OIDC Client Secret are required. For the
list of available configuration options, please see the [API documentation](/api-docs/auth/jwt).
1. Use the `/config` endpoint to configure Vault. To support JWT roles, either local keys, a JWKS URL, or an OIDC
Discovery URL must be present. For OIDC roles, OIDC Discovery URL, OIDC Client ID and OIDC Client Secret are required. For the
list of available configuration options, please see the [API documentation](/api-docs/auth/jwt).
```text
$ vault write auth/jwt/config \
oidc_discovery_url="https://myco.auth0.com/" \
oidc_client_id="m5i8bj3iofytj" \
oidc_client_secret="f4ubv72nfiu23hnsj" \
default_role="demo"
```
```text
$ vault write auth/jwt/config \
oidc_discovery_url="https://myco.auth0.com/" \
oidc_client_id="m5i8bj3iofytj" \
oidc_client_secret="f4ubv72nfiu23hnsj" \
default_role="demo"
```
1. Create a named role:
1. Create a named role:
```text
vault write auth/jwt/role/demo \
allowed_redirect_uris="http://localhost:8250/oidc/callback" \
bound_subject="r3qX9DljwFIWhsiqwFiu38209F10atW6@clients" \
bound_audiences="https://vault.plugin.auth.jwt.test" \
user_claim="https://vault/user" \
groups_claim="https://vault/groups" \
policies=webapps \
ttl=1h
```
```text
vault write auth/jwt/role/demo \
allowed_redirect_uris="http://localhost:8250/oidc/callback" \
bound_subject="r3qX9DljwFIWhsiqwFiu38209F10atW6@clients" \
bound_audiences="https://vault.plugin.auth.jwt.test" \
user_claim="https://vault/user" \
groups_claim="https://vault/groups" \
policies=webapps \
ttl=1h
```
This role authorizes JWTs with the given subject and audience claims, gives
it the `webapps` policy, and uses the given user/groups claims to set up
Identity aliases.
This role authorizes JWTs with the given subject and audience claims, gives
it the `webapps` policy, and uses the given user/groups claims to set up
Identity aliases.
For the complete list of configuration options, please see the API
documentation.
For the complete list of configuration options, please see the API
documentation.
### Bound Claims

2
website/content/docs/commands/operator/generate-root.mdx
View File

@ -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

4
website/content/docs/commands/operator/rekey.mdx
View File

@ -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.

4
website/content/docs/concepts/client-count/faq.mdx
View File

@ -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?

2
website/content/docs/concepts/dev-server.mdx
View File

@ -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.

2
website/content/docs/concepts/integrated-storage/autopilot.mdx
View File

@ -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)

38
website/content/docs/concepts/policies.mdx
View File

@ -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
@ -263,19 +263,19 @@ 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 |
| `identity.entity.aliases.<mount accessor>.id` | Entity alias ID for the given mount |
| `identity.entity.aliases.<mount accessor>.name` | Entity alias name for the given mount |
| `identity.entity.aliases.<mount accessor>.metadata.<metadata key>` | Metadata associated with the alias for the given mount and metadata key |
| `identity.entity.aliases.<mount accessor>.custom_metadata.<custom_metadata key>` | Custom metadata associated with the alias for the given mount and custom metadata key |
| `identity.groups.ids.<group id>.name` | The group name for the given group ID |
| `identity.groups.names.<group name>.id` | The group ID for the given group name |
| `identity.groups.ids.<group id>.metadata.<metadata key>` | Metadata associated with the group for the given key |
| `identity.groups.names.<group name>.metadata.<metadata key>` | Metadata associated with the group for the given key |
| 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 |
| `identity.entity.aliases.<mount accessor>.id` | Entity alias ID for the given mount |
| `identity.entity.aliases.<mount accessor>.name` | Entity alias name for the given mount |
| `identity.entity.aliases.<mount accessor>.metadata.<metadata key>` | Metadata associated with the alias for the given mount and metadata key |
| `identity.entity.aliases.<mount accessor>.custom_metadata.<custom_metadata key>` | Custom metadata associated with the alias for the given mount and custom metadata key |
| `identity.groups.ids.<group id>.name` | The group name for the given group ID |
| `identity.groups.names.<group name>.id` | The group ID for the given group name |
| `identity.groups.ids.<group id>.metadata.<metadata key>` | Metadata associated with the group for the given key |
| `identity.groups.names.<group name>.metadata.<metadata key>` | Metadata associated with the group for the given key |
### Examples
@ -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

4
website/content/docs/concepts/storage.mdx
View File

@ -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

24
website/content/docs/concepts/tokens.mdx
View File

@ -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

2
website/content/docs/configuration/index.mdx
View File

@ -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

2
website/content/docs/configuration/sentinel.mdx
View File

@ -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.

2
website/content/docs/configuration/service-registration/consul.mdx
View File

@ -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

2
website/content/docs/configuration/service-registration/index.mdx
View File

@ -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

2
website/content/docs/configuration/storage/index.mdx
View File

@ -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:

2
website/content/docs/enterprise/license/faq.mdx
View File

@ -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)?

2
website/content/docs/faq/ssct.mdx
View File

@ -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.

2
website/content/docs/index.mdx
View File

@ -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.

2
website/content/docs/internals/limits.mdx
View File

@ -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

24
website/content/docs/internals/telemetry.mdx
View File

@ -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

20
website/content/docs/partnerships.mdx
View File

@ -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/).
@ -67,12 +67,12 @@ The Vault integration development process is divided into six steps. By followin
![Development Process](/img/integration-program-devprocess.png)
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. Engage: Initial contact between vendor and HashiCorp
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.

2
website/content/docs/platform/k8s/helm/index.mdx
View File

@ -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:

2
website/content/docs/platform/k8s/helm/terraform.mdx
View File

@ -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

2
website/content/docs/release-notes/1.10.0.mdx
View File

@ -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

4
website/content/docs/release-notes/1.9.0.mdx
View File

@ -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.

2
website/content/docs/secrets/consul.mdx
View File

@ -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

108
website/content/docs/secrets/databases/elasticdb.mdx
View File

@ -106,78 +106,78 @@ Now, Elasticsearch is configured and ready to be used with Vault.
## Setup
1. Enable the database secrets engine if it is not already enabled:
1. Enable the database secrets engine if it is not already enabled:
```text
$ vault secrets enable database
Success! Enabled the database secrets engine at: database/
```
```text
$ vault secrets enable database
Success! Enabled the database secrets engine at: database/
```
By default, the secrets engine will enable at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
By default, the secrets engine will enable at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
1. Configure Vault with the proper plugin and connection information:
1. Configure Vault with the proper plugin and connection information:
```text
$ vault write database/config/my-elasticsearch-database \
plugin_name="elasticsearch-database-plugin" \
allowed_roles="internally-defined-role,externally-defined-role" \
username=vault \
password=myPa55word \
url=http://localhost:9200 \
ca_cert=/usr/share/ca-certificates/extra/elastic-stack-ca.crt.pem \
client_cert=$ES_HOME/config/certs/elastic-certificates.crt.pem \
client_key=$ES_HOME/config/certs/elastic-certificates.key.pem
```
```text
$ vault write database/config/my-elasticsearch-database \
plugin_name="elasticsearch-database-plugin" \
allowed_roles="internally-defined-role,externally-defined-role" \
username=vault \
password=myPa55word \
url=http://localhost:9200 \
ca_cert=/usr/share/ca-certificates/extra/elastic-stack-ca.crt.pem \
client_cert=$ES_HOME/config/certs/elastic-certificates.crt.pem \
client_key=$ES_HOME/config/certs/elastic-certificates.key.pem
```
1. Configure a role that maps a name in Vault to a role definition in Elasticsearch.
This is considered the most secure type of role because nobody can perform
a privilege escalation by editing a role's privileges out-of-band in
Elasticsearch:
1. Configure a role that maps a name in Vault to a role definition in Elasticsearch.
This is considered the most secure type of role because nobody can perform
a privilege escalation by editing a role's privileges out-of-band in
Elasticsearch:
```text
$ vault write database/roles/internally-defined-role \
db_name=my-elasticsearch-database \
creation_statements='{"elasticsearch_role_definition": {"indices": [{"names":["*"], "privileges":["read"]}]}}' \
default_ttl="1h" \
max_ttl="24h"
Success! Data written to: database/roles/internally-defined-role
```
```text
$ vault write database/roles/internally-defined-role \
db_name=my-elasticsearch-database \
creation_statements='{"elasticsearch_role_definition": {"indices": [{"names":["*"], "privileges":["read"]}]}}' \
default_ttl="1h" \
max_ttl="24h"
Success! Data written to: database/roles/internally-defined-role
```
1. Alternatively, configure a role that maps a name in Vault to a pre-existing
role definition in Elasticsearch:
1. Alternatively, configure a role that maps a name in Vault to a pre-existing
role definition in Elasticsearch:
```text
$ vault write database/roles/externally-defined-role \
db_name=my-elasticsearch-database \
creation_statements='{"elasticsearch_roles": ["pre-existing-role-in-elasticsearch"]}' \
default_ttl="1h" \
max_ttl="24h"
Success! Data written to: database/roles/externally-defined-role
```
```text
$ vault write database/roles/externally-defined-role \
db_name=my-elasticsearch-database \
creation_statements='{"elasticsearch_roles": ["pre-existing-role-in-elasticsearch"]}' \
default_ttl="1h" \
max_ttl="24h"
Success! Data written to: database/roles/externally-defined-role
```
## Usage
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials.
1. Generate a new credential by reading from the `/creds` endpoint with the name
of the role:
1. Generate a new credential by reading from the `/creds` endpoint with the name
of the role:
```text
$ vault read database/creds/my-role
Key Value
--- -----
lease_id database/creds/my-role/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
lease_duration 1h
lease_renewable true
password 0ZsueAP-dqCNGZo35M0n
username v-vaultuser-my-role-AgIViC5TdQHBdeiCxae0-1602541724
```
```text
$ vault read database/creds/my-role
Key Value
--- -----
lease_id database/creds/my-role/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
lease_duration 1h
lease_renewable true
password 0ZsueAP-dqCNGZo35M0n
username v-vaultuser-my-role-AgIViC5TdQHBdeiCxae0-1602541724
```
## 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.

6
website/content/docs/secrets/databases/index.mdx
View File

@ -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

78
website/content/docs/secrets/databases/mysql-maria.mdx
View File

@ -37,57 +37,57 @@ more information about setting up the database secrets engine.
## Setup
1. Enable the database secrets engine if it is not already enabled:
1. Enable the database secrets engine if it is not already enabled:
```text
$ vault secrets enable database
Success! Enabled the database secrets engine at: database/
```
```text
$ vault secrets enable database
Success! Enabled the database secrets engine at: database/
```
By default, the secrets engine will enable at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
By default, the secrets engine will enable at the name of the engine. To
enable the secrets engine at a different path, use the `-path` argument.
1. Configure Vault with the proper plugin and connection information:
1. Configure Vault with the proper plugin and connection information:
```text
$ vault write database/config/my-mysql-database \
plugin_name=mysql-database-plugin \
connection_url="{{username}}:{{password}}@tcp(127.0.0.1:3306)/" \
allowed_roles="my-role" \
username="vaultuser" \
password="vaultpass"
```
```text
$ vault write database/config/my-mysql-database \
plugin_name=mysql-database-plugin \
connection_url="{{username}}:{{password}}@tcp(127.0.0.1:3306)/" \
allowed_roles="my-role" \
username="vaultuser" \
password="vaultpass"
```
1. Configure a role that maps a name in Vault to an SQL statement to execute to
create the database credential:
1. Configure a role that maps a name in Vault to an SQL statement to execute to
create the database credential:
```text
$ vault write database/roles/my-role \
db_name=my-mysql-database \
creation_statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}';GRANT SELECT ON *.* TO '{{name}}'@'%';" \
default_ttl="1h" \
max_ttl="24h"
Success! Data written to: database/roles/my-role
```
```text
$ vault write database/roles/my-role \
db_name=my-mysql-database \
creation_statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}';GRANT SELECT ON *.* TO '{{name}}'@'%';" \
default_ttl="1h" \
max_ttl="24h"
Success! Data written to: database/roles/my-role
```
## Usage
After the secrets engine is configured and a user/machine has a Vault token with
the proper permission, it can generate credentials.
1. Generate a new credential by reading from the `/creds` endpoint with the name
of the role:
1. Generate a new credential by reading from the `/creds` endpoint with the name
of the role:
```text
$ vault read database/creds/my-role
Key Value
--- -----
lease_id database/creds/my-role/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
lease_duration 1h
lease_renewable true
password yY-57n3X5UQhxnmFRP3f
username v_vaultuser_my-role_crBWVqVh2Hc1
```
```text
$ vault read database/creds/my-role
Key Value
--- -----
lease_id database/creds/my-role/2f6a614c-4aa2-7b19-24b9-ad944a8d4de6
lease_duration 1h
lease_renewable true
password yY-57n3X5UQhxnmFRP3f
username v_vaultuser_my-role_crBWVqVh2Hc1
```
## Client x509 Certificate Authentication
@ -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

8
website/content/docs/secrets/identity/oidc-provider.mdx
View File

@ -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

4
website/content/docs/secrets/nomad.mdx
View File

@ -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:

2
website/content/docs/secrets/pki/considerations.mdx
View File

@ -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.

6
website/content/docs/secrets/terraform.mdx
View File

@ -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

2
website/content/docs/what-is-vault.mdx
View File

@ -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

41
website/data/api-docs-nav-data.json
View File

@ -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>",

56
website/data/docs-nav-data.json
View File

@ -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"
}
]

4
website/scripts/website-build.sh
View File

@ -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
website/scripts/website-start.sh
View File

@ -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