diff --git a/.github/workflows/check-legacy-links-format.yml b/.github/workflows/check-legacy-links-format.yml new file mode 100644 index 0000000000..1330579dc0 --- /dev/null +++ b/.github/workflows/check-legacy-links-format.yml @@ -0,0 +1,17 @@ +name: Legacy Link Format Checker + +on: + push: + paths: + - "website/content/**/*.mdx" + - "website/data/*-nav-data.json" + +jobs: + check-links: + uses: hashicorp/dev-portal/.github/workflows/docs-content-check-legacy-links-format.yml@475289345d312552b745224b46895f51cc5fc490 + with: + repo-owner: "hashicorp" + repo-name: "vault" + commit-sha: ${{ github.sha }} + mdx-directory: "website/content" + nav-data-directory: "website/data" diff --git a/.github/workflows/test-link-rewrites.yml b/.github/workflows/test-link-rewrites.yml new file mode 100644 index 0000000000..1d9c0ba60b --- /dev/null +++ b/.github/workflows/test-link-rewrites.yml @@ -0,0 +1,16 @@ +name: Test Link Rewrites + +on: [deployment_status] + +jobs: + test-link-rewrites: + if: github.event.deployment_status.state == 'success' + uses: hashicorp/dev-portal/.github/workflows/docs-content-link-rewrites-e2e.yml@2aceb60125f6c15f4c8dbe2e4d79148047bfa437 + with: + repo-owner: "hashicorp" + repo-name: "vault" + commit-sha: ${{ github.sha }} + main-branch-preview-url: "https://vault-git-main-hashicorp.vercel.app/" + # Workflow is only intended to run for one single migration PR + # This variable does not need to be updated + pr-branch-preview-url: "https://vault-git-docs-ambmigrate-link-formats-hashicorp.vercel.app/" diff --git a/website/content/api-docs/auth/alicloud.mdx b/website/content/api-docs/auth/alicloud.mdx index 94289b58ca..8717787fcc 100644 --- a/website/content/api-docs/auth/alicloud.mdx +++ b/website/content/api-docs/auth/alicloud.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for the Vault AliCloud auth method. This is the API documentation for the Vault AliCloud auth method. For general information about the usage and operation of the AliCloud method, please -see the [Vault AliCloud auth method documentation](/docs/auth/alicloud). +see the [Vault AliCloud auth method documentation](/vault/docs/auth/alicloud). This documentation assumes the AliCloud auth method is mounted at the `/auth/alicloud` path in Vault. Since it is possible to enable auth methods at any location, diff --git a/website/content/api-docs/auth/app-id.mdx b/website/content/api-docs/auth/app-id.mdx index 5d4e609da2..bca5712a3b 100644 --- a/website/content/api-docs/auth/app-id.mdx +++ b/website/content/api-docs/auth/app-id.mdx @@ -11,7 +11,7 @@ Please use AppRole instead. This is the API documentation for the Vault App ID auth method. For general information about the usage and operation of the App ID method, please -see the [Vault App ID method documentation](/docs/auth/app-id). +see the [Vault App ID method documentation](/vault/docs/auth/app-id). This documentation assumes the App ID method is mounted at the `/auth/app-id` path in Vault. Since it is possible to enable auth methods at any location, diff --git a/website/content/api-docs/auth/approle.mdx b/website/content/api-docs/auth/approle.mdx index 2ecfae6d7e..2e10ac7e6b 100644 --- a/website/content/api-docs/auth/approle.mdx +++ b/website/content/api-docs/auth/approle.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for the Vault AppRole auth method. This is the API documentation for the Vault AppRole auth method. For general information about the usage and operation of the AppRole method, please -see the [Vault AppRole method documentation](/docs/auth/approle). +see the [Vault AppRole method documentation](/vault/docs/auth/approle). This documentation assumes the AppRole method is mounted at the `/auth/approle` path in Vault. Since it is possible to enable auth methods at any location, diff --git a/website/content/api-docs/auth/aws.mdx b/website/content/api-docs/auth/aws.mdx index ba80410651..ca2ad49c38 100644 --- a/website/content/api-docs/auth/aws.mdx +++ b/website/content/api-docs/auth/aws.mdx @@ -12,7 +12,7 @@ description: This is the API documentation for the Vault AWS auth method. This is the API documentation for the Vault AWS auth method. For general information about the usage and operation of the AWS method, please -see the [Vault AWS method documentation](/docs/auth/aws). +see the [Vault AWS method documentation](/vault/docs/auth/aws). This documentation assumes the AWS method is mounted at the `/auth/aws` path in Vault. Since it is possible to enable auth methods at any location, @@ -188,7 +188,7 @@ The new access key Vault uses is returned by this operation. ## Configure Identity Integration This configures the way that Vault interacts with the -[Identity](/docs/secrets/identity) store. The default (as of Vault +[Identity](/vault/docs/secrets/identity) store. The default (as of Vault 1.0.3) is `role_id` for both values. | Method | Path | diff --git a/website/content/api-docs/auth/azure.mdx b/website/content/api-docs/auth/azure.mdx index 9dbe63f649..2771777ef2 100644 --- a/website/content/api-docs/auth/azure.mdx +++ b/website/content/api-docs/auth/azure.mdx @@ -10,7 +10,7 @@ description: |- This is the API documentation for the Vault Azure auth method plugin. To learn more about the usage and operation, see the -[Vault Azure method documentation](/docs/auth/azure). +[Vault Azure method documentation](/vault/docs/auth/azure). This documentation assumes the plugin method is mounted at the `/auth/azure` path in Vault. Since it is possible to enable auth methods @@ -31,7 +31,7 @@ virtual machine. - `tenant_id` `(string: )` - The tenant id for the Azure Active Directory organization. This value can also be provided with the `AZURE_TENANT_ID` environment variable. - `resource` `(string: )` - The resource URL for the application registered in Azure Active Directory. - The value is expected to match the audience (`aud` claim) of the [JWT](/api-docs/auth/azure#jwt) + The value is expected to match the audience (`aud` claim) of the [JWT](/vault/api-docs/auth/azure#jwt) provided to the login API. See the [resource](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/how-to-use-vm-token#get-a-token-using-http) parameter for how the audience is set when requesting a JWT access token from the Azure Instance Metadata Service (IMDS) endpoint. This value can also be provided with the `AZURE_AD_RESOURCE` environment variable. diff --git a/website/content/api-docs/auth/cert.mdx b/website/content/api-docs/auth/cert.mdx index 4ba273776a..2151fc87f0 100644 --- a/website/content/api-docs/auth/cert.mdx +++ b/website/content/api-docs/auth/cert.mdx @@ -12,7 +12,7 @@ description: |- This is the API documentation for the Vault TLS Certificate authentication method. For general information about the usage and operation of the TLS -Certificate method, please see the [Vault TLS Certificate method documentation](/docs/auth/cert). +Certificate method, please see the [Vault TLS Certificate method documentation](/vault/docs/auth/cert). This documentation assumes the TLS Certificate method is mounted at the `/auth/cert` path in Vault. Since it is possible to enable auth methods at any diff --git a/website/content/api-docs/auth/cf.mdx b/website/content/api-docs/auth/cf.mdx index a8ddb0fe71..e70a16a4fa 100644 --- a/website/content/api-docs/auth/cf.mdx +++ b/website/content/api-docs/auth/cf.mdx @@ -10,7 +10,7 @@ description: This is the API documentation for the Vault Cloud Foundry auth meth This is the API documentation for the Vault CF auth method. For general information about the usage and operation of the CF method, please -see the [Vault CF method documentation](/docs/auth/cf). +see the [Vault CF method documentation](/vault/docs/auth/cf). This documentation assumes the CF method is mounted at the `/auth/cf` path in Vault. Since it is possible to enable auth methods at any location, @@ -21,7 +21,7 @@ please update your API calls accordingly. Configure the root CA certificate to be used for verifying instance identity certificates, and configure access to the CF API. For detailed instructions on how to obtain these values, please see the [Vault CF method -documentation](/docs/auth/cf). +documentation](/vault/docs/auth/cf). | Method | Path | | :----- | ----------------- | diff --git a/website/content/api-docs/auth/gcp.mdx b/website/content/api-docs/auth/gcp.mdx index 7169d4d2b9..69430ee1c9 100644 --- a/website/content/api-docs/auth/gcp.mdx +++ b/website/content/api-docs/auth/gcp.mdx @@ -10,7 +10,7 @@ description: |- This is the API documentation for the Vault Google Cloud auth method. To learn more about the usage and operation, see the -[Vault Google Cloud method documentation](/docs/auth/gcp). +[Vault Google Cloud method documentation](/vault/docs/auth/gcp). This documentation assumes the plugin method is mounted at the `/auth/gcp` path in Vault. Since it is possible to enable auth methods @@ -31,7 +31,7 @@ to confirm signed JWTs passed in during login. - `credentials` `(string: "")` - A JSON string containing the contents of a GCP service account credentials file. The service account associated with the credentials - file must have the following [permissions](/docs/auth/gcp#required-gcp-permissions). + file must have the following [permissions](/vault/docs/auth/gcp#required-gcp-permissions). If this value is empty, Vault will try to use [Application Default Credentials][gcp-adc] from the machine on which the Vault server is running. diff --git a/website/content/api-docs/auth/github.mdx b/website/content/api-docs/auth/github.mdx index 09e0c527a8..289fc73602 100644 --- a/website/content/api-docs/auth/github.mdx +++ b/website/content/api-docs/auth/github.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for the Vault GitHub auth method. This is the API documentation for the Vault GitHub auth method. For general information about the usage and operation of the GitHub method, please -see the [Vault GitHub method documentation](/docs/auth/github). +see the [Vault GitHub method documentation](/vault/docs/auth/github). This documentation assumes the GitHub method is enabled at the `/auth/github` path in Vault. Since it is possible to enable auth methods at any location, diff --git a/website/content/api-docs/auth/jwt.mdx b/website/content/api-docs/auth/jwt.mdx index 5ea46200ed..98b79aacf0 100644 --- a/website/content/api-docs/auth/jwt.mdx +++ b/website/content/api-docs/auth/jwt.mdx @@ -12,7 +12,7 @@ description: |- This is the API documentation for the Vault JWT/OIDC auth method plugin. To learn more about the usage and operation, see the -[Vault JWT/OIDC method documentation](/docs/auth/jwt). +[Vault JWT/OIDC method documentation](/vault/docs/auth/jwt). This documentation assumes the plugin method is mounted at the `/auth/jwt` path in Vault. Since it is possible to enable auth methods @@ -43,7 +43,7 @@ set. - `bound_issuer` `(string: )` - The value against which to match the `iss` claim in a JWT. - `jwt_supported_algs` `(comma-separated string, or array of strings: )` - A list of supported signing algorithms. Defaults to [RS256] for OIDC roles. Defaults to all [available algorithms](https://github.com/hashicorp/cap/blob/main/jwt/algs.go) for JWT roles. - `default_role` `(string: )` - The default role to use if none is provided during login. -- `provider_config` `(map: )` - Configuration options for provider-specific handling. Providers with specific handling include: Azure, Google, SecureAuth. The options are described in each provider's section in [OIDC Provider Setup](/docs/auth/jwt/oidc-providers). +- `provider_config` `(map: )` - Configuration options for provider-specific handling. Providers with specific handling include: Azure, Google, SecureAuth. The options are described in each provider's section in [OIDC Provider Setup](/vault/docs/auth/jwt/oidc-providers). - `namespace_in_state` `(bool: true)` - Pass namespace in the OIDC state parameter instead of as a separate query parameter. With this setting, the allowed redirect URL(s) in Vault and on the provider side should not contain a namespace query parameter. This means only one redirect URL entry needs to be maintained on the provider side for all vault namespaces that will be authenticating against it. Defaults to true for new configs. ### Sample Payload @@ -117,7 +117,7 @@ entities attempting to login. At least one of the bound values must be set. the user; this will be used as the name for the Identity entity alias created due to a successful login. The claim value must be a string. - `user_claim_json_pointer` `(bool: false)` - Specifies if the `user_claim` value uses - [JSON pointer](/docs/auth/jwt#claim-specifications-and-json-pointer) syntax for + [JSON pointer](/vault/docs/auth/jwt#claim-specifications-and-json-pointer) syntax for referencing claims. By default, the `user_claim` value will not use JSON pointer. - `clock_skew_leeway` `(int or string: )` - The amount of leeway to add to all claims to account for clock skew, in seconds. Defaults to `60` seconds if set to `0` and can be disabled @@ -135,7 +135,7 @@ entities attempting to login. At least one of the bound values must be set. claim matches this value. - `bound_claims` `(map: )` - If set, a map of claims (keys) to match against respective claim values (values). The expected value may be a single string or a list of strings. The interpretation of the bound - claim values is configured with `bound_claims_type`. Keys support [JSON pointer](/docs/auth/jwt#claim-specifications-and-json-pointer) + claim values is configured with `bound_claims_type`. Keys support [JSON pointer](/vault/docs/auth/jwt#claim-specifications-and-json-pointer) syntax for referencing claims. - `bound_claims_type` `(string: "string")` - Configures the interpretation of the bound_claims values. If `"string"` (the default), the values will treated as string literals and must match exactly. @@ -144,10 +144,10 @@ entities attempting to login. At least one of the bound values must be set. - `groups_claim` `(string: )` - The claim to use to uniquely identify the set of groups to which the user belongs; this will be used as the names for the Identity group aliases created due to a successful login. The claim - value must be a list of strings. Supports [JSON pointer](/docs/auth/jwt#claim-specifications-and-json-pointer) + value must be a list of strings. Supports [JSON pointer](/vault/docs/auth/jwt#claim-specifications-and-json-pointer) syntax for referencing claims. - `claim_mappings` `(map: )` - If set, a map of claims (keys) to be copied to - specified metadata fields (values). Keys support [JSON pointer](/docs/auth/jwt#claim-specifications-and-json-pointer) + specified metadata fields (values). Keys support [JSON pointer](/vault/docs/auth/jwt#claim-specifications-and-json-pointer) syntax for referencing claims. - `oidc_scopes` `(list: )` - If set, a list of OIDC scopes to be used with an OIDC role. The standard scope "openid" is automatically included and need not be specified. @@ -306,10 +306,10 @@ Obtain an authorization URL from Vault to start an OIDC login flow. - `redirect_uri` `(string: )` - 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 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. + provider. See [Redirect URIs](/vault/docs/auth/jwt#redirect-uris) for more information. - `client_nonce` `(string: )` - Optional client-provided nonce that must match the `client_nonce` value provided during a subsequent request to the - [callback](/api-docs/auth/jwt#oidc-callback) API. + [callback](/vault/api-docs/auth/jwt#oidc-callback) API. ### Sample Payload @@ -360,7 +360,7 @@ against any bound claims, and if valid a Vault token will be returned. an ID token. - `client_nonce` `(string: )` - Optional client-provided nonce that must match the `client_nonce` value provided during the prior request to the - [auth_url](/api-docs/auth/jwt#oidc-authorization-url-request) API. + [auth_url](/vault/api-docs/auth/jwt#oidc-authorization-url-request) API. ### Sample Request diff --git a/website/content/api-docs/auth/kerberos.mdx b/website/content/api-docs/auth/kerberos.mdx index e5ad3dafa4..52468eb0c8 100644 --- a/website/content/api-docs/auth/kerberos.mdx +++ b/website/content/api-docs/auth/kerberos.mdx @@ -10,7 +10,7 @@ description: This is the API documentation for the Vault Kerberos auth method pl This is the API documentation for the Vault Kerberos auth method plugin. To learn more about the usage and operation, see the -[Vault Kerberos auth method](/docs/auth/kerberos). +[Vault Kerberos auth method](/vault/docs/auth/kerberos). This documentation assumes the Kerberos auth method is mounted at the `auth/kerberos` path in Vault. Since it is possible to enable auth methods at diff --git a/website/content/api-docs/auth/kubernetes.mdx b/website/content/api-docs/auth/kubernetes.mdx index 88be94c96d..0cdc4d9384 100644 --- a/website/content/api-docs/auth/kubernetes.mdx +++ b/website/content/api-docs/auth/kubernetes.mdx @@ -10,7 +10,7 @@ description: This is the API documentation for the Vault Kubernetes auth method This is the API documentation for the Vault Kubernetes auth method plugin. To learn more about the usage and operation, see the -[Vault Kubernetes auth method](/docs/auth/kubernetes). +[Vault Kubernetes auth method](/vault/docs/auth/kubernetes). This documentation assumes the Kubernetes method is mounted at the `/auth/kubernetes` path in Vault. Since it is possible to enable auth methods at @@ -50,7 +50,7 @@ access the Kubernetes API. - `disable_iss_validation` `(bool: true)` **Deprecated** Disable JWT issuer validation. Allows to skip ISS validation. - `issuer` `(string: "")` **Deprecated** Optional JWT issuer. If no issuer is specified, then this plugin will use `kubernetes/serviceaccount` as the default issuer. -See [these instructions](/docs/auth/kubernetes#discovering-the-service-account-issuer) for looking up the issuer for a given Kubernetes cluster. +See [these instructions](/vault/docs/auth/kubernetes#discovering-the-service-account-issuer) for looking up the issuer for a given Kubernetes cluster. ### Caveats @@ -138,7 +138,7 @@ entities attempting to login. While it is strongly advised that you use `serviceaccount_uid`, you may also use `serviceaccount_name` in cases where you want to set the alias ahead of time, and the risks are mitigated or otherwise acceptable given your use case. It is very important to limit who is able to delete/create service accounts within a given cluster. - See the [Create an Entity Alias](/api-docs/secret/identity/entity-alias#create-an-entity-alias) document + See the [Create an Entity Alias](/vault/api-docs/secret/identity/entity-alias#create-an-entity-alias) document which further expands on the potential security implications mentioned above. @include 'tokenfields.mdx' diff --git a/website/content/api-docs/auth/ldap.mdx b/website/content/api-docs/auth/ldap.mdx index e28d0292fb..16aa4ebce6 100644 --- a/website/content/api-docs/auth/ldap.mdx +++ b/website/content/api-docs/auth/ldap.mdx @@ -10,7 +10,7 @@ description: This is the API documentation for the Vault LDAP auth method. This is the API documentation for the Vault LDAP auth method. For general information about the usage and operation of the LDAP method, please -see the [Vault LDAP method documentation](/docs/auth/ldap). +see the [Vault LDAP method documentation](/vault/docs/auth/ldap). This documentation assumes the LDAP method is mounted at the `/auth/ldap` path in Vault. Since it is possible to enable auth methods at any location, diff --git a/website/content/api-docs/auth/oci.mdx b/website/content/api-docs/auth/oci.mdx index 1b1185b651..bf5fba8deb 100644 --- a/website/content/api-docs/auth/oci.mdx +++ b/website/content/api-docs/auth/oci.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for the Vault OCI auth method plugin. This is the API documentation for the Vault OCI auth method plugin. To learn more about the usage and operation, see the -[Vault OCI auth method](/docs/auth/oci). +[Vault OCI auth method](/vault/docs/auth/oci). This documentation assumes the OCI method is mounted at the `/auth/oci` path in Vault. Since it is possible to enable auth methods at diff --git a/website/content/api-docs/auth/okta.mdx b/website/content/api-docs/auth/okta.mdx index a2d1543011..b3dda440fd 100644 --- a/website/content/api-docs/auth/okta.mdx +++ b/website/content/api-docs/auth/okta.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for the Vault Okta auth method. This is the API documentation for the Vault Okta auth method. For general information about the usage and operation of the Okta method, please -see the [Vault Okta method documentation](/docs/auth/okta). +see the [Vault Okta method documentation](/vault/docs/auth/okta). This documentation assumes the Okta method is mounted at the `/auth/okta` path in Vault. Since it is possible to enable auth methods at any location, diff --git a/website/content/api-docs/auth/radius.mdx b/website/content/api-docs/auth/radius.mdx index 91e370c4b4..ec139ceac4 100644 --- a/website/content/api-docs/auth/radius.mdx +++ b/website/content/api-docs/auth/radius.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for the Vault RADIUS auth method. This is the API documentation for the Vault RADIUS auth method. For general information about the usage and operation of the RADIUS method, please -see the [Vault RADIUS method documentation](/docs/auth/radius). +see the [Vault RADIUS method documentation](/vault/docs/auth/radius). This documentation assumes the RADIUS method is mounted at the `/auth/radius` path in Vault. Since it is possible to enable auth methods at any location, diff --git a/website/content/api-docs/auth/token.mdx b/website/content/api-docs/auth/token.mdx index 1abe2cdb2b..7b876f055a 100644 --- a/website/content/api-docs/auth/token.mdx +++ b/website/content/api-docs/auth/token.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for the Vault token auth method. This is the API documentation for the Vault token auth method. For general information about the usage and operation of the token method, please -see the [Vault Token method documentation](/docs/auth/token). +see the [Vault Token method documentation](/vault/docs/auth/token). ## List Accessors @@ -88,7 +88,7 @@ during this call. - `lease` `(string: "")` - DEPRECATED; use `ttl` instead - `ttl` `(string: "")` - The TTL period of the token, provided as "1h", where hour is the largest suffix. If not provided, the token is valid for the - [default lease TTL](/docs/configuration), or indefinitely if the + [default lease TTL](/vault/docs/configuration), or indefinitely if the root policy is used. - `type` `(string: "")` - The token type. Can be "batch" or "service". Defaults to the type specified by the role configuration named by `role_name`. @@ -800,7 +800,7 @@ be cached. Listing the `/auth/token/accessors` endpoint is a good way to get some sense of the potential impact: tidy does this and more, so if this call creates problems for your cluster, it would be wise to give Vault more resources before attempting tidy. Note that the request may time out depending on -[max duration](https://www.vaultproject.io/docs/configuration#default_max_request_duration) +[max duration](/vault/docs/configuration#default_max_request_duration) and your client's timeout configuration, make sure to allow it run to completion to properly judge the impact. diff --git a/website/content/api-docs/auth/userpass.mdx b/website/content/api-docs/auth/userpass.mdx index fb95dc93be..737c121c7a 100644 --- a/website/content/api-docs/auth/userpass.mdx +++ b/website/content/api-docs/auth/userpass.mdx @@ -10,7 +10,7 @@ description: |- This is the API documentation for the Vault Username & Password auth method. For general information about the usage and operation of the Username and Password method, please -see the [Vault Userpass method documentation](/docs/auth/userpass). +see the [Vault Userpass method documentation](/vault/docs/auth/userpass). This documentation assumes the Username & Password method is mounted at the `/auth/userpass` path in Vault. Since it is possible to enable auth methods at any location, diff --git a/website/content/api-docs/index.mdx b/website/content/api-docs/index.mdx index 387c3ef525..608485a074 100644 --- a/website/content/api-docs/index.mdx +++ b/website/content/api-docs/index.mdx @@ -36,7 +36,7 @@ either the `X-Vault-Token` HTTP Header or as `Authorization` HTTP Header using the `Bearer ` scheme. Otherwise, a client token can be retrieved using an [authentication -engine](/docs/auth). +engine](/vault/docs/auth). Each auth method has one or more unauthenticated login endpoints. These endpoints can be reached without any authentication, and are used for @@ -54,7 +54,7 @@ in periods. Otherwise, Vault will return a 404 unsupported path error. ## Namespaces -When using [Namespaces](/docs/enterprise/namespaces) the final path of the API +When using [Namespaces](/vault/docs/enterprise/namespaces) the final path of the API request is relative to the `X-Vault-Namespace` header. For instance, if a request URI is `secret/foo` with the `X-Vault-Namespace` header set as `ns1/ns2/`, then the resulting request path to Vault will be `ns1/ns2/secret/foo`. @@ -89,8 +89,8 @@ Typically the request data, body and response data to and from Vault is in JSON. Vault sets the `Content-Type` header appropriately with its response and does not require it from the clients request. -The demonstration below uses the [`KVv1` secrets engine](/api/secret/kv/kv-v1), which is a -simple Key/Value store. Please read [the API documentation of KV secret engines](/api/secret/kv) +The demonstration below uses the [`KVv1` secrets engine](/vault/api-docs/secret/kv/kv-v1), which is a +simple Key/Value store. Please read [the API documentation of KV secret engines](/vault/api-docs/secret/kv) for details of `KVv1` compared to `KVv2` and how they differ in their URI paths as well as the features available in version 2 of the KV secrets engine. @@ -163,7 +163,7 @@ discover whether an operation is actually a create or update operation based on the data already stored within Vault. This makes permission management via ACLs more flexible. -A [KVv2 example](api/secret/kv/kv-v2#sample-request-3) for the engine path of `secret` requires that URI is +A [KVv2 example](/vault/api-docs/secret/kv/kv-v2#sample-request-3) for the engine path of `secret` requires that URI is appended with ***`data/`*** prior to the secret name (`baz`) such as: ```shell-session @@ -204,7 +204,7 @@ methods, etc. then append `?help=1` to any URL. If you have valid permission to access the path, then the help text will be returned as 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](/vault/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. @@ -297,7 +297,7 @@ warnings are generated during the operation. - `412` - Precondition failed. Returned on Enterprise when a request can't be processed yet due to some missing eventually consistent data. Should be retried, perhaps with a little backoff. - See [Vault Eventual Consistency](/docs/enterprise/consistency). + See [Vault Eventual Consistency](/vault/docs/enterprise/consistency). - `429` - Default return code for health status of standby nodes. This will likely change in the future. - `473` - Default return code for health status of performance standby nodes. @@ -314,4 +314,4 @@ A maximum request size of 32MB is imposed to prevent a denial of service attack with arbitrarily large requests; this can be tuned per `listener` block in Vault's server configuration file. -[agent]: /docs/agent#listener-stanza +[agent]: /vault/docs/agent#listener-stanza diff --git a/website/content/api-docs/libraries.mdx b/website/content/api-docs/libraries.mdx index baf49d4dc4..61c3018453 100644 --- a/website/content/api-docs/libraries.mdx +++ b/website/content/api-docs/libraries.mdx @@ -11,7 +11,7 @@ description: >- The programming libraries listed on this page can be used to consume the API more conveniently. Some are officially maintained while others are provided by the community. -For a step-by-step walkthrough on using these client libraries, see the [developer quickstart](https://www.vaultproject.io/docs/get-started/developer-qs). +For a step-by-step walkthrough on using these client libraries, see the [developer quickstart](/vault/docs/get-started/developer-qs). For copy-pastable code examples, see the [vault-examples](https://github.com/hashicorp/vault-examples) repo. ## Official diff --git a/website/content/api-docs/secret/ad.mdx b/website/content/api-docs/secret/ad.mdx index c8e63630bf..fa2c1b5ba6 100644 --- a/website/content/api-docs/secret/ad.mdx +++ b/website/content/api-docs/secret/ad.mdx @@ -10,7 +10,7 @@ description: This is the API documentation for the Vault Active Directory secret This is the API documentation for the Vault AD secrets engine. For general information about the usage and operation of the AD secrets engine, please see -the [Vault Active Directory documentation](/docs/secrets/ad). +the [Vault Active Directory documentation](/vault/docs/secrets/ad). This documentation assumes the AD secrets engine is enabled at the `/ad` path in Vault. Since it is possible to enable secrets engines at any location, please @@ -26,7 +26,7 @@ The `config` endpoint configures the LDAP connection and binding parameters, as be rotated the next time it's requested. - `max_ttl` `(int: "")` - The maximum password time-to-live in seconds. No role will be allowed to set a custom ttl greater than the `max_ttl`. -- `password_policy` `(string: "")` - Name of the [password policy](/docs/concepts/password-policies) to use to +- `password_policy` `(string: "")` - Name of the [password policy](/vault/docs/concepts/password-policies) to use to generate passwords from. Mutually exclusive with `length` and `formatter`. **Deprecated parameters**: @@ -257,10 +257,10 @@ The `library` endpoint configures the sets of service accounts that Vault will o service accounts must already exist in Active Directory. - `ttl` (duration: "24h", optional): The maximum amount of time a single check-out lasts before Vault automatically checks it back in. Defaults to 24 hours. Setting it to zero reflects an unlimited lending period. - Uses [duration format strings](/docs/concepts/duration-format). + Uses [duration format strings](/vault/docs/concepts/duration-format). - `max_ttl` (duration: "24h", optional): The maximum amount of time a check-out last with renewal before Vault automatically checks it back in. Defaults to 24 hours. Setting it to zero reflects an unlimited lending period. - Uses [duration format strings](/docs/concepts/duration-format). + Uses [duration format strings](/vault/docs/concepts/duration-format). - `disable_check_in_enforcement` (bool: false, optional): Disable enforcing that service accounts must be checked in by the entity or client token that checked them out. Defaults to false. @@ -325,7 +325,7 @@ Returns a `200` if a credential is available, and a `400` if no credential is av - `ttl` (duration: "", optional): The maximum amount of time a check-out lasts before Vault automatically checks it back in. Setting it to zero reflects an unlimited lending period. Defaults to the set's `ttl`. If the requested `ttl` is higher than the set's, the set's will be used. - Uses [duration format strings](/docs/concepts/duration-format). + Uses [duration format strings](/vault/docs/concepts/duration-format). | Method | Path | | :----- | :-------------------------------- | diff --git a/website/content/api-docs/secret/alicloud.mdx b/website/content/api-docs/secret/alicloud.mdx index 688cbcb721..14630697bc 100644 --- a/website/content/api-docs/secret/alicloud.mdx +++ b/website/content/api-docs/secret/alicloud.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for the Vault AliCloud secrets engine This is the API documentation for the Vault AliCloud secrets engine. For general information about the usage and operation of the AliCloud secrets engine, please see -the [Vault AliCloud documentation](/docs/secrets/alicloud). +the [Vault AliCloud documentation](/vault/docs/secrets/alicloud). This documentation assumes the AliCloud secrets engine is enabled at the `/alicloud` path in Vault. Since it is possible to enable secrets engines at any location, please @@ -28,7 +28,7 @@ To use instance metadata, leave the static credential configuration unset. At present, this endpoint does not confirm that the provided AliCloud credentials are valid AliCloud credentials with proper permissions. -Please see the [Vault AliCloud documentation](/docs/secrets/alicloud) for +Please see the [Vault AliCloud documentation](/vault/docs/secrets/alicloud) for the policies that should be attached to the access key you provide. | Method | Path | @@ -77,7 +77,7 @@ The `role` endpoint configures how Vault will generate credentials for users of - `name` (string, required) – Specifies the name of the role to generate credentials against. This is part of the request URL. - `remote_policies` (string, optional) - The names and types of a pre-existing policies to be applied to the generate access token. Example: "name:AliyunOSSReadOnlyAccess,type:System". - `inline_policies` (string, optional) - The policy document JSON to be generated and attached to the access token. -- `role_arn` (string, optional) - The ARN of a role that will be assumed to obtain STS credentials. See [Vault AliCloud documentation](/docs/secrets/alicloud) regarding trusted actors. +- `role_arn` (string, optional) - The ARN of a role that will be assumed to obtain STS credentials. See [Vault AliCloud documentation](/vault/docs/secrets/alicloud) regarding trusted actors. - `ttl` (int, optional) - The duration in seconds after which the issued token should expire. Defaults to 0, in which case the value will fallback to the system/mount defaults. - `max_ttl` (int, optional) - The maximum allowed lifetime of tokens issued using this role. diff --git a/website/content/api-docs/secret/aws.mdx b/website/content/api-docs/secret/aws.mdx index 306874e3e7..5d60934112 100644 --- a/website/content/api-docs/secret/aws.mdx +++ b/website/content/api-docs/secret/aws.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for the Vault AWS secrets engine. This is the API documentation for the Vault AWS secrets engine. For general information about the usage and operation of the AWS secrets engine, please see -the [Vault AWS documentation](/docs/secrets/aws). +the [Vault AWS documentation](/vault/docs/secrets/aws). This documentation assumes the AWS secrets engine is enabled at the `/aws` path in Vault. Since it is possible to enable secrets engines at any location, please @@ -58,7 +58,7 @@ valid AWS credentials with proper permissions. - `sts_endpoint` `(string: )` – Specifies a custom HTTP STS endpoint to use. -- `username_template` `(string: )` - [Template](/docs/concepts/username-templating) describing how +- `username_template` `(string: )` - [Template](/vault/docs/concepts/username-templating) describing how dynamic usernames are generated. The username template is used to generate both IAM usernames (capped at 64 characters) and STS usernames (capped at 32 characters). Longer usernames result in a 500 error. diff --git a/website/content/api-docs/secret/azure.mdx b/website/content/api-docs/secret/azure.mdx index 8a9571a137..225860eacf 100644 --- a/website/content/api-docs/secret/azure.mdx +++ b/website/content/api-docs/secret/azure.mdx @@ -29,12 +29,12 @@ service principals. Environment variables will override any parameters set in th - `tenant_id` (`string: `) - The tenant id for the Azure Active Directory. This value can also be provided with the AZURE_TENANT_ID environment variable. - `client_id` (`string:""`) - The OAuth2 client id to connect to Azure. This value can also be provided - with the AZURE_CLIENT_ID environment variable. See [authentication](/docs/secrets/azure#authentication) for more details. + with the AZURE_CLIENT_ID environment variable. See [authentication](/vault/docs/secrets/azure#authentication) for more details. - `client_secret` (`string:""`) - The OAuth2 client secret to connect to Azure. This value can also be - provided with the AZURE_CLIENT_SECRET environment variable. See [authentication](/docs/secrets/azure#authentication) for more details. + provided with the AZURE_CLIENT_SECRET environment variable. See [authentication](/vault/docs/secrets/azure#authentication) for more details. - `environment` (`string:""`) - The Azure environment. This value can also be provided with the AZURE_ENVIRONMENT environment variable. If not specified, Vault will use Azure Public Cloud. -- `password_policy` `(string: "")` - Specifies a [password policy](/docs/concepts/password-policies) to +- `password_policy` `(string: "")` - Specifies a [password policy](/vault/docs/concepts/password-policies) to use when creating dynamic credentials. Defaults to generating an alphanumeric password if not set. - `use_microsoft_graph_api` `(bool: true)` - Indicates whether the secrets engine should use the [Microsoft Graph API](https://docs.microsoft.com/en-us/graph/use-the-api). @@ -69,7 +69,7 @@ service principals. Environment variables will override any parameters set in th Aside from the permissions listed above, setting this to true should be transparent to users. - `root_password_ttl` `(string: 182d)` - Specifies how long the root password is valid for in Azure when - rotate-root generates a new client secret. Uses [duration format strings](/docs/concepts/duration-format). + rotate-root generates a new client secret. Uses [duration format strings](/vault/docs/concepts/duration-format). ### Sample Payload @@ -360,8 +360,8 @@ $ vault read azure/creds/my-role ## Revoking/Renewing Secrets -See docs on how to [renew](/api-docs/system/leases#renew-lease) and [revoke](/api-docs/system/leases#revoke-lease) leases. +See docs on how to [renew](/vault/api-docs/system/leases#renew-lease) and [revoke](/vault/api-docs/system/leases#revoke-lease) leases. -[docs]: /docs/secrets/azure -[roles]: /docs/secrets/azure#roles -[groups]: /docs/secrets/azure#azure-groups +[docs]: /vault/docs/secrets/azure +[roles]: /vault/docs/secrets/azure#roles +[groups]: /vault/docs/secrets/azure#azure-groups diff --git a/website/content/api-docs/secret/cassandra.mdx b/website/content/api-docs/secret/cassandra.mdx index 1cd829e598..a3c7c90ebb 100644 --- a/website/content/api-docs/secret/cassandra.mdx +++ b/website/content/api-docs/secret/cassandra.mdx @@ -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-docs/secret/databases/cassandra). +[Cassandra database plugin HTTP API](/vault/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/databases/cassandra). +[Vault Cassandra backend documentation](/vault/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, @@ -56,7 +56,7 @@ Cassandra. private key; a certificate, private key, and issuing CA certificate; or just a CA certificate. For convenience format is the same as the output of the `issue` command from the `pki` backend; see - [the pki documentation](/docs/secrets/pki). + [the pki documentation](/vault/docs/secrets/pki). - `protocol_version` `(int: 2)` – Specifies the CQL protocol version to use. diff --git a/website/content/api-docs/secret/consul.mdx b/website/content/api-docs/secret/consul.mdx index 3751299b0f..87b8d7a5e1 100644 --- a/website/content/api-docs/secret/consul.mdx +++ b/website/content/api-docs/secret/consul.mdx @@ -12,7 +12,7 @@ description: This is the API documentation for the Vault Consul secrets engine. This is the API documentation for the Vault Consul secrets engine. For general information about the usage and operation of the Consul secrets engine, please -see the [Vault Consul documentation](/docs/secrets/consul). +see the [Vault Consul documentation](/vault/docs/secrets/consul). This documentation assumes the Consul secrets engine is enabled at the `/consul` path in Vault. Since it is possible to enable secrets engines at any location, @@ -162,11 +162,11 @@ To create a client token with service identities attached: - `token_type` DEPRECATED (1.11) `(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://developer.hashicorp.com/consul/api-docs/acl/legacy) + removed as of Consul 1.11.](/consul/api-docs/acl/legacy) - `policy` DEPRECATED (1.11) `(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://developer.hashicorp.com/consul/api-docs/acl/legacy) + removed as of Consul 1.11.](/consul/api-docs/acl/legacy) - `policies` DEPRECATED (1.11) `(list: )` - Same as `consul_policies`. Deprecated in favor of using `consul_policies`. @@ -179,10 +179,10 @@ To create a client token with service identities attached: 1.4 and greater. - `ttl` `(duration: "")` – Specifies the TTL for this role. If not - provided, the default Vault TTL is used. Uses [duration format strings](/docs/concepts/duration-format). + provided, the default Vault TTL is used. Uses [duration format strings](/vault/docs/concepts/duration-format). - `max_ttl` `(duration: "")` – Specifies the max TTL for this role. If not - provided, the default Vault Max TTL is used. Uses [duration format strings](/docs/concepts/duration-format). + provided, the default Vault Max TTL is used. Uses [duration format strings](/vault/docs/concepts/duration-format). ### Sample Payload @@ -197,12 +197,12 @@ To create a client token with policies defined in Consul: ### Parameters for Consul version below 1.4 - `lease` DEPRECATED (1.11) `(string: "")` – Specifies the lease for this role. - Uses [duration format strings](/docs/concepts/duration-format). If not + Uses [duration format strings](/vault/docs/concepts/duration-format). If not provided, the default Vault lease is used. - `policy` DEPRECATED (1.11) `(string: )` – Specifies the base64-encoded ACL policy. The ACL format can be found in the [Consul ACL - documentation](https://developer.hashicorp.com/consul/docs/security/acl/acl-legacy). This is + documentation](/consul/docs/security/acl/acl-legacy). This is required unless the `token_type` is `"management"`. ### Sample Payload diff --git a/website/content/api-docs/secret/cubbyhole.mdx b/website/content/api-docs/secret/cubbyhole.mdx index f384a06eb3..7361c95bb6 100644 --- a/website/content/api-docs/secret/cubbyhole.mdx +++ b/website/content/api-docs/secret/cubbyhole.mdx @@ -9,7 +9,7 @@ description: This is the API documentation for the Vault Cubbyhole secrets engin This is the API documentation for the Vault Cubbyhole secrets engine. For general information about the usage and operation of the Cubbyhole secrets engine, please see the -[Vault Cubbyhole documentation](/docs/secrets/cubbyhole). +[Vault Cubbyhole documentation](/vault/docs/secrets/cubbyhole). This documentation assumes the Cubbyhole secrets engine is enabled at the `/cubbyhole` path in Vault. Since it is possible to enable secrets engines at diff --git a/website/content/api-docs/secret/databases/cassandra.mdx b/website/content/api-docs/secret/databases/cassandra.mdx index 620ea6af58..88563e9708 100644 --- a/website/content/api-docs/secret/databases/cassandra.mdx +++ b/website/content/api-docs/secret/databases/cassandra.mdx @@ -17,7 +17,7 @@ configured roles for the Cassandra database. ## Configure Connection In addition to the parameters defined by the [Database -Secrets Engine](/api-docs/secret/databases#configure-connection), this plugin +Secrets Engine](/vault/api-docs/secret/databases#configure-connection), this plugin has a number of parameters to further configure a connection. | Method | Path | @@ -55,7 +55,7 @@ has a number of parameters to further configure a connection. private key; a certificate, private key, and issuing CA certificate; or just a CA certificate. The value in this field must be an encoded JSON object. For convenience format is the same as the output of the `issue` command from the `pki` secrets engine; see - [the pki documentation](/docs/secrets/pki). Only one of `pem_bundle` or `pem_json` can be specified. + [the pki documentation](/vault/docs/secrets/pki). Only one of `pem_bundle` or `pem_json` can be specified.
pem_json example @@ -97,7 +97,7 @@ vault write database/config/cassandra-example <...other fields> pem_json=@/path/ definition](https://github.com/gocql/gocql/blob/master/frame.go#L188) for valid options. -- `username_template` `(string)` - [Template](/docs/concepts/username-templating) describing how +- `username_template` `(string)` - [Template](/vault/docs/concepts/username-templating) describing how dynamic usernames are generated.
@@ -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-docs/secret/databases#create-role) in the database secrets engine docs. +API](/vault/api-docs/secret/databases#create-role) in the database secrets engine docs. ### Parameters diff --git a/website/content/api-docs/secret/databases/couchbase.mdx b/website/content/api-docs/secret/databases/couchbase.mdx index 86f5f81f55..fc19e9ae11 100644 --- a/website/content/api-docs/secret/databases/couchbase.mdx +++ b/website/content/api-docs/secret/databases/couchbase.mdx @@ -17,7 +17,7 @@ configured roles for the Couchbase database. ## Configure Connection In addition to the parameters defined by the [Database -Secrets Engine](/api-docs/secret/databases#configure-connection), this plugin +Secrets Engine](/vault/api-docs/secret/databases#configure-connection), this plugin has a number of parameters to further configure a connection. | Method | Path | @@ -47,7 +47,7 @@ has a number of parameters to further configure a connection. - `bucket_name` `(string: "")` - Required for Couchbase versions prior to 6.5.0. This is only used to verify vault's connection to the server. -- `username_template` `(string)` - [Template](/docs/concepts/username-templating) describing how +- `username_template` `(string)` - [Template](/vault/docs/concepts/username-templating) describing how dynamic usernames are generated.
@@ -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-docs/secret/databases#create-role) in the database secrets engine docs. +API](/vault/api-docs/secret/databases#create-role) in the database secrets engine docs. ### Parameters diff --git a/website/content/api-docs/secret/databases/elasticdb.mdx b/website/content/api-docs/secret/databases/elasticdb.mdx index ffdf87c6ed..88bee60af1 100644 --- a/website/content/api-docs/secret/databases/elasticdb.mdx +++ b/website/content/api-docs/secret/databases/elasticdb.mdx @@ -17,7 +17,7 @@ configured roles for Elasticsearch. ## Configure Connection In addition to the parameters defined by the [Database -Backend](/api-docs/secret/databases#configure-connection), this plugin +Backend](/vault/api-docs/secret/databases#configure-connection), this plugin has a number of parameters to further configure a connection. | Method | Path | @@ -35,7 +35,7 @@ has a number of parameters to further configure a connection. - `client_key` `(string: "")` - The path to the key for the Elasticsearch client to use for communication. - `tls_server_name` `(string: "")` - This, if set, is used to set the SNI host when connecting via TLS. - `insecure` `(bool: false)` - Not recommended. Default to `false`. Can be set to `true` to disable certificate verification. -- `username_template` `(string)` - [Template](/docs/concepts/username-templating) describing how dynamic usernames are generated. +- `username_template` `(string)` - [Template](/vault/docs/concepts/username-templating) describing how dynamic usernames are generated. - `use_old_xpack` `(bool: false)` - Can be set to `true` to use the `/_xpack/security` base API path when managing Elasticsearch. May be required for Elasticsearch server versions prior to 6. ### Sample Payload @@ -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-docs/secret/databases#create-role) in the database secrets engine docs. +API](/vault/api-docs/secret/databases#create-role) in the database secrets engine docs. ### Parameters diff --git a/website/content/api-docs/secret/databases/hanadb.mdx b/website/content/api-docs/secret/databases/hanadb.mdx index a9a76cacab..7bb6bcb91d 100644 --- a/website/content/api-docs/secret/databases/hanadb.mdx +++ b/website/content/api-docs/secret/databases/hanadb.mdx @@ -15,7 +15,7 @@ configured roles for the HANA database. ## Configure Connection In addition to the parameters defined by the [database -secrets engine](/api-docs/secret/databases#configure-connection), this plugin +secrets engine](/vault/api-docs/secret/databases#configure-connection), this plugin has a number of parameters to further configure a connection. | Method | Path | Produces | @@ -44,10 +44,10 @@ has a number of parameters to further configure a connection. - `password` `(string: "")` - The root credential password used in the connection URL. -- `username_template` `(string)` - [Template](/docs/concepts/username-templating) describing how dynamic usernames are generated. +- `username_template` `(string)` - [Template](/vault/docs/concepts/username-templating) describing how dynamic usernames are generated. - `disable_escaping` `(boolean: false)` - Turns off the escaping of special characters inside of the username - and password fields. See the [databases secrets engine docs](/docs/secrets/databases#disable-character-escaping) + and password fields. See the [databases secrets engine docs](/vault/docs/secrets/databases#disable-character-escaping) for more information. Defaults to `false`. ### Sample Payload @@ -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-docs/secret/databases#create-role) in the database secrets engine docs. +API](/vault/api-docs/secret/databases#create-role) in the database secrets engine docs. ### Parameters diff --git a/website/content/api-docs/secret/databases/index.mdx b/website/content/api-docs/secret/databases/index.mdx index 18cf9f1898..9150144855 100644 --- a/website/content/api-docs/secret/databases/index.mdx +++ b/website/content/api-docs/secret/databases/index.mdx @@ -9,7 +9,7 @@ description: Top page for database secrets engine information This is the API documentation for the Vault Database secrets engine. For general information about the usage and operation of the database secrets engine, please see the -[Vault database secrets engine documentation](/docs/secrets/databases). +[Vault database secrets engine documentation](/vault/docs/secrets/databases). This documentation assumes the database secrets engine is enabled at the `/database` path in Vault. Since it is possible to enable secrets engines at any @@ -51,7 +51,7 @@ list of additional parameters. information on support and formatting for this parameter. - `password_policy` `(string: "")` - The name of the - [password policy](/docs/concepts/password-policies) to use when generating passwords + [password policy](/vault/docs/concepts/password-policies) to use when generating passwords for this database. If not specified, this will use a default policy defined as: 20 characters with at least 1 uppercase, 1 lowercase, 1 number, and 1 dash character. @@ -90,7 +90,7 @@ are supported and any additional details about them. - `disable_escaping` `(boolean: false)` - Determines whether special characters in the username and password fields will be escaped. Useful for alternate connection string formats like ADO. More information regarding this parameter can be found on the - [databases secrets engine docs.](/docs/secrets/databases#disable-character-escaping) + [databases secrets engine docs.](/vault/docs/secrets/databases#disable-character-escaping) Defaults to `false`. ### Sample Payload @@ -301,7 +301,7 @@ This endpoint creates or updates a role definition. - `max_ttl` `(string/int: 0)` - Specifies the maximum TTL for the leases associated with this role. Accepts time suffixed strings (`1h`) or an integer - number of seconds. Defaults to `sys/mounts`'s default TTL time; 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. See also [The TTL General Case](/docs/concepts/tokens#the-general-case). + number of seconds. Defaults to `sys/mounts`'s default TTL time; 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. See also [The TTL General Case](/vault/docs/concepts/tokens#the-general-case). - `creation_statements` `(list: )` – Specifies the database statements executed to create and configure a user. See the plugin's API page diff --git a/website/content/api-docs/secret/databases/influxdb.mdx b/website/content/api-docs/secret/databases/influxdb.mdx index 56209f603b..681615726d 100644 --- a/website/content/api-docs/secret/databases/influxdb.mdx +++ b/website/content/api-docs/secret/databases/influxdb.mdx @@ -17,7 +17,7 @@ configured roles for the Influxdb database. ## Configure Connection In addition to the parameters defined by the [Database -Secrets Engine](/api-docs/secret/databases#configure-connection), this plugin +Secrets Engine](/vault/api-docs/secret/databases#configure-connection), this plugin has a number of parameters to further configure a connection. | Method | Path | @@ -52,11 +52,11 @@ has a number of parameters to further configure a connection. private key; a certificate, private key, and issuing CA certificate; or just a CA certificate. For convenience format is the same as the output of the `issue` command from the `pki` secrets engine; see - [the pki documentation](/docs/secrets/pki). + [the pki documentation](/vault/docs/secrets/pki). - `connect_timeout` `(string: "5s")` – Specifies the connection timeout to use. -- `username_template` `(string)` - [Template](/docs/concepts/username-templating) describing how +- `username_template` `(string)` - [Template](/vault/docs/concepts/username-templating) describing how dynamic usernames are generated. TLS works as follows: @@ -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-docs/secret/databases#create-role) in the database secrets engine docs. +API](/vault/api-docs/secret/databases#create-role) in the database secrets engine docs. ### Parameters diff --git a/website/content/api-docs/secret/databases/mongodb.mdx b/website/content/api-docs/secret/databases/mongodb.mdx index 158a4f7e91..b3f94a6b1a 100644 --- a/website/content/api-docs/secret/databases/mongodb.mdx +++ b/website/content/api-docs/secret/databases/mongodb.mdx @@ -17,7 +17,7 @@ configured roles for the MongoDB database. ## Configure Connection In addition to the parameters defined by the [Database -Backend](/api-docs/secret/databases#configure-connection), this plugin +Backend](/vault/api-docs/secret/databases#configure-connection), this plugin has a number of parameters to further configure a connection. | Method | Path | @@ -47,7 +47,7 @@ has a number of parameters to further configure a connection. - `tls_ca` `(string: "")` - x509 CA file for validating the certificate presented by the MongoDB server. Must be PEM encoded. -- `username_template` `(string)` - [Template](/docs/concepts/username-templating) describing how +- `username_template` `(string)` - [Template](/vault/docs/concepts/username-templating) describing how dynamic usernames are generated.
@@ -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-docs/secret/databases#create-role) in the database secrets engine docs. +API](/vault/api-docs/secret/databases#create-role) in the database secrets engine docs. ### Parameters diff --git a/website/content/api-docs/secret/databases/mongodbatlas.mdx b/website/content/api-docs/secret/databases/mongodbatlas.mdx index c01cd2aec8..36a2b05639 100644 --- a/website/content/api-docs/secret/databases/mongodbatlas.mdx +++ b/website/content/api-docs/secret/databases/mongodbatlas.mdx @@ -14,7 +14,7 @@ configured roles. ## Configure Connection In addition to the parameters defined by the [Database -Backend](/api-docs/secret/databases#configure-connection), this plugin +Backend](/vault/api-docs/secret/databases#configure-connection), this plugin has a number of parameters to further configure a connection. | Method | Path | @@ -26,7 +26,7 @@ has a number of parameters to further configure a connection. - `public_key` `(string: )` – The Public Programmatic API Key used to authenticate with the MongoDB Atlas API. - `private_key` `(string: )` - The Private Programmatic API Key used to connect with MongoDB Atlas API. - `project_id` `(string: )` - The [Project ID](https://docs.atlas.mongodb.com/api/#project-id) the Database User should be created within. -- `username_template` `(string)` - [Template](/docs/concepts/username-templating) describing how +- `username_template` `(string)` - [Template](/vault/docs/concepts/username-templating) describing how dynamic usernames are generated. @@ -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-docs/secret/databases#create-role) +revocation. For more information on configuring roles see the [Role API](/vault/api-docs/secret/databases#create-role) in the Database Secrets Engine docs. ### Parameters @@ -82,7 +82,7 @@ list the plugin does not support that statement type. - `max_ttl` `(string/int): 0` - Specifies the maximum TTL for the leases associated with this role. Accepts time suffixed strings (`1h`) or an integer number of seconds. Defaults to `sys/mounts` default TTL time; 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. See also [The TTL General Case](/docs/concepts/tokens#the-general-case). + but it is not allowed to be longer. See also [The TTL General Case](/vault/docs/concepts/tokens#the-general-case). ### Sample Creation Statement diff --git a/website/content/api-docs/secret/databases/mssql.mdx b/website/content/api-docs/secret/databases/mssql.mdx index 7d750d7527..29d46da81f 100644 --- a/website/content/api-docs/secret/databases/mssql.mdx +++ b/website/content/api-docs/secret/databases/mssql.mdx @@ -15,7 +15,7 @@ configured roles for the MSSQL database. ## Configure Connection In addition to the parameters defined by the [Database -Backend](/api-docs/secret/databases#configure-connection), this plugin +Backend](/vault/api-docs/secret/databases#configure-connection), this plugin has a number of parameters to further configure a connection. | Method | Path | @@ -44,7 +44,7 @@ has a number of parameters to further configure a connection. - `password` `(string: "")` - The root credential password used in the connection URL. -- `username_template` `(string)` - [Template](/docs/concepts/username-templating) describing how +- `username_template` `(string)` - [Template](/vault/docs/concepts/username-templating) describing how dynamic usernames are generated. - `contained_db` `(bool: false)` - If set, specifies that the connection being configured is to a @@ -52,7 +52,7 @@ has a number of parameters to further configure a connection. like AzureSQL. - `disable_escaping` `(boolean: false)` - Turns off the escaping of special characters inside of the username - and password fields. See the [databases secrets engine docs](/docs/secrets/databases#disable-character-escaping) + and password fields. See the [databases secrets engine docs](/vault/docs/secrets/databases#disable-character-escaping) for more information. Defaults to `false`.
@@ -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-docs/secret/databases#create-role) in the database secrets engine docs. +API](/vault/api-docs/secret/databases#create-role) in the database secrets engine docs. ### Parameters diff --git a/website/content/api-docs/secret/databases/mysql-maria.mdx b/website/content/api-docs/secret/databases/mysql-maria.mdx index 0164853f33..62f4b769b5 100644 --- a/website/content/api-docs/secret/databases/mysql-maria.mdx +++ b/website/content/api-docs/secret/databases/mysql-maria.mdx @@ -17,7 +17,7 @@ configured roles for the MySQL database. ## Configure Connection In addition to the parameters defined by the [Database -Backend](/api-docs/secret/databases#configure-connection), this plugin +Backend](/vault/api-docs/secret/databases#configure-connection), this plugin has a number of parameters to further configure a connection. | Method | Path | @@ -58,11 +58,11 @@ has a number of parameters to further configure a connection. - `tls_skip_verify` `(boolean: false)` - When set to true, disables the server certificate verification. Setting this to true is not recommended for production. -- `username_template` `(string)` - [Template](/docs/concepts/username-templating) describing how +- `username_template` `(string)` - [Template](/vault/docs/concepts/username-templating) describing how dynamic usernames are generated. - `disable_escaping` `(boolean: false)` - Turns off the escaping of special characters inside of the username - and password fields. See the [databases secrets engine docs](/docs/secrets/databases#disable-character-escaping) + and password fields. See the [databases secrets engine docs](/vault/docs/secrets/databases#disable-character-escaping) for more information. Defaults to `false`. **Default Username Templates:** @@ -150,7 +150,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-docs/secret/databases#create-role) in the database secrets engine docs. +API](/vault/api-docs/secret/databases#create-role) in the database secrets engine docs. ### Parameters diff --git a/website/content/api-docs/secret/databases/oracle.mdx b/website/content/api-docs/secret/databases/oracle.mdx index ed10da398c..8dd5b063bb 100644 --- a/website/content/api-docs/secret/databases/oracle.mdx +++ b/website/content/api-docs/secret/databases/oracle.mdx @@ -15,7 +15,7 @@ configured roles for the Oracle database. ## Configure Connection In addition to the parameters defined by the [Database -Backend](/api-docs/secret/databases#configure-connection), this plugin +Backend](/vault/api-docs/secret/databases#configure-connection), this plugin has a number of parameters to further configure a connection. | Method | Path | @@ -41,11 +41,11 @@ has a number of parameters to further configure a connection. - `password` `(string: "")` - The root credential password used in the connection URL. -- `username_template` `(string)` - [Template](/docs/concepts/username-templating) describing how +- `username_template` `(string)` - [Template](/vault/docs/concepts/username-templating) describing how dynamic usernames are generated. - `disable_escaping` `(boolean: false)` - Turns off the escaping of special characters inside of the username - and password fields. See the [databases secrets engine docs](/docs/secrets/databases#disable-character-escaping) + and password fields. See the [databases secrets engine docs](/vault/docs/secrets/databases#disable-character-escaping) for more information. Defaults to `false`.
@@ -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-docs/secret/databases#create-role) in the database secrets engine docs. +API](/vault/api-docs/secret/databases#create-role) in the database secrets engine docs. ### Parameters diff --git a/website/content/api-docs/secret/databases/postgresql.mdx b/website/content/api-docs/secret/databases/postgresql.mdx index d2db58b903..68667d313e 100644 --- a/website/content/api-docs/secret/databases/postgresql.mdx +++ b/website/content/api-docs/secret/databases/postgresql.mdx @@ -15,7 +15,7 @@ configured roles for the PostgreSQL database. ## Configure Connection In addition to the parameters defined by the [Database -Backend](/api-docs/secret/databases#configure-connection), this plugin +Backend](/vault/api-docs/secret/databases#configure-connection), this plugin has a number of parameters to further configure a connection. | Method | Path | @@ -48,11 +48,11 @@ has a number of parameters to further configure a connection. - `password` `(string: "")` - The root credential password used in the connection URL. -- `username_template` `(string)` - [Template](/docs/concepts/username-templating) describing how +- `username_template` `(string)` - [Template](/vault/docs/concepts/username-templating) describing how dynamic usernames are generated. - `disable_escaping` `(boolean: false)` - Turns off the escaping of special characters inside of the username - and password fields. See the [databases secrets engine docs](/docs/secrets/databases#disable-character-escaping) + and password fields. See the [databases secrets engine docs](/vault/docs/secrets/databases#disable-character-escaping) for more information. Defaults to `false`.
@@ -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-docs/secret/databases#create-role) in the database secrets engine docs. +API](/vault/api-docs/secret/databases#create-role) in the database secrets engine docs. ### Parameters diff --git a/website/content/api-docs/secret/databases/redis.mdx b/website/content/api-docs/secret/databases/redis.mdx index b05964741a..9d0e096b59 100644 --- a/website/content/api-docs/secret/databases/redis.mdx +++ b/website/content/api-docs/secret/databases/redis.mdx @@ -15,7 +15,7 @@ configured roles for the Redis database. ## Configure Connection In addition to the parameters defined by the [Database -Secrets Engine](/api-docs/secret/databases#configure-connection), this plugin +Secrets Engine](/vault/api-docs/secret/databases#configure-connection), this plugin has a number of parameters to further configure a connection. | Method | Path | @@ -64,7 +64,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-docs/secret/databases#create-role) in the database secrets engine docs. +API](/vault/api-docs/secret/databases#create-role) in the database secrets engine docs. ### Parameters diff --git a/website/content/api-docs/secret/databases/rediselasticache.mdx b/website/content/api-docs/secret/databases/rediselasticache.mdx index 31e741c559..25a18e3ad9 100644 --- a/website/content/api-docs/secret/databases/rediselasticache.mdx +++ b/website/content/api-docs/secret/databases/rediselasticache.mdx @@ -14,7 +14,7 @@ configured roles for the Redis ElastiCache database. ## Configure Connection In addition to the parameters defined by the [Database -Secrets Engine](/api-docs/secret/databases#configure-connection), this plugin +Secrets Engine](/vault/api-docs/secret/databases#configure-connection), this plugin has a number of parameters to further configure a connection. | Method | Path | diff --git a/website/content/api-docs/secret/databases/redshift.mdx b/website/content/api-docs/secret/databases/redshift.mdx index d60fbe8f98..30b05a729d 100644 --- a/website/content/api-docs/secret/databases/redshift.mdx +++ b/website/content/api-docs/secret/databases/redshift.mdx @@ -15,7 +15,7 @@ configured roles for the Redshift database. ## Configure Connection In addition to the parameters defined by the [Database -Backend](/api-docs/secret/databases#configure-connection), this plugin +Backend](/vault/api-docs/secret/databases#configure-connection), this plugin has a number of parameters to further configure a connection. | Method | Path | @@ -44,10 +44,10 @@ has a number of parameters to further configure a connection. - `password` `(string: "")` - The root credential password used in the connection URL. -- `username_template` `(string)` - [Template](/docs/concepts/username-templating) describing how dynamic usernames are generated. +- `username_template` `(string)` - [Template](/vault/docs/concepts/username-templating) describing how dynamic usernames are generated. - `disable_escaping` `(boolean: false)` - Turns off the escaping of special characters inside of the username - and password fields. See the [databases secrets engine docs](/docs/secrets/databases#disable-character-escaping) + and password fields. See the [databases secrets engine docs](/vault/docs/secrets/databases#disable-character-escaping) for more information. Defaults to `false`. ### Sample Payload @@ -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-docs/secret/databases#create-role) in the database secrets engine docs. +API](/vault/api-docs/secret/databases#create-role) in the database secrets engine docs. ### Parameters diff --git a/website/content/api-docs/secret/databases/snowflake.mdx b/website/content/api-docs/secret/databases/snowflake.mdx index de62c12dbc..2bad673e72 100644 --- a/website/content/api-docs/secret/databases/snowflake.mdx +++ b/website/content/api-docs/secret/databases/snowflake.mdx @@ -15,7 +15,7 @@ configured roles for the Snowflake database. ## Configure Connection In addition to the parameters defined by the [Database -Backend](/api-docs/secret/databases#configure-connection), this plugin +Backend](/vault/api-docs/secret/databases#configure-connection), this plugin has a number of parameters to further configure a connection. | Method | Path | @@ -44,10 +44,10 @@ has a number of parameters to further configure a connection. - `password` `(string: "")` - The root credential password used in the connection URL. -- `username_template` `(string)` - [Template](/docs/concepts/username-templating) describing how dynamic usernames are generated. +- `username_template` `(string)` - [Template](/vault/docs/concepts/username-templating) describing how dynamic usernames are generated. - `disable_escaping` `(boolean: false)` - Turns off the escaping of special characters inside of the username - and password fields. See the [databases secrets engine docs](/docs/secrets/databases#disable-character-escaping) + and password fields. See the [databases secrets engine docs](/vault/docs/secrets/databases#disable-character-escaping) for more information. Defaults to `false`. ### Sample Payload @@ -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-docs/secret/databases#create-role) in the database secrets engine docs. +API](/vault/api-docs/secret/databases#create-role) in the database secrets engine docs. ### Parameters @@ -93,7 +93,7 @@ list the plugin does not support that statement type. array. The `{{name}}` and `{{expiration}}` values will be substituted. The following values will be substituted depending on the - [credential_type](/api-docs/secret/databases#credential_type) of the role: + [credential_type](/vault/api-docs/secret/databases#credential_type) of the role: - `{{password}}` is substituted for the `password` credential type - `{{public_key}}` is substituted for the `rsa_private_key` credential type @@ -125,7 +125,7 @@ list the plugin does not support that statement type. array. The `{{name}}` value will be substituted. The following values will be substituted depending on the - [credential_type](/api-docs/secret/databases#credential_type) of the role: + [credential_type](/vault/api-docs/secret/databases#credential_type) of the role: - `{{password}}` is substituted for the `password` credential type - `{{public_key}}` is substituted for the `rsa_private_key` credential type diff --git a/website/content/api-docs/secret/gcp.mdx b/website/content/api-docs/secret/gcp.mdx index c05fd0d8cc..02301cf760 100644 --- a/website/content/api-docs/secret/gcp.mdx +++ b/website/content/api-docs/secret/gcp.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for the Vault Google Cloud secrets en This is the API documentation for the Vault Google Cloud Platform (GCP) secrets engine. For general information about the usage and operation of -the GCP secrets engine, please see [these docs](/docs/secrets/gcp). +the GCP secrets engine, please see [these docs](/vault/docs/secrets/gcp). This documentation assumes the GCP secrets engine is enabled at the `/gcp` path in Vault. Since it is possible to mount secrets engines at any path, please @@ -25,15 +25,15 @@ This endpoint configures shared information for the secrets engine. ### Parameters - `credentials` (`string:""`) - JSON credentials (either file contents or '@path/to/file') - See docs for [alternative ways](/docs/secrets/gcp#setup) + See docs for [alternative ways](/vault/docs/secrets/gcp#setup) to pass in to this parameter, as well as the - [required permissions](/docs/secrets/gcp#required-permissions). + [required permissions](/vault/docs/secrets/gcp#required-permissions). - `ttl` (`int: 0 || string:"0s"`) – Specifies default config TTL for long-lived credentials - (i.e. service account keys). Uses [duration format strings](/docs/concepts/duration-format). + (i.e. service account keys). Uses [duration format strings](/vault/docs/concepts/duration-format). - `max_ttl` (`int: 0 || string:"0s"`)– Specifies the maximum config TTL for long-lived credentials - (i.e. service account keys). Uses [duration format strings](/docs/concepts/duration-format).\*\* + (i.e. service account keys). Uses [duration format strings](/vault/docs/concepts/duration-format).\*\* ### Sample Payload @@ -115,7 +115,7 @@ $ curl \ | :----- | :------------------- | | `POST` | `/gcp/roleset/:name` | -This method allows you to create a roleset or update an existing roleset. See [docs](/docs/secrets/gcp#bindings) for the GCP secrets backend +This method allows you to create a roleset or update an existing roleset. See [docs](/vault/docs/secrets/gcp#bindings) for the GCP secrets backend to learn more about what happens when you create or update a roleset. **If you update a roleset's bindings, this will effectively revoke any secrets @@ -145,7 +145,7 @@ generated under this roleset.** #### Sample Bindings: -See [bindings format docs](/docs/secrets/gcp#bindings) for more information. +See [bindings format docs](/vault/docs/secrets/gcp#bindings) for more information. ```hcl resource "//cloudresourcemanager.googleapis.com/projects/mygcpproject" { @@ -307,7 +307,7 @@ $ curl \ | :----- | :-------------------------- | | `POST` | `/gcp/static-account/:name` | -This method allows you to create a static account or update an existing static account. See [docs](/docs/secrets/gcp#bindings) for the GCP secrets backend +This method allows you to create a static account or update an existing static account. See [docs](/vault/docs/secrets/gcp#bindings) for the GCP secrets backend to learn more about what happens when you create or update a static account. **If you update a static account's bindings, this will effectively revoke any secrets @@ -337,7 +337,7 @@ generated under this static account.** #### Sample Bindings: -See [bindings format docs](/docs/secrets/gcp#bindings) for more information. +See [bindings format docs](/vault/docs/secrets/gcp#bindings) for more information. ```hcl resource "//cloudresourcemanager.googleapis.com/projects/mygcpproject" { @@ -493,7 +493,7 @@ impersonated account. - `token_scopes` (`array: []`): List of OAuth scopes to assign to access tokens generated under this impersonation account. - `ttl` (`duration: ""`): Lifetime of the token generated. Defaults to 1 hour and - is limited to a maximum of 12 hours. Uses [duration format strings](/docs/concepts/duration-format). + is limited to a maximum of 12 hours. Uses [duration format strings](/vault/docs/concepts/duration-format). ### Sample Payload @@ -693,7 +693,7 @@ or the system default if config was not defined. `enum(`[`ServiceAccountKeyAlgorithm`](https://cloud.google.com/iam/reference/rest/v1/projects.serviceAccounts.keys#ServiceAccountKeyAlgorithm)`)` - `key_type` (`string:"TYPE_GOOGLE_CREDENTIALS_FILE`): Private key type to generate. Defaults to JSON credentials file. Accepted values are `enum(`[`ServiceAccountPrivateKeyType`](https://cloud.google.com/iam/reference/rest/v1/projects.serviceAccounts.keys#ServiceAccountPrivateKeyType)`)` -- `ttl` (`string: ""`): Specifies the Time To Live value provided using a [duration format string](/docs/concepts/duration-format). If not set, uses the system default value. +- `ttl` (`string: ""`): Specifies the Time To Live value provided using a [duration format string](/vault/docs/concepts/duration-format). If not set, uses the system default value. ### Sample Payload @@ -742,5 +742,5 @@ $ curl \ ## Revoking/Renewing Secrets -See docs on how to [renew](/api-docs/system/leases#renew-lease) and [revoke](/api-docs/system/leases#revoke-lease) leases. +See docs on how to [renew](/vault/api-docs/system/leases#renew-lease) and [revoke](/vault/api-docs/system/leases#revoke-lease) leases. Note this only applies to service account keys. diff --git a/website/content/api-docs/secret/gcpkms.mdx b/website/content/api-docs/secret/gcpkms.mdx index ef2676fbd9..5ffaab5089 100644 --- a/website/content/api-docs/secret/gcpkms.mdx +++ b/website/content/api-docs/secret/gcpkms.mdx @@ -9,7 +9,7 @@ description: This is the API documentation for the Vault Google Cloud KMS secret This is the API documentation for the Vault Google Cloud KMS secrets engine. For general information about the usage and operation of the Google Cloud KMS secrets engine, please see the -[Google Cloud KMS documentation](/docs/secrets/gcpkms). +[Google Cloud KMS documentation](/vault/docs/secrets/gcpkms). This documentation assumes the Google Cloud KMS secrets engine is enabled at the `/gcpkms` path in Vault. Since it is possible to enable secrets engines at any diff --git a/website/content/api-docs/secret/identity/entity.mdx b/website/content/api-docs/secret/identity/entity.mdx index 8eb2c0a4e1..c5f7793534 100644 --- a/website/content/api-docs/secret/identity/entity.mdx +++ b/website/content/api-docs/secret/identity/entity.mdx @@ -398,7 +398,7 @@ $ curl \ This endpoint merges many entities into one entity. Additionally, all groups associated with `from_entity_ids` are merged with those of `to_entity_id`. Note that if these entities contain aliases sharing the same mount accessor, the merge will fail unless `conflicting_alias_ids_to_keep` is present, and entities must be merged one at a time. This is because each entity can only have one alias with each mount accessor - for more -information, see the [identity concepts page](/docs/concepts/identity). +information, see the [identity concepts page](/vault/docs/concepts/identity). | Method | Path | | :----- | :----------------------- | diff --git a/website/content/api-docs/secret/identity/index.mdx b/website/content/api-docs/secret/identity/index.mdx index 2c5f20bebb..d423551830 100644 --- a/website/content/api-docs/secret/identity/index.mdx +++ b/website/content/api-docs/secret/identity/index.mdx @@ -8,15 +8,15 @@ description: This is the API documentation for the Vault Identity secrets engine This is the API documentation for the Vault Identity secrets engine. For general information about the usage and operation of the Identity secrets engine, please -see the [Vault Identity documentation](/docs/secrets/identity). +see the [Vault Identity documentation](/vault/docs/secrets/identity). ## API Sections -- [Entity](/api-docs/secret/identity/entity) -- [Entity Alias](/api-docs/secret/identity/entity-alias) -- [Group](/api-docs/secret/identity/group) -- [Group Alias](/api-docs/secret/identity/group-alias) -- [Identity Tokens](/api-docs/secret/identity/tokens) -- [Lookup](/api-docs/secret/identity/lookup) -- [OIDC Provider](/api-docs/secret/identity/oidc-provider) -- [MFA](/api-docs/secret/identity/mfa) +- [Entity](/vault/api-docs/secret/identity/entity) +- [Entity Alias](/vault/api-docs/secret/identity/entity-alias) +- [Group](/vault/api-docs/secret/identity/group) +- [Group Alias](/vault/api-docs/secret/identity/group-alias) +- [Identity Tokens](/vault/api-docs/secret/identity/tokens) +- [Lookup](/vault/api-docs/secret/identity/lookup) +- [OIDC Provider](/vault/api-docs/secret/identity/oidc-provider) +- [MFA](/vault/api-docs/secret/identity/mfa) diff --git a/website/content/api-docs/secret/identity/mfa/duo.mdx b/website/content/api-docs/secret/identity/mfa/duo.mdx index bf2d8675c8..d6fb0a05aa 100644 --- a/website/content/api-docs/secret/identity/mfa/duo.mdx +++ b/website/content/api-docs/secret/identity/mfa/duo.mdx @@ -103,7 +103,7 @@ $ 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-docs/secret/identity/mfa/login-enforcement). +by a [login enforcement](/vault/api-docs/secret/identity/mfa/login-enforcement). | Method | Path | | :------- | :----------------------------- | diff --git a/website/content/api-docs/secret/identity/mfa/index.mdx b/website/content/api-docs/secret/identity/mfa/index.mdx index ab505c6215..5f441af358 100644 --- a/website/content/api-docs/secret/identity/mfa/index.mdx +++ b/website/content/api-docs/secret/identity/mfa/index.mdx @@ -9,18 +9,18 @@ description: >- ## Supported MFA types. -- [TOTP](/api-docs/secret/identity/mfa/totp) +- [TOTP](/vault/api-docs/secret/identity/mfa/totp) -- [Okta](/api-docs/secret/identity/mfa/okta) +- [Okta](/vault/api-docs/secret/identity/mfa/okta) -- [Duo](/api-docs/secret/identity/mfa/duo) +- [Duo](/vault/api-docs/secret/identity/mfa/duo) -- [PingID](/api-docs/secret/identity/mfa/pingid) +- [PingID](/vault/api-docs/secret/identity/mfa/pingid) ## Other -- [Login Enforcement](/api-docs/secret/identity/mfa/login-enforcement) -- [MFA Validate](/api-docs/system/mfa/validate) +- [Login Enforcement](/vault/api-docs/secret/identity/mfa/login-enforcement) +- [MFA Validate](/vault/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 diff --git a/website/content/api-docs/secret/identity/mfa/okta.mdx b/website/content/api-docs/secret/identity/mfa/okta.mdx index 8e63db5394..06c41ce1ca 100644 --- a/website/content/api-docs/secret/identity/mfa/okta.mdx +++ b/website/content/api-docs/secret/identity/mfa/okta.mdx @@ -96,7 +96,7 @@ $ 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-docs/secret/identity/mfa/login-enforcement). +by a [login enforcement](/vault/api-docs/secret/identity/mfa/login-enforcement). | Method | Path | | :------- | :------------------------------ | diff --git a/website/content/api-docs/secret/identity/mfa/pingid.mdx b/website/content/api-docs/secret/identity/mfa/pingid.mdx index d61f2e65a7..dfe8a17283 100644 --- a/website/content/api-docs/secret/identity/mfa/pingid.mdx +++ b/website/content/api-docs/secret/identity/mfa/pingid.mdx @@ -90,7 +90,7 @@ $ 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-docs/secret/identity/mfa/login-enforcement). +by a [login enforcement](/vault/api-docs/secret/identity/mfa/login-enforcement). | Method | Path | | :------- | :-------------------------------- | diff --git a/website/content/api-docs/secret/identity/mfa/totp.mdx b/website/content/api-docs/secret/identity/mfa/totp.mdx index 404c2f609e..58c3e12254 100644 --- a/website/content/api-docs/secret/identity/mfa/totp.mdx +++ b/website/content/api-docs/secret/identity/mfa/totp.mdx @@ -104,7 +104,7 @@ $ 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-docs/secret/identity/mfa/login-enforcement). +by a [login enforcement](/vault/api-docs/secret/identity/mfa/login-enforcement). | Method | Path | | :------- | :------------------------------ | diff --git a/website/content/api-docs/secret/identity/oidc-provider.mdx b/website/content/api-docs/secret/identity/oidc-provider.mdx index a35d27c6d0..0688f6b627 100644 --- a/website/content/api-docs/secret/identity/oidc-provider.mdx +++ b/website/content/api-docs/secret/identity/oidc-provider.mdx @@ -87,7 +87,7 @@ This endpoint returns a list of all OIDC providers. ### Query Parameters - `allowed_client_id` `(string: )` – Filters the list of OIDC providers to those - that allow the given client ID in their set of [allowed_client_ids](/api-docs/secret/identity/oidc-provider#allowed_client_ids). + that allow the given client ID in their set of [allowed_client_ids](/vault/api-docs/secret/identity/oidc-provider#allowed_client_ids). ### Sample Request @@ -152,7 +152,7 @@ This endpoint creates or updates a scope. - `name` `(string: )` – The name of the scope. This parameter is specified as part of the URL. The `openid` scope name is reserved. -- `template` `(string: )` - The [JSON template](/docs/concepts/oidc-provider#scopes) +- `template` `(string: )` - The [JSON template](/vault/docs/concepts/oidc-provider#scopes) string for the scope. This may be provided as escaped JSON or base64 encoded JSON. - `description` `(string: )` – A description of the scope. @@ -269,9 +269,9 @@ This endpoint creates or updates a client. - `name` `(string: )` – The name of the client. This parameter is specified as part of the URL. -- `key` `(string: "default")` – A reference to a [named key](/api-docs/secret/identity/tokens#create-a-named-key) +- `key` `(string: "default")` – A reference to a [named key](/vault/api-docs/secret/identity/tokens#create-a-named-key) resource. This key will be used to sign ID tokens for the client. This cannot be modified - after creation. If not supplied, defaults to the built-in [default key](/docs/concepts/oidc-provider#keys). + after creation. If not supplied, defaults to the built-in [default key](/vault/docs/concepts/oidc-provider#keys). - `redirect_uris` `([]string: )` - Redirection URI values used by the client. One of these values must exactly match the `redirect_uri` parameter value used in each [authentication request](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest). @@ -280,7 +280,7 @@ This endpoint creates or updates a client. the client. Client assignments limit the Vault entities and groups that are allowed to authenticate through the client. By default, no Vault entities are allowed. To allow all Vault entities to authenticate through the client, supply the built-in - [allow_all](/docs/concepts/oidc-provider#assignments) assignment. + [allow_all](/vault/docs/concepts/oidc-provider#assignments) assignment. - `client_type` `(string: "confidential")` – The [client type](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1) based on its ability to maintain confidentiality of credentials. This cannot be modified @@ -300,11 +300,11 @@ This endpoint creates or updates a client. for the authorization code flow - `id_token_ttl` `(int or duration: "24h")` – The time-to-live for ID tokens obtained by the client. - Accepts [duration format strings](/docs/concepts/duration-format). The value should be less than the `verification_ttl` + Accepts [duration format strings](/vault/docs/concepts/duration-format). The value should be less than the `verification_ttl` on the key. - `access_token_ttl` `(int or duration: "24h")` – The time-to-live for access tokens obtained by the client. - Accepts [duration format strings](/docs/concepts/duration-format). + Accepts [duration format strings](/vault/docs/concepts/duration-format). ### Sample Payload @@ -440,9 +440,9 @@ This endpoint creates or updates an assignment. - `name` `(string: )` – The name of the assignment. This parameter is specified as part of the URL. -- `entity_ids` `([]string: )` - A list of Vault [entity](https://www.vaultproject.io/docs/secrets/identity#entities-and-aliases) IDs. +- `entity_ids` `([]string: )` - A list of Vault [entity](/vault/docs/secrets/identity#entities-and-aliases) IDs. -- `group_ids` `([]string: )` – A list of Vault [group](https://www.vaultproject.io/docs/secrets/identity#identity-groups) IDs. +- `group_ids` `([]string: )` – A list of Vault [group](/vault/docs/secrets/identity#identity-groups) IDs. ### Sample Payload diff --git a/website/content/api-docs/secret/identity/tokens.mdx b/website/content/api-docs/secret/identity/tokens.mdx index ac453e0ff6..a952b08be4 100644 --- a/website/content/api-docs/secret/identity/tokens.mdx +++ b/website/content/api-docs/secret/identity/tokens.mdx @@ -86,9 +86,9 @@ This endpoint creates or updates a named key which is used by a role to sign tok - `name` `(string)` – Name of the named key. -- `rotation_period` `(int or time string: "24h")` - How often to generate a new signing key. Uses [duration format strings](/docs/concepts/duration-format). +- `rotation_period` `(int or time string: "24h")` - How often to generate a new signing key. Uses [duration format strings](/vault/docs/concepts/duration-format). -- `verification_ttl` `(int or time string: "24h")` - Controls how long the public portion of a signing key will be available for verification after being rotated. Uses [duration format strings](/docs/concepts/duration-format). +- `verification_ttl` `(int or time string: "24h")` - Controls how long the public portion of a signing key will be available for verification after being rotated. Uses [duration format strings](/vault/docs/concepts/duration-format). - `allowed_client_ids` `(list: [])` - Array of role client ids allowed to use this key for signing. If empty, no roles are allowed. If "\*", all roles are allowed. @@ -244,7 +244,7 @@ Create or update a role. ID tokens are generated against a role and signed again - `client_id` `(string: )` - Optional client ID. A random ID will be generated if left unset. -- `ttl` `(int or time string: "24h")` - TTL of the tokens generated against the role. Uses [duration format strings](/docs/concepts/duration-format). +- `ttl` `(int or time string: "24h")` - TTL of the tokens generated against the role. Uses [duration format strings](/vault/docs/concepts/duration-format). ### Sample Payload diff --git a/website/content/api-docs/secret/key-management/gcpkms.mdx b/website/content/api-docs/secret/key-management/gcpkms.mdx index 824e16f5a5..b4b56efd20 100644 --- a/website/content/api-docs/secret/key-management/gcpkms.mdx +++ b/website/content/api-docs/secret/key-management/gcpkms.mdx @@ -38,7 +38,7 @@ the given parameter values. - `credentials` `(map: nil)` – The credentials to use for authentication with GCP Cloud KMS. Supplying values for this parameter is optional, as credentials may also be specified - as environment variables. See the [authentication](/docs/secrets/key-management/gcpkms#authentication) + as environment variables. See the [authentication](/vault/docs/secrets/key-management/gcpkms#authentication) section for details on precedence. - `service_account_file` `(string: )` - The path to a Google service account key file. The diff --git a/website/content/api-docs/secret/key-management/index.mdx b/website/content/api-docs/secret/key-management/index.mdx index dcdb339dbc..1969011791 100644 --- a/website/content/api-docs/secret/key-management/index.mdx +++ b/website/content/api-docs/secret/key-management/index.mdx @@ -8,7 +8,7 @@ description: The API documentation for the Key Management secrets engine. This is the API documentation for the Key Management secrets engine. For general information about the usage and operation of the secrets engine, please see the -[Key Management secrets engine documentation](/docs/secrets/key-management). +[Key Management secrets engine documentation](/vault/docs/secrets/key-management). This documentation assumes the Key Management secrets engine is enabled at the `/keymgmt` path in Vault. Since it is possible to enable secrets engines at any @@ -265,7 +265,7 @@ the given parameter values. - `provider` `(string: )` – Specifies the name of a KMS provider that's external to Vault. Cannot be changed after creation. For more information about each provider, refer to - the [KMS Providers](/docs/secrets/key-management#kms-providers) section. The following values + the [KMS Providers](/vault/docs/secrets/key-management#kms-providers) section. The following values are supported: - `azurekeyvault` diff --git a/website/content/api-docs/secret/kmip.mdx b/website/content/api-docs/secret/kmip.mdx index bf97b52c9f..35efae51c8 100644 --- a/website/content/api-docs/secret/kmip.mdx +++ b/website/content/api-docs/secret/kmip.mdx @@ -10,7 +10,7 @@ description: This is the API documentation for the Vault KMIP secrets engine. This is the API documentation for the Vault KMIP secrets engine. For general information about the usage and operation of -the KMIP secrets engine, please see [these docs](/docs/secrets/kmip). +the KMIP secrets engine, please see [these docs](/vault/docs/secrets/kmip). This documentation assumes the KMIP secrets engine is enabled at the `/kmip` path in Vault. Since it is possible to mount secrets engines at any path, please diff --git a/website/content/api-docs/secret/kubernetes.mdx b/website/content/api-docs/secret/kubernetes.mdx index d3f0edcfb1..5098aae38a 100644 --- a/website/content/api-docs/secret/kubernetes.mdx +++ b/website/content/api-docs/secret/kubernetes.mdx @@ -10,7 +10,7 @@ description: This is the API documentation for the Vault Kubernetes secrets engi This is the API documentation for the Vault Kubernetes secrets engine. To learn more about the usage and operation, see the -[Kubernetes secrets engine documentation](/docs/secrets/kubernetes). +[Kubernetes secrets engine documentation](/vault/docs/secrets/kubernetes). This documentation assumes the Kubernetes secrets engine is mounted at the `/kubernetes` path in Vault. Since it is possible to enable secrets engines at @@ -136,15 +136,15 @@ Only one of `service_account_name`, `kubernetes_role_name` or namespaces in which credentials can be generated. Accepts either a JSON or YAML object. The value should be of type [LabelSelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.24/#labelselector-v1-meta) - as illustrated in [Sample Payload 4](/api-docs/secret/kubernetes#sample-payload-4) and - [Sample Payload 5](/api-docs/secret/kubernetes#sample-payload-5) below. + as illustrated in [Sample Payload 4](/vault/api-docs/secret/kubernetes#sample-payload-4) and + [Sample Payload 5](/vault/api-docs/secret/kubernetes#sample-payload-5) below. If set with `allowed_kubernetes_namespaces`, the conditions are `OR`ed. - `token_max_ttl` `(string: "")` - The maximum TTL for generated Kubernetes tokens, specified in seconds or as a Go duration format string, e.g. `"1h"`. - If not set or set to 0, the [system default](/docs/configuration#max_lease_ttl) will be used. + If not set or set to 0, the [system default](/vault/docs/configuration#max_lease_ttl) will be used. - `token_default_ttl` `(string: "")` - The default TTL for generated Kubernetes tokens, specified in seconds or as a Go duration format string, e.g. `"1h"`. - If not set or set to 0, the [system default](/docs/configuration#default_lease_ttl) will be used. + If not set or set to 0, the [system default](/vault/docs/configuration#default_lease_ttl) will be used. - `service_account_name` `(string: "")` - The pre-existing service account to generate tokens for. Mutually exclusive with all role parameters. If set, only a Kubernetes token will be created when credentials are requested. See the @@ -164,10 +164,10 @@ Only one of `service_account_name`, `kubernetes_role_name` or [PolicyRule](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#policyrule-v1-rbac-authorization-k8s-io) objects, as illustrated in the [Kubernetes RBAC documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) - and [Sample Payload 3](/api-docs/secret/kubernetes#sample-payload-3) below. + and [Sample Payload 3](/vault/api-docs/secret/kubernetes#sample-payload-3) below. - `name_template` `(string: "")` - The name template to use when generating service accounts, roles and role bindings. If unset, a default template is - used. See [username templating](https://www.vaultproject.io/docs/concepts/username-templating) + used. See [username templating](/vault/docs/concepts/username-templating) for details on how to write a custom template. - `extra_annotations` `(map: nil)` - Additional annotations to apply to all generated Kubernetes objects. See the diff --git a/website/content/api-docs/secret/kv/index.mdx b/website/content/api-docs/secret/kv/index.mdx index ea7f37d0c7..9fcc209dff 100644 --- a/website/content/api-docs/secret/kv/index.mdx +++ b/website/content/api-docs/secret/kv/index.mdx @@ -8,8 +8,8 @@ description: This is the API documentation for the Vault KV secrets engine. This backend can be run in one of two versions. Each of which have a distinct API. Choose the version below you are running. For more information on the KV secrets -engine see the [Vault kv documentation](/docs/secrets/kv). +engine see the [Vault kv documentation](/vault/docs/secrets/kv). -- [KV Version 1 API](/api-docs/secret/kv/kv-v1) +- [KV Version 1 API](/vault/api-docs/secret/kv/kv-v1) -- [KV Version 2 API](/api-docs/secret/kv/kv-v2) +- [KV Version 2 API](/vault/api-docs/secret/kv/kv-v2) diff --git a/website/content/api-docs/secret/kv/kv-v1.mdx b/website/content/api-docs/secret/kv/kv-v1.mdx index 359e6a557b..8ef9e6a0dc 100644 --- a/website/content/api-docs/secret/kv/kv-v1.mdx +++ b/website/content/api-docs/secret/kv/kv-v1.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for the Vault KV secrets engine. This is the API documentation for the Vault KV secrets engine. For general information about the usage and operation of the kv secrets engine, please -see the [Vault kv documentation](/docs/secrets/kv). +see the [Vault kv documentation](/vault/docs/secrets/kv). ~> Note: This documentation assumes the kv secrets engine is enabled at the `/secret` path in Vault. Since it is possible to enable secrets engines at any @@ -53,7 +53,7 @@ $ curl \ _Note_: the `lease_duration` field, which will be populated if a "ttl" field was included in the data, is advisory. No lease is created. This is a way for writers to indicate how often a given value should be re-read by the client. -See the [Vault KV secrets engine documentation](/docs/secrets/kv) +See the [Vault KV secrets engine documentation](/vault/docs/secrets/kv) for more details. ## List Secrets @@ -120,7 +120,7 @@ policy granting the `update` capability. be held at the given location. Multiple key/value pairs can be specified, and all will be returned on a read operation. A key called `ttl` will trigger some special behavior. See the [Vault KV secrets engine - documentation](/docs/secrets/kv) for details. + documentation](/vault/docs/secrets/kv) for details. ### Sample Payload diff --git a/website/content/api-docs/secret/kv/kv-v2.mdx b/website/content/api-docs/secret/kv/kv-v2.mdx index c8cdb6d3e5..9786117c67 100644 --- a/website/content/api-docs/secret/kv/kv-v2.mdx +++ b/website/content/api-docs/secret/kv/kv-v2.mdx @@ -9,7 +9,7 @@ description: This is the API documentation for the Vault KV secrets engine. This is the API documentation for the Vault KV secrets engine while running in versioned mode. For general information about the usage and operation of the kv secrets engine, please see the [Vault kv -documentation](/docs/secrets/kv). +documentation](/vault/docs/secrets/kv). ~> Note: This documentation assumes the kv secrets engine is enabled at the `/secret` path in Vault and that versioning has been enabled. Since it is @@ -38,7 +38,7 @@ key-value store. - `delete_version_after` `(string:"0s")` – If set, specifies the length of time before a version is deleted. - Accepts [duration format strings](/docs/concepts/duration-format). + Accepts [duration format strings](/vault/docs/concepts/duration-format). ### Sample Payload @@ -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-docs/secret/kv/kv-v2#read-secret-metadata). +the associated [metadata endpoint](/vault/api-docs/secret/kv/kv-v2#read-secret-metadata). | Method | Path | | :----- | :------------------------------------------- | @@ -654,7 +654,7 @@ not create a new version. written to this key. If not set, the backend's `delete_version_after` will be used. If the value is greater than the backend's `delete_version_after`, the backend's `delete_version_after` will be used. Accepts [duration format - strings](/docs/concepts/duration-format). + strings](/vault/docs/concepts/duration-format). - `custom_metadata` `(map: nil)` - A map of arbitrary string to string valued user-provided metadata meant to describe the secret. diff --git a/website/content/api-docs/secret/ldap.mdx b/website/content/api-docs/secret/ldap.mdx index 544484cd84..bd93acc5d4 100644 --- a/website/content/api-docs/secret/ldap.mdx +++ b/website/content/api-docs/secret/ldap.mdx @@ -10,7 +10,7 @@ description: This is the API documentation for the Vault LDAP secrets engine. This is the API documentation for the Vault LDAP secrets engine. For general information about the usage and operation of the LDAP secrets engine, -please see the [LDAP secrets engine docs](/docs/secrets/ldap). +please see the [LDAP secrets engine docs](/vault/docs/secrets/ldap). This documentation assumes the LDAP secrets engine is enabled at the `/ldap` path in Vault. Since it is possible to mount secrets engines at any path, please @@ -38,15 +38,15 @@ to search and change entry passwords in LDAP. `ldaps://ldap.myorg.com:636`. This can also be a comma-delineated list of URLs, e.g. `ldaps://ldap.myorg.com, ldaps://ldap.myorg.com:636`, in which case the servers will be tried in-order if there are errors during the connection process.`. -- `password_policy` `(string: )` - The name of the [password policy](/docs/concepts/password-policies) +- `password_policy` `(string: )` - The name of the [password policy](/vault/docs/concepts/password-policies) to use to generate passwords. Note that this accepts the name of the policy, not the policy itself. - `schema` `(string: "openldap")` - The LDAP schema to use when storing entry passwords. Valid schemas include `openldap`, `ad`, and `racf`. - `userdn` `(string: )` - The base DN under which to perform user search in - [library management](/api-docs/secret/ldap#library-management) and [static roles](/api-docs/secret/ldap#static-roles). + [library management](/vault/api-docs/secret/ldap#library-management) and [static roles](/vault/api-docs/secret/ldap#static-roles). For example, `ou=Users,dc=hashicorp,dc=com`. - `userattr` `(string: )` – The attribute field name used to perform user search - in [library management](/api-docs/secret/ldap#library-management) and [static roles](/api-docs/secret/ldap#static-roles). + in [library management](/vault/api-docs/secret/ldap#library-management) and [static roles](/vault/api-docs/secret/ldap#static-roles). Defaults to `cn` for the `openldap` schema, `userPrincipalName` for the `ad` schema, and `racfid` for the `racf` schema. - `upndomain` (string: `optional`) - The domain (userPrincipalDomain) used to construct a UPN @@ -78,11 +78,11 @@ configuration if both are specified. prior to the introduction of password policies). - If `length` is set, the same algorithm is used, but with the length specified instead of the default length. - If `password_policy` is set, the password will be generated from the associated - [password policy](/docs/concepts/password-policies). The policy is not exercised prior to saving the configuration. + [password policy](/vault/docs/concepts/password-policies). The policy is not exercised prior to saving the configuration. The policy will need to exist prior to passwords needing to be generated by this engine, but does not need to exist prior to saving the configuration. -See [LDAP secrets engine docs](/docs/secrets/ldap) for additional information. +See [LDAP secrets engine docs](/vault/docs/secrets/ldap) for additional information. ### Sample Payload @@ -164,9 +164,9 @@ The `static-role` endpoint configures Vault to manage the passwords of existing ### Parameters - `username` `(string: )` - The username of the existing LDAP entry to manage - password rotation for. LDAP search for the username will be rooted at the [userdn](/api-docs/secret/ldap#userdn) + password rotation for. LDAP search for the username will be rooted at the [userdn](/vault/api-docs/secret/ldap#userdn) configuration value. The attribute to use when searching for the user can be configured - with the [userattr](/api-docs/secret/ldap#userattr) configuration value. This is useful + with the [userattr](/vault/api-docs/secret/ldap#userattr) configuration value. This is useful when `dn` isn't used for login purposes (such as SSH). Cannot be modified after creation.
**Example:** `"bob"` - `dn` `(string: )` - Distinguished name (DN) of the existing LDAP entry to manage @@ -174,7 +174,7 @@ The `static-role` endpoint configures Vault to manage the passwords of existing search performed during password rotation. Cannot be modified after creation.
**Example:** `cn=bob,ou=Users,dc=hashicorp,dc=com` - `rotation_period` `(string: )` - How often Vault should rotate the password of the user entry. Accepts - [duration format strings](/docs/concepts/duration-format). The minimum rotation period is 5 seconds.
+ [duration format strings](/vault/docs/concepts/duration-format). The minimum rotation period is 5 seconds.
**Example:** `"3600", "5s", "1h"` ### Sample Payload @@ -338,14 +338,14 @@ v_{{.DisplayName}}_{{.RoleName}}_{{random 10}}_{{unix_time}}
- `default_ttl` `(string/int)` - Specifies the TTL for the leases associated with this role. Accepts - [duration format strings](/docs/concepts/duration-format). Defaults to system/engine default TTL time. + [duration format strings](/vault/docs/concepts/duration-format). Defaults to system/engine default TTL time. - `max_ttl` `(string/int)` - Specifies the maximum TTL for the leases associated with this role. Accepts - [duration format strings](/docs/concepts/duration-format). Defaults to system/mount default TTL time; + [duration format strings](/vault/docs/concepts/duration-format). Defaults to system/mount default TTL time; 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. The `creation_ldif`, `deletion_ldif`, `rollback_ldif`, and `username_template` fields are all templated fields. See -[Username Templating](/docs/concepts/username-templating) for details on how to use templating. Also see +[Username Templating](/vault/docs/concepts/username-templating) for details on how to use templating. Also see [Templates](#templates) for specifics on what data is available for each template. #### Sample Payload @@ -443,7 +443,7 @@ The following parameters are available within the LDIF templates: **Default pattern:** `v___<10 random chars>_` `.Password` - The generated password (optionally from -[password policies](https://www.vaultproject.io/docs/concepts/password-policies)) +[password policies](/vault/docs/concepts/password-policies)) `.RoleName` - The name of the role that credentials are being generated for. @@ -568,10 +568,10 @@ When adding a service account to the library, Vault verifies it already exists i service accounts must already exist in the LDAP directory. - `ttl` `(duration: "24h", optional)` - The maximum amount of time a single check-out lasts before Vault automatically checks it back in. Defaults to 24 hours. Setting it to zero reflects an unlimited lending period. - Uses [duration format strings](/docs/concepts/duration-format). + Uses [duration format strings](/vault/docs/concepts/duration-format). - `max_ttl` `(duration: "24h", optional)` - The maximum amount of time a check-out last with renewal before Vault automatically checks it back in. Defaults to 24 hours. Setting it to zero reflects an unlimited lending period. - Uses [duration format strings](/docs/concepts/duration-format). + Uses [duration format strings](/vault/docs/concepts/duration-format). - `disable_check_in_enforcement` `(bool: false, optional)` - Disable enforcing that service accounts must be checked in by the entity or client token that checked them out. Defaults to false. @@ -672,7 +672,7 @@ Returns a `200` if a credential is available, and a `400` if no credential is av - `ttl` `(duration: "", optional)` - The maximum amount of time a check-out lasts before Vault automatically checks it back in. Setting it to zero reflects an unlimited lending period. Defaults to the set's `ttl`. If the requested `ttl` is higher than the set's, the set's will be used. - Uses [duration format strings](/docs/concepts/duration-format). + Uses [duration format strings](/vault/docs/concepts/duration-format). ### Sample POST Request diff --git a/website/content/api-docs/secret/nomad.mdx b/website/content/api-docs/secret/nomad.mdx index 2c74c53012..b71f1cacdc 100644 --- a/website/content/api-docs/secret/nomad.mdx +++ b/website/content/api-docs/secret/nomad.mdx @@ -10,7 +10,7 @@ description: This is the API documentation for the Vault Nomad secrets engine. This is the API documentation for the Vault Nomad secrets engine. For general information about the usage and operation of the Nomad secrets engine, please see the -[Vault Nomad secrets engine documentation](/docs/secrets/nomad). +[Vault Nomad secrets engine documentation](/vault/docs/secrets/nomad). This documentation assumes the Nomad secrets engine is mounted at the `/nomad` path in Vault. Since it is possible to mount secrets engines at any location, please @@ -107,9 +107,9 @@ This endpoint configures the lease settings for generated tokens. ### Parameters -- `ttl` `(string: "")` – Specifies the ttl for the lease. Uses [duration format strings](/docs/concepts/duration-format). +- `ttl` `(string: "")` – Specifies the ttl for the lease. Uses [duration format strings](/vault/docs/concepts/duration-format). -- `max_ttl` `(string: "")` – Specifies the max ttl for the lease. Uses [duration format strings](/docs/concepts/duration-format). +- `max_ttl` `(string: "")` – Specifies the max ttl for the lease. Uses [duration format strings](/vault/docs/concepts/duration-format). ### Sample Payload @@ -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://learn.hashicorp.com/collections/nomad/access-control#acl-tokens). +- `global` `(bool: "false")` – Specifies if the token should be global, as defined in the [Nomad Documentation](/nomad/tutorials/access-control#acl-tokens). - `type` `(string: "client")` - Specifies the type of token to create when using this role. Valid values are `"client"` or `"management"`. diff --git a/website/content/api-docs/secret/pki.mdx b/website/content/api-docs/secret/pki.mdx index 79b4fe0d83..08764d4f99 100644 --- a/website/content/api-docs/secret/pki.mdx +++ b/website/content/api-docs/secret/pki.mdx @@ -10,7 +10,7 @@ description: This is the API documentation for the Vault PKI secrets engine. This is the API documentation for the Vault PKI secrets engine. For general information about the usage and operation of the PKI secrets engine, please see -the [PKI documentation](/docs/secrets/pki). +the [PKI documentation](/vault/docs/secrets/pki). This documentation assumes the PKI secrets engine is enabled at the `/pki` path in Vault. Since it is possible to enable secrets engines at any location, please @@ -583,7 +583,7 @@ when signing an externally-owned intermediate. - `not_before_duration` `(duration: "30s")` - Specifies the duration by which to backdate the NotBefore property. This value has no impact in the validity period of the requested certificate, specified in the `ttl` field. - Uses [duration format strings](/docs/concepts/duration-format). + Uses [duration format strings](/vault/docs/concepts/duration-format). - `not_after` `(string)` - Set the Not After field of the certificate with specified date value. The value format should be given in UTC format @@ -1662,7 +1662,7 @@ use the values set via `config/urls`. - `not_before_duration` `(duration: "30s")` - Specifies the duration by which to backdate the NotBefore property. This value has no impact in the validity period of the requested certificate, specified in the `ttl` field. - Uses [duration format strings](/docs/concepts/duration-format). + Uses [duration format strings](/vault/docs/concepts/duration-format). - `not_after` `(string)` - Set the Not After field of the certificate with specified date value. The value format should be given in UTC format @@ -1728,7 +1728,7 @@ key. If using Vault as a root (and, like many other CAs), the various parameters on the final signed certificate are set at signing time and _may or may not honor the parameters set here_ (and transmitted in the returned CSR). -Note that this API supports [Managed Keys](/docs/enterprise/managed-keys); +Note that this API supports [Managed Keys](/vault/docs/enterprise/managed-keys); additional details are available [below in a dedicated section](#managed-keys). The parameters below are mostly meant as a helper function; not all possible @@ -1952,7 +1952,7 @@ imported entries present in the same bundle). issues; this may impact long-term use of these issuers, but some issuers or keys may still be imported as a result of this process. -~> Warning: See the [note](/docs/secrets/pki/considerations#issuer-subjects-and-crls) +~> Warning: See the [note](/vault/docs/secrets/pki/considerations#issuer-subjects-and-crls) regarding Subject naming on externally created CA certificates and shortcomings with CRL building. @@ -2594,7 +2594,7 @@ request is denied. `foo.*.example.com` and `bar` is a subdomain of that. - `allowed_domains_template` `(bool: false)` - When set, `allowed_domains` - may contain templates, as with [ACL Path Templating](/docs/concepts/policies). + may contain templates, as with [ACL Path Templating](/vault/docs/concepts/policies). Non-templated domains are also still permitted. - `allow_bare_domains` `(bool: false)` - Specifies if clients can request @@ -2662,7 +2662,7 @@ request is denied. `spiffe://hostname/*`). - `allowed_uri_sans_template` `(bool: false)` - When set, `allowed_uri_sans` - may contain templates, as with [ACL Path Templating](/docs/concepts/policies). + may contain templates, as with [ACL Path Templating](/vault/docs/concepts/policies). Non-templated domains are also still permitted. - `allowed_other_sans` `(string: "")` - Defines allowed custom OID/UTF8-string @@ -3059,7 +3059,7 @@ This endpoint allows setting the value of the default issuer. generation) will become the default and it will look (to anyone strictly using old APIs) that it is the only issuer in the mount. However, it is encouraged for applications to update to the newer, safer semantics - associated with [multi-issuer rotation](/docs/secrets/pki/rotation-primitives). + associated with [multi-issuer rotation](/vault/docs/secrets/pki/rotation-primitives). ~> Note: When an import creates more than one new issuer with key material known to this mount, no default update will occur. @@ -3641,7 +3641,7 @@ expiration time. if present). Migration will only occur after `issuer_safety_buffer` has passed since the last successful migration. -- `safety_buffer` `(string: "")` - Specifies a duration using [duration format strings](/docs/concepts/duration-format) +- `safety_buffer` `(string: "")` - Specifies a duration using [duration format strings](/vault/docs/concepts/duration-format) used as a safety buffer to ensure certificates are not expunged prematurely; as an example, this can keep certificates from being removed from the CRL that, due to clock skew, might still be considered valid on other hosts. For a certificate to be expunged, @@ -3733,7 +3733,7 @@ status endpoint described below. if present). Migration will only occur after `issuer_safety_buffer` has passed since the last successful migration. -- `safety_buffer` `(string: "")` - Specifies a duration using [duration format strings](/docs/concepts/duration-format) +- `safety_buffer` `(string: "")` - Specifies a duration using [duration format strings](/vault/docs/concepts/duration-format) used as a safety buffer to ensure certificates are not expunged prematurely; as an example, this can keep certificates from being removed from the CRL that, due to clock skew, might still be considered valid on other hosts. For a certificate to be expunged, @@ -3872,7 +3872,7 @@ $ curl \ ## Cluster Scalability -See [PKI Cluster Scalability](/docs/secrets/pki/considerations#cluster-scalability) in the considerations page. +See [PKI Cluster Scalability](/vault/docs/secrets/pki/considerations#cluster-scalability) in the considerations page. ## Managed Keys diff --git a/website/content/api-docs/secret/rabbitmq.mdx b/website/content/api-docs/secret/rabbitmq.mdx index e3da050084..df14f54e10 100644 --- a/website/content/api-docs/secret/rabbitmq.mdx +++ b/website/content/api-docs/secret/rabbitmq.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for the Vault RabbitMQ secrets engine This is the API documentation for the Vault RabbitMQ secrets engine. For general information about the usage and operation of the RabbitMQ secrets engine, please -see the [RabbitMQ documentation](/docs/secrets/rabbitmq). +see the [RabbitMQ documentation](/vault/docs/secrets/rabbitmq). This documentation assumes the RabbitMQ secrets engine is enabled at the `/rabbitmq` path in Vault. Since it is possible to enable secrets engines at any @@ -33,10 +33,10 @@ RabbitMQ. - `verify_connection` `(bool: true)` – Specifies whether to verify connection URI, username, and password. -- `password_policy` `(string: "")` - Specifies a [password policy](/docs/concepts/password-policies) to +- `password_policy` `(string: "")` - Specifies a [password policy](/vault/docs/concepts/password-policies) to use when creating dynamic credentials. Defaults to generating an alphanumeric password if not set. -- `username_template` `(string)` - [Template](/docs/concepts/username-templating) describing how +- `username_template` `(string)` - [Template](/vault/docs/concepts/username-templating) describing how dynamic usernames are generated. ### Sample Payload diff --git a/website/content/api-docs/secret/ssh.mdx b/website/content/api-docs/secret/ssh.mdx index d54464bcb2..09c4c0bc1d 100644 --- a/website/content/api-docs/secret/ssh.mdx +++ b/website/content/api-docs/secret/ssh.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for the Vault SSH secrets engine. This is the API documentation for the Vault SSH secrets engine. For general information about the usage and operation of the SSH secrets engine, please see -the [SSH documentation](/docs/secrets/ssh). +the [SSH documentation](/vault/docs/secrets/ssh). This documentation assumes the SSH secrets engine is enabled at the `/ssh` path in Vault. Since it is possible to enable secrets engines at any location, please @@ -261,7 +261,7 @@ This endpoint creates or updates a named role. explicit `algorithm_signer=rsa-sha` parameter or has been migrated to such. - `not_before_duration` `(duration: "30s")` – Specifies the duration by which to - backdate the `ValidAfter` property. Uses [duration format strings](/docs/concepts/duration-format). + backdate the `ValidAfter` property. Uses [duration format strings](/vault/docs/concepts/duration-format). ### Sample Payload diff --git a/website/content/api-docs/secret/terraform.mdx b/website/content/api-docs/secret/terraform.mdx index 9d9e6893fa..2ab1d7c480 100644 --- a/website/content/api-docs/secret/terraform.mdx +++ b/website/content/api-docs/secret/terraform.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for the Vault Terraform Cloud secret This is the API documentation for the Vault Terraform Cloud secret backend. For general information about the usage and operation of the Terraform Cloud backend, please see the -[Vault Terraform Cloud backend documentation](/docs/secrets/terraform). +[Vault Terraform Cloud backend documentation](/vault/docs/secrets/terraform). This documentation assumes the Terraform Cloud backend is mounted at the `/terraform` path in Vault. Since it is possible to mount secret backends at any location, please @@ -102,7 +102,7 @@ with the `/rotate-role` endpoint. Please see the [Terraform Cloud API Token documentation for more -information](https://www.terraform.io/cloud-docs/users-teams-organizations/api-tokens). +information](/terraform/cloud-docs/users-teams-organizations/api-tokens). | Method | Path | | :----- | :---------------------- | @@ -126,11 +126,11 @@ information](https://www.terraform.io/cloud-docs/users-teams-organizations/api-t - `ttl` `(duration: "")` – Specifies the TTL for this role. If not provided, the default Vault TTL is used. Only applies to User API tokens. - Uses [duration format strings](/docs/concepts/duration-format). + Uses [duration format strings](/vault/docs/concepts/duration-format). - `max_ttl` `(duration: "")` – Specifies the max TTL for this role. If not provided, the default Vault Max TTL is used. Only applies to User API tokens. - Uses [duration format strings](/docs/concepts/duration-format). + Uses [duration format strings](/vault/docs/concepts/duration-format). ### Sample Payload diff --git a/website/content/api-docs/secret/totp.mdx b/website/content/api-docs/secret/totp.mdx index f04e2a6c3d..6e3d78fc56 100644 --- a/website/content/api-docs/secret/totp.mdx +++ b/website/content/api-docs/secret/totp.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for the Vault TOTP secrets engine. This is the API documentation for the Vault TOTP secrets engine. For general information about the usage and operation of the TOTP secrets engine, please see -the [TOTP documentation](/docs/secrets/totp). +the [TOTP documentation](/vault/docs/secrets/totp). This documentation assumes the TOTP secrets engine is enabled at the `/totp` path in Vault. Since it is possible to enable secrets engines at any location, diff --git a/website/content/api-docs/secret/transform.mdx b/website/content/api-docs/secret/transform.mdx index 390b609778..3fb592e0c4 100644 --- a/website/content/api-docs/secret/transform.mdx +++ b/website/content/api-docs/secret/transform.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for the Transform secrets engine. This is the API documentation for the Transform secrets engine. For general information about the usage and operation of the secrets engine, please see the -[Transform secrets engine documentation](/docs/secrets/transform). +[Transform secrets engine documentation](/vault/docs/secrets/transform). This documentation assumes the transform secrets engine is enabled at the `/transform` path in Vault. Since it is possible to enable secrets engines at any @@ -974,7 +974,7 @@ The database user configured here should only have permission to `SELECT`, - `max_connection_lifetime` `(duration: 0)` - The maximum amount of time a connection can be open before closing it. - 0 means no limit. Uses [duration format strings](/docs/concepts/duration-format). + 0 means no limit. Uses [duration format strings](/vault/docs/concepts/duration-format). ### Sample Payloads @@ -1890,7 +1890,7 @@ This endpoint starts or continues retrieving an export of tokenization state, including the tokens and their decoded values. This call is only supported on tokenization stores configured with the `exportable` mapping mode. Refer to the Tokenization -[documentation](../../docs/secrets/transform/tokenization#security-considerations) +[documentation](/vault/docs/secrets/transform/tokenization#security-considerations) for when to use the `exportable` mapping mode. Decoded values are in Base64 representation. @@ -2011,7 +2011,7 @@ Only valid for tokenization transformations. - `auto_rotate_period` `(duration: "0", optional)` - The period at which this key should be rotated automatically. Setting this to "0" will disable automatic key rotation. This value cannot be shorter than one hour. Uses - [duration format strings](/docs/concepts/duration-format). + [duration format strings](/vault/docs/concepts/duration-format). ### Sample Payload diff --git a/website/content/api-docs/secret/transit.mdx b/website/content/api-docs/secret/transit.mdx index 7ddb726e0a..b4e37b27f7 100644 --- a/website/content/api-docs/secret/transit.mdx +++ b/website/content/api-docs/secret/transit.mdx @@ -8,7 +8,7 @@ description: This is the API documentation for the Vault Transit secrets engine. This is the API documentation for the Vault Transit secrets engine. For general information about the usage and operation of the Transit secrets engine, please -see the [transit documentation](/docs/secrets/transit). +see the [transit documentation](/vault/docs/secrets/transit). This documentation assumes the transit secrets engine is enabled at the `/transit` path in Vault. Since it is possible to enable secrets engines at any @@ -79,7 +79,7 @@ values set here cannot be changed after key creation. - `auto_rotate_period` `(duration: "0", optional)` – The period at which this key should be rotated automatically. Setting this to "0" (the default) will disable automatic key rotation. This value cannot be shorter than one - hour. Uses [duration format strings](/docs/concepts/duration-format). + hour. Uses [duration format strings](/vault/docs/concepts/duration-format). ### Sample Payload @@ -119,7 +119,7 @@ two values: an ephemeral 256-bit AES key wrapped using the wrapping key returned by Vault and the encryption of the import key material under the provided AES key. The wrapped AES key should be the first 512 bytes of the ciphertext, and the encrypted key material should be the remaining bytes. -See the BYOK section of the [Transit secrets engine documentation](/docs/secrets/transit#bring-your-own-key-byok) +See the BYOK section of the [Transit secrets engine documentation](/vault/docs/secrets/transit#bring-your-own-key-byok) for more information on constructing the ciphertext. - `hash_function` `(string: "SHA256")` - The hash function used for the @@ -212,7 +212,7 @@ two values: an ephemeral 256-bit AES key wrapped using the wrapping key returned by Vault and the encryption of the import key material under the provided AES key. The wrapped AES key should be the first 512 bytes of the ciphertext, and the encrypted key material should be the remaining bytes. -See the BYOK section of the [Transit secrets engine documentation](/docs/secrets/transit#bring-your-own-key-byok) +See the BYOK section of the [Transit secrets engine documentation](/vault/docs/secrets/transit#bring-your-own-key-byok) for more information on constructing the ciphertext. - `hash_function` `(string: "SHA256")` - The hash function used for the @@ -414,7 +414,7 @@ are returned during a read operation on the named key.) - `auto_rotate_period` `(duration: "", optional)` – The period at which this key should be rotated automatically. Setting this to "0" will disable automatic key rotation. This value cannot be shorter than one hour. When no value is - provided, the period remains unchanged. Uses [duration format strings](/docs/concepts/duration-format). + provided, the period remains unchanged. Uses [duration format strings](/vault/docs/concepts/duration-format). ### Sample Payload @@ -697,7 +697,7 @@ Use the base64-encoded plaintext in the payload: } ``` -!> Vault HTTP API imposes a maximum request size of 32MB to prevent a denial of service attack. This can be tuned per [`listener` block](/docs/configuration/listener/tcp) in the Vault server configuration. +!> Vault HTTP API imposes a maximum request size of 32MB to prevent a denial of service attack. This can be tuned per [`listener` block](/vault/docs/configuration/listener/tcp) in the Vault server configuration. ### Sample Request @@ -1750,4 +1750,4 @@ $ curl \ }, ``` -[sys-plugin-reload-backend]: /api-docs/system/plugins-reload-backend#reload-plugins +[sys-plugin-reload-backend]: /vault/api-docs/system/plugins-reload-backend#reload-plugins diff --git a/website/content/api-docs/system/experiments.mdx b/website/content/api-docs/system/experiments.mdx index a33f5623b6..93a4c10ea1 100644 --- a/website/content/api-docs/system/experiments.mdx +++ b/website/content/api-docs/system/experiments.mdx @@ -12,8 +12,8 @@ The `/sys/experiments` endpoint returns information about experiments on the Vau This endpoint returns the experiments available and enabled on the Vault node. Experiments are per-node and cannot be changed while the node is running. See -the [`-experiment`](/docs/commands/server#experiment) flag and the -[`experiments`](/docs/configuration#experiments) config key documentation for +the [`-experiment`](/vault/docs/commands/server#experiment) flag and the +[`experiments`](/vault/docs/configuration#experiments) config key documentation for details on enabling experiments. | Method | Path | diff --git a/website/content/api-docs/system/init.mdx b/website/content/api-docs/system/init.mdx index a54d18184e..696084cbd0 100644 --- a/website/content/api-docs/system/init.mdx +++ b/website/content/api-docs/system/init.mdx @@ -35,7 +35,7 @@ $ curl \ This endpoint initializes a new Vault. The Vault must not have been previously initialized. The recovery options, as well as the stored shares option, are only -available when using [Auto Unseal](/docs/concepts/seal#auto-unseal). +available when using [Auto Unseal](/vault/docs/concepts/seal#auto-unseal). | Method | Path | | :----- | :---------- | diff --git a/website/content/api-docs/system/inspect/index.mdx b/website/content/api-docs/system/inspect/index.mdx index 47b8eae702..33fb07c8fc 100644 --- a/website/content/api-docs/system/inspect/index.mdx +++ b/website/content/api-docs/system/inspect/index.mdx @@ -10,7 +10,7 @@ description: >- The `/sys/internal/inspect` family of endpoints is intended to inspect a specific internal subsystem for debugging purposes. This endpoint is off by default. See the -[Vault configuration documentation](/docs/configuration) to +[Vault configuration documentation](/vault/docs/configuration) to enable. Once the endpoint is turned on, it can be accessed with a root token or sudo privileges. ~> **NOTE**: These endpoints are only available in Vault version 1.13+. Backwards compatibility is not guaranteed. These endpoints are subject to change or may disappear without notice. @@ -18,5 +18,5 @@ enable. Once the endpoint is turned on, it can be accessed with a root token or ## Supported Inspection Paths -- [Router](/api-docs/system/inspect/router) +- [Router](/vault/api-docs/system/inspect/router) diff --git a/website/content/api-docs/system/internal-counters.mdx b/website/content/api-docs/system/internal-counters.mdx index 3237028de9..5ea156e31a 100644 --- a/website/content/api-docs/system/internal-counters.mdx +++ b/website/content/api-docs/system/internal-counters.mdx @@ -318,7 +318,7 @@ That is to say, the response will appear as follows. ``` -Please visit the [client count](/docs/concepts/client-count) concepts page for +Please visit the [client count](/vault/docs/concepts/client-count) concepts page for more information on how clients map to these client IDs and how they are counted, or for more information about how the new clients for the current month are estimated in a billing period. diff --git a/website/content/api-docs/system/internal-specs-openapi.mdx b/website/content/api-docs/system/internal-specs-openapi.mdx index 68545600d3..452c62ed92 100644 --- a/website/content/api-docs/system/internal-specs-openapi.mdx +++ b/website/content/api-docs/system/internal-specs-openapi.mdx @@ -15,7 +15,7 @@ The set of included paths is based on the permissions of the request token. The response may include Vault-specific [extensions](https://github.com/oai/openapi-specification/blob/master/versions/3.0.2.md#specification-extensions). Three are currently defined: -- `x-vault-sudo` - Endpoint requires [sudo](/docs/concepts/policies#sudo) privileges. +- `x-vault-sudo` - Endpoint requires [sudo](/vault/docs/concepts/policies#sudo) privileges. - `x-vault-unauthenticated` - Endpoint is unauthenticated. - `x-vault-create-supported` - Endpoint allows creation of new items, in addition to updating existing items. diff --git a/website/content/api-docs/system/license.mdx b/website/content/api-docs/system/license.mdx index 0689f7bbbd..45520e819d 100644 --- a/website/content/api-docs/system/license.mdx +++ b/website/content/api-docs/system/license.mdx @@ -15,7 +15,7 @@ Vault. ## License Status -This endpoint returns information about licensing. See [license autoloading](/docs/enterprise/license/autoloading) for additional background. +This endpoint returns information about licensing. See [license autoloading](/vault/docs/enterprise/license/autoloading) for additional background. In the response: diff --git a/website/content/api-docs/system/managed-keys.mdx b/website/content/api-docs/system/managed-keys.mdx index 12b9bc1167..9e6ad9a971 100644 --- a/website/content/api-docs/system/managed-keys.mdx +++ b/website/content/api-docs/system/managed-keys.mdx @@ -7,7 +7,7 @@ description: The `/sys/managed-keys` endpoint is used to manage the managed keys # `/sys/managed-keys` The `/sys/managed-keys` endpoint is used to manage the Managed Key configuration within Vault. -See the [Managed Keys](/docs/enterprise/managed-keys) section for further details on the Managed Keys system. +See the [Managed Keys](/vault/docs/enterprise/managed-keys) section for further details on the Managed Keys system. ## List managed keys. @@ -101,7 +101,7 @@ $ curl \ - `type` `(string: "pkcs11")` - To select a PKCS#11 backend, the type parameter must be set to `pkcs11`. - `library` `(string: )` - The name of the `kms_library` stanza to use from Vault's config to - lookup the local library path. See [kms_library stanza](/docs/configuration/kms-library) for further details. + lookup the local library path. See [kms_library stanza](/vault/docs/configuration/kms-library) for further details. - `key_label` `(string: )` - The label of the key to use. If the key does not exist and generation is enabled, this is the label that will be given to the generated key. This diff --git a/website/content/api-docs/system/mfa/index.mdx b/website/content/api-docs/system/mfa/index.mdx index 43311c3d7e..d44e99215f 100644 --- a/website/content/api-docs/system/mfa/index.mdx +++ b/website/content/api-docs/system/mfa/index.mdx @@ -13,17 +13,17 @@ behaviors in Vault Enterprise MFA. ## Supported MFA types -- [TOTP](/api-docs/system/mfa/totp) +- [TOTP](/vault/api-docs/system/mfa/totp) -- [Okta](/api-docs/system/mfa/okta) +- [Okta](/vault/api-docs/system/mfa/okta) -- [Duo](/api-docs/system/mfa/duo) +- [Duo](/vault/api-docs/system/mfa/duo) -- [PingID](/api-docs/system/mfa/pingid) +- [PingID](/vault/api-docs/system/mfa/pingid) ## Step-up Enterprise MFA -[Vault Enterprise](/docs/enterprise/mfa) allows MFA for login and access to +[Vault Enterprise](/vault/docs/enterprise/mfa) allows MFA for login and access to sensitive resources in Vault. The Step-up Enterprise MFA expects the method creator to specify a name for the method; Login MFA does not, and instead returns an ID when a method is created. Although MFA methods supported with Step-up Enterprise MFA are supported with the Login MFA, they use different API endpoints. @@ -34,5 +34,5 @@ returns an ID when a method is created. Although MFA methods supported with Step ~> **Note:** While the `sys/mfa` endpoint is supported for both OSS and Vault Enterprise, `sys/mfa/method/:type/:/name` is only supported for Vault Enterprise. Refer to the [Login MFA -FAQ](/docs/auth/login-mfa/faq#q-are-there-new-mfa-api-endpoints-introduced-as-part-of-the-new-vault-version-1-10-mfa-for-login-functionality) document +FAQ](/vault/docs/auth/login-mfa/faq#q-are-there-new-mfa-api-endpoints-introduced-as-part-of-the-new-vault-version-1-10-mfa-for-login-functionality) document for more details. diff --git a/website/content/api-docs/system/mounts.mdx b/website/content/api-docs/system/mounts.mdx index a072b936df..284f59cc6c 100644 --- a/website/content/api-docs/system/mounts.mdx +++ b/website/content/api-docs/system/mounts.mdx @@ -242,7 +242,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](/api-docs/system/leases) +performing a [force revoke](/vault/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. diff --git a/website/content/api-docs/system/namespaces.mdx b/website/content/api-docs/system/namespaces.mdx index d4bc7212fd..a00961e111 100644 --- a/website/content/api-docs/system/namespaces.mdx +++ b/website/content/api-docs/system/namespaces.mdx @@ -172,7 +172,7 @@ $ curl \ This endpoint locks the API for the current namespace path or optional subpath. The behavior when interacting with Vault from a locked namespace is described in -[API Locked Response](/docs/concepts/namespace-api-lock#api-locked-response). +[API Locked Response](/vault/docs/concepts/namespace-api-lock#api-locked-response). | Method | Path | | :----- | :---------------------- | diff --git a/website/content/api-docs/system/policies-password.mdx b/website/content/api-docs/system/policies-password.mdx index 583bbf8067..e81fca7d28 100644 --- a/website/content/api-docs/system/policies-password.mdx +++ b/website/content/api-docs/system/policies-password.mdx @@ -13,7 +13,7 @@ are using for compatibility. ~> Password policies are only available in Vault version 1.5+. -See [Password Policies](/docs/concepts/password-policies) for details of how password policies work +See [Password Policies](/vault/docs/concepts/password-policies) for details of how password policies work as well as the syntax of the policies themselves. ## Create/Update Password Policy @@ -37,7 +37,7 @@ generation times. This is specified as part of the request URL. - `policy` `(string: )` - Specifies the password policy document. This can be - base64-encoded to avoid string escaping. See [Password Policy Syntax](/docs/concepts/password-policies#password-policy-syntax) + base64-encoded to avoid string escaping. See [Password Policy Syntax](/vault/docs/concepts/password-policies#password-policy-syntax) for details on password policy definitions. ### Sample Payload diff --git a/website/content/api-docs/system/raw.mdx b/website/content/api-docs/system/raw.mdx index 227210e38a..a8bccb1ddf 100644 --- a/website/content/api-docs/system/raw.mdx +++ b/website/content/api-docs/system/raw.mdx @@ -9,7 +9,7 @@ description: The `/sys/raw` endpoint is used to access the raw underlying store The `/sys/raw` endpoint is used to access the raw underlying store in Vault. This endpoint is off by default. See the -[Vault configuration documentation](/docs/configuration) to +[Vault configuration documentation](/vault/docs/configuration) to enable. ## Read Raw diff --git a/website/content/api-docs/system/remount.mdx b/website/content/api-docs/system/remount.mdx index b7abdf0b9c..6e394701fa 100644 --- a/website/content/api-docs/system/remount.mdx +++ b/website/content/api-docs/system/remount.mdx @@ -17,7 +17,7 @@ engines and auth methods. The remount operation returns a migration ID to the user. The user may utilize the migration ID to look up the status of the mount migration. More details about the remount operation are described in -[Mount Migration](/docs/concepts/mount-migration). +[Mount Migration](/vault/docs/concepts/mount-migration). ~> Note: This endpoint requires a policy with both `sudo` and `update` capabilities to `sys/remount` diff --git a/website/content/api-docs/system/replication/replication-dr.mdx b/website/content/api-docs/system/replication/replication-dr.mdx index 2e1063593f..1f63c8bbb5 100644 --- a/website/content/api-docs/system/replication/replication-dr.mdx +++ b/website/content/api-docs/system/replication/replication-dr.mdx @@ -343,7 +343,7 @@ result in data loss! ~> It is not safe to replicate from a newer version of Vault to an older version. When upgrading replicated clusters, ensure that upstream clusters are always on older versions of Vault than downstream clusters. See -[Upgrading Vault](/docs/upgrading#replication-installations) for an example. +[Upgrading Vault](/vault/docs/upgrading#replication-installations) for an example. | Method | Path | diff --git a/website/content/api-docs/system/storage/index.mdx b/website/content/api-docs/system/storage/index.mdx index 5c93c276b4..ce25488325 100644 --- a/website/content/api-docs/system/storage/index.mdx +++ b/website/content/api-docs/system/storage/index.mdx @@ -6,6 +6,6 @@ description: |- The '/sys/storage' endpoints are used to manage Vault's storage backends. --- -This API sub-section is currently only used to manage [Raft](/api-docs/system/storage/raft) storage backend. +This API sub-section is currently only used to manage [Raft](/vault/api-docs/system/storage/raft) storage backend. -On Enterprise there are additional endpoints for working with [Raft Automated Snapshots](/api-docs/system/storage/raftautosnapshots). +On Enterprise there are additional endpoints for working with [Raft Automated Snapshots](/vault/api-docs/system/storage/raftautosnapshots). diff --git a/website/content/api-docs/system/storage/raftautopilot.mdx b/website/content/api-docs/system/storage/raftautopilot.mdx index b3e3fe332e..538aaffb9d 100644 --- a/website/content/api-docs/system/storage/raftautopilot.mdx +++ b/website/content/api-docs/system/storage/raftautopilot.mdx @@ -10,12 +10,12 @@ description: |- # `/sys/storage/raft/autopilot` The `/sys/storage/raft/autopilot` endpoints are used to manage raft clusters using autopilot -with Vault's [Integrated Storage backend](/docs/internals/integrated-storage). -Refer to the [Integrated Storage Autopilot](https://learn.hashicorp.com/tutorials/vault/raft-autopilot?in=vault/raft) tutorial to learn how to manage raft clusters using autopilot. +with Vault's [Integrated Storage backend](/vault/docs/internals/integrated-storage). +Refer to the [Integrated Storage Autopilot](/vault/tutorials/raft/raft-autopilot) tutorial to learn how to manage raft clusters using autopilot. ## Get Cluster State -This endpoint is used to retrieve the raft cluster state. See the [docs page](/docs/commands/operator/raft#autopilot-state) for a description of the output. +This endpoint is used to retrieve the raft cluster state. See the [docs page](/vault/docs/commands/operator/raft#autopilot-state) for a description of the output. | Method | Path | | :----- | :---------------------------------- | diff --git a/website/content/api-docs/system/user-lockout.mdx b/website/content/api-docs/system/user-lockout.mdx index 497a1cc129..f43b5f2cb7 100644 --- a/website/content/api-docs/system/user-lockout.mdx +++ b/website/content/api-docs/system/user-lockout.mdx @@ -8,7 +8,7 @@ description: The `/sys/locked-users` endpoint is used to manage locked users in The `/sys/locked-users` endpoint is used to list and unlock locked users in Vault. -Please visit [user lockout](/docs/concepts/user-lockout) concepts page for more details about the feature. +Please visit [user lockout](/vault/docs/concepts/user-lockout) concepts page for more details about the feature. ## List Locked Users diff --git a/website/content/docs/agent/apiproxy.mdx b/website/content/docs/agent/apiproxy.mdx index 7e763ecb31..7d511ba107 100644 --- a/website/content/docs/agent/apiproxy.mdx +++ b/website/content/docs/agent/apiproxy.mdx @@ -13,20 +13,20 @@ for Vault's API. ## Functionality -The [`listener` stanza](/docs/agent#listener-stanza) for Vault Agent configures a listener for Vault Agent. If +The [`listener` stanza](/vault/docs/agent#listener-stanza) for Vault Agent configures a listener for Vault Agent. If its `role` is not set to `metrics_only`, it will act as a proxy for the Vault server that -has been configured in the [`vault` stanza](/docs/agent#vault-stanza) stanza of Vault Agent. This enables access to the Vault +has been configured in the [`vault` stanza](/vault/docs/agent#vault-stanza) stanza of Vault Agent. This enables access to the Vault API from the Agent API, and can be configured to optionally allow or force the automatic use of the Auto-Auth token for these requests, as described below. If a `listener` has been configured alongside a `cache` stanza, the API Proxy will first attempt to utilize the cache subsystem for qualifying requests, before forwarding the -request to Vault. See the [caching docs](/docs/agent/caching) for more information on caching. +request to Vault. See the [caching docs](/vault/docs/agent/caching) for more information on caching. ## Using Auto-Auth Token Vault Agent allows for easy authentication to Vault in a wide variety of -environments using [Auto-Auth](/docs/agent/autoauth). By setting the +environments using [Auto-Auth](/vault/docs/agent/autoauth). By setting the `use_auto_auth_token` (see below) configuration, clients will not be required to provide a Vault token to the requests made to the Agent. When this configuration is set, if the request doesn't already bear a token, then the @@ -40,7 +40,7 @@ request to the Vault server. Vault Agent can be configured to force the use of the auto-auth token by using the value `force` for the `use_auto_auth_token` option. This configuration overrides the default behavior described above in [Using Auto-Auth -Token](/docs/agent/apiproxy#using-auto-auth-token), and instead ignores any +Token](/vault/docs/agent/apiproxy#using-auto-auth-token), and instead ignores any existing Vault token in the request and instead uses the auto-auth token. @@ -57,7 +57,7 @@ auto-auth token, overwriting the attached Vault token if set. The following two `api_proxy` options are only useful when making requests to a Vault Enterprise cluster, and are documented as part of its -[Eventual Consistency](/docs/enterprise/consistency#vault-agent-and-consistency-headers) +[Eventual Consistency](/vault/docs/enterprise/consistency#vault-agent-and-consistency-headers) page. - `enforce_consistency` `(string: "never")` - Set to one of `"always"` diff --git a/website/content/docs/agent/autoauth/index.mdx b/website/content/docs/agent/autoauth/index.mdx index dc6fb55050..8935cf2b95 100644 --- a/website/content/docs/agent/autoauth/index.mdx +++ b/website/content/docs/agent/autoauth/index.mdx @@ -31,7 +31,7 @@ configured Sinks, subject to their configuration. Sinks support some advanced features, including the ability for the written values to be encrypted or -[response-wrapped](/docs/concepts/response-wrapping). +[response-wrapped](/vault/docs/concepts/response-wrapping). Both mechanisms can be used concurrently; in this case, the value will be response-wrapped, then encrypted. @@ -110,7 +110,7 @@ The top level `auto_auth` block has two configuration entries: Agent does not track the number of uses remaining, and may allow the token to expire before attempting to renew it. For example, if using AppRole auto-auth, you must use 0 (meaning unlimited) as the value for -[`token_num_uses`](https://www.vaultproject.io/api-docs/auth/approle#token_num_uses). +[`token_num_uses`](/vault/api-docs/auth/approle#token_num_uses). These are common configuration values that live within the `method` block: @@ -135,14 +135,14 @@ These are common configuration values that live within the `method` block: automatically reauthenticate when it expires. Rather than a simple string, the written value will be a JSON-encoded [SecretWrapInfo](https://godoc.org/github.com/hashicorp/vault/api#SecretWrapInfo) - structure. Uses [duration format strings](/docs/concepts/duration-format). + structure. Uses [duration format strings](/vault/docs/concepts/duration-format). - `min_backoff` `(string or integer: "1s")` - The minimum backoff time Agent will delay before retrying after a failed auth attempt. The backoff will start at the configured value and double (with some randomness) after successive failures, capped by `max_backoff.` If Agent templating is being used, this value is also used as the min backoff time for the templating server. - Uses [duration format strings](/docs/concepts/duration-format). + Uses [duration format strings](/vault/docs/concepts/duration-format). - `max_backoff` `(string or integer: "5m")` - The maximum time Agent will delay before retrying after a failed auth attempt. The backoff will start at @@ -150,7 +150,7 @@ These are common configuration values that live within the `method` block: capped by `max_backoff.` If Agent templating is being used, this value is also used as the max backoff time for the templating server. `max_backoff` is the duration between retries, and **not** the duration that retries will be - performed before giving up. Uses [duration format strings](/docs/concepts/duration-format). + performed before giving up. Uses [duration format strings](/vault/docs/concepts/duration-format). - `exit_on_err` `(bool: false)` - When set to true, Vault Agent will exit if any errors occur during authentication. This configurable only affects login attempts @@ -173,7 +173,7 @@ These configuration values are common to all Sinks: reauthenticate when it expires. Rather than a simple string, the written value will be a JSON-encoded [SecretWrapInfo](https://godoc.org/github.com/hashicorp/vault/api#SecretWrapInfo) - structure. Uses [duration format strings](/docs/concepts/duration-format). + structure. Uses [duration format strings](/vault/docs/concepts/duration-format). - `dh_type` `(string: optional)` - If specified, the type of Diffie-Hellman exchange to perform, meaning, which ciphers and/or curves. Currently only `curve25519` is diff --git a/website/content/docs/agent/autoauth/methods/alicloud.mdx b/website/content/docs/agent/autoauth/methods/alicloud.mdx index dea7cb73d1..5b40d22132 100644 --- a/website/content/docs/agent/autoauth/methods/alicloud.mdx +++ b/website/content/docs/agent/autoauth/methods/alicloud.mdx @@ -7,7 +7,7 @@ description: AliCloud Method for Vault Agent Auto-Auth # Vault Agent Auto-Auth AliCloud Method The `alicloud` method performs authentication against the [AliCloud Auth -method](/docs/auth/alicloud). +method](/vault/docs/auth/alicloud). ## Credentials diff --git a/website/content/docs/agent/autoauth/methods/approle.mdx b/website/content/docs/agent/autoauth/methods/approle.mdx index 3371c139d9..3d96889bd0 100644 --- a/website/content/docs/agent/autoauth/methods/approle.mdx +++ b/website/content/docs/agent/autoauth/methods/approle.mdx @@ -8,7 +8,7 @@ description: AppRole Method for Vault Agent Auto-Auth The `approle` method reads in a role ID and a secret ID from files and sends the values to the [AppRole Auth -method](/docs/auth/approle). +method](/vault/docs/auth/approle). The method caches values and it is safe to delete the role ID/secret ID files after they have been read. In fact, by default, after reading the secret ID, @@ -32,15 +32,15 @@ cached. - `secret_id_response_wrapping_path` `(string: optional)` - If set, the value at `secret_id_file_path` will be expected to be a [Response-Wrapping - Token](/docs/concepts/response-wrapping) + Token](/vault/docs/concepts/response-wrapping) containing the output of the secret ID retrieval endpoint for the role (e.g. `auth/approle/role/webservers/secret-id`) and the creation path for the response-wrapping token must match the value set here. ## Example Configuration -An example configuration, using approle to enable [auto-auth](/docs/agent/autoauth) -and creating both a plaintext token sink and a [response-wrapped token sink file](/docs/agent/autoauth#wrap_ttl), follows: +An example configuration, using approle to enable [auto-auth](/vault/docs/agent/autoauth) +and creating both a plaintext token sink and a [response-wrapped token sink file](/vault/docs/agent/autoauth#wrap_ttl), follows: ```hcl pid_file = "./pidfile" diff --git a/website/content/docs/agent/autoauth/methods/aws.mdx b/website/content/docs/agent/autoauth/methods/aws.mdx index 9abbd74a11..69ea5b8171 100644 --- a/website/content/docs/agent/autoauth/methods/aws.mdx +++ b/website/content/docs/agent/autoauth/methods/aws.mdx @@ -7,7 +7,7 @@ description: AWS Method for Vault Agent Auto-Auth # Vault Agent Auto-Auth AWS Method The `aws` method performs authentication against the [AWS Auth -method](/docs/auth/aws). Both `ec2` and `iam` +method](/vault/docs/auth/aws). Both `ec2` and `iam` authentication types are supported. If `ec2` is used, the agent will store the reauthentication value in memory and use it for reauthenticating, but will not persist it to disk. @@ -48,17 +48,17 @@ parameters unset in your configuration. - `region` `(string: "us-east-1")` - The region to use for signing the authentication request. The region Agent uses should match that corresponding to - [`sts_endpoint`](/api-docs/auth/aws#sts_endpoint), + [`sts_endpoint`](/vault/api-docs/auth/aws#sts_endpoint), if a custom endpoint has been configured on the Vault server. - `session_token` `(string: optional)` - The session token to use for authentication, if needed. - `header_value` `(string: optional)` - If configured in Vault, the value to use for - [`iam_server_id_header_value`](/api-docs/auth/aws#iam_server_id_header_value). + [`iam_server_id_header_value`](/vault/api-docs/auth/aws#iam_server_id_header_value). - `nonce` `(string: optional)` - If not provided, Vault will generate a new UUID every time `vault agent` runs. If set, make sure you understand the importance of generating a good, unique `nonce` and protecting it. - See [Client Nonce](/docs/auth/aws#client-nonce) for more information. + See [Client Nonce](/vault/docs/auth/aws#client-nonce) for more information. ## Tutorial diff --git a/website/content/docs/agent/autoauth/methods/azure.mdx b/website/content/docs/agent/autoauth/methods/azure.mdx index d02d0e61e9..fdab0d1201 100644 --- a/website/content/docs/agent/autoauth/methods/azure.mdx +++ b/website/content/docs/agent/autoauth/methods/azure.mdx @@ -8,7 +8,7 @@ description: Azure Method for Vault Agent Auto-Auth The `azure` method reads in Azure instance credentials and uses them to authenticate with the [Azure Auth -method](/docs/auth/azure). It reads most +method](/vault/docs/auth/azure). It reads most parameters needed for authentication directly from instance information based on the value of the `resource` parameter. diff --git a/website/content/docs/agent/autoauth/methods/cert.mdx b/website/content/docs/agent/autoauth/methods/cert.mdx index 21f0a7fc62..73a7cefd3c 100644 --- a/website/content/docs/agent/autoauth/methods/cert.mdx +++ b/website/content/docs/agent/autoauth/methods/cert.mdx @@ -14,13 +14,13 @@ It is strongly advised to provide TLS settings in the configuration stanza within the auth method to avoid agent cache, if also enabled, from using the same TLS settings when proxying requests. If TLS settings are not present in the config stanza, Agent will fall back to using TLS settings from the [`vault` -Stanza](/docs/agent#vault-stanza). +Stanza](/vault/docs/agent#vault-stanza). ## Configuration - `name` `(string: optional)` - The trusted certificate role which should be used when authenticating with TLS. If a `name` is not specified, the auth method will - try to authenticate against [all trusted certificates](/docs/auth/cert#authentication). + try to authenticate against [all trusted certificates](/vault/docs/auth/cert#authentication). - `ca_cert` `(string: optional)` - Path on the local disk to a single PEM-encoded CA certificate to verify the Vault server's SSL certificate. diff --git a/website/content/docs/agent/autoauth/methods/cf.mdx b/website/content/docs/agent/autoauth/methods/cf.mdx index 9446dda20f..ef8d8d1fa1 100644 --- a/website/content/docs/agent/autoauth/methods/cf.mdx +++ b/website/content/docs/agent/autoauth/methods/cf.mdx @@ -7,7 +7,7 @@ description: CF Method for Vault Agent Auto-Auth # Vault Agent Auto-Auth CF Method The `cf` method performs authentication against the [CF Auth -method](/docs/auth/cf). +method](/vault/docs/auth/cf). ## Credentials diff --git a/website/content/docs/agent/autoauth/methods/gcp.mdx b/website/content/docs/agent/autoauth/methods/gcp.mdx index 1fb8e5ddca..32b3c999a0 100644 --- a/website/content/docs/agent/autoauth/methods/gcp.mdx +++ b/website/content/docs/agent/autoauth/methods/gcp.mdx @@ -7,7 +7,7 @@ description: GCP Method for Vault Agent Auto-Auth # Vault Agent Auto-Auth GCP Method The `gcp` method performs authentication against the [GCP Auth -method](/docs/auth/gcp). Both `gce` and `iam` +method](/vault/docs/auth/gcp). Both `gce` and `iam` authentication types are supported. ## Credentials diff --git a/website/content/docs/agent/autoauth/methods/jwt.mdx b/website/content/docs/agent/autoauth/methods/jwt.mdx index 26400a219f..da290dda66 100644 --- a/website/content/docs/agent/autoauth/methods/jwt.mdx +++ b/website/content/docs/agent/autoauth/methods/jwt.mdx @@ -7,7 +7,7 @@ description: JWT Method for Vault Agent Auto-Auth # Vault Agent Auto-Auth JWT Method The `jwt` method reads in a JWT from a file and sends it to the [JWT Auth -method](/docs/auth/jwt). +method](/vault/docs/auth/jwt). ## Configuration diff --git a/website/content/docs/agent/autoauth/methods/kerberos.mdx b/website/content/docs/agent/autoauth/methods/kerberos.mdx index 6905995c91..daab824942 100644 --- a/website/content/docs/agent/autoauth/methods/kerberos.mdx +++ b/website/content/docs/agent/autoauth/methods/kerberos.mdx @@ -13,7 +13,7 @@ a Vault token for Kerberos entities. It reads in configuration and identification information from the surrounding environment, and uses it to authenticate to Vault. -For more on this auth method, see the [Kerberos auth method](/docs/auth/kerberos). +For more on this auth method, see the [Kerberos auth method](/vault/docs/auth/kerberos). ## Configuration diff --git a/website/content/docs/agent/autoauth/methods/kubernetes.mdx b/website/content/docs/agent/autoauth/methods/kubernetes.mdx index b8b81371e9..77497d2c16 100644 --- a/website/content/docs/agent/autoauth/methods/kubernetes.mdx +++ b/website/content/docs/agent/autoauth/methods/kubernetes.mdx @@ -9,7 +9,7 @@ description: Kubernetes Method for Vault Agent Auto-Auth The `kubernetes` method reads in a Kubernetes service account token from the running pod (via `/var/run/secrets/kubernetes.io/serviceaccount/token`) and sends it to the [Kubernetes Auth -method](/docs/auth/kubernetes/). +method](/vault/docs/auth/kubernetes/). ## Configuration diff --git a/website/content/docs/agent/autoauth/methods/token_file.mdx b/website/content/docs/agent/autoauth/methods/token_file.mdx index 7b4bfe311f..81080c3d12 100644 --- a/website/content/docs/agent/autoauth/methods/token_file.mdx +++ b/website/content/docs/agent/autoauth/methods/token_file.mdx @@ -25,7 +25,7 @@ auto-auth method, such that Agent is issuing its own authentication requests to ## Example Configuration -An example configuration, using the `token_file` method to enable [auto-auth](/docs/agent/autoauth), follows: +An example configuration, using the `token_file` method to enable [auto-auth](/vault/docs/agent/autoauth), follows: ```hcl pid_file = "./pidfile" diff --git a/website/content/docs/agent/autoauth/sinks/file.mdx b/website/content/docs/agent/autoauth/sinks/file.mdx index e1b226a775..6b2d436780 100644 --- a/website/content/docs/agent/autoauth/sinks/file.mdx +++ b/website/content/docs/agent/autoauth/sinks/file.mdx @@ -24,4 +24,4 @@ written with `0640` permissions as default, but can be overridden with the optio - `mode` `(int: optional)` - A string containing an octal number representing the bit pattern for the file mode, similar to chmod. Set to `0000` to prevent Vault from modifying the file mode. Note: This configuration option is only available in Vault 1.3.0 and above. ~> Note: Configuration options for response-wrapping and encryption for the sink -file are located within the [options common to all sinks](/docs/agent/autoauth#configuration-sinks) documentation. +file are located within the [options common to all sinks](/vault/docs/agent/autoauth#configuration-sinks) documentation. diff --git a/website/content/docs/agent/caching/index.mdx b/website/content/docs/agent/caching/index.mdx index 4a2753523d..bcb75a3eec 100644 --- a/website/content/docs/agent/caching/index.mdx +++ b/website/content/docs/agent/caching/index.mdx @@ -42,7 +42,7 @@ Vault Agent can restore tokens and leases from a persistent cache file created by a previous Vault Agent process. Refer to the [Vault Agent Persistent -Caching](/docs/agent/caching/persistent-caches) page for more information on +Caching](/vault/docs/agent/caching/persistent-caches) page for more information on this functionality. ## Cache Evictions @@ -162,7 +162,7 @@ The top level `cache` block has the following configuration entry: The `cache` block also supports the `use_auto_auth_token`, `enforce_consistency`, and `when_inconsistent` configuration values of the `api_proxy` block -[described in the API Proxy documentation](/docs/agent/apiproxy#configuration-api_proxy) only to +[described in the API Proxy documentation](/vault/docs/agent/apiproxy#configuration-api_proxy) only to maintain backwards compatibility. This configuration **cannot** be specified alongside `api_proxy` equivalents, should not be preferred over configuring these values in the `api_proxy` block, and `api_proxy` should be the preferred place to configure these values. @@ -171,8 +171,8 @@ and `api_proxy` should be the preferred place to configure these values. [template][agent-template] or [listener][agent-listener] must also be defined in the config, otherwise there is no way to utilize the cache. -[agent-template]: /docs/agent/template -[agent-listener]: /docs/agent#listener-stanza +[agent-template]: /vault/docs/agent/template +[agent-listener]: /vault/docs/agent#listener-stanza ### Configuration (Persist) @@ -200,9 +200,9 @@ Defaults to `/var/run/secrets/kubernetes.io/serviceaccount/token`. - `listener` `(array of objects: required)` - Configuration for the listeners. There can be one or more `listener` blocks at the top level. Adding a listener enables -the [API Proxy](/docs/agent/apiproxy) and enables the API proxy to use the cache, if configured. +the [API Proxy](/vault/docs/agent/apiproxy) and enables the API proxy to use the cache, if configured. These configuration values are common to both `tcp` and `unix` listener blocks. Blocks of type -`tcp` support the standard `tcp` [listener](/docs/configuration/listener/tcp) +`tcp` support the standard `tcp` [listener](/vault/docs/configuration/listener/tcp) options. Additionally, the `role` string option is available as part of the top level of the `listener` block, which can be configured to `metrics_only` to serve only metrics, or the default role, `default`, which serves everything (including metrics). diff --git a/website/content/docs/agent/caching/persistent-caches/kubernetes.mdx b/website/content/docs/agent/caching/persistent-caches/kubernetes.mdx index 5217edb06d..febf9d3bc4 100644 --- a/website/content/docs/agent/caching/persistent-caches/kubernetes.mdx +++ b/website/content/docs/agent/caching/persistent-caches/kubernetes.mdx @@ -16,7 +16,7 @@ and leases between initialization and sidecar Vault Agent containers. This cache using a memory volume between the Vault Agent containers. If the Vault Agent Injector for Kubernetes is being used, the persistent cache is automatically configured -and used if the annotation [`vault.hashicorp.com/agent-cache-enable: true`](/docs/platform/k8s/injector/annotations#vault-hashicorp-com-agent-cache-enable) is set. +and used if the annotation [`vault.hashicorp.com/agent-cache-enable: true`](/vault/docs/platform/k8s/injector/annotations#vault-hashicorp-com-agent-cache-enable) is set. ## Configuration diff --git a/website/content/docs/agent/index.mdx b/website/content/docs/agent/index.mdx index f1b6beca1a..755d888a15 100644 --- a/website/content/docs/agent/index.mdx +++ b/website/content/docs/agent/index.mdx @@ -26,7 +26,7 @@ request secrets from Vault. This implies code changes to client applications along with additional testing and maintenance of the application. The following code example implements Vault API to authenticate with Vault -through [AppRole auth method](/docs/auth/approle#code-example), and then uses +through [AppRole auth method](/vault/docs/auth/approle#code-example), and then uses the returned client token to read secrets at `kv-v2/data/creds`. ```go @@ -111,7 +111,7 @@ the Auto-Auth token for these requests. Please see the [API Proxy docs][apiproxy for more information. API Proxy functionality takes place within a defined `listener`, and its behaviour can be configured with an -[`api_proxy` stanza](/docs/agent/apiproxy#configuration-api_proxy). +[`api_proxy` stanza](/vault/docs/agent/apiproxy#configuration-api_proxy). ## Caching @@ -133,7 +133,7 @@ to only enable this on trusted interfaces, as it does not require any authorizat ### Cache -See the [caching](/docs/agent/caching#api) page for details on the cache API. +See the [caching](/vault/docs/agent/caching#api) page for details on the cache API. ## Configuration @@ -211,7 +211,7 @@ These are the currently-available general configuration options: - `template_config` ([template_config][template-config]: ) - Specifies templating engine behavior. - `telemetry` ([telemetry][telemetry]: ) – Specifies the telemetry - reporting system. See the [telemetry Stanza](/docs/agent#telemetry-stanza) section below + reporting system. See the [telemetry Stanza](/vault/docs/agent#telemetry-stanza) section below for a list of metrics specific to Agent. - `log_level` - Equivalent to the [`-log-level` command-line flag](#_log_level). @@ -326,7 +326,7 @@ listener configuration, an Agent's listener configuration also supports the foll #### agent_api Stanza -- `enable_quit` `(bool: false)` - If set to `true`, the agent will enable the [quit](/docs/agent#quit) API. +- `enable_quit` `(bool: false)` - If set to `true`, the agent will enable the [quit](/vault/docs/agent#quit) API. ### telemetry Stanza @@ -347,7 +347,7 @@ runtime metrics about its performance, the auto-auth and the cache status: To run Vault Agent: -1. [Download](/downloads) the Vault binary where the client application runs +1. [Download](/vault/downloads) the Vault binary where the client application runs (virtual machine, Kubernetes pod, etc.) 1. Create a Vault Agent configuration file. (See the [Example @@ -446,15 +446,15 @@ template { } ``` -[vault]: /docs/agent#vault-stanza -[autoauth]: /docs/agent/autoauth -[caching]: /docs/agent/caching -[apiproxy]: /docs/agent/apiproxy -[persistent-cache]: /docs/agent/caching/persistent-caches -[template]: /docs/agent/template -[template-config]: /docs/agent/template#template-configurations -[agent-api]: /docs/agent/#agent_api-stanza -[listener]: /docs/agent#listener-stanza -[listener_main]: /docs/configuration/listener/tcp -[winsvc]: /docs/agent/winsvc -[telemetry]: /docs/configuration/telemetry +[vault]: /vault/docs/agent#vault-stanza +[autoauth]: /vault/docs/agent/autoauth +[caching]: /vault/docs/agent/caching +[apiproxy]: /vault/docs/agent/apiproxy +[persistent-cache]: /vault/docs/agent/caching/persistent-caches +[template]: /vault/docs/agent/template +[template-config]: /vault/docs/agent/template#template-configurations +[agent-api]: /vault/docs/agent/#agent_api-stanza +[listener]: /vault/docs/agent#listener-stanza +[listener_main]: /vault/docs/configuration/listener/tcp +[winsvc]: /vault/docs/agent/winsvc +[telemetry]: /vault/docs/configuration/telemetry diff --git a/website/content/docs/agent/template.mdx b/website/content/docs/agent/template.mdx index ffbfd10d62..d3f08f74d7 100644 --- a/website/content/docs/agent/template.mdx +++ b/website/content/docs/agent/template.mdx @@ -51,7 +51,7 @@ of secret that's being rendered by this function, template will have different renewal behavior as detailed in the [Renewals section](#renewals-and-updating-secrets). The `pkiCert` function is intended to work specifically for certificates issued by the [PKI Secrets -Engine](/docs/secrets/pki). Refer to the [Certificates](#certificates) section +Engine](/vault/docs/secrets/pki). Refer to the [Certificates](#certificates) section for differences in certificate renewal behavior between `secret` and `pkiCert`. The following links contain additional resources for the templating language used by Vault Agent templating. @@ -104,7 +104,7 @@ failures. - `static_secret_render_interval` `(string or integer: 5m)` - If specified, configures how often Vault Agent Template should render non-leased secrets such as KV v2. This setting will not change how often Vault Agent Templating renders leased - secrets. Uses [duration format strings](/docs/concepts/duration-format). + secrets. Uses [duration format strings](/vault/docs/concepts/duration-format). ### `template_config` Stanza Example @@ -115,7 +115,7 @@ template_config { } ``` -In another example `template_config` with [`error_on_missing_key` parameter in the template stanza](/docs/agent/template#error_on_missing_key) +In another example `template_config` with [`error_on_missing_key` parameter in the template stanza](/vault/docs/agent/template#error_on_missing_key) as well as `exit_on_retry_failure` result in the agent exiting in case of no key / value issues instead of the default retry behavior. @@ -135,7 +135,7 @@ template { ### Interaction between `exit_on_retry_failure` and `error_on_missing_key` The parameter -[`error_on_missing_key`](/docs/agent/template#error_on_missing_key) can be +[`error_on_missing_key`](/vault/docs/agent/template#error_on_missing_key) can be specified within the `template` stanza which determines if a template should error when a key is missing in the secret. When `error_on_missing_key` is not specified or set to `false` and the key to render is not in the secret's @@ -184,7 +184,7 @@ can be used here: - `error_on_missing_key` `(bool: false)` - Exit with an error when accessing a struct or map field/key that does notexist. The default behavior will print `` when accessing a field that does not exist. It is highly recommended you set this - to "true". Also see [`exit_on_retry_failure` in global Vault Agent Template Config](/docs/agent/template#interaction-between-exit_on_retry_failure-and-error_on_missing_key). + to "true". Also see [`exit_on_retry_failure` in global Vault Agent Template Config](/vault/docs/agent/template#interaction-between-exit_on_retry_failure-and-error_on_missing_key). - `exec` `(object: optional)` - The exec block executes a command when the template is rendered and the output has changed. The block parameters are `command` `(string or array: required)` and `timeout` `(string: optional, defaults @@ -231,7 +231,7 @@ the `auto_auth` stanza in the agent configuration. ## Renewals and Updating Secrets The Vault Agent templating automatically renews and fetches secrets/tokens. -Unlike [Vault Agent caching](/docs/agent/caching), the behavior of how Vault Agent +Unlike [Vault Agent caching](/vault/docs/agent/caching), the behavior of how Vault Agent templating does this depends on the type of secret or token. The following is a high level overview of different behaviors. @@ -243,18 +243,18 @@ of the secret's lease duration has elapsed. ### Non-Renewable Secrets If a secret or token isn't renewable or leased, Vault Agent will fetch the secret every 5 minutes. -This can be configured using Template config [static_secret_render_interval](/docs/agent/template#static_secret_render_interval) (requires Vault 1.8+). -Non-renewable secrets include (but not limited to) [KV Version 2](/docs/secrets/kv/kv-v2). +This can be configured using Template config [static_secret_render_interval](/vault/docs/agent/template#static_secret_render_interval) (requires Vault 1.8+). +Non-renewable secrets include (but not limited to) [KV Version 2](/vault/docs/secrets/kv/kv-v2). ### Non-Renewable Leased Secrets If a secret or token is non-renewable but leased, Vault Agent will fetch the secret when 85% of the secrets time-to-live (TTL) is reached. Leased, non-renewable secrets include (but not limited -to) dynamic secrets such as [database credentials](/docs/secrets/databases) and [KV Version 1](/docs/secrets/kv/kv-v1). +to) dynamic secrets such as [database credentials](/vault/docs/secrets/databases) and [KV Version 1](/vault/docs/secrets/kv/kv-v1). ### Static Roles -If a secret has a `rotation_period`, such as a [database static role](/docs/secrets/databases#static-roles), +If a secret has a `rotation_period`, such as a [database static role](/vault/docs/secrets/databases#static-roles), Vault Agent template will fetch the new secret as it changes in Vault. It does this by inspecting the secret's time-to-live (TTL). @@ -267,7 +267,7 @@ re-authenticates. #### Rendering using the `pkiCert` template function -If a [certificate](/docs/secrets/pki) is rendered using the `pkiCert` template +If a [certificate](/vault/docs/secrets/pki) is rendered using the `pkiCert` template function, Vault Agent template will have the following fetching and re-rendering behaviors on certificates: @@ -278,7 +278,7 @@ skip fetching unless the current rendered one has expired. #### Rendering using the `secret` template function -If a [certificate](/docs/secrets/pki) is rendered using the `secret` template +If a [certificate](/vault/docs/secrets/pki) is rendered using the `secret` template function, Vault Agent template will have the following fetching and re-rendering behaviors on certificates: diff --git a/website/content/docs/audit/file.mdx b/website/content/docs/audit/file.mdx index d282df0dd8..4c2457d0e3 100644 --- a/website/content/docs/audit/file.mdx +++ b/website/content/docs/audit/file.mdx @@ -43,7 +43,7 @@ Note the difference between `audit enable` command options and the `file` backen configuration options. Use `vault audit enable -help` to see the command options. The `file` audit device supports the common configuration options documented on -the [main Audit Devices page](/docs/audit#common-configuration-options), and +the [main Audit Devices page](/vault/docs/audit#common-configuration-options), and these device-specific options: - `file_path` `(string: )` - The path to where the audit log will be diff --git a/website/content/docs/audit/index.mdx b/website/content/docs/audit/index.mdx index c8a3bffa67..fc88b7c36f 100644 --- a/website/content/docs/audit/index.mdx +++ b/website/content/docs/audit/index.mdx @@ -19,7 +19,7 @@ a way to check for data tampering in the logs themselves. Vault considers a request to be successful if it can log to *at least* one configured audit device (see: [Blocked Audit -Devices](/docs/audit#blocked-audit-devices) section below). Therefore in order +Devices](/vault/docs/audit#blocked-audit-devices) section below). Therefore in order to build a complete picture of all audited actions, use the aggregate/union of the logs from each audit device. @@ -49,15 +49,15 @@ HMAC'd. Other data types, like integers, booleans, and so on, are passed through in plaintext. We recommend that all sensitive data be provided as string values inside all JSON sent to Vault (i.e., that integer values are provided in quotes). -While most strings are hashed, Vault does make some exceptions, such as auth and secrets, and users can enable additional exceptions using the [secrets enable](/docs/commands/secrets/enable) command, and then tune it afterward. +While most strings are hashed, Vault does make some exceptions, such as auth and secrets, and users can enable additional exceptions using the [secrets enable](/vault/docs/commands/secrets/enable) command, and then tune it afterward. **see also**: -[secrets tune](/docs/commands/secrets/tune) +[secrets tune](/vault/docs/commands/secrets/tune) -[auth enable](/docs/commands/auth/enable) +[auth enable](/vault/docs/commands/auth/enable) -[auth tune](/docs/commands/auth/tune) +[auth tune](/vault/docs/commands/auth/tune) ## Enabling/Disabling Audit Devices @@ -80,7 +80,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-docs/system/audit#local) parameter. +An audit device can be limited to only within the node's cluster with the [`local`](/vault/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. @@ -99,17 +99,17 @@ In other words, Vault will not complete any requests until the blocked audit dev ## Tutorial -Refer to [Blocked Audit Devices](https://learn.hashicorp.com/tutorials/vault/blocked-audit-devices) for a step-by-step tutorial. +Refer to [Blocked Audit Devices](/vault/tutorials/monitoring/blocked-audit-devices) for a step-by-step tutorial. ## API Audit devices also have a full HTTP API. Please see the [Audit device API -docs](/api-docs/system/audit) for more details. +docs](/vault/api-docs/system/audit) for more details. ## Common configuration options - `elide_list_responses` `(bool: false)` - See [Eliding list response - bodies](docs/audit#eliding-list-response-bodies) below. + bodies](/vault/docs/audit#eliding-list-response-bodies) below. - `format` `(string: "json")` - Allows selecting the output format. Valid values are `"json"` and `"jsonx"`, which formats the normal log entries as XML. diff --git a/website/content/docs/audit/socket.mdx b/website/content/docs/audit/socket.mdx index 5a03cd3ce2..4daa56874b 100644 --- a/website/content/docs/audit/socket.mdx +++ b/website/content/docs/audit/socket.mdx @@ -29,7 +29,7 @@ $ vault audit enable socket address=127.0.0.1:9090 socket_type=tcp ## Configuration The `socket` audit device supports the common configuration options documented on -the [main Audit Devices page](/docs/audit#common-configuration-options), and +the [main Audit Devices page](/vault/docs/audit#common-configuration-options), and these device-specific options: - `address` `(string: "")` - The socket server address to use. Example @@ -38,4 +38,4 @@ these device-specific options: - `socket_type` `(string: "tcp")` - The socket type to use, any type compatible with net.Dial is acceptable. It's important to note if TCP is used and the destination socket becomes unavailable - Vault may become unresponsive per [Blocked Audit Devices](docs/audit/#blocked-audit-devices). + Vault may become unresponsive per [Blocked Audit Devices](/vault/docs/audit/#blocked-audit-devices). diff --git a/website/content/docs/audit/syslog.mdx b/website/content/docs/audit/syslog.mdx index 12f715791b..ca114d3d13 100644 --- a/website/content/docs/audit/syslog.mdx +++ b/website/content/docs/audit/syslog.mdx @@ -37,7 +37,7 @@ $ vault audit enable syslog tag="vault" facility="AUTH" ## Configuration The `syslog` audit device supports the common configuration options documented on -the [main Audit Devices page](/docs/audit#common-configuration-options), and +the [main Audit Devices page](/vault/docs/audit#common-configuration-options), and these device-specific options: - `facility` `(string: "AUTH")` - The syslog facility to use. diff --git a/website/content/docs/auth/alicloud.mdx b/website/content/docs/auth/alicloud.mdx index c1f514b5fe..4c67ebfd8a 100644 --- a/website/content/docs/auth/alicloud.mdx +++ b/website/content/docs/auth/alicloud.mdx @@ -108,5 +108,5 @@ can be found found in the ## API The AliCloud auth method has a full HTTP API. Please see the -[AliCloud Auth API](/api-docs/auth/alicloud) for more +[AliCloud Auth API](/vault/api-docs/auth/alicloud) for more details. diff --git a/website/content/docs/auth/app-id.mdx b/website/content/docs/auth/app-id.mdx index 033f4ec8a2..34fb117b6b 100644 --- a/website/content/docs/auth/app-id.mdx +++ b/website/content/docs/auth/app-id.mdx @@ -7,7 +7,7 @@ description: The AppID auth method is a mechanism for machines to authenticate w # AppID Auth Method ~> **DEPRECATED!** As of Vault 0.6.1, AppID is deprecated in favor of -[AppRole](/docs/auth/approle). AppRole can accommodate the same workflow as +[AppRole](/vault/docs/auth/approle). AppRole can accommodate the same workflow as AppID while enabling much more secure and flexible management and other types of authentication workflows. No new features or enhancements are planned for App ID, and new users should use AppRole instead of AppID. @@ -120,5 +120,5 @@ management tool. ## API The AppID auth method has a full HTTP API. Please see the -[AppID auth method API](/api-docs/auth/app-id) for more +[AppID auth method API](/vault/api-docs/auth/app-id) for more details. diff --git a/website/content/docs/auth/approle.mdx b/website/content/docs/auth/approle.mdx index eed7aade40..29ea2fe9cb 100644 --- a/website/content/docs/auth/approle.mdx +++ b/website/content/docs/auth/approle.mdx @@ -216,7 +216,7 @@ full set of client credentials (RoleID and SecretID) in order to create the entry, even if these are then distributed via different paths. However, in Pull mode, even though the RoleID must be known in order to distribute it to the client, the SecretID can be kept confidential from all parties except for the -final authenticating client by using [Response Wrapping](/docs/concepts/response-wrapping). +final authenticating client by using [Response Wrapping](/vault/docs/concepts/response-wrapping). Push mode is available for App-ID workflow compatibility, which in some specific cases is preferable, but in most cases Pull mode is more secure and @@ -242,7 +242,7 @@ tutorial to learn how to use the AppRole method to generate tokens for machines ## API The AppRole auth method has a full HTTP API. Please see the -[AppRole API](/api-docs/auth/approle) for more +[AppRole API](/vault/api-docs/auth/approle) for more details. ## Code Example diff --git a/website/content/docs/auth/aws.mdx b/website/content/docs/auth/aws.mdx index 1714f0451d..6a50945b02 100644 --- a/website/content/docs/auth/aws.mdx +++ b/website/content/docs/auth/aws.mdx @@ -348,7 +348,7 @@ are needed. `sts:AssumeRole` statement). - The `ManageOwnAccessKeys` stanza is necessary when you have configured Vault with static credentials, and wish to rotate these credentials with the - [Rotate Root Credentials](https://www.vaultproject.io/api-docs/auth/aws#rotate-root-credentials) + [Rotate Root Credentials](/vault/api-docs/auth/aws#rotate-root-credentials) API call. ## Client Nonce @@ -442,7 +442,7 @@ not specify the policy component, the client will inherit the allowed policies s on the role. If the role tag creation specifies the policy component but it contains no policies, the token will contain only the `default` policy; by default, this policy allows only manipulation (revocation, renewal, lookup) of the existing token, plus -access to its [cubbyhole](/docs/secrets/cubbyhole). +access to its [cubbyhole](/vault/docs/secrets/cubbyhole). This can be useful to allow instances access to a secure "scratch space" for storing data (via the token's cubbyhole) but without granting any access to other resources provided by or resident in Vault. @@ -758,7 +758,7 @@ The response will be in JSON. For example: ## API The AWS auth method has a full HTTP API. Please see the -[AWS Auth API](/api-docs/auth/aws) for more +[AWS Auth API](/vault/api-docs/auth/aws) for more details. ## Code Example diff --git a/website/content/docs/auth/azure.mdx b/website/content/docs/auth/azure.mdx index 485ff81eee..a680557368 100644 --- a/website/content/docs/auth/azure.mdx +++ b/website/content/docs/auth/azure.mdx @@ -40,15 +40,15 @@ must be granted to the Azure AD application in order for the auth method to acce APIs during authentication. ~> **Note:** The role assignments are only required when the -[`vm_name`](/api-docs/auth/azure#vm_name), [`vmss_name`](/api-docs/auth/azure#vmss_name), -or [`resource_id`](/api-docs/auth/azure#resource_id) parameters are used on login. +[`vm_name`](/vault/api-docs/auth/azure#vm_name), [`vmss_name`](/vault/api-docs/auth/azure#vmss_name), +or [`resource_id`](/vault/api-docs/auth/azure#resource_id) parameters are used on login. | Azure Environment | Login Parameter | Azure API Permission | | ----------- | --------------- | -------------------- | -| Virtual Machine | [`vm_name`](/api-docs/auth/azure#vm_name) | `Microsoft.Compute/virtualMachines/*/read` | -| Virtual Machine Scale Set ([Uniform Orchestration][vmss-uniform]) | [`vmss_name`](/api-docs/auth/azure#vmss_name) | `Microsoft.Compute/virtualMachineScaleSets/*/read` | -| Virtual Machine Scale Set ([Flexible Orchestration][vmss-flex]) | [`vmss_name`](/api-docs/auth/azure#vmss_name) | `Microsoft.Compute/virtualMachineScaleSets/*/read` `Microsoft.ManagedIdentity/userAssignedIdentities/*/read` | -| Services that ([support managed identities][managed-identities]) for Azure resources | [`resource_id`](/api-docs/auth/azure#resource_id) | `read` on the resource used to obtain the JWT | +| Virtual Machine | [`vm_name`](/vault/api-docs/auth/azure#vm_name) | `Microsoft.Compute/virtualMachines/*/read` | +| Virtual Machine Scale Set ([Uniform Orchestration][vmss-uniform]) | [`vmss_name`](/vault/api-docs/auth/azure#vmss_name) | `Microsoft.Compute/virtualMachineScaleSets/*/read` | +| Virtual Machine Scale Set ([Flexible Orchestration][vmss-flex]) | [`vmss_name`](/vault/api-docs/auth/azure#vmss_name) | `Microsoft.Compute/virtualMachineScaleSets/*/read` `Microsoft.ManagedIdentity/userAssignedIdentities/*/read` | +| Services that ([support managed identities][managed-identities]) for Azure resources | [`resource_id`](/vault/api-docs/auth/azure#resource_id) | `read` on the resource used to obtain the JWT | [vmss-uniform]: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-orchestration-modes#scale-sets-with-uniform-orchestration [vmss-flex]: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-orchestration-modes#scale-sets-with-flexible-orchestration @@ -154,7 +154,7 @@ tool. authentication type, as well as overall constraints and configuration for the generated auth tokens. - For the complete list of role options, please see the [API documentation](/api-docs/auth/azure). + For the complete list of role options, please see the [API documentation](/vault/api-docs/auth/azure). ### Via the API @@ -220,7 +220,7 @@ AZURE_GO_SDK_LOG_LEVEL=DEBUG ## API -The Azure Auth Plugin has a full HTTP API. Please see the [API documentation](/api-docs/auth/azure) for more details. +The Azure Auth Plugin has a full HTTP API. Please see the [API documentation](/vault/api-docs/auth/azure) for more details. ## Code Example diff --git a/website/content/docs/auth/cert.mdx b/website/content/docs/auth/cert.mdx index 4b5439bbbf..385e60bdaf 100644 --- a/website/content/docs/auth/cert.mdx +++ b/website/content/docs/auth/cert.mdx @@ -135,4 +135,4 @@ management tool. ## API The TLS Certificate auth method has a full HTTP API. Please see the -[TLS Certificate API](/api-docs/auth/cert) for more details. +[TLS Certificate API](/vault/api-docs/auth/cert) for more details. diff --git a/website/content/docs/auth/cf.mdx b/website/content/docs/auth/cf.mdx index c0a8b22589..78a7621682 100644 --- a/website/content/docs/auth/cf.mdx +++ b/website/content/docs/auth/cf.mdx @@ -324,5 +324,5 @@ match the certificates you're checking. ## API -The CF auth method has a full HTTP API. Please see the [CF Auth API](/api-docs/auth/cf) +The CF auth method has a full HTTP API. Please see the [CF Auth API](/vault/api-docs/auth/cf) for more details. diff --git a/website/content/docs/auth/gcp.mdx b/website/content/docs/auth/gcp.mdx index 1c06f51839..1b44e5139b 100644 --- a/website/content/docs/auth/gcp.mdx +++ b/website/content/docs/auth/gcp.mdx @@ -98,7 +98,7 @@ management tool. -> **Note**: If you're using a [Private Google Access](https://cloud.google.com/vpc/docs/configure-private-google-access) environment, you will additionally need to configure your environment’s custom endpoints - via the [custom_endpoint](/api-docs/auth/gcp#custom_endpoint) configuration parameter. + via the [custom_endpoint](/vault/api-docs/auth/gcp#custom_endpoint) configuration parameter. 1. Create a named role: @@ -163,18 +163,18 @@ The GCP project must have the following APIs enabled: - [compute.googleapis.com](https://console.cloud.google.com/flows/enableapi?apiid=compute.googleapis.com) for `gce` type roles. - [cloudresourcemanager.googleapis.com](https://console.cloud.google.com/flows/enableapi?apiid=cloudresourcemanager.googleapis.com) - for `iam` and `gce` type roles that set [`add_group_aliases`](/api-docs/auth/gcp#add_group_aliases) to true. + for `iam` and `gce` type roles that set [`add_group_aliases`](/vault/api-docs/auth/gcp#add_group_aliases) to true. #### Vault Server Permissions -**For `iam`-type Vault roles**, the service account [`credentials`](/api-docs/auth/gcp#credentials) +**For `iam`-type Vault roles**, the service account [`credentials`](/vault/api-docs/auth/gcp#credentials) given to Vault can have the following role: ```text roles/iam.serviceAccountKeyAdmin ``` -**For `gce`-type Vault roles**, the service account [`credentials`](/api-docs/auth/gcp#credentials) +**For `gce`-type Vault roles**, the service account [`credentials`](/vault/api-docs/auth/gcp#credentials) given to Vault can have the following role: ```text @@ -400,8 +400,8 @@ The GCP Auth Plugin has a full HTTP API. Please see the [signjwt-method]: https://cloud.google.com/iam/docs/reference/credentials/rest/v1/projects.serviceAccounts/signJwt [cloud-creds]: https://cloud.google.com/docs/authentication/production#providing_credentials_to_your_application [service-accounts]: https://cloud.google.com/compute/docs/access/service-accounts -[api-docs]: /api-docs/auth/gcp -[identity-group-aliases]: /api-docs/secret/identity/group-alias +[api-docs]: /vault/api-docs/auth/gcp +[identity-group-aliases]: /vault/api-docs/secret/identity/group-alias [instance-identity]: https://cloud.google.com/compute/docs/instances/verifying-instance-identity [repo]: https://github.com/hashicorp/vault-plugin-auth-gcp diff --git a/website/content/docs/auth/github.mdx b/website/content/docs/auth/github.mdx index d802c80eee..c50b6fe06f 100644 --- a/website/content/docs/auth/github.mdx +++ b/website/content/docs/auth/github.mdx @@ -109,5 +109,5 @@ management tool. ## API The GitHub auth method has a full HTTP API. Please see the -[GitHub Auth API](/api-docs/auth/github) for more +[GitHub Auth API](/vault/api-docs/auth/github) for more details. diff --git a/website/content/docs/auth/index.mdx b/website/content/docs/auth/index.mdx index 35163c5db4..2908a94d8d 100644 --- a/website/content/docs/auth/index.mdx +++ b/website/content/docs/auth/index.mdx @@ -16,12 +16,12 @@ Azure, Okta ...). Having multiple auth methods enables you to use an auth method that makes the most sense for your use case of Vault and your organization. -For example, on developer machines, the [GitHub auth method](/docs/auth/github) -is easiest to use. But for servers the [AppRole](/docs/auth/approle) +For example, on developer machines, the [GitHub auth method](/vault/docs/auth/github) +is easiest to use. But for servers the [AppRole](/vault/docs/auth/approle) method is the recommended choice. To learn more about authentication, see the -[authentication concepts page](/docs/concepts/auth). +[authentication concepts page](/vault/docs/concepts/auth). ## Enabling/Disabling Auth Methods @@ -31,7 +31,7 @@ Auth methods can be enabled/disabled using the CLI or the API. $ vault auth enable userpass ``` -When enabled, auth methods are similar to [secrets engines](/docs/secrets): +When enabled, auth methods are similar to [secrets engines](/vault/docs/secrets): they are mounted within the Vault mount table and can be accessed and configured using the standard read/write API. All auth methods are mounted underneath the `auth/` prefix. @@ -52,5 +52,5 @@ automatically logged out. When using an external auth method (e.g., GitHub), Vault will call the external service at the time of authentication and for any subsequent token renewals. This means that issued tokens are valid for their entire duration, and are not invalidated until a renewal or user re-authentication -occurs. Operators should ensure appropriate [token TTLs](/docs/concepts/tokens#the-general-case) +occurs. Operators should ensure appropriate [token TTLs](/vault/docs/concepts/tokens#the-general-case) are set when using these auth methods. \ No newline at end of file diff --git a/website/content/docs/auth/jwt/index.mdx b/website/content/docs/auth/jwt/index.mdx index b39196baf3..f8d7b0d87c 100644 --- a/website/content/docs/auth/jwt/index.mdx +++ b/website/content/docs/auth/jwt/index.mdx @@ -28,7 +28,7 @@ examples of OIDC and JWT usage. ## OIDC Authentication This section covers the setup and use of OIDC roles. If a JWT is to be provided directly, -refer to the [JWT Authentication](/docs/auth/jwt#jwt-authentication) section below. Basic +refer to the [JWT Authentication](/vault/docs/auth/jwt#jwt-authentication) section below. Basic familiarity with [OIDC concepts](https://developer.okta.com/blog/2017/07/25/oidc-primer-part-1) is assumed. The Authorization Code flow makes use of the Proof Key for Code Exchange (PKCE) extension. @@ -60,19 +60,19 @@ Logging in via the Vault UI requires a redirect URI of the form: The "host:port" must be correct for the Vault server, and "path" must match the path the JWT backend is mounted at (e.g. "oidc" or "jwt"). -If the [oidc_response_mode](/api-docs/auth/jwt#oidc_response_mode) is set to `form_post`, then +If the [oidc_response_mode](/vault/api-docs/auth/jwt#oidc_response_mode) is set to `form_post`, then logging in via the Vault UI requires a redirect URI of the form: `https://{host:port}/v1/auth/{path}/oidc/callback` -Prior to Vault 1.6, if [namespaces](/docs/enterprise/namespaces) are in use, +Prior to Vault 1.6, if [namespaces](/vault/docs/enterprise/namespaces) are in use, they must be added as query parameters, for example: `https://vault.example.com:8200/ui/vault/auth/oidc/oidc/callback?namespace=my_ns` For Vault 1.6+, it is no longer necessary to add the namespace as a query parameter in the redirect URI, if -[`namespace_in_state`](/api-docs/auth/jwt#namespace_in_state) is set to `true`, +[`namespace_in_state`](/vault/api-docs/auth/jwt#namespace_in_state) is set to `true`, which is the default for new configs. ### OIDC Login (Vault UI) @@ -115,7 +115,7 @@ not required to be set: The OIDC authentication flow has been successfully tested with a number of providers. A full guide to configuring OAuth/OIDC applications is beyond the scope of Vault documentation, but a collection of provider configuration steps has been collected to help get started: -[OIDC Provider Setup](/docs/auth/jwt/oidc-providers) +[OIDC Provider Setup](/vault/docs/auth/jwt/oidc-providers) ### OIDC Configuration Troubleshooting @@ -161,7 +161,7 @@ EOF `cat jwt.json | jq -r .access_token | cut -d. -f2 | base64 -D` -- As of Vault 1.2, the [`verbose_oidc_logging`](/api-docs/auth/jwt#verbose_oidc_logging) role +- As of Vault 1.2, the [`verbose_oidc_logging`](/vault/api-docs/auth/jwt#verbose_oidc_logging) role option is available which will log the received OIDC token to the _server_ logs if debug-level logging is enabled. This can 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 @@ -169,7 +169,7 @@ EOF - 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) + configuration](/vault/docs/auth/jwt/oidc-providers/azuread#optional-azure-specific-configuration) ## JWT Authentication @@ -248,7 +248,7 @@ management tool. 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). + list of available configuration options, please see the [API documentation](/vault/api-docs/auth/jwt). ```text $ vault write auth/jwt/config \ @@ -315,7 +315,7 @@ To limit authorization to a set of email addresses: } ``` -Bound claims can optionally be configured with globs. See the [API documentation](/api-docs/auth/jwt#bound_claims_type) for more details. +Bound claims can optionally be configured with globs. See the [API documentation](/vault/api-docs/auth/jwt#bound_claims_type) for more details. ### Claims as Metadata @@ -363,4 +363,4 @@ JSON Pointer can be used as a selector. Refer to the ## API The JWT Auth Plugin has a full HTTP API. Please see the -[API docs](/api-docs/auth/jwt) for more details. +[API docs](/vault/api-docs/auth/jwt) for more details. diff --git a/website/content/docs/auth/jwt/oidc-providers/azuread.mdx b/website/content/docs/auth/jwt/oidc-providers/azuread.mdx index 3f9e3337b9..1eab00b45a 100644 --- a/website/content/docs/auth/jwt/oidc-providers/azuread.mdx +++ b/website/content/docs/auth/jwt/oidc-providers/azuread.mdx @@ -34,12 +34,12 @@ Reference: [Azure Active Directory v2.0 and the OpenID Connect protocol](https:/ ### Connect AD group with Vault external group -Reference: [Azure Active Directory with OIDC Auth Method and External Groups](https://learn.hashicorp.com/tutorials/vault/oidc-auth-azure) +Reference: [Azure Active Directory with OIDC Auth Method and External Groups](/vault/tutorials/auth-methods/oidc-auth-azure) -To connect the AD group with a [Vault external groups](/docs/secrets/identity#external-vs-internal-groups), +To connect the AD group with a [Vault external groups](/vault/docs/secrets/identity#external-vs-internal-groups), you will need [Azure AD v2.0 endpoints](https://docs.microsoft.com/en-gb/azure/active-directory/develop/azure-ad-endpoint-comparison). -You should set up a [Vault policy](https://learn.hashicorp.com/tutorials/vault/policies) for the Azure AD group to use. +You should set up a [Vault policy](/vault/tutorials/policies/policies) for the Azure AD group to use. 1. Go to **Azure Active Directory** and choose your Vault application. @@ -59,7 +59,7 @@ You should set up a [Vault policy](https://learn.hashicorp.com/tutorials/vault/p oidc_discovery_url="https://login.microsoftonline.com/tenant_id/v2.0" ``` -1. Configure the [OIDC Role](/api-docs/auth/jwt#create-role) with the following: +1. Configure the [OIDC Role](/vault/api-docs/auth/jwt#create-role) with the following: - `user_claim` should be `"sub"` or `"oid"` following the [recommendation](https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens#using-claims-to-reliably-identify-a-user-subject-and-object-id) from Azure. @@ -75,16 +75,16 @@ You should set up a [Vault policy](https://learn.hashicorp.com/tutorials/vault/p policies=default ``` -1. In Vault, create the [external group](/api-docs/secret/identity/group). +1. In Vault, create the [external group](/vault/api-docs/secret/identity/group). Record the group ID as you will need it for the group alias. -1. From Vault, retrieve the [OIDC accessor ID](/api-docs/system/auth#list-auth-methods) +1. From Vault, retrieve the [OIDC accessor ID](/vault/api-docs/system/auth#list-auth-methods) from the OIDC auth method as you will need it for the group alias's `mount_accessor`. 1. Go to the Azure AD Group you want to attach to Vault's external group. Record the `objectId` as you will need it as the group alias name in Vault. -1. In Vault, create a [group alias](/api-docs/secret/identity/group-alias) +1. In Vault, create a [group alias](/vault/api-docs/secret/identity/group-alias) for the external group and set the `objectId` as the group alias name. ```shell vault write identity/group-alias \ diff --git a/website/content/docs/auth/jwt/oidc-providers/forgerock.mdx b/website/content/docs/auth/jwt/oidc-providers/forgerock.mdx index 113094b02d..b5a1785f6f 100644 --- a/website/content/docs/auth/jwt/oidc-providers/forgerock.mdx +++ b/website/content/docs/auth/jwt/oidc-providers/forgerock.mdx @@ -29,7 +29,7 @@ description: OIDC provider configuration for ForgeRock oidc_discovery_url="https://openam.example.com:8443/openam/oauth2" ``` -1. Configure the [OIDC Role](/api-docs/auth/jwt) with the following: +1. Configure the [OIDC Role](/vault/api-docs/auth/jwt) with the following: - `user_claim` should be `"sub"`. - `allowed_redirect_uris` should be the two redirect URIs for Vault CLI and UI access. - `oidc_scopes` should be set to the OIDC scopes. diff --git a/website/content/docs/auth/jwt/oidc-providers/google.mdx b/website/content/docs/auth/jwt/oidc-providers/google.mdx index edd51885da..6cdd00f887 100644 --- a/website/content/docs/auth/jwt/oidc-providers/google.mdx +++ b/website/content/docs/auth/jwt/oidc-providers/google.mdx @@ -14,7 +14,7 @@ Main reference: [Using OAuth 2.0 to Access Google APIs](https://developers.googl 1. Create a new credential via Credentials > Create Credentials > OAuth Client ID. 1. Configure the OAuth Consent Screen. Application Name is required. Save. 1. Select application type: "Web Application". -1. Configure Authorized [Redirect URIs](/docs/auth/jwt#redirect-uris). +1. Configure Authorized [Redirect URIs](/vault/docs/auth/jwt#redirect-uris). 1. Save client ID and secret. ### Optional Google-specific Configuration @@ -23,7 +23,7 @@ Google-specific configuration is available when using Google as an identity prov Vault JWT/OIDC auth method. The configuration allows Vault to obtain Google Workspace group membership and user information during the JWT/OIDC authentication flow. The group membership obtained from Google Workspace may be used for Identity group alias association. The user information obtained from Google Workspace can be -used to copy claims data into resulting auth token and alias metadata via [claim_mappings](/api-docs/auth/jwt#claim_mappings). +used to copy claims data into resulting auth token and alias metadata via [claim_mappings](/vault/api-docs/auth/jwt#claim_mappings). #### Setup @@ -65,7 +65,7 @@ that enable the feature. - `fetch_user_info` `(bool: false)` - If set to true, user info will be fetched from Google Workspace using the configured [user_custom_schemas](#user_custom_schemas). - `groups_recurse_max_depth` `(int: )` - Group membership recursion max depth. Defaults to 0, which means don't recurse. - `user_custom_schemas` `(string: )` - Comma-separated list of Google Workspace [custom schemas](https://developers.google.com/admin-sdk/directory/v1/guides/manage-schemas). - Values set for Google Workspace users using custom schema fields will be fetched and made available as claims that can be used with [claim_mappings](/api-docs/auth/jwt#claim_mappings). Required if [fetch_user_info](#fetch_user_info) is set to true. + Values set for Google Workspace users using custom schema fields will be fetched and made available as claims that can be used with [claim_mappings](/vault/api-docs/auth/jwt#claim_mappings). Required if [fetch_user_info](#fetch_user_info) is set to true. Example configuration: @@ -91,7 +91,7 @@ EOF #### Role -The [user_claim](/api-docs/auth/jwt#user_claim) value of the role must be set to +The [user_claim](/vault/api-docs/auth/jwt#user_claim) value of the role must be set to one of either `sub` or `email` for the Google Workspace group and user information queries to succeed. diff --git a/website/content/docs/auth/jwt/oidc-providers/index.mdx b/website/content/docs/auth/jwt/oidc-providers/index.mdx index 568d2e2ee4..8a19a2b71e 100644 --- a/website/content/docs/auth/jwt/oidc-providers/index.mdx +++ b/website/content/docs/auth/jwt/oidc-providers/index.mdx @@ -8,19 +8,19 @@ description: OIDC provider configuration quick starts This page collects high-level setup steps on how to configure an OIDC application for various providers. For more general usage and operation -information, see the [Vault JWT/OIDC method documentation](/docs/auth/jwt). +information, see the [Vault JWT/OIDC method documentation](/vault/docs/auth/jwt). OIDC providers are often highly configurable, and you should become familiar with their recommended settings and best practices. The guides listed below are largely community-driven and intended to help you get started. Corrections and additions may be submitted via the [Vault Github repository](https://github.com/hashicorp/vault). -- [Auth0](/docs/auth/jwt/oidc-providers/auth0) -- [Azure AD](/docs/auth/jwt/oidc-providers/azuread) -- [ForgeRock](/docs/auth/jwt/oidc-providers/forgerock) -- [Gitlab](/docs/auth/jwt/oidc-providers/gitlab) -- [Google](/docs/auth/jwt/oidc-providers/google) -- [Keycloak](/docs/auth/jwt/oidc-providers/keycloak) -- [Kubernetes](/docs/auth/jwt/oidc-providers/kubernetes) -- [Okta](/docs/auth/jwt/oidc-providers/okta) -- [SecureAuth](/docs/auth/jwt/oidc-providers/secureauth) +- [Auth0](/vault/docs/auth/jwt/oidc-providers/auth0) +- [Azure AD](/vault/docs/auth/jwt/oidc-providers/azuread) +- [ForgeRock](/vault/docs/auth/jwt/oidc-providers/forgerock) +- [Gitlab](/vault/docs/auth/jwt/oidc-providers/gitlab) +- [Google](/vault/docs/auth/jwt/oidc-providers/google) +- [Keycloak](/vault/docs/auth/jwt/oidc-providers/keycloak) +- [Kubernetes](/vault/docs/auth/jwt/oidc-providers/kubernetes) +- [Okta](/vault/docs/auth/jwt/oidc-providers/okta) +- [SecureAuth](/vault/docs/auth/jwt/oidc-providers/secureauth) diff --git a/website/content/docs/auth/jwt/oidc-providers/kubernetes.mdx b/website/content/docs/auth/jwt/oidc-providers/kubernetes.mdx index fe30820a83..383b12592e 100644 --- a/website/content/docs/auth/jwt/oidc-providers/kubernetes.mdx +++ b/website/content/docs/auth/jwt/oidc-providers/kubernetes.mdx @@ -14,7 +14,7 @@ during authentication, and instead uses public key cryptography to verify the contents of JWTs. This means tokens that have been revoked by Kubernetes will still be considered valid by Vault until their expiry time. To mitigate this risk, use short TTLs for service account tokens or use -[Kubernetes auth](/docs/auth/kubernetes) which _does_ use the `TokenReview` API. +[Kubernetes auth](/vault/docs/auth/kubernetes) which _does_ use the `TokenReview` API. ### Using service account issuer discovery diff --git a/website/content/docs/auth/jwt/oidc-providers/secureauth.mdx b/website/content/docs/auth/jwt/oidc-providers/secureauth.mdx index 22ca5904a0..fd024b8d44 100644 --- a/website/content/docs/auth/jwt/oidc-providers/secureauth.mdx +++ b/website/content/docs/auth/jwt/oidc-providers/secureauth.mdx @@ -29,6 +29,6 @@ EOH ``` This will instruct the OIDC Auth Method to parse the comma-separated groups claims string -into individual groups. Note that the role's [`groups_claim`](/api-docs/auth/jwt#groups_claim) +into individual groups. Note that the role's [`groups_claim`](/vault/api-docs/auth/jwt#groups_claim) value must be properly configured to target the groups claim for your SecureAuth identity provider. diff --git a/website/content/docs/auth/kerberos.mdx b/website/content/docs/auth/kerberos.mdx index f62589dca7..fa2314a25d 100644 --- a/website/content/docs/auth/kerberos.mdx +++ b/website/content/docs/auth/kerberos.mdx @@ -27,8 +27,8 @@ it into HashiCorp's maintenance. ## Prerequisites Kerberos is a very hands-on auth method. Other auth methods like -[LDAP](/docs/auth/ldap) and -[Azure](/docs/auth/azure) only require +[LDAP](/vault/docs/auth/ldap) and +[Azure](/vault/docs/auth/azure) only require a cursory amount of knowledge for configuration and use. Kerberos, on the other hand, is best used by people already familiar with it. We recommend that you use simpler authentication methods if @@ -114,14 +114,14 @@ $ vault write auth/kerberos/config/ldap \ ``` The LDAP above relies upon the same code as the LDAP auth method. -See [its documentation](/docs/auth/ldap) +See [its documentation](/vault/docs/auth/ldap) for further discussion of available parameters. - Configure the Vault policies that should be granted to those who successfully authenticate based on their LDAP group membership. Since this is identical to the LDAP auth method, see - [Group Membership Resolution](/docs/auth/ldap#group-membership-resolution) - and [LDAP Group -> Policy Mapping](/docs/auth/ldap#ldap-group-policy-mapping) + [Group Membership Resolution](/vault/docs/auth/ldap#group-membership-resolution) + and [LDAP Group -> Policy Mapping](/vault/docs/auth/ldap#ldap-group-policy-mapping) for further discussion. ```shell-session @@ -231,5 +231,5 @@ client. ## API The Kerberos auth method has a full HTTP API. Please see the -[Kerberos auth method API](/api-docs/auth/kerberos) for more +[Kerberos auth method API](/vault/api-docs/auth/kerberos) for more details. diff --git a/website/content/docs/auth/kubernetes.mdx b/website/content/docs/auth/kubernetes.mdx index 0643cd6f03..367a51db9a 100644 --- a/website/content/docs/auth/kubernetes.mdx +++ b/website/content/docs/auth/kubernetes.mdx @@ -83,7 +83,7 @@ management tool. 1. Use the `/config` endpoint to configure Vault to talk to Kubernetes. Use `kubectl cluster-info` to validate the Kubernetes host address and TCP port. For the list of available configuration options, please see the - [API documentation](/api-docs/auth/kubernetes). + [API documentation](/vault/api-docs/auth/kubernetes). ```bash vault write auth/kubernetes/config \ @@ -94,7 +94,7 @@ management tool. !> **Note:** The pattern Vault uses to authenticate Pods depends on sharing the JWT token over the network. Given the [security model of - Vault](/docs/internals/security), this is allowable because Vault is + Vault](/vault/docs/internals/security), this is allowable because Vault is part of the trusted compute base. In general, Kubernetes applications should **not** share this JWT with other applications, as it allows API calls to be made on behalf of the Pod and can result in unintended access being granted @@ -114,7 +114,7 @@ management tool. namespace and it gives it the default policy. For the complete list of configuration options, please see the [API - documentation](/api-docs/auth/kubernetes). + documentation](/vault/api-docs/auth/kubernetes). ## Kubernetes 1.21 @@ -127,7 +127,7 @@ Kubernetes auth: * The value of the JWT's `"iss"` claim depends on the cluster's configuration. The changes to token lifetime are important when configuring the -[`token_reviewer_jwt`](/api-docs/auth/kubernetes#token_reviewer_jwt) option. +[`token_reviewer_jwt`](/vault/api-docs/auth/kubernetes#token_reviewer_jwt) option. If a short-lived token is used, Kubernetes will revoke it as soon as the pod or service account are deleted, or if the expiry time passes, and Vault will no longer be able to use the @@ -166,7 +166,7 @@ injected service account tokens to a year to help smooth the transition to short-lived tokens. If you would like to disable this, set [--service-account-extend-token-expiration=false][k8s-extended-tokens] for `kube-apiserver` or specify your own `serviceAccountToken` volume mount. See -[here](/docs/auth/jwt/oidc-providers/kubernetes#specifying-ttl-and-audience) for an example. +[here](/vault/docs/auth/jwt/oidc-providers/kubernetes#specifying-ttl-and-audience) for an example. [k8s-extended-tokens]: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/#options @@ -239,7 +239,7 @@ JWT tokens Kubernetes generates can also be verified using Kubernetes as an OIDC provider. The JWT auth method documentation has [instructions][k8s-jwt-auth] for setting up JWT auth with Kubernetes as the OIDC provider. -[k8s-jwt-auth]: /docs/auth/jwt/oidc-providers/kubernetes +[k8s-jwt-auth]: /vault/docs/auth/jwt/oidc-providers/kubernetes This solution allows you to use short-lived tokens for all clients and removes the need for a reviewer JWT. However, the client tokens cannot be revoked before @@ -256,7 +256,7 @@ value, but `disable_iss_validation=true` is the new recommended value for all versions of Vault. Kubernetes 1.21+ clusters may require setting the service account -[`issuer`](/api-docs/auth/kubernetes#issuer) to the same value as +[`issuer`](/vault/api-docs/auth/kubernetes#issuer) to the same value as `kube-apiserver`'s `--service-account-issuer` flag. This is because the service account JWTs for these clusters may have an issuer specific to the cluster itself, instead of the old default of `kubernetes/serviceaccount`. If you are @@ -318,7 +318,7 @@ subjects: ## API The Kubernetes Auth Plugin has a full HTTP API. Please see the -[API docs](/api-docs/auth/kubernetes) for more details. +[API docs](/vault/api-docs/auth/kubernetes) for more details. [k8s-tokenreview]: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#tokenreview-v1-authentication-k8s-io diff --git a/website/content/docs/auth/ldap.mdx b/website/content/docs/auth/ldap.mdx index 2a9573df6c..82641bf3d5 100644 --- a/website/content/docs/auth/ldap.mdx +++ b/website/content/docs/auth/ldap.mdx @@ -269,5 +269,5 @@ It should be noted that user -> policy mapping happens at token creation time. A ## API The LDAP auth method has a full HTTP API. Please see the -[LDAP auth method API](/api-docs/auth/ldap) for more +[LDAP auth method API](/vault/api-docs/auth/ldap) for more details. diff --git a/website/content/docs/auth/login-mfa/faq.mdx b/website/content/docs/auth/login-mfa/faq.mdx index 8174039980..f155b03e31 100644 --- a/website/content/docs/auth/login-mfa/faq.mdx +++ b/website/content/docs/auth/login-mfa/faq.mdx @@ -26,7 +26,7 @@ This FAQ section contains frequently asked questions about the Login MFA feature Vault supports Step-up Enterprise MFA as part of our Enterprise edition. The Step-up Enterprise MFA provides MFA on login, or for step-up access to sensitive resources in Vault using ACL and Sentinel policies, and is configurable through the CLI/API. -Starting with Vault version 1.10, Vault OSS provides [MFA on login](/docs/auth/login-mfa) only. This is also available with Vault Enterprise and configurable through the CLI/API. +Starting with Vault version 1.10, Vault OSS provides [MFA on login](/vault/docs/auth/login-mfa) only. This is also available with Vault Enterprise and configurable through the CLI/API. The Step-up Enterprise MFA will co-exist with the newly introduced Login MFA starting with Vault version 1.10. @@ -34,15 +34,15 @@ The Step-up Enterprise MFA will co-exist with the newly introduced Login MFA sta | MFA workflow | What does it do? | Who manages the MFA? | OSS vs. Enterprise Support | | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | ----------------------------- | -| [Login MFA](/docs/auth/login-mfa) | MFA in Vault OSS provides MFA on login. CLI, API, and UI-based login are supported. | MFA is managed by Vault | Supported in Vault OSS | -| [Okta Auth MFA](/docs/auth/okta#mfa) | This is MFA as part of [Okta Auth method](/docs/auth/okta) in Vault OSS, where MFA is enforced by Okta on login. MFA must be satisfied for authentication to be successful. This is different from the Okta MFA method used with Login MFA and Step-up Enterprise MFA. CLI/API login are supported. | MFA is managed externally by Okta | Supported in Vault OSS | -| [Step-up Enterprise MFA](/docs/enterprise/mfa) | MFA in Vault Enterprise provides MFA for login and for step-up access to sensitive resources in Vault. Supports CLI/API based login, and ACL/Sentinel policies. | MFA is managed by Vault | Supported in Vault Enterprise | +| [Login MFA](/vault/docs/auth/login-mfa) | MFA in Vault OSS provides MFA on login. CLI, API, and UI-based login are supported. | MFA is managed by Vault | Supported in Vault OSS | +| [Okta Auth MFA](/vault/docs/auth/okta#mfa) | This is MFA as part of [Okta Auth method](/vault/docs/auth/okta) in Vault OSS, where MFA is enforced by Okta on login. MFA must be satisfied for authentication to be successful. This is different from the Okta MFA method used with Login MFA and Step-up Enterprise MFA. CLI/API login are supported. | MFA is managed externally by Okta | Supported in Vault OSS | +| [Step-up Enterprise MFA](/vault/docs/enterprise/mfa) | MFA in Vault Enterprise provides MFA for login and for step-up access to sensitive resources in Vault. Supports CLI/API based login, and ACL/Sentinel policies. | MFA is managed by Vault | Supported in Vault Enterprise | -~> **Note**: [The Legacy MFA](/docs/v1.10.x/auth/mfa) is a **deprecated** MFA workflow in Vault OSS. Refer [here](#q-what-is-the-legacy-mfa-feature) for more details. +~> **Note**: [The Legacy MFA](/vault/docs/v1.10.x/auth/mfa) is a **deprecated** MFA workflow in Vault OSS. Refer [here](#q-what-is-the-legacy-mfa-feature) for more details. ### Q: What is the Legacy MFA feature? -[Legacy MFA](/docs/v1.10.x/auth/mfa) is functionality that was available in Vault OSS, prior to introducing MFA in the Enterprise version. This is now a deprecated feature. Please see the [Vault Feature Deprecation Notice and Plans](/docs/deprecation) for detailed product plans around deprecated features. We plan to remove Legacy MFA in 1.11. +[Legacy MFA](/vault/docs/v1.10.x/auth/mfa) is functionality that was available in Vault OSS, prior to introducing MFA in the Enterprise version. This is now a deprecated feature. Please see the [Vault Feature Deprecation Notice and Plans](/vault/docs/deprecation) for detailed product plans around deprecated features. We plan to remove Legacy MFA in 1.11. ### Q: Will HCP Vault support MFA? @@ -61,7 +61,7 @@ If the configured MFA methods, such as PingID, Okta, or Duo, do not require a pa ### Q: Are there new MFA API endpoints introduced as part of the new Vault version 1.10 MFA for login functionality? -Yes, this feature adds the following new MFA configuration endpoints: `identity/mfa/method`, `identity/mfa/login-enforcement`, and `sys/mfa/validate`. Refer to the [documentation](/api-docs/secret/identity/mfa/duo) for more details. +Yes, this feature adds the following new MFA configuration endpoints: `identity/mfa/method`, `identity/mfa/login-enforcement`, and `sys/mfa/validate`. Refer to the [documentation](/vault/api-docs/secret/identity/mfa/duo) for more details. ### Q: How do MFA configurations differ between the Login MFA and Step-up Enterprise MFA? @@ -72,27 +72,27 @@ All MFA methods supported with the Step-up Enterprise MFA are supported with the There are also two differences in how methods are defined in the two systems. The Step-up Enterprise MFA expects the method creator to specify a name for the method; Login MFA does not, and instead returns an ID when a method is created. -The Step-up Enterprise MFA uses the combination of mount accessors plus a `username_format` template string, whereas in Login MFA, these are combined into a single field `username_format`, which uses the same identity [templating format](/docs/concepts/policies#templated-policies) as used in policies. +The Step-up Enterprise MFA uses the combination of mount accessors plus a `username_format` template string, whereas in Login MFA, these are combined into a single field `username_format`, which uses the same identity [templating format](/vault/docs/concepts/policies#templated-policies) as used in policies. ### Q: What are the ways to configure the various MFA workflows? | MFA workflow | Configuration methods | Details | | ---------------------------------------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [Login MFA](/docs/auth/login-mfa) | CLI/API. The UI does not support the configuration of Login MFA as of Vault version 1.10. | Configured using the `identity/mfa/method` endpoints, then passing those method IDs to the `identity/mfa/login-enforcement` endpoint. MFA methods supported: TOTP, Okta, Duo, PingID. | -| [Okta Auth MFA](/docs/auth/okta) | CLI/API | MFA methods supported: [TOTP](https://help.okta.com/en/prod/Content/Topics/Security/mfa-totp-seed.htm) , [Okta Verify Push](https://help.okta.com/en/prod/Content/Topics/Mobile/ov-admin-config.htm). Note that Vault does not support Okta Verify Push with Number Challenge at this time. | -| [Step-up Enterprise MFA](/docs/enterprise/mfa) | CLI/API | [Configured](/api-docs/system/mfa) using the `sys/mfa/method` endpoints and by referencing those methods in policies. MFA Methods supported: TOTP, Okta, Duo, PingID | +| [Login MFA](/vault/docs/auth/login-mfa) | CLI/API. The UI does not support the configuration of Login MFA as of Vault version 1.10. | Configured using the `identity/mfa/method` endpoints, then passing those method IDs to the `identity/mfa/login-enforcement` endpoint. MFA methods supported: TOTP, Okta, Duo, PingID. | +| [Okta Auth MFA](/vault/docs/auth/okta) | CLI/API | MFA methods supported: [TOTP](https://help.okta.com/en/prod/Content/Topics/Security/mfa-totp-seed.htm) , [Okta Verify Push](https://help.okta.com/en/prod/Content/Topics/Mobile/ov-admin-config.htm). Note that Vault does not support Okta Verify Push with Number Challenge at this time. | +| [Step-up Enterprise MFA](/vault/docs/enterprise/mfa) | CLI/API | [Configured](/vault/api-docs/system/mfa) using the `sys/mfa/method` endpoints and by referencing those methods in policies. MFA Methods supported: TOTP, Okta, Duo, PingID | ### Q: Which MFA mechanism is used with the different MFA workflows in Vault version 1.10? | MFA workflow | UI | CLI/API | Single-Phase | Two-Phase | | ---------------------------------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | --------------------------- | -| [Login MFA](/docs/auth/login-mfa) | Supported | Supported. You can select single-phase MFA by supplying the X-Vault-MFA header. In the absence of this header, the Two- Phase MFA is used | N/A | Supported | -| [Okta Auth MFA](/docs/auth/okta) | N/A | N/A | MFA is not managed by Vault | MFA is not managed by Vault | -| [Step-up Enterprise MFA](/docs/enterprise/mfa) | N/A | Supported | Supported | N/A | +| [Login MFA](/vault/docs/auth/login-mfa) | Supported | Supported. You can select single-phase MFA by supplying the X-Vault-MFA header. In the absence of this header, the Two- Phase MFA is used | N/A | Supported | +| [Okta Auth MFA](/vault/docs/auth/okta) | N/A | N/A | MFA is not managed by Vault | MFA is not managed by Vault | +| [Step-up Enterprise MFA](/vault/docs/enterprise/mfa) | N/A | Supported | Supported | N/A | ### Q: Are namespaces supported with the MFA workflows that Vault has as of Vault version 1.10? -The Step-up Enterprise MFA configurations can only be configured in the root [namespace](/docs/enterprise/mfa#namespaces), although they can be referenced in other namespaces via the policies. +The Step-up Enterprise MFA configurations can only be configured in the root [namespace](/vault/docs/enterprise/mfa#namespaces), although they can be referenced in other namespaces via the policies. The Login MFA supports namespaces awareness. Users will need a Vault Enterprise license to user or configure Login MFA with namespaces. MFA method configurations can be defined per namespace with Login MFA, and used in enforcements defined in that namespace and its children. Everything operates in the root namespace in Vault OSS. MFA login enforcements can also be defined per namespace, and applied to that namespace and its children. ### Q: I use the Vault Agent. Does MFA pose any challenges for me? @@ -101,7 +101,7 @@ The Vault Agent should not use MFA to authenticate to Vault; it should be able t ### Q: I am a Step-up Enterprise MFA user using MFA for login. Should I migrate to the new Login MFA? -If you are currently using Enterprise MFA, evaluate your MFA specific use cases to determine whether or not you should migrate to [Login MFA](/docs/auth/login-mfa). +If you are currently using Enterprise MFA, evaluate your MFA specific use cases to determine whether or not you should migrate to [Login MFA](/vault/docs/auth/login-mfa). Here are some considerations: @@ -118,6 +118,6 @@ If you wish to migrate to Login MFA, follow these steps and guidelines to migrat -the new endpoints yield an ID instead of allowing you to define a name - -the new non-TOTP endpoints have a username_format field instead of username_format+mount_accessor fields; see [Templated Policies](/docs/concepts/policies#templated-policies) for the username_format format. + -the new non-TOTP endpoints have a username_format field instead of username_format+mount_accessor fields; see [Templated Policies](/vault/docs/concepts/policies#templated-policies) for the username_format format. 1. Instead of writing sentinel EGP rules to require that logins use MFA, use the `identity/mfa/login_enforcement` endpoint to specify the MFA methods. diff --git a/website/content/docs/auth/login-mfa/index.mdx b/website/content/docs/auth/login-mfa/index.mdx index 835354c75c..4649e29acc 100644 --- a/website/content/docs/auth/login-mfa/index.mdx +++ b/website/content/docs/auth/login-mfa/index.mdx @@ -10,7 +10,7 @@ description: |- Vault supports Multi-factor Authentication (MFA) for authenticating to an auth method using different authentication types. We use the term `Login MFA` to distinguish -this feature and the [Vault Enterprise MFA](/docs/enterprise/mfa). +this feature and the [Vault Enterprise MFA](/vault/docs/enterprise/mfa). Login MFA is built on top of the Identity system of Vault. ## MFA Types @@ -40,15 +40,15 @@ MFA in Vault includes the following login types: ## Login MFA Procedure ~> **NOTE:** Vault's built-in Login MFA feature does not protect against brute forcing of -TOTP passcodes by default. We recommend that per-client [rate limits](/docs/concepts/resource-quotas) +TOTP passcodes by default. We recommend that per-client [rate limits](/vault/docs/concepts/resource-quotas) are applied to the relevant login and/or mfa paths (e.g. `/sys/mfa/validate`). External MFA methods (`Duo`, `Ping` and `Okta`) may already provide configurable rate limiting. Rate limiting of Login MFA paths are enforced by default in Vault 1.10.1 and above. Login MFA can be configured to secure further authenticating to an auth method. To enable login -MFA, an MFA method needs to be configured. Please see [Login MFA API](/api-docs/secret/identity/mfa) for details +MFA, an MFA method needs to be configured. Please see [Login MFA API](/vault/api-docs/secret/identity/mfa) for details on how to configure an MFA method. Once an MFA method is configured, an operator can configure an MFA enforcement using the returned unique MFA method ID. -Please see [Login MFA Enforcement API](/api-docs/secret/identity/mfa/login-enforcement) +Please see [Login MFA Enforcement API](/vault/api-docs/secret/identity/mfa/login-enforcement) for details on how to configure an MFA enforcement config. MFA could be enforced for an entity, a group of entities, a specific auth method accessor, or an auth method type. A login request that matches any MFA enforcement restrictions is subject to further MFA validation, @@ -137,10 +137,10 @@ note that this can affect the login response on any auth mount protected by MFA Note that the `uses_passcode` boolean value will always show true for TOTP, and false for Okta and PingID. For Duo method, the value can be configured as part of the method configuration, using the `use_passcode` parameter. -Please see [Duo API](/api-docs/secret/identity/mfa/duo) for details +Please see [Duo API](/vault/api-docs/secret/identity/mfa/duo) for details on how to configure the boolean value for Duo. -To validate the MFA restricted login request, the user sends a second request to the [validate](/api-docs/system/mfa/validate) +To validate the MFA restricted login request, the user sends a second request to the [validate](/vault/api-docs/system/mfa/validate) endpoint including the MFA request ID and MFA payload. MFA payload contains a map of methodIDs and their associated credentials. If the configured MFA methods, such as PingID, Okta, and Duo, do not require a passcode, the associated credentials will be a list with one empty string. @@ -189,7 +189,7 @@ To disable the interactive login experience, a user needs to pass in the `non-in $ vault write -non-interactive sys/mfa/validate -format=json @payload.json ``` -To get started with Login MFA, refer to the [Login MFA](https://learn.hashicorp.com/tutorials/vault/multi-factor-authentication) tutorial. +To get started with Login MFA, refer to the [Login MFA](/vault/tutorials/auth-methods/multi-factor-authentication) tutorial. ### TOTP Passcode Validation Rate Limit diff --git a/website/content/docs/auth/oci.mdx b/website/content/docs/auth/oci.mdx index 07f806814f..ad15118d99 100644 --- a/website/content/docs/auth/oci.mdx +++ b/website/content/docs/auth/oci.mdx @@ -101,7 +101,7 @@ Create the Vault admin role: You will see a response that includes a token with the previously added policy. -1. Use the received token to read secrets, writer secrets, and add roles per the instructions in [/docs/secrets/kv/kv-v1](/docs/secrets/kv/kv-v1). +1. Use the received token to read secrets, writer secrets, and add roles per the instructions in [/docs/secrets/kv/kv-v1](/vault/docs/secrets/kv/kv-v1). 1. Log into Vault using the user API key. - [Add an API Key](https://docs.cloud.oracle.com/iaas/Content/API/Concepts/apisigningkey.htm) for a user in the console. This user should be part of a group that has previously been added to the Vault admin role. @@ -111,7 +111,7 @@ You will see a response that includes a token with the previously added policy. `vault login -method=oci auth_type=apikey role=vaultadminrole` -1. Stop Vault and re-start it in the production environment. See [the configuration docs](/docs/configuration/) for more information. +1. Stop Vault and re-start it in the production environment. See [the configuration docs](/vault/docs/configuration/) for more information. 1. Repeat all steps in this [Configure the OCI Auth Method](#configure-the-oci-auth-method) section while in the production environment. ### Manage Roles in the OCI Auth method @@ -199,4 +199,4 @@ POST http://127.0.0.1/v1/auth/oci/login/devrole ## API -The OCI Auth method has a full HTTP API. Please see the [API docs](/api-docs/auth/oci) for more details. +The OCI Auth method has a full HTTP API. Please see the [API docs](/vault/api-docs/auth/oci) for more details. diff --git a/website/content/docs/auth/okta.mdx b/website/content/docs/auth/okta.mdx index 2cb37c903e..56ce27e5ee 100644 --- a/website/content/docs/auth/okta.mdx +++ b/website/content/docs/auth/okta.mdx @@ -12,7 +12,7 @@ The `okta` auth method allows authentication using Okta and user/password credentials. This allows Vault to be integrated into environments using Okta. The mapping of groups in Okta to Vault policies is managed by using the -[users](/api-docs/auth/okta#register-user) and [groups](/api-docs/auth/okta#register-group) +[users](/vault/api-docs/auth/okta#register-user) and [groups](/vault/api-docs/auth/okta#register-group) APIs. ## Authentication @@ -75,7 +75,7 @@ It does not manage Okta [sessions](https://developer.okta.com/docs/reference/api users. This means that if MFA Push is configured, it will be required during both login and token renewal. Note that this MFA support is integrated with Okta Auth and is limited strictly to login -operations. It is not related to [Enterprise MFA](https://www.vaultproject.io/docs/enterprise/mfa). +operations. It is not related to [Enterprise MFA](/vault/docs/enterprise/mfa). ## Configuration @@ -106,7 +106,7 @@ management tool. queried. For the complete list of configuration options, please see the - [API documentation](/api-docs/auth/okta). + [API documentation](/vault/api-docs/auth/okta). 1. Map an Okta group to a Vault policy: @@ -138,7 +138,7 @@ management tool. The `okta` auth method uses the [Authentication](https://developer.okta.com/docs/reference/api/authn/) and [User Groups](https://developer.okta.com/docs/reference/api/users/#get-user-s-groups) -APIs to authenticate users and obtain their group membership. The [`api_token`](/api-docs/auth/okta#api_token) +APIs to authenticate users and obtain their group membership. The [`api_token`](/vault/api-docs/auth/okta#api_token) provided to the auth method's configuration must have sufficient privileges to exercise these Okta APIs. @@ -150,4 +150,4 @@ role. Custom roles may also be used to grant minimal permissions to the Okta API ## API The Okta auth method has a full HTTP API. Please see the -[Okta Auth API](/api-docs/auth/okta) for more details. +[Okta Auth API](/vault/api-docs/auth/okta) for more details. diff --git a/website/content/docs/auth/radius.mdx b/website/content/docs/auth/radius.mdx index 755a73ccad..a0581e7ea4 100644 --- a/website/content/docs/auth/radius.mdx +++ b/website/content/docs/auth/radius.mdx @@ -78,5 +78,5 @@ The response will contain a token at `auth.client_token`: ## API The RADIUS auth method has a full HTTP API. Please see the -[RADIUS Auth API](/api-docs/auth/radius) for more +[RADIUS Auth API](/vault/api-docs/auth/radius) for more details. diff --git a/website/content/docs/auth/token.mdx b/website/content/docs/auth/token.mdx index 491bb1d0b3..d743cbceaa 100644 --- a/website/content/docs/auth/token.mdx +++ b/website/content/docs/auth/token.mdx @@ -17,7 +17,7 @@ The token store can also be used to bypass any other auth method: you can create tokens directly, as well as perform a variety of other operations on tokens such as renewal and revocation. -Please see the [token concepts](/docs/concepts/tokens) page dedicated +Please see the [token concepts](/vault/docs/concepts/tokens) page dedicated to tokens. ## Authentication @@ -36,5 +36,5 @@ either `X-Vault-Token: ` or `Authorization: Bearer `. ## API The Token auth method has a full HTTP API. Please see the -[Token auth method API](/api-docs/auth/token) for more +[Token auth method API](/vault/api-docs/auth/token) for more details. diff --git a/website/content/docs/auth/userpass.mdx b/website/content/docs/auth/userpass.mdx index ae581bcc23..69cc57e8e7 100644 --- a/website/content/docs/auth/userpass.mdx +++ b/website/content/docs/auth/userpass.mdx @@ -84,4 +84,4 @@ management tool. ## API The Userpass auth method has a full HTTP API. Please see the [Userpass auth -method API](/api-docs/auth/userpass) for more details. +method API](/vault/api-docs/auth/userpass) for more details. diff --git a/website/content/docs/commands/agent.mdx b/website/content/docs/commands/agent.mdx index 18b7005e5a..196fb4fe0a 100644 --- a/website/content/docs/commands/agent.mdx +++ b/website/content/docs/commands/agent.mdx @@ -6,4 +6,4 @@ description: The "agent" command is used to start Vault Agent # agent -Please see the [Vault Agent documentation page](/docs/agent). +Please see the [Vault Agent documentation page](/vault/docs/agent). diff --git a/website/content/docs/commands/audit/disable.mdx b/website/content/docs/commands/audit/disable.mdx index 7a271dc1a1..05e9899142 100644 --- a/website/content/docs/commands/audit/disable.mdx +++ b/website/content/docs/commands/audit/disable.mdx @@ -29,5 +29,5 @@ Success! Disabled audit device (if it was enabled) at: file/ ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. diff --git a/website/content/docs/commands/audit/enable.mdx b/website/content/docs/commands/audit/enable.mdx index 6f3326f64e..f92d9bf0b5 100644 --- a/website/content/docs/commands/audit/enable.mdx +++ b/website/content/docs/commands/audit/enable.mdx @@ -24,12 +24,12 @@ Success! Enabled the file audit device at: file/ ``` Full configuration parameters for each audit device are available on the -[Audit Devices](/docs/audit) page. +[Audit Devices](/vault/docs/audit) page. ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. - `-description` `(string: "")` - Human-friendly description for the purpose of this audit device. diff --git a/website/content/docs/commands/audit/index.mdx b/website/content/docs/commands/audit/index.mdx index e492cffac6..f06fd9475c 100644 --- a/website/content/docs/commands/audit/index.mdx +++ b/website/content/docs/commands/audit/index.mdx @@ -12,7 +12,7 @@ The `audit` command groups subcommands for interacting with Vault's audit devices. Users can list, enable, and disable audit devices. For more information, please see the [audit device -documentation](/docs/audit) +documentation](/vault/docs/audit) ## Examples diff --git a/website/content/docs/commands/audit/list.mdx b/website/content/docs/commands/audit/list.mdx index c4400d95bb..327e838dff 100644 --- a/website/content/docs/commands/audit/list.mdx +++ b/website/content/docs/commands/audit/list.mdx @@ -34,7 +34,7 @@ file/ file n/a replicated file_path=/var/log/audit.log ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/auth/disable.mdx b/website/content/docs/commands/auth/disable.mdx index 41011e53b8..fd451aa465 100644 --- a/website/content/docs/commands/auth/disable.mdx +++ b/website/content/docs/commands/auth/disable.mdx @@ -28,5 +28,5 @@ Success! Disabled the auth method (if it existed) at: userpass/ ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. diff --git a/website/content/docs/commands/auth/enable.mdx b/website/content/docs/commands/auth/enable.mdx index 46d65b3d4d..f19c418d08 100644 --- a/website/content/docs/commands/auth/enable.mdx +++ b/website/content/docs/commands/auth/enable.mdx @@ -17,7 +17,7 @@ auth method. An auth method is responsible for authenticating users or machines and assigning them policies and a token with which they can access Vault. Authentication is usually mapped to policy. Please see the [policies -concepts](/docs/concepts/policies) page for more information. +concepts](/vault/docs/concepts/policies) page for more information. ## Examples @@ -36,17 +36,17 @@ Success! Data written to: auth/userpass/users/sethvargo ``` For more information on the specific configuration options and paths, please see -the [auth method](/docs/auth) documentation. +the [auth method](/vault/docs/auth) documentation. ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. - `-audit-non-hmac-request-keys` `(string: "")` - Key that will not be HMAC'd by audit devices in the request data object. Note that multiple keys may be specified by providing this option multiple times, each time with 1 key. - An example of this is provided in the [tune section](/docs/commands/auth/tune). + An example of this is provided in the [tune section](/vault/docs/commands/auth/tune). - `-audit-non-hmac-response-keys` `(string: "")` - Key that will not be HMAC'd by audit devices in the response data object. Note that multiple keys may be @@ -55,7 +55,7 @@ flags](/docs/commands) included on all commands. - `-default-lease-ttl` `(duration: "")` - The default lease TTL for this auth method. If unspecified, this defaults to the Vault server's globally configured default lease TTL, or a previously configured value for the auth - method. Uses [duration format strings](/docs/concepts/duration-format). + method. Uses [duration format strings](/vault/docs/concepts/duration-format). - `-passthrough-request-headers` `(string: "")` - request header values that will be sent to the auth method. Note that multiple keys may be diff --git a/website/content/docs/commands/auth/help.mdx b/website/content/docs/commands/auth/help.mdx index 610e188566..3bb4adb736 100644 --- a/website/content/docs/commands/auth/help.mdx +++ b/website/content/docs/commands/auth/help.mdx @@ -39,5 +39,5 @@ $ vault auth help my-method/ ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. diff --git a/website/content/docs/commands/auth/index.mdx b/website/content/docs/commands/auth/index.mdx index eec90c7388..5e7d73a7bc 100644 --- a/website/content/docs/commands/auth/index.mdx +++ b/website/content/docs/commands/auth/index.mdx @@ -13,10 +13,10 @@ The `auth` command groups subcommands for interacting with Vault's auth methods. Users can list, enable, disable, and get help for different auth methods. For more information, please see the [auth method -documentation](/docs/auth) or the [authentication -concepts](/docs/concepts/auth) page. +documentation](/vault/docs/auth) or the [authentication +concepts](/vault/docs/concepts/auth) page. -To authenticate to Vault as a user or machine, use the [`vault login`](/docs/commands/login) command instead. This command is for +To authenticate to Vault as a user or machine, use the [`vault login`](/vault/docs/commands/login) command instead. This command is for interacting with the auth methods themselves, not authenticating to Vault. ## Examples diff --git a/website/content/docs/commands/auth/list.mdx b/website/content/docs/commands/auth/list.mdx index 61c6a3546c..8414cf62ce 100644 --- a/website/content/docs/commands/auth/list.mdx +++ b/website/content/docs/commands/auth/list.mdx @@ -58,7 +58,7 @@ token/ token auth_token_aafab997 system system defaul ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/auth/move.mdx b/website/content/docs/commands/auth/move.mdx index e567d4d42b..cb5e3a5000 100644 --- a/website/content/docs/commands/auth/move.mdx +++ b/website/content/docs/commands/auth/move.mdx @@ -30,5 +30,5 @@ $ vault auth move ns1/auth/approle/ ns2/auth/new-approle/ ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. diff --git a/website/content/docs/commands/auth/tune.mdx b/website/content/docs/commands/auth/tune.mdx index 529e3949ec..15c5980542 100644 --- a/website/content/docs/commands/auth/tune.mdx +++ b/website/content/docs/commands/auth/tune.mdx @@ -70,7 +70,7 @@ user_lockout_threshold 10 ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. - `-allowed-response-headers` `(string: "")` - response header values that the auth method will be allowed to set. @@ -97,7 +97,7 @@ flags](/docs/commands) included on all commands. - `-max-lease-ttl` `(duration: "")` - The maximum lease TTL for this auth method. If unspecified, this defaults to the Vault server's globally - configured [maximum lease TTL](/docs/configuration#max_lease_ttl), or a + configured [maximum lease TTL](/vault/docs/configuration#max_lease_ttl), or a previously configured value for the auth method. This value is allowed to override the server's global max TTL; it can be longer or shorter. @@ -110,7 +110,7 @@ flags](/docs/commands) included on all commands. - `-plugin-version` `(string: "")` - Configures the semantic version of the plugin to use. The new version will not start running until the mount is - [reloaded](/docs/commands/plugin/reload). + [reloaded](/vault/docs/commands/plugin/reload). - `-user-lockout-threshold` `(string: "")` - Specifies the number of failed login attempts after which the user is locked out. User lockout feature was added in Vault 1.13. diff --git a/website/content/docs/commands/debug.mdx b/website/content/docs/commands/debug.mdx index 4b8b938dfb..3330ff4412 100644 --- a/website/content/docs/commands/debug.mdx +++ b/website/content/docs/commands/debug.mdx @@ -58,7 +58,7 @@ Additionally, host information is not available on the OpenBSD platform due to library limitations in fetching the data without enabling `cgo`. [Enterprise] Telemetry can be gathered from a DR Secondary active node via the -`metrics` target if [unauthenticated_metrics_access](/docs/configuration/listener/tcp#unauthenticated_metrics_access) is enabled. +`metrics` target if [unauthenticated_metrics_access](/vault/docs/configuration/listener/tcp#unauthenticated_metrics_access) is enabled. ## Output Layout @@ -125,7 +125,7 @@ $ vault debug -target=host -target=metrics ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Command Options diff --git a/website/content/docs/commands/delete.mdx b/website/content/docs/commands/delete.mdx index 75bebffe3a..57ea7cd495 100644 --- a/website/content/docs/commands/delete.mdx +++ b/website/content/docs/commands/delete.mdx @@ -28,7 +28,7 @@ $ vault delete transit/keys/my-key ``` Note: changing the `deletion_allowed` parameter to `true` is necessary for the -key to be successfully deleted, you can read more on key parameters [here](/api-docs/secret/transit#update-key-configuration) +key to be successfully deleted, you can read more on key parameters [here](/vault/api-docs/secret/transit#update-key-configuration) Delete an IAM role: @@ -38,5 +38,5 @@ $ vault delete aws/roles/ops ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. diff --git a/website/content/docs/commands/index.mdx b/website/content/docs/commands/index.mdx index 1dfd38e034..c1a536066e 100644 --- a/website/content/docs/commands/index.mdx +++ b/website/content/docs/commands/index.mdx @@ -13,10 +13,10 @@ description: |- ~> **Note:** The Vault command-line interface (CLI) changed substantially in 0.9.2+ and may cause confusion while using older versions of Vault with this documentation. Read our [upgrade -guide](/docs/upgrading/upgrade-to-0.9.2#backwards-compatible-cli-changes) for +guide](/vault/docs/upgrading/upgrade-to-0.9.2#backwards-compatible-cli-changes) for more information. -In addition to a verbose [HTTP API](/api-docs), Vault features a command-line +In addition to a verbose [HTTP API](/vault/api-docs), Vault features a command-line interface (CLI) that wraps common functionality and formats output. The Vault CLI is a single static binary. It is a thin wrapper around the HTTP API. Every CLI command maps directly to the HTTP API internally. @@ -38,7 +38,7 @@ vault [options] [path] [args] -- `options` - [Flags](/docs/commands#flags) to specify additional settings +- `options` - [Flags](/vault/docs/commands#flags) to specify additional settings - `args` - API arguments specific to the operation -> **NOTE:** Use the [command help](#command-help) to display available options @@ -49,7 +49,7 @@ and arguments. The following `write` command creates a new user (`bob`) in the userpass auth method. It passes the `-address` flag to specify the Vault server address which precedes the path (`auth/userpass/users/bob`) and its -[argument](/api-docs/auth/userpass#create-update-user) +[argument](/vault/api-docs/auth/userpass#create-update-user) (`password="long-password"`) at last. ```shell-session @@ -57,7 +57,7 @@ $ vault write -address="http://127.0.0.1:8200" auth/userpass/users/bob password= ``` If multiple options (`-address` and `-namespace`) and -[arguments](/api-docs/auth/userpass#create-update-user) (`password` and +[arguments](/vault/api-docs/auth/userpass#create-update-user) (`password` and `policies`) are specified, the command would look like: ```shell-session @@ -68,9 +68,9 @@ $ vault write -address="http://127.0.0.1:8200" -namespace="my-organization" \ The options (flags) come after the command (or subcommand) preceding the path, and the args always follow the path to set API parameter values. -The four most common operations in Vault are [read](/docs/commands/read), -[write](/docs/commands/write), [delete](/docs/commands/delete), and -[list](/docs/commands/list). These operations work on most paths in Vault. Some +The four most common operations in Vault are [read](/vault/docs/commands/read), +[write](/vault/docs/commands/write), [delete](/vault/docs/commands/delete), and +[list](/vault/docs/commands/list). These operations work on most paths in Vault. Some paths will contain secrets while other paths may contain configuration. Whatever it is, the primary interface for reading and writing data to Vault is similar. @@ -123,10 +123,10 @@ The help output displays available subcommands, parameters, and command flags. ### API Help -To invoke the Vault API paths, you can use the [read](/docs/commands/read) (for -HTTP GET), [write](/docs/commands/write) (for HTTP PUT or POST), -[delete](/docs/commands/delete) (for HTTP DELETE), and -[list](/docs/commands/list) (for HTTP LIST) commands. +To invoke the Vault API paths, you can use the [read](/vault/docs/commands/read) (for +HTTP GET), [write](/vault/docs/commands/write) (for HTTP PUT or POST), +[delete](/vault/docs/commands/delete) (for HTTP DELETE), and +[list](/vault/docs/commands/list) (for HTTP LIST) commands. Use `path-help` to get Vault API help: @@ -138,7 +138,7 @@ The `path-help` retrieves API help on any API paths. Vault API paths provide built-in help in markdown format. This includes system paths, secret engines, and auth methods. -**Example:** API help on the [`sys/mounts/`](/api-docs/system/mounts) path. +**Example:** API help on the [`sys/mounts/`](/vault/api-docs/system/mounts) path. ```shell-session $ vault path-help sys/mounts @@ -281,7 +281,7 @@ variables available to the Vault process will be logged during startup. Vault authentication token. Conceptually similar to a session token on a website, the `VAULT_TOKEN` environment variable holds the contents of the token. For more information, please see the [token -concepts](/docs/concepts/tokens) page. +concepts](/vault/docs/concepts/tokens) page. ### `VAULT_ADDR` @@ -326,12 +326,12 @@ Provide Vault output (read/status/write) in the specified format. Valid formats [Enterprise, Server only] Specify a license to use for this node. This takes precedence over [#VAULT_LICENSE_PATH](#vault_license_path) and -[license_path in config](/docs/configuration#license_path). +[license_path in config](/vault/docs/configuration#license_path). ### `VAULT_LICENSE_PATH` [Enterprise, Server only] Specify a path to a license on disk to use for this node. -This takes precedence over [license_path in config](/docs/configuration#license_path). +This takes precedence over [license_path in config](/vault/docs/configuration#license_path). ### `VAULT_LOG_LEVEL` @@ -355,7 +355,7 @@ High Availability mode. Do not verify Vault's presented certificate before communicating with it. Setting this variable is not recommended and voids Vault's [security -model](/docs/internals/security). +model](/vault/docs/internals/security). ### `VAULT_TLS_SERVER_NAME` @@ -379,7 +379,7 @@ limiting is off by default. _Note:_ The rate is limited for each invocation of the `vault` CLI. Since each invocation of the `vault` CLI typically only makes a few requests, this environment variable is most useful when using the Go -[Vault client API](/api-docs/libraries#go). +[Vault client API](/vault/api-docs/libraries#go). ### `VAULT_NAMESPACE` diff --git a/website/content/docs/commands/kv/delete.mdx b/website/content/docs/commands/kv/delete.mdx index 67973b1e43..c123285458 100644 --- a/website/content/docs/commands/kv/delete.mdx +++ b/website/content/docs/commands/kv/delete.mdx @@ -32,7 +32,7 @@ Success! Data deleted (if it existed) at: secret/data/creds ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. ### Command Options diff --git a/website/content/docs/commands/kv/destroy.mdx b/website/content/docs/commands/kv/destroy.mdx index 86fa351c49..20eb296359 100644 --- a/website/content/docs/commands/kv/destroy.mdx +++ b/website/content/docs/commands/kv/destroy.mdx @@ -8,7 +8,7 @@ description: |- # kv destroy -~> **NOTE:** This is a [K/V Version 2](/docs/secrets/kv/kv-v2) secrets +~> **NOTE:** This is a [K/V Version 2](/vault/docs/secrets/kv/kv-v2) secrets engine command, and not available for Version 1. The `kv destroy` command permanently removes the specified versions' data @@ -26,7 +26,7 @@ Success! Data written to: secret/destroy/creds ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/kv/enable-versioning.mdx b/website/content/docs/commands/kv/enable-versioning.mdx index 2a8c51a3f2..5b210276df 100644 --- a/website/content/docs/commands/kv/enable-versioning.mdx +++ b/website/content/docs/commands/kv/enable-versioning.mdx @@ -23,7 +23,7 @@ Success! Tuned the secrets engine at: secret/ ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/kv/index.mdx b/website/content/docs/commands/kv/index.mdx index 642d77bff3..487320b3e1 100644 --- a/website/content/docs/commands/kv/index.mdx +++ b/website/content/docs/commands/kv/index.mdx @@ -9,8 +9,8 @@ description: |- # kv The `kv` command groups subcommands for interacting with Vault's key/value -secrets engine (both [K/V Version 1](/docs/secrets/kv/kv-v1) and [K/V -Version 2](/docs/secrets/kv/kv-v2). +secrets engine (both [K/V Version 1](/vault/docs/secrets/kv/kv-v1) and [K/V +Version 2](/vault/docs/secrets/kv/kv-v2). ## Syntax diff --git a/website/content/docs/commands/kv/list.mdx b/website/content/docs/commands/kv/list.mdx index 4ac6b7db2d..6f565e2ac9 100644 --- a/website/content/docs/commands/kv/list.mdx +++ b/website/content/docs/commands/kv/list.mdx @@ -33,7 +33,7 @@ release ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/kv/metadata.mdx b/website/content/docs/commands/kv/metadata.mdx index 637f145ae0..6d40126a2f 100644 --- a/website/content/docs/commands/kv/metadata.mdx +++ b/website/content/docs/commands/kv/metadata.mdx @@ -8,7 +8,7 @@ description: |- # kv metadata -~> **NOTE:** This is a [K/V Version 2](/docs/secrets/kv/kv-v2) secrets +~> **NOTE:** This is a [K/V Version 2](/vault/docs/secrets/kv/kv-v2) secrets engine command, and not available for Version 1. The `kv metadata` command has subcommands for interacting with the metadata and @@ -150,7 +150,7 @@ be applied to new versions. to a duration to specify the `deletion_time` for all new versions written to this key. If not set, the backend's `delete_version_after` will be used. If the value is greater than the backend's `delete_version_after`, the backend's - `delete_version_after` will be used. Accepts [duration format strings](/docs/concepts/duration-format). + `delete_version_after` will be used. Accepts [duration format strings](/vault/docs/concepts/duration-format). - `-custom-metadata` `(string: "")` - Specifies a key-value pair for the `custom_metadata` field. This can be specified multiple times to add multiple diff --git a/website/content/docs/commands/kv/patch.mdx b/website/content/docs/commands/kv/patch.mdx index 9870927cfb..676ea62322 100644 --- a/website/content/docs/commands/kv/patch.mdx +++ b/website/content/docs/commands/kv/patch.mdx @@ -8,7 +8,7 @@ description: |- # kv patch -~> **NOTE:** This is a [K/V Version 2](/docs/secrets/kv/kv-v2) secrets +~> **NOTE:** This is a [K/V Version 2](/vault/docs/secrets/kv/kv-v2) secrets engine command, and not available for Version 1. The `kv patch` command writes the data to the given path in the K/V v2 secrets diff --git a/website/content/docs/commands/kv/put.mdx b/website/content/docs/commands/kv/put.mdx index e4698cce5a..c158f6baf6 100644 --- a/website/content/docs/commands/kv/put.mdx +++ b/website/content/docs/commands/kv/put.mdx @@ -43,7 +43,7 @@ $ echo "abcd1234" | vault kv put -mount=secret foo bar=- ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/kv/rollback.mdx b/website/content/docs/commands/kv/rollback.mdx index 92fc42867e..94191fe4cf 100644 --- a/website/content/docs/commands/kv/rollback.mdx +++ b/website/content/docs/commands/kv/rollback.mdx @@ -8,7 +8,7 @@ description: |- # kv rollback -~> **NOTE:** This is a [K/V Version 2](/docs/secrets/kv/kv-v2) secrets +~> **NOTE:** This is a [K/V Version 2](/vault/docs/secrets/kv/kv-v2) secrets engine command, and not available for Version 1. The `kv rollback` command restores a given previous version to the current @@ -33,7 +33,7 @@ version 6 ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/kv/undelete.mdx b/website/content/docs/commands/kv/undelete.mdx index 759bea8de0..0428f81614 100644 --- a/website/content/docs/commands/kv/undelete.mdx +++ b/website/content/docs/commands/kv/undelete.mdx @@ -9,7 +9,7 @@ description: |- # kv undelete -~> **NOTE:** This is a [K/V Version 2](/docs/secrets/kv/kv-v2) secrets +~> **NOTE:** This is a [K/V Version 2](/vault/docs/secrets/kv/kv-v2) secrets engine command, and not available for Version 1. The `kv undelete` command undoes the deletes of the data for the provided version @@ -27,7 +27,7 @@ Success! Data written to: secret/undelete/creds ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/lease/index.mdx b/website/content/docs/commands/lease/index.mdx index db47755061..b1de95902f 100644 --- a/website/content/docs/commands/lease/index.mdx +++ b/website/content/docs/commands/lease/index.mdx @@ -9,7 +9,7 @@ description: |- # lease The `lease` command groups subcommands for interacting with leases attached to -secrets. For leases attached to tokens, use the [`vault token`](/docs/commands/token) subcommand. +secrets. For leases attached to tokens, use the [`vault token`](/vault/docs/commands/token) subcommand. ## Examples diff --git a/website/content/docs/commands/lease/lookup.mdx b/website/content/docs/commands/lease/lookup.mdx index a483a88ed0..6d9aed6d3c 100644 --- a/website/content/docs/commands/lease/lookup.mdx +++ b/website/content/docs/commands/lease/lookup.mdx @@ -30,5 +30,5 @@ ttl 9m52s ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. diff --git a/website/content/docs/commands/lease/renew.mdx b/website/content/docs/commands/lease/renew.mdx index e1cc1cdbff..f90ec757d7 100644 --- a/website/content/docs/commands/lease/renew.mdx +++ b/website/content/docs/commands/lease/renew.mdx @@ -31,7 +31,7 @@ lease_renewable true ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. - `-increment` `(duration: "")` - Request a specific increment in seconds. Vault is not required to honor this request. diff --git a/website/content/docs/commands/lease/revoke.mdx b/website/content/docs/commands/lease/revoke.mdx index fa76fc2058..dc8618fc8d 100644 --- a/website/content/docs/commands/lease/revoke.mdx +++ b/website/content/docs/commands/lease/revoke.mdx @@ -30,7 +30,7 @@ Success! Revoked any leases with prefix: database/creds ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. - `-force` `(bool: false)` - Delete the lease from Vault even if the secret engine revocation fails. This is meant for recovery situations where the diff --git a/website/content/docs/commands/license/get.mdx b/website/content/docs/commands/license/get.mdx index abdaedab14..f36f4d6602 100644 --- a/website/content/docs/commands/license/get.mdx +++ b/website/content/docs/commands/license/get.mdx @@ -9,7 +9,7 @@ description: |- The `license get` command reports on the license in use. With the `-signed` flag, it will return the actual license string, but only if the license -is stored, as opposed to [autoloaded](/docs/enterprise/license/autoloading). +is stored, as opposed to [autoloaded](/vault/docs/enterprise/license/autoloading). ## Examples @@ -44,7 +44,7 @@ License not found or using a temporary license. ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Command Options diff --git a/website/content/docs/commands/license/index.mdx b/website/content/docs/commands/license/index.mdx index 77ebf6862b..2567c9ce0b 100644 --- a/website/content/docs/commands/license/index.mdx +++ b/website/content/docs/commands/license/index.mdx @@ -9,7 +9,7 @@ description: |- The `license` command groups subcommands for interacting with Vault licenses -For more information, please see the [license documentation](/docs/enterprise/license) +For more information, please see the [license documentation](/vault/docs/enterprise/license) ## Examples diff --git a/website/content/docs/commands/license/inspect.mdx b/website/content/docs/commands/license/inspect.mdx index 3a05960414..2fcef167ae 100644 --- a/website/content/docs/commands/license/inspect.mdx +++ b/website/content/docs/commands/license/inspect.mdx @@ -51,7 +51,7 @@ License is valid ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Command Options diff --git a/website/content/docs/commands/list.mdx b/website/content/docs/commands/list.mdx index dce32d7b5d..9caed719a0 100644 --- a/website/content/docs/commands/list.mdx +++ b/website/content/docs/commands/list.mdx @@ -21,5 +21,5 @@ $ vault list identity/entity/id ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. diff --git a/website/content/docs/commands/login.mdx b/website/content/docs/commands/login.mdx index 2503400ece..8228f08394 100644 --- a/website/content/docs/commands/login.mdx +++ b/website/content/docs/commands/login.mdx @@ -123,7 +123,7 @@ token_meta_username my-username ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/monitor.mdx b/website/content/docs/commands/monitor.mdx index e0afc5a916..e90f94fd45 100644 --- a/website/content/docs/commands/monitor.mdx +++ b/website/content/docs/commands/monitor.mdx @@ -34,7 +34,7 @@ $ vault monitor -log-level=debug ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/operator/diagnose.mdx b/website/content/docs/commands/operator/diagnose.mdx index 4c6c8dd008..4513e54603 100644 --- a/website/content/docs/commands/operator/diagnose.mdx +++ b/website/content/docs/commands/operator/diagnose.mdx @@ -23,7 +23,7 @@ messages or warnings. ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/operator/generate-root.mdx b/website/content/docs/commands/operator/generate-root.mdx index c40e6c785c..b9c3d3fb47 100644 --- a/website/content/docs/commands/operator/generate-root.mdx +++ b/website/content/docs/commands/operator/generate-root.mdx @@ -20,14 +20,14 @@ One of the following must be provided to start the root token generation: final value. - A file containing a PGP key or a - [keybase](/docs/concepts/pgp-gpg-keybase) username in the `-pgp-key` + [keybase](/vault/docs/concepts/pgp-gpg-keybase) username in the `-pgp-key` flag. The resulting token is encrypted with this public key. 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](https://learn.hashicorp.com/tutorials/vault/generate-root) for +Please see the [generate root guide](/vault/tutorials/operations/generate-root) for step-by-step instructions. ## Examples @@ -53,7 +53,7 @@ $ vault operator generate-root -otp="..." ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/operator/init.mdx b/website/content/docs/commands/operator/init.mdx index b9457f3a7e..ea55ab098b 100644 --- a/website/content/docs/commands/operator/init.mdx +++ b/website/content/docs/commands/operator/init.mdx @@ -20,7 +20,7 @@ During initialization, Vault generates a root key, which is stored in the storag The default Vault configuration uses [Shamir's Secret Sharing](https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing) to split the root key into a configured number of shards (referred as key shares, or unseal keys). A certain threshold of shards is required to reconstruct the root key, which is then used to decrypt the Vault's encryption key. -Refer to the [Seal/Unseal](/docs/concepts/seal#seal-unseal) documentation for further details. +Refer to the [Seal/Unseal](/vault/docs/concepts/seal#seal-unseal) documentation for further details. ## Examples @@ -57,7 +57,7 @@ $ vault operator init -root-token-pgp-key="keybase:hashicorp" ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options @@ -109,17 +109,17 @@ flags](/docs/commands) included on all commands. ### HSM and KMS Options - `-recovery-pgp-keys` `(string: "...")` - Behaves like `-pgp-keys`, but for the - recovery key shares. This is only available with [Auto Unseal](/docs/concepts/seal#auto-unseal) seals (HSM, KMS and Transit seals). + recovery key shares. This is only available with [Auto Unseal](/vault/docs/concepts/seal#auto-unseal) seals (HSM, KMS and Transit seals). - `-recovery-shares` `(int: 5)` - Number of key shares to split the recovery key - into. This is only available with [Auto Unseal](/docs/concepts/seal#auto-unseal) seals (HSM, KMS and Transit seals). + into. This is only available with [Auto Unseal](/vault/docs/concepts/seal#auto-unseal) seals (HSM, KMS and Transit seals). - `-recovery-threshold` `(int: 3)` - Number of key shares required to - reconstruct the recovery key. This is only available with [Auto Unseal](/docs/concepts/seal#auto-unseal) seals (HSM, KMS and Transit seals). + reconstruct the recovery key. This is only available with [Auto Unseal](/vault/docs/concepts/seal#auto-unseal) seals (HSM, KMS and Transit seals). - `-stored-shares` `(int: 0)` - Number of unseal keys to store on an HSM. This must be equal to `-key-shares`. -> **Recovery keys:** Refer to the - [Seal/Unseal](/docs/concepts/seal#recovery-key) documentation to learn more + [Seal/Unseal](/vault/docs/concepts/seal#recovery-key) documentation to learn more about recovery keys. diff --git a/website/content/docs/commands/operator/key-status.mdx b/website/content/docs/commands/operator/key-status.mdx index 80959f1a1d..02d34832de 100644 --- a/website/content/docs/commands/operator/key-status.mdx +++ b/website/content/docs/commands/operator/key-status.mdx @@ -24,7 +24,7 @@ Install Time 01 Jan 17 12:30 UTC ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/operator/members.mdx b/website/content/docs/commands/operator/members.mdx index de5b82b64e..d532302c37 100644 --- a/website/content/docs/commands/operator/members.mdx +++ b/website/content/docs/commands/operator/members.mdx @@ -30,7 +30,7 @@ Note that in the above output, `Upgrade Version` and `Redundancy Zone` are Enter ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/operator/migrate.mdx b/website/content/docs/commands/operator/migrate.mdx index 17b69abcac..81af3b27b5 100644 --- a/website/content/docs/commands/operator/migrate.mdx +++ b/website/content/docs/commands/operator/migrate.mdx @@ -48,7 +48,7 @@ $ vault operator migrate -config migrate.hcl -start "data/logical/fd" The `operator migrate` command uses a dedicated configuration file to specify the source and destination storage backends. The format of the storage stanzas is identical -to that used to [configure Vault](/docs/configuration/storage), +to that used to [configure Vault](/vault/docs/configuration/storage), with the only difference being that two stanzas are required: `storage_source` and `storage_destination`. ```hcl @@ -71,9 +71,9 @@ storage_destination "consul" { The below configuration will migrate away from Consul storage to integrated raft storage. The raft data will be stored on the local filesystem in the defined `path`. `node_id` can optionally be set to identify this node. -[cluster_addr](/docs/configuration#cluster_addr) must be set to the +[cluster_addr](/vault/docs/configuration#cluster_addr) must be set to the cluster hostname of this node. For more configuration options see the [raft -storage configuration documentation](/docs/configuration/storage/raft). +storage configuration documentation](/vault/docs/configuration/storage/raft). If the original configuration uses "raft" for `ha_storage` a different `path` needs to be declared for the path in `storage_destination` and the new @@ -110,7 +110,7 @@ $ vault operator migrate -config migrate.hcl After migration has completed, the data is stored on the local file system. To use the new storage backend with Vault, update Vault's configuration file as described in the [raft storage configuration -documentation](/docs/configuration/storage/raft). Then start and unseal the +documentation](/vault/docs/configuration/storage/raft). Then start and unseal the vault server. ### Join additional nodes diff --git a/website/content/docs/commands/operator/raft.mdx b/website/content/docs/commands/operator/raft.mdx index 9156beb593..75bfd9db58 100644 --- a/website/content/docs/commands/operator/raft.mdx +++ b/website/content/docs/commands/operator/raft.mdx @@ -79,7 +79,7 @@ The following flags are available for the `operator raft join` command. server not participate in the Raft quorum, and have it only receive the data replication stream. This can be used to add read scalability to a cluster in cases where a high volume of reads to servers are needed. The default is false. - See [`retry_join_as_non_voter`](/docs/configuration/storage/raft#retry_join_as_non_voter) + See [`retry_join_as_non_voter`](/vault/docs/configuration/storage/raft#retry_join_as_non_voter) for the equivalent config option when using `retry_join` stanzas instead. - `-retry` `(bool: false)` - Continuously retry joining the Raft cluster upon @@ -194,7 +194,7 @@ This command groups subcommands for operators interacting with the autopilot functionality of the integrated Raft storage backend. There are 3 subcommands supported: `get-config`, `set-config` and `state`. -For a more detailed overview of autopilot features, see the [concepts page](/docs/concepts/integrated-storage/autopilot). +For a more detailed overview of autopilot features, see the [concepts page](/vault/docs/concepts/integrated-storage/autopilot). ```text Usage: vault operator raft autopilot [options] [args] @@ -218,7 +218,7 @@ State includes a list of all servers by nodeID and IP address. Last Index indicates how close the state on each node is to the leader's. A node can have a status of "leader", "voter", and -"[non-voter](/docs/concepts/integrated-storage#non-voting-nodes-enterprise-only)". +"[non-voter](/vault/docs/concepts/integrated-storage#non-voting-nodes-enterprise-only)". ```text Usage: vault operator raft autopilot state diff --git a/website/content/docs/commands/operator/rekey.mdx b/website/content/docs/commands/operator/rekey.mdx index a1a6eb67cb..80341a2518 100644 --- a/website/content/docs/commands/operator/rekey.mdx +++ b/website/content/docs/commands/operator/rekey.mdx @@ -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](https://learn.hashicorp.com/tutorials/vault/rekeying-and-rotating) for +Please see the [rotating and rekeying](/vault/tutorials/operations/rekeying-and-rotating) for step-by-step instructions. ## Examples @@ -106,7 +106,7 @@ $ vault operator rekey -verify -nonce="..." ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options @@ -143,7 +143,7 @@ flags](/docs/commands) included on all commands. providing an unseal key. The default is false. - `-target` `(string: "barrier")` - Target for rekeying. "recovery" only applies - when HSM support is enabled or using [Auto Unseal](/docs/concepts/seal#auto-unseal). + when HSM support is enabled or using [Auto Unseal](/vault/docs/concepts/seal#auto-unseal). - `-verify` `(bool: false)` - Indicate during the phase `-init` that the verification process is activated for the rekey. Along with `-nonce` option diff --git a/website/content/docs/commands/operator/rotate.mdx b/website/content/docs/commands/operator/rotate.mdx index db3ab2235e..40ffcec34c 100644 --- a/website/content/docs/commands/operator/rotate.mdx +++ b/website/content/docs/commands/operator/rotate.mdx @@ -32,7 +32,7 @@ Install Time 01 May 17 10:30 UTC ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/operator/seal.mdx b/website/content/docs/commands/operator/seal.mdx index 9e2db28b9b..9edbb885a0 100644 --- a/website/content/docs/commands/operator/seal.mdx +++ b/website/content/docs/commands/operator/seal.mdx @@ -25,7 +25,7 @@ Users will have to re-enter their portions of the root key again. This command does nothing if the Vault server is already sealed. For more information on sealing and unsealing, please the [seal concepts -page](/docs/concepts/seal). +page](/vault/docs/concepts/seal). ## Examples @@ -38,5 +38,5 @@ Success! Vault is sealed. ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. diff --git a/website/content/docs/commands/operator/step-down.mdx b/website/content/docs/commands/operator/step-down.mdx index fa74c0536c..e66714d9d2 100644 --- a/website/content/docs/commands/operator/step-down.mdx +++ b/website/content/docs/commands/operator/step-down.mdx @@ -8,9 +8,9 @@ description: |- # operator step-down -The `operator step-down` forces the active Vault node within an [HA cluster](/docs/concepts/ha) +The `operator step-down` forces the active Vault node within an [HA cluster](/vault/docs/concepts/ha) to step down from active duty. When executed against a non-active node, i.e. a -standby or [performance standby](/docs/enterprise/performance-standby) node, +standby or [performance standby](/vault/docs/enterprise/performance-standby) node, the request will be forwarded to the active node. While the affected node will have a delay before attempting to acquire the leader lock again, if no other Vault nodes acquire the @@ -28,5 +28,5 @@ Success! Stepped down: http://127.0.0.1:8200 ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. diff --git a/website/content/docs/commands/operator/unseal.mdx b/website/content/docs/commands/operator/unseal.mdx index aa535d4a16..0019fcd6af 100644 --- a/website/content/docs/commands/operator/unseal.mdx +++ b/website/content/docs/commands/operator/unseal.mdx @@ -28,7 +28,7 @@ Key (will be hidden): IXyR0OJnSFobekZMMCKCoVEpT7wI6l+USMzE3IcyDyo= ``` For more information on sealing and unsealing, please the [seal concepts -page](/docs/concepts/seal). +page](/vault/docs/concepts/seal). ## Examples @@ -46,7 +46,7 @@ Unseal Progress: 0 ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/operator/usage.mdx b/website/content/docs/commands/operator/usage.mdx index 65c35a045b..2a3bf728d6 100644 --- a/website/content/docs/commands/operator/usage.mdx +++ b/website/content/docs/commands/operator/usage.mdx @@ -8,7 +8,7 @@ description: |- # operator usage The `operator usage` command allows an administrator to retrieve a -[client count](https://www.vaultproject.io/docs/concepts/client-count) report +[client count](/vault/docs/concepts/client-count) report for the default reporting period, or for a specific time range of months. The command output will list clients by distinct entities, non-entity tokens, and total @@ -17,7 +17,7 @@ indicate that no data is available for the requested time range, which may be because the client count reporting is disabled, the time range is too far in the past, or no data has yet been collected since the feature was enabled. -> Refer to the [Vault Usage Metrics](https://learn.hashicorp.com/tutorials/vault/usage-metrics) tutorial to learn more about usage metrics, +> Refer to the [Vault Usage Metrics](/vault/tutorials/monitoring/usage-metrics) tutorial to learn more about usage metrics, > including required policy and data collection details. ## Examples @@ -53,7 +53,7 @@ Total 954 176 1130 ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/patch.mdx b/website/content/docs/commands/patch.mdx index c94b19d9f0..9009359a87 100644 --- a/website/content/docs/commands/patch.mdx +++ b/website/content/docs/commands/patch.mdx @@ -28,7 +28,7 @@ from stdin. This argument will be ignored if used in conjunction with any For a full list of examples and paths, please see the documentation that corresponds to the secrets engines in use. -Unlike [the `write` command](/docs/commands/write), the `patch` command only +Unlike [the `write` command](/vault/docs/commands/write), the `patch` command only modifies data specified on the command line. ## Examples @@ -68,7 +68,7 @@ The `vault patch` command simplifies the API call. ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/path-help.mdx b/website/content/docs/commands/path-help.mdx index af2a88be64..4099fb1104 100644 --- a/website/content/docs/commands/path-help.mdx +++ b/website/content/docs/commands/path-help.mdx @@ -87,5 +87,5 @@ user of this backend. ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. diff --git a/website/content/docs/commands/pki/health-check.mdx b/website/content/docs/commands/pki/health-check.mdx index 45a7324ecb..b496bbb071 100644 --- a/website/content/docs/commands/pki/health-check.mdx +++ b/website/content/docs/commands/pki/health-check.mdx @@ -136,7 +136,7 @@ be added in future releases and may default to being enabled. This health check will check each issuer in the mount for validity status, returning a list. If a CA expires within the next 30 days, the result will be critical. If a root CA expires within the next 12 months or an intermediate CA within the next 2 months, the result will be a warning. If a root CA expires within 24 months or an intermediate CA within 6 months, the result will be informational. -The remediation here is to remove old CAs after they expire and perform a [CA rotation operation](/docs/secrets/pki/rotation-primitives) for any with pending expiry. +The remediation here is to remove old CAs after they expire and perform a [CA rotation operation](/vault/docs/secrets/pki/rotation-primitives) for any with pending expiry. ### CRL Validity Period diff --git a/website/content/docs/commands/pki/index.mdx b/website/content/docs/commands/pki/index.mdx index 6e95ea872c..b6c054ca5e 100644 --- a/website/content/docs/commands/pki/index.mdx +++ b/website/content/docs/commands/pki/index.mdx @@ -9,7 +9,7 @@ description: |- # pki The `pki` command groups subcommands for interacting with Vault's -[PKI Secrets Engine](/docs/secrets/pki). +[PKI Secrets Engine](/vault/docs/secrets/pki). ## Syntax @@ -17,7 +17,7 @@ Option flags for a given subcommand are provided after the subcommand, but befor ## Examples -To [health check](/docs/commands/pki/health-check) a mount, use the +To [health check](/vault/docs/commands/pki/health-check) a mount, use the `vault pki health-check ` command: ``` diff --git a/website/content/docs/commands/plugin/deregister.mdx b/website/content/docs/commands/plugin/deregister.mdx index 5f5efbea1c..e000b5ab6b 100644 --- a/website/content/docs/commands/plugin/deregister.mdx +++ b/website/content/docs/commands/plugin/deregister.mdx @@ -23,5 +23,5 @@ Success! Deregistered plugin (if it was registered): my-custom-plugin ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. diff --git a/website/content/docs/commands/plugin/info.mdx b/website/content/docs/commands/plugin/info.mdx index 7838323460..8a1127f12c 100644 --- a/website/content/docs/commands/plugin/info.mdx +++ b/website/content/docs/commands/plugin/info.mdx @@ -49,7 +49,7 @@ version n/a ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/plugin/list.mdx b/website/content/docs/commands/plugin/list.mdx index 45d77325c4..6a92a4f02d 100644 --- a/website/content/docs/commands/plugin/list.mdx +++ b/website/content/docs/commands/plugin/list.mdx @@ -47,7 +47,7 @@ app-id auth v1.12.0+builtin.vault ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/plugin/register.mdx b/website/content/docs/commands/plugin/register.mdx index d50b8d194e..51bb725003 100644 --- a/website/content/docs/commands/plugin/register.mdx +++ b/website/content/docs/commands/plugin/register.mdx @@ -34,7 +34,7 @@ $ vault plugin register \ ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/plugin/reload.mdx b/website/content/docs/commands/plugin/reload.mdx index 27a6e24bb1..ec53e4350f 100644 --- a/website/content/docs/commands/plugin/reload.mdx +++ b/website/content/docs/commands/plugin/reload.mdx @@ -41,7 +41,7 @@ Success! Reloaded mounts: [my-custom-plugin-1/ my-custom-plugin-2/] ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Command Options diff --git a/website/content/docs/commands/policy/delete.mdx b/website/content/docs/commands/policy/delete.mdx index cb0a1e1dc4..05c1cadd70 100644 --- a/website/content/docs/commands/policy/delete.mdx +++ b/website/content/docs/commands/policy/delete.mdx @@ -26,5 +26,5 @@ $ vault policy delete my-policy ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. diff --git a/website/content/docs/commands/policy/fmt.mdx b/website/content/docs/commands/policy/fmt.mdx index 0c047a6c9c..9a3ba7e513 100644 --- a/website/content/docs/commands/policy/fmt.mdx +++ b/website/content/docs/commands/policy/fmt.mdx @@ -23,5 +23,5 @@ $ vault policy fmt my-policy.hcl ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. diff --git a/website/content/docs/commands/policy/index.mdx b/website/content/docs/commands/policy/index.mdx index b76bba3ee1..1f66e7d8d3 100644 --- a/website/content/docs/commands/policy/index.mdx +++ b/website/content/docs/commands/policy/index.mdx @@ -12,7 +12,7 @@ The `policy` command groups subcommands for interacting with policies. Users can write, read, and list policies in Vault. For more information, please see the [policy -documentation](/docs/concepts/policies). +documentation](/vault/docs/concepts/policies). ## Examples diff --git a/website/content/docs/commands/policy/list.mdx b/website/content/docs/commands/policy/list.mdx index 23904bf848..3355ac2973 100644 --- a/website/content/docs/commands/policy/list.mdx +++ b/website/content/docs/commands/policy/list.mdx @@ -24,7 +24,7 @@ root ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/policy/read.mdx b/website/content/docs/commands/policy/read.mdx index 29dcf03ac6..c01334e4b4 100644 --- a/website/content/docs/commands/policy/read.mdx +++ b/website/content/docs/commands/policy/read.mdx @@ -22,7 +22,7 @@ $ vault policy read my-policy ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/policy/write.mdx b/website/content/docs/commands/policy/write.mdx index abd5332ac6..b9ff586e7f 100644 --- a/website/content/docs/commands/policy/write.mdx +++ b/website/content/docs/commands/policy/write.mdx @@ -14,7 +14,7 @@ a local file PATH or stdin. If PATH is "-", the policy is read from stdin. Otherwise, it is loaded from the file at the given path on the local disk. For details on the policy syntax, please see the [policy -documentation](/docs/concepts/policies). +documentation](/vault/docs/concepts/policies). ## Examples @@ -32,5 +32,5 @@ $ cat my-policy.hcl | vault policy write my-policy - ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. diff --git a/website/content/docs/commands/read.mdx b/website/content/docs/commands/read.mdx index 6ec90e6abe..03cdeecb5b 100644 --- a/website/content/docs/commands/read.mdx +++ b/website/content/docs/commands/read.mdx @@ -45,7 +45,7 @@ $ curl --request GET --header "X-Vault-Token: $VAULT_TOKEN" \ ``` Since K/V secrets engine is a commonly used feature, Vault CLI provides the -[`kv`](/docs/commands/kv) command. Read secrets from the `secret/data/customers` +[`kv`](/vault/docs/commands/kv) command. Read secrets from the `secret/data/customers` path using the `kv` CLI command: ```shell-session @@ -61,7 +61,7 @@ engine, it prints the output in more structured format that is easy to read. ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/secrets/disable.mdx b/website/content/docs/commands/secrets/disable.mdx index 78d4b5a784..7918990e4c 100644 --- a/website/content/docs/commands/secrets/disable.mdx +++ b/website/content/docs/commands/secrets/disable.mdx @@ -28,7 +28,7 @@ $ vault secrets disable aws/ ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. ## Force Disable @@ -43,7 +43,7 @@ can be as 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 [prefix force revoke](/docs/commands/lease/revoke) on the mount +performing a [prefix force revoke](/vault/docs/commands/lease/revoke) 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. diff --git a/website/content/docs/commands/secrets/enable.mdx b/website/content/docs/commands/secrets/enable.mdx index 82963528c5..179ce517ab 100644 --- a/website/content/docs/commands/secrets/enable.mdx +++ b/website/content/docs/commands/secrets/enable.mdx @@ -22,7 +22,7 @@ Some secrets engines persist data, some act as data pass-through, and some generate dynamic credentials. The secrets engine will likely require configuration after it is mounted. For details on the specific configuration options, please see the [secrets engine -documentation](/docs/secrets). +documentation](/vault/docs/secrets). ## Examples @@ -52,17 +52,17 @@ $ vault secrets enable -path=my-secrets my-plugin ``` For more information on the specific configuration options and paths, please see -the [secrets engine](/docs/secrets) documentation. +the [secrets engine](/vault/docs/secrets) documentation. ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. - `-audit-non-hmac-request-keys` `(string: "")` - Key that will not be HMAC'd by audit devices in the request data object. Note that multiple keys may be specified by providing this option multiple times, each time with 1 key. - An example of this is provided in the [tune section](/docs/commands/secrets/tune). + An example of this is provided in the [tune section](/vault/docs/commands/secrets/tune). - `-audit-non-hmac-response-keys` `(string: "")` - Key that will not be HMAC'd by audit devices in the response data object. Note that multiple keys may be diff --git a/website/content/docs/commands/secrets/index.mdx b/website/content/docs/commands/secrets/index.mdx index f40f139c2d..a88cb59f48 100644 --- a/website/content/docs/commands/secrets/index.mdx +++ b/website/content/docs/commands/secrets/index.mdx @@ -16,7 +16,7 @@ Some secrets engines persist data, some act as data pass-through, and some generate dynamic credentials. The secrets engine will likely require configuration after it is mounted. For details on the specific configuration options, please see the [secrets engine -documentation](/docs/secrets). +documentation](/vault/docs/secrets). ## Examples diff --git a/website/content/docs/commands/secrets/list.mdx b/website/content/docs/commands/secrets/list.mdx index 68e84f6f8c..c4253011a8 100644 --- a/website/content/docs/commands/secrets/list.mdx +++ b/website/content/docs/commands/secrets/list.mdx @@ -64,7 +64,7 @@ sys/ system system_c86bd362 n/a n/a fa ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/secrets/move.mdx b/website/content/docs/commands/secrets/move.mdx index 4e769f0b7e..e8956cb3af 100644 --- a/website/content/docs/commands/secrets/move.mdx +++ b/website/content/docs/commands/secrets/move.mdx @@ -30,5 +30,5 @@ $ vault secrets move ns1/secret/ ns2/kv/ ## Usage -There are no flags beyond the [standard set of flags](/docs/commands) +There are no flags beyond the [standard set of flags](/vault/docs/commands) included on all commands. diff --git a/website/content/docs/commands/secrets/tune.mdx b/website/content/docs/commands/secrets/tune.mdx index ecd445c369..4074374888 100644 --- a/website/content/docs/commands/secrets/tune.mdx +++ b/website/content/docs/commands/secrets/tune.mdx @@ -52,7 +52,7 @@ $ vault secrets tune -audit-non-hmac-request-keys=common_name -audit-non-hmac-re ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. - `-allowed-response-headers` `(string: "")` - response header values that the secrets engine will be allowed to set. Note that multiple keys may be @@ -69,7 +69,7 @@ flags](/docs/commands) included on all commands. - `-default-lease-ttl` `(duration: "")` - The default lease TTL for this secrets engine. If unspecified, this defaults to the Vault server's globally configured default lease TTL, or a previously configured value for the secrets - engine. Uses [duration format strings](/docs/concepts/duration-format). + engine. Uses [duration format strings](/vault/docs/concepts/duration-format). - `-description` `(string: "")` - Specifies the description of the mount. This overrides the current stored value, if any. @@ -80,10 +80,10 @@ flags](/docs/commands) included on all commands. - `-max-lease-ttl` `(duration: "")` - The maximum lease TTL for this secrets engine. If unspecified, this defaults to the Vault server's globally - configured [maximum lease TTL](/docs/configuration#max_lease_ttl), or a + configured [maximum lease TTL](/vault/docs/configuration#max_lease_ttl), or a previously configured value for the secrets engine. This value is allowed to override the server's global max TTL; it can be longer or shorter. - Uses [duration format strings](/docs/concepts/duration-format). + Uses [duration format strings](/vault/docs/concepts/duration-format). - `-passthrough-request-headers` `(string: "")` - request header values that will be sent to the secrets engine. Note that multiple keys may be @@ -96,4 +96,4 @@ flags](/docs/commands) included on all commands. - `-plugin-version` `(string: "")` - Configures the semantic version of the plugin to use. The new version will not start running until the mount is - [reloaded](/docs/commands/plugin/reload). + [reloaded](/vault/docs/commands/plugin/reload). diff --git a/website/content/docs/commands/server.mdx b/website/content/docs/commands/server.mdx index 053afbac8b..43bb692bee 100644 --- a/website/content/docs/commands/server.mdx +++ b/website/content/docs/commands/server.mdx @@ -17,13 +17,13 @@ API before the server can respond to requests. For more information, please see: -- [`operator init` command](/docs/commands/operator/init) for information +- [`operator init` command](/vault/docs/commands/operator/init) for information on initializing a Vault server. -- [`operator unseal` command](/docs/commands/operator/unseal) for +- [`operator unseal` command](/vault/docs/commands/operator/unseal) for information on providing unseal keys. -- [Vault configuration](/docs/configuration) for the syntax and +- [Vault configuration](/vault/docs/configuration) for the syntax and various configuration options for a Vault server. ## Examples @@ -43,7 +43,7 @@ $ vault server -dev -dev-root-token-id="root" ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Command Options @@ -86,7 +86,7 @@ flags](/docs/commands) included on all commands. should NOT be used in production, and the associated APIs may have backwards incompatible changes between releases. Additional experiments can also be specified via the `VAULT_EXPERIMENTS` environment variable as a comma-separated list, or via the - [`experiments`](/docs/configuration#experiments) config key. + [`experiments`](/vault/docs/configuration#experiments) config key. - `VAULT_ALLOW_PENDING_REMOVAL_MOUNTS` `(bool: false)` - (environment variable) Allow Vault to be started with builtin engines which have the `Pending Removal` @@ -94,7 +94,7 @@ flags](/docs/commands) included on all commands. upgrade and disable these engines. Once these engines are marked `Removed` (in the next major release of Vault), the environment variable will no longer work and a downgrade must be performed in order to remove the offending engines. For - more information, see the [deprecation faq](/docs/deprecation/faq/#q-what-are-the-phases-of-deprecation). + more information, see the [deprecation faq](/vault/docs/deprecation/faq/#q-what-are-the-phases-of-deprecation). ### Dev Options diff --git a/website/content/docs/commands/ssh.mdx b/website/content/docs/commands/ssh.mdx index fab9f7d63a..eefc739d67 100644 --- a/website/content/docs/commands/ssh.mdx +++ b/website/content/docs/commands/ssh.mdx @@ -45,12 +45,12 @@ $ vault ssh \ For step-by-step guides and instructions for each of the available SSH auth methods, please see the corresponding [SSH secrets -engine](/docs/secrets/ssh). +engine](/vault/docs/secrets/ssh). ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/status.mdx b/website/content/docs/commands/status.mdx index ea60237de6..48f5208101 100644 --- a/website/content/docs/commands/status.mdx +++ b/website/content/docs/commands/status.mdx @@ -42,7 +42,7 @@ High-Availability Enabled: false ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/token/capabilities.mdx b/website/content/docs/commands/token/capabilities.mdx index c8becdd6c4..dd524aa99f 100644 --- a/website/content/docs/commands/token/capabilities.mdx +++ b/website/content/docs/commands/token/capabilities.mdx @@ -35,7 +35,7 @@ deny ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/token/create.mdx b/website/content/docs/commands/token/create.mdx index b4292fab19..047d9aa0d0 100644 --- a/website/content/docs/commands/token/create.mdx +++ b/website/content/docs/commands/token/create.mdx @@ -57,7 +57,7 @@ token_policies [my-policy] ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options @@ -82,7 +82,7 @@ flags](/docs/commands) included on all commands. - `-explicit-max-ttl` `(duration: "")` - Explicit maximum lifetime for the token. Unlike normal TTLs, the maximum TTL is a hard limit and cannot be - exceeded. Uses [duration format strings](/docs/concepts/duration-format). + exceeded. Uses [duration format strings](/vault/docs/concepts/duration-format). - `-id` `(string: "")` - Value for the token. By default, this is an auto-generated value. Specifying this value requires sudo permissions. @@ -101,7 +101,7 @@ flags](/docs/commands) included on all commands. - `-period` `(duration: "")` - If specified, every renewal will use the given period. Periodic tokens do not expire as long as they are actively being renewed (unless `-explicit-max-ttl` is also provided). Setting this value - requires sudo permissions. Uses [duration format strings](/docs/concepts/duration-format). + requires sudo permissions. Uses [duration format strings](/vault/docs/concepts/duration-format). - `-policy` `(string: "")` - Name of a policy to associate with this token. This can be specified multiple times to attach multiple policies. @@ -115,7 +115,7 @@ flags](/docs/commands) included on all commands. - `-ttl` `(duration: "")` - Initial TTL to associate with the token. Token renewals may be able to extend beyond this value, depending on the configured - maximumTTLs. Uses [duration format strings](/docs/concepts/duration-format). + maximumTTLs. Uses [duration format strings](/vault/docs/concepts/duration-format). - `-type` `(string: "service")` - The type of token to create. Can be "service" or "batch". diff --git a/website/content/docs/commands/token/index.mdx b/website/content/docs/commands/token/index.mdx index 181e4f8b0c..d4a4645c92 100644 --- a/website/content/docs/commands/token/index.mdx +++ b/website/content/docs/commands/token/index.mdx @@ -12,7 +12,7 @@ The `token` command groups subcommands for interacting with tokens. Users can create, lookup, renew, and revoke tokens. For more information on tokens, please see the [token concepts -page](/docs/concepts/tokens). +page](/vault/docs/concepts/tokens). ## Examples diff --git a/website/content/docs/commands/token/lookup.mdx b/website/content/docs/commands/token/lookup.mdx index 8b617bbfc0..bee5061fa9 100644 --- a/website/content/docs/commands/token/lookup.mdx +++ b/website/content/docs/commands/token/lookup.mdx @@ -36,7 +36,7 @@ $ vault token lookup -accessor 9793c9b3-e04a-46f3-e7b8-748d7da248da ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/token/renew.mdx b/website/content/docs/commands/token/renew.mdx index 48052f609b..9ff30eafe2 100644 --- a/website/content/docs/commands/token/renew.mdx +++ b/website/content/docs/commands/token/renew.mdx @@ -39,7 +39,7 @@ $ vault token renew -increment=30m 96ddf4bc-d217-f3ba-f9bd-017055595017 ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/token/revoke.mdx b/website/content/docs/commands/token/revoke.mdx index 8d0e33a477..a281d4607a 100644 --- a/website/content/docs/commands/token/revoke.mdx +++ b/website/content/docs/commands/token/revoke.mdx @@ -38,7 +38,7 @@ Success! Revoked token (if it existed) ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. - `-accessor` `(bool: false)` - Treat the argument as an accessor instead of a token. diff --git a/website/content/docs/commands/unwrap.mdx b/website/content/docs/commands/unwrap.mdx index 533cf6174d..db562b8076 100644 --- a/website/content/docs/commands/unwrap.mdx +++ b/website/content/docs/commands/unwrap.mdx @@ -32,7 +32,7 @@ $ vault unwrap # unwraps 848f9ccf... ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/commands/write.mdx b/website/content/docs/commands/write.mdx index 6ced095210..7755a507d3 100644 --- a/website/content/docs/commands/write.mdx +++ b/website/content/docs/commands/write.mdx @@ -86,8 +86,8 @@ $ curl --header "X-Vault-Token: $VAULT_TOKEN" \ The `vault write` command simplifies the API call. Since token management is a common task, Vault CLI provides a -[`token`](/docs/commands/token) command with -[`create`](/docs/commands/token/create) subcommand. The CLI command simplifies +[`token`](/vault/docs/commands/token) command with +[`create`](/vault/docs/commands/token/create) subcommand. The CLI command simplifies the token creation. Use the `vault create` command with options to set the token TTL, policies, and use limit. @@ -102,7 +102,7 @@ you are invoking. ## Usage The following flags are available in addition to the [standard set of -flags](/docs/commands) included on all commands. +flags](/vault/docs/commands) included on all commands. ### Output Options diff --git a/website/content/docs/concepts/auth.mdx b/website/content/docs/concepts/auth.mdx index 77ac470d01..7ad6fdf89d 100644 --- a/website/content/docs/concepts/auth.mdx +++ b/website/content/docs/concepts/auth.mdx @@ -10,14 +10,14 @@ description: >- Authentication in Vault is the process by which user or machine supplied information is verified against an internal or external system. Vault supports -multiple [auth methods](/docs/auth) including GitHub, +multiple [auth methods](/vault/docs/auth) including GitHub, LDAP, AppRole, and more. Each auth method has a specific use case. Before a client can interact with Vault, it must _authenticate_ against an auth method. Upon authentication, a token is generated. This token is conceptually similar to a session ID on a website. The token may have attached policy, which is mapped at authentication time. This process is described in -detail in the [policies concepts](/docs/concepts/policies) documentation. +detail in the [policies concepts](/vault/docs/concepts/policies) documentation. ## auth methods @@ -48,7 +48,7 @@ access, although some backends do support MFA. ## Tokens -There is an [entire page dedicated to tokens](/docs/concepts/tokens), +There is an [entire page dedicated to tokens](/vault/docs/concepts/tokens), but it is important to understand that authentication works by verifying your identity and then generating a token to associate with that identity. @@ -60,7 +60,7 @@ the API you'll have to do this manually. This token given for authentication with any backend can also be used with the full set of token commands, such as creating new sub-tokens, revoking tokens, and renewing tokens. This is all covered on the -[token concepts page](/docs/concepts/tokens). +[token concepts page](/vault/docs/concepts/tokens). ## Authenticating @@ -99,7 +99,7 @@ be used. ## Auth Leases Just like secrets, identities have -[leases](/docs/concepts/lease) associated with them. This means that +[leases](/vault/docs/concepts/lease) associated with them. This means that you must reauthenticate after the given lease period to continue accessing Vault. diff --git a/website/content/docs/concepts/client-count/faq.mdx b/website/content/docs/concepts/client-count/faq.mdx index 8f72e845e5..b5f9772961 100644 --- a/website/content/docs/concepts/client-count/faq.mdx +++ b/website/content/docs/concepts/client-count/faq.mdx @@ -46,9 +46,9 @@ This FAQ section contains frequently asked questions about the client count feat ### Q: What is a client? -Clients are unique applications, services, or users that authenticate to a HashiCorp Vault cluster. For billing and consumption, only unique and active clients during the billing period (monthly in the case of HCP and annual in the case of self-managed Vault) count towards totals. Each client is counted just once within a billing period, regardless of how many times it's been active. When a client authenticates to a cluster, those clients have unlimited access to that cluster for the remainder of the billing period. The client metric is a combination of active identity entities and active non-entity tokens. To learn more, refer to the documentation on [What is a Client?](/docs/concepts/client-count#what-is-a-client). +Clients are unique applications, services, or users that authenticate to a HashiCorp Vault cluster. For billing and consumption, only unique and active clients during the billing period (monthly in the case of HCP and annual in the case of self-managed Vault) count towards totals. Each client is counted just once within a billing period, regardless of how many times it's been active. When a client authenticates to a cluster, those clients have unlimited access to that cluster for the remainder of the billing period. The client metric is a combination of active identity entities and active non-entity tokens. To learn more, refer to the documentation on [What is a Client?](/vault/docs/concepts/client-count#what-is-a-client). -~> **Note**: For KMIP, a different metric is used to compute clients, as described in the **Vault Usage Metrics** documentation under the [KMIP Client metrics](https://learn.hashicorp.com/tutorials/vault/usage-metrics) section. +~> **Note**: For KMIP, a different metric is used to compute clients, as described in the **Vault Usage Metrics** documentation under the [KMIP Client metrics](/vault/tutorials/monitoring/usage-metrics) section. ### Q: Where can I learn more about Vault clients? @@ -56,21 +56,21 @@ Refer to the table below for documentation resources. | Resource | Description | | -------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | -| [What is a Client?](/docs/concepts/client-count/#what-is-a-client) | Provides a conceptual overview of Vault client | -| [Usage Metrics UI](https://learn.hashicorp.com/tutorials/vault/usage-metrics) | Provides an overview of the client count dashboard and how to use it | -| [Client Count API](https://www.vaultproject.io/api-docs/system/internal-counters#client-count) | Provides information about the client count API endpoints | -| [Vault Auditor Tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool) | Provides a walkthrough on how to use the vault-auditor tool to extract metrics from the server audit device logs | +| [What is a Client?](/vault/docs/concepts/client-count/#what-is-a-client) | Provides a conceptual overview of Vault client | +| [Usage Metrics UI](/vault/tutorials/monitoring/usage-metrics) | Provides an overview of the client count dashboard and how to use it | +| [Client Count API](/vault/api-docs/system/internal-counters#client-count) | Provides information about the client count API endpoints | +| [Vault Auditor Tool](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool) | Provides a walkthrough on how to use the vault-auditor tool to extract metrics from the server audit device logs | ### Q: What is the difference between a direct entity (entity client) and a non-entity token (non-entity client)? -While the definition of clients appears to be simple on the surface, there are many nuances involved in the computation of clients. As mentioned, clients are unique applications, services, and/or users that authenticate to a Vault cluster. When anything authenticates to Vault, it is associated with a unique identity entity within the [Vault Identity system](/docs/secrets/identity). The name reported to the identity systems by the different types of authentication methods varies, and each entity is created or verified during authorization. +While the definition of clients appears to be simple on the surface, there are many nuances involved in the computation of clients. As mentioned, clients are unique applications, services, and/or users that authenticate to a Vault cluster. When anything authenticates to Vault, it is associated with a unique identity entity within the [Vault Identity system](/vault/docs/secrets/identity). The name reported to the identity systems by the different types of authentication methods varies, and each entity is created or verified during authorization. One thing to note is that Vault clients are a combination of active identities as well as non-entity tokens. Identity entities are unique users, and when identities authenticate to Vault, corresponding tokens are generated. However, there are some situations in which tokens are generated without corresponding identities (e.g., when using the token auth method to create a token for someone else whose identity is unknown). As such, these non-entity tokens also represent users, and are counted towards the overall client aggregates. Here are some situations in which non-entity tokens get created within Vault. -- Tokens within Vault are the core method for authentication. You can use Tokens to authenticate directly, or use the [auth methods](/docs/concepts/auth) to dynamically generate tokens based on external identities. +- Tokens within Vault are the core method for authentication. You can use Tokens to authenticate directly, or use the [auth methods](/vault/docs/concepts/auth) to dynamically generate tokens based on external identities. - There are scenarios where tokens are created outside of the identity system without an associated entity. For this reason, unique identity entities alone cannot always add up to the total unique authentications made to Vault over a stipulated time period. - In a scenario where tokens are created outside of the identity system, these tokens are considered clients. Note that it should be rare for production usage to have any tokens created outside any identity systems. -- There are a few ways of creating tokens without entities: _Token Roles_, _Token Create APIs_, _Wrapping Tokens_, and _Control Groups_. For more information, refer to the [What is a Client?](/docs/concepts/client-count/#what-is-a-client) documentation. +- There are a few ways of creating tokens without entities: _Token Roles_, _Token Create APIs_, _Wrapping Tokens_, and _Control Groups_. For more information, refer to the [What is a Client?](/vault/docs/concepts/client-count/#what-is-a-client) documentation. Client counts are not computed solely using a combination of unique identity entities within Vault but also computed using a combination of unique identity entities and non-entity tokens. @@ -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?](/vault/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) @@ -99,7 +99,7 @@ Although client counts have been available via the usage metrics UI since Vault - Display of clients month to month for a selected billing period via the API. - Vault 1.11: - - (Tech preview) New functionality to export the unique clients that contribute to the client count aggregate for the selected billing period - available via a new [activity export API endpoint](/api-docs/system/internal-counters#activity-export). + - (Tech preview) New functionality to export the unique clients that contribute to the client count aggregate for the selected billing period - available via a new [activity export API endpoint](/vault/api-docs/system/internal-counters#activity-export). - Display of clients month over month in the UI. **Auditor tool**: @@ -113,25 +113,25 @@ The latest GA version of the Vault binary contains the most updated version of t ### Q: For customers using versions of Vault older than 1.6, what’s the best way to compute clients? -The Vault [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool) was built to compute clients for Vault versions older than Vault 1.6. It has been tested for versions 1.3 to 1.5 but should work for earlier versions, such as Vault 1.0, although not officially tested. To use the Vault [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool), customers should have audit logs for the billing period for computed client counts. You can also set a specific date range in the [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool). +The Vault [auditor tool](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool) was built to compute clients for Vault versions older than Vault 1.6. It has been tested for versions 1.3 to 1.5 but should work for earlier versions, such as Vault 1.0, although not officially tested. To use the Vault [auditor tool](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool), customers should have audit logs for the billing period for computed client counts. You can also set a specific date range in the [auditor tool](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool). -The auditor tool is separate from the Vault binary. It does not include the latest updates for the usage metrics UI/API (e.g., it does not contain changes made to the deduplication of non-entity tokens logic). Currently, there are no plans to augment the capabilities of the [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool). +The auditor tool is separate from the Vault binary. It does not include the latest updates for the usage metrics UI/API (e.g., it does not contain changes made to the deduplication of non-entity tokens logic). Currently, there are no plans to augment the capabilities of the [auditor tool](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool). ### Q: For customers using newer versions than Vault 1.6, what’s the best way to compute clients? -The usage metrics UI that leverages the internal client count API is the best way to compute clients for versions greater than or equal to Vault 1.6. It’s important to note that the upgrade should have occurred before the ‘billing period’ started. Otherwise, it’s best to use the [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool) to compute clients because the usage metrics UI will not reflect all clients for the billing period; it will only reflect active unique clients since the upgrade. +The usage metrics UI that leverages the internal client count API is the best way to compute clients for versions greater than or equal to Vault 1.6. It’s important to note that the upgrade should have occurred before the ‘billing period’ started. Otherwise, it’s best to use the [auditor tool](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool) to compute clients because the usage metrics UI will not reflect all clients for the billing period; it will only reflect active unique clients since the upgrade. ### Q: Why do we have two different tools (auditor tool and UI/API) to compute clients? Do we plan to deprecate one in the future? -Not all customers may be on a version greater than Vault version 1.6 that leverages the client count API to display clients via the UI. The [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool) is available for customers running older Vault versions to compute client counts. The [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool) does not contain client count computation logic updates (e.g., non-entity token computation logic made in Vault 1.9). In the future, we will deprecate the [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool). +Not all customers may be on a version greater than Vault version 1.6 that leverages the client count API to display clients via the UI. The [auditor tool](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool) is available for customers running older Vault versions to compute client counts. The [auditor tool](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool) does not contain client count computation logic updates (e.g., non-entity token computation logic made in Vault 1.9). In the future, we will deprecate the [auditor tool](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool). ### Q: How can I compute KMIP clients for Vault? -As of Vault 1.11.0, KMIP clients are not available via the usage metrics UI or the client count API; they are provided via the [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool). To learn more, refer to the [Vault Usage Metrics](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool) documentation. +As of Vault 1.11.0, KMIP clients are not available via the usage metrics UI or the client count API; they are provided via the [auditor tool](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool). To learn more, refer to the [Vault Usage Metrics](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool) documentation. ### Q: Why do the Vault auditor tool and the usage metrics UI show me different results for the total number of clients? -For versions prior to Vault 1.7, the [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool) and usage metrics UI should typically result in the same number of total unique clients for the billing period, unless there is some discrepancy in the underlying data represented by both or due to some other error. For example: +For versions prior to Vault 1.7, the [auditor tool](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool) and usage metrics UI should typically result in the same number of total unique clients for the billing period, unless there is some discrepancy in the underlying data represented by both or due to some other error. For example: - If there is a discrepancy between the dates selected in the two tools, then the clients reflected in the results may be different - If the auditor tool does not leverage audit data for the billing period, the auditor results may be incorrect @@ -143,14 +143,14 @@ For newer versions of Vault 1.8, the API/UI for client counts was updated to ref ### Q: When I upgrade to a version of Vault that's greater Vault 1.6, will the clients be available for the entire history of the billing period, or only available after the upgrade occurred during the billing period? -The client counts will only be available after the upgrade occurs. For the complete billing period data, it’s preferable to refer to the [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool). However, keep in mind that since Vault 1.8, we made improvements to the client count API/UI that may cause mismatched results from the [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool). For more details, refer to the question [If I migrate from Vault 1.8 to 1.9, how will the changes to non-entity token logic and local auth mount made in Vault 1.9 affect the clients created prior to the migration?](/docs/concepts/client-count/faq#q-if-i-migrate-from-vault-1-8-to-1-9-how-will-the-changes-to-non-entity-token-logic-and-local-auth-mount-made-in-vault-1-9-affect-the-clients-created-prior-to-the-migration). -A workaround is to leverage the results from the UI/API (if on a newer version greater than Vault 1.8) instead of the [auditor tool](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool), and extrapolate the clients for the available period to the billing period. +The client counts will only be available after the upgrade occurs. For the complete billing period data, it’s preferable to refer to the [auditor tool](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool). However, keep in mind that since Vault 1.8, we made improvements to the client count API/UI that may cause mismatched results from the [auditor tool](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool). For more details, refer to the question [If I migrate from Vault 1.8 to 1.9, how will the changes to non-entity token logic and local auth mount made in Vault 1.9 affect the clients created prior to the migration?](/vault/docs/concepts/client-count/faq#q-if-i-migrate-from-vault-1-8-to-1-9-how-will-the-changes-to-non-entity-token-logic-and-local-auth-mount-made-in-vault-1-9-affect-the-clients-created-prior-to-the-migration). +A workaround is to leverage the results from the UI/API (if on a newer version greater than Vault 1.8) instead of the [auditor tool](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool), and extrapolate the clients for the available period to the billing period. ### Q: If I upgrade from Vault 1.8 to 1.9+, how will the changes to non-entity token logic and local auth mount made in Vault 1.9 affect the clients created prior to the upgrade? If you have a non-entity token for a fragment pre-Vault 1.9 version and then use the same token post-Vault 1.9 version, it will be counted again. However, for post-upgrade, the token will have an ID associated with it. From there, the subsequent uses of the token will not be counted again, as the token is tracked with the unique clientID. Hence, only for the period post the upgrade, the new deduplication logic for non-entity tokens are accounted for. -As for the local auth mounts, the tokens issued by the local auth mounts pre-Vault 1.9 version will be non-entity-tokens and counted as clients - 1 for each token. After the upgrade to Vault 1.9, the older tokens will continue to be counted as they were counted before, but the newer tokens issued will be part of entities and counted as far lesser clients (equal to the number of entities). To learn more, refer to the documentation on [What is a Client?](/docs/concepts/client-count#what-is-a-client). +As for the local auth mounts, the tokens issued by the local auth mounts pre-Vault 1.9 version will be non-entity-tokens and counted as clients - 1 for each token. After the upgrade to Vault 1.9, the older tokens will continue to be counted as they were counted before, but the newer tokens issued will be part of entities and counted as far lesser clients (equal to the number of entities). To learn more, refer to the documentation on [What is a Client?](/vault/docs/concepts/client-count#what-is-a-client). ### Q: Post Vault 1.9, will the clientID be viewable via the audit logs when non-entity tokens are used? @@ -158,7 +158,7 @@ Yes, beginning with Vault 1.9, audit logs have a new field called clientID, whic ### Q: Is it possible to view a list of unique client IDs that contributed to the client count aggregate? -Yes. This is possible starting with Vault 1.11, with new functionality (tech preview) to export the unique clients that contribute to the client count aggregate for the selected billing period. This is possible via a new [activity export API endpoint](/api-docs/system/internal-counters#activity-export). +Yes. This is possible starting with Vault 1.11, with new functionality (tech preview) to export the unique clients that contribute to the client count aggregate for the selected billing period. This is possible via a new [activity export API endpoint](/vault/api-docs/system/internal-counters#activity-export). ### Q: What happens if audit logs are unreadable for use by the Vault auditor tool? @@ -239,7 +239,7 @@ Should a Vault node go down any time during the 10-minute window (e.g., at the 8 ### Q: How can I disable the counting of client activity? -You can disable the count of client activity by using the enabled parameter in the client count config. For more information, refer to the documentation on [Update the Client Count Configuration](https://www.vaultproject.io/api-docs/system/internal-counters#update-the-client-count-configuration). Disabling the feature during the middle of a month will discard any data recorded for that month but does not delete previous months. +You can disable the count of client activity by using the enabled parameter in the client count config. For more information, refer to the documentation on [Update the Client Count Configuration](/vault/api-docs/system/internal-counters#update-the-client-count-configuration). Disabling the feature during the middle of a month will discard any data recorded for that month but does not delete previous months. ### Q: If I request data for January 2021 - December 2021, but April’s data does not exist, what will be included in the total client count result? @@ -247,7 +247,7 @@ In this scenario where you requested data for January 2021 through December 2021 ### Q: How can I configure the activity for log retention? -Specify retention months in the client config by following the steps in the documentation on [Update the Client Count Configuration](https://www.vaultproject.io/api-docs/system/internal-counters#update-the-client-count-configuration). +Specify retention months in the client config by following the steps in the documentation on [Update the Client Count Configuration](/vault/api-docs/system/internal-counters#update-the-client-count-configuration). ### Q: Do child namespaces create duplicate tokens? @@ -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#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](/nomad/docs/integrations/vault-integration#token-role-based-integration) uses [token roles](/nomad/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](/vault/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? @@ -270,7 +270,7 @@ To provide further clarity, post Vault 1.9, if there was an auth mount per names ### Q: How does mount migration impact the client count metric? -In Vault 1.10, we made improvements to the [`sys/remount`](/api-docs/system/remount) API endpoint to simplify the complexities of moving data, such as secret engine and authentication method configuration from one mount to another, within a namespace or across namespaces. This can help with restructuring namespaces and mounts for various reasons, including [migrating mounts](/docs/concepts/mount-migration) from root to other namespaces when transitioning to using namespaces for the first time. To learn more, refer to the [Mount Move](https://learn.hashicorp.com/tutorials/vault/mount-move) tutorial. +In Vault 1.10, we made improvements to the [`sys/remount`](/vault/api-docs/system/remount) API endpoint to simplify the complexities of moving data, such as secret engine and authentication method configuration from one mount to another, within a namespace or across namespaces. This can help with restructuring namespaces and mounts for various reasons, including [migrating mounts](/vault/docs/concepts/mount-migration) from root to other namespaces when transitioning to using namespaces for the first time. To learn more, refer to the [Mount Move](/vault/tutorials/enterprise/mount-move) tutorial. When migrating mounts, any aliases that refer to users on the auth mount could now point to an invalid mount when an auth mount is moved. Pointing to an invalid mount may not be the case for every instance; a remount within a namespace will end in the aliases pointing to a valid mount. Still, a remount across namespaces will always result in the aliases pointing to an invalid mount. In the latter case, the Vault operator should find and remove those aliases from the source namespace, and create equivalent aliases and entities for the new mount in the target namespace. If new entities and aliases aren’t created in the target namespace, Vault will dynamically generate them upon login operations. @@ -282,7 +282,7 @@ When migrating mounts within a namespace, client counts are not impacted. ### Q: Vault 1.9 added support for providing custom user filters through the userfilter parameter. How does this affect client counts? -Vault 1.9 added support for providing custom user filters through the [userfilter](/api-docs/auth/ldap#userfilter) parameter. This addition changed the way that entity alias gets mapped to an entity. Prior to Vault 1.9, alias names were always based on the [login username](/api-docs/auth/ldap#username-3) (which in turn is based on the value of the [userattr](/api-docs/auth/ldap#userattr)). In Vault 1.9, alias names no longer always map to the login username. Instead, the mapping depends on other config values as well, such as [updomain](/api-docs/auth/ldap#upndomain), [binddn](/api-docs/auth/ldap#binddn), [discoverydn](/api-docs/auth/ldap#discoverdn), and userattr. +Vault 1.9 added support for providing custom user filters through the [userfilter](/vault/api-docs/auth/ldap#userfilter) parameter. This addition changed the way that entity alias gets mapped to an entity. Prior to Vault 1.9, alias names were always based on the [login username](/vault/api-docs/auth/ldap#username-3) (which in turn is based on the value of the [userattr](/vault/api-docs/auth/ldap#userattr)). In Vault 1.9, alias names no longer always map to the login username. Instead, the mapping depends on other config values as well, such as [updomain](/vault/api-docs/auth/ldap#upndomain), [binddn](/vault/api-docs/auth/ldap#binddn), [discoverydn](/vault/api-docs/auth/ldap#discoverdn), and userattr. Vault 1.10 re-introduces the option to force the alias name to map to the login username with the optional parameter username_as_alias. Users that have the LDAP auth method enabled prior to Vault 1.9 may want to consider setting this to true to revert back to the old behavior. Otherwise, depending on the other aforementioned config values, logins may generate a new and different entity for an existing user that already had an entity associated in Vault. This in turn affects client counts since there may be more than one entity tied to this user. The username_as_alias flag will also be made available in subsequent Vault 1.8.1x and Vault 1.9.x releases to allow for this to be set prior to a Vault 1.10 upgrade. diff --git a/website/content/docs/concepts/client-count/index.mdx b/website/content/docs/concepts/client-count/index.mdx index 72939978c3..ef7e9f3bc2 100644 --- a/website/content/docs/concepts/client-count/index.mdx +++ b/website/content/docs/concepts/client-count/index.mdx @@ -21,21 +21,21 @@ There are three main ways clients are assigned an identity: There can be many different types of clients that authenticate and communicate with Vault using one of the above identities, including: -1. **[Human users](https://learn.hashicorp.com/tutorials/vault/pattern-centralized-secrets?in=vault/recommended-patterns#human-authentication):** GitHub ID, username/password, LDAP, Active Directory, Kerberos, JWT/ OIDC claims, OKTA +1. **[Human users](/vault/tutorials/recommended-patterns/pattern-centralized-secrets#human-authentication):** GitHub ID, username/password, LDAP, Active Directory, Kerberos, JWT/ OIDC claims, OKTA 2. **Applications or Microservices:** 2-Factor Authentication methods such as AppRole, or by LDAP, Active Directory, or based on the platform’s identity, such as credentials from AWS, Azure, GCP, AliCloud, OCI, Kubernetes, Cloud Foundry, etc. -3. **[Servers and Platforms](https://learn.hashicorp.com/tutorials/vault/pattern-centralized-secrets?in=vault/recommended-patterns#machine-programmatic-authentication):** VMs, Containers, Pods (Identified by LDAP, Active Directory service accounts, AWS, Azure, GCP, AliCloud, OCI, Kubernetes, TLS Certs +3. **[Servers and Platforms](/vault/tutorials/recommended-patterns/pattern-centralized-secrets#machine-programmatic-authentication):** VMs, Containers, Pods (Identified by LDAP, Active Directory service accounts, AWS, Azure, GCP, AliCloud, OCI, Kubernetes, TLS Certs 4. **Orchestrators:** Nomad, Terraform, Ansible, or Continuous Integration Continuous Delivery (CI/CD) Pipelines where each pipeline usually identified by 2FA -5. **[Vault Agents](/docs/agent/autoauth):** acting on behalf of a app/microservice, typically identified by App role, Cloud credentials, Kubernetes, TLS Certs +5. **[Vault Agents](/vault/docs/agent/autoauth):** acting on behalf of a app/microservice, typically identified by App role, Cloud credentials, Kubernetes, TLS Certs 6. **Tokens**: which are not tied to any identities at all. **_These should be used sparingly._** Hashicorp recommends always associating tokens to an entity alias and token role. ## How do Clients work in Vault? -When anything authenticates to Vault, be it a user, application, machine, etc., it is associated with a unique **entity** within the [Vault identity system](/docs/secrets/identity). The name reported to the identity systems by the different types of authentication methods varies ([list below](#authentication-methods-and-how-they-re-counted-in-vault)), each entity is created or verified during authorization. There are scenarios where tokens can be created outside of the identity system, without an associated entity. In this scenario, these tokens are considered **clients** (for production usage, it should be rare to have any tokens created outside any identity systems). +When anything authenticates to Vault, be it a user, application, machine, etc., it is associated with a unique **entity** within the [Vault identity system](/vault/docs/secrets/identity). The name reported to the identity systems by the different types of authentication methods varies ([list below](#authentication-methods-and-how-they-re-counted-in-vault)), each entity is created or verified during authorization. There are scenarios where tokens can be created outside of the identity system, without an associated entity. In this scenario, these tokens are considered **clients** (for production usage, it should be rare to have any tokens created outside any identity systems). ## But wait, there’s more... -Want to take full advantage of the Vault identity system and how clients are counted? The Vault identity system also has [Entity Aliases](/api-docs/secret/identity/entity-alias) and [Identity Groups](/api-docs/secret/identity/group-alias). +Want to take full advantage of the Vault identity system and how clients are counted? The Vault identity system also has [Entity Aliases](/vault/api-docs/secret/identity/entity-alias) and [Identity Groups](/vault/api-docs/secret/identity/group-alias). ![Vault Identity Entities and Aliases](https://www.datocms-assets.com/2885/1617325026-vault-clients-identity-entity-aliases.png) @@ -47,7 +47,7 @@ Entity Aliases enable users or services to authenticate with more than one metho Identity Groups within Vault leverage entities, in that Vault enables teams to create and manage logical groupings of entities. **Identity Groups** that can be based on organizations or teams within companies and can be used to assign policies and metadata, making user management dramatically simpler, especially for automating workflows by using Identity Groups to quickly and easily grant access to secrets and functionality within Vault. -For more on managing access with identity, entities, and more, check out [Identity-based Security and Low-trust Networks](https://www.hashicorp.com/identity-based-security-and-low-trust-networks) and the HashiCorp Learn tutorial [Identity: Entities and Groups | Vault](https://learn.hashicorp.com/tutorials/vault/identity) +For more on managing access with identity, entities, and more, check out [Identity-based Security and Low-trust Networks](https://www.hashicorp.com/identity-based-security-and-low-trust-networks) and the HashiCorp Learn tutorial [Identity: Entities and Groups | Vault](/vault/tutorials/auth-methods/identity) ## How does Vault avoid counting the same entity twice? @@ -55,18 +55,18 @@ Using the identity system allows for Vault to make sure that entities aren’t c ## Non-entity Tokens -If you choose to use the [Token Auth Method](/docs/auth/token) without an identity, this will create a non-entity token. Starting with Vault 1.9, any number of non-entity tokens having the same namespace and set of policies assigned, count as one client. In earlier versions, every non-entity token counted as a separate client, which could rapidly drive up client count to unrealistic values. If you are using Vault 1.8 or earlier, and need to address this without upgrading, one option is to create a [Token Role](/api-docs/auth/token#create-update-token-role) first, with allowable entity aliases and create your token with the appropriate [role and entity alias name](/api-docs/auth/token#create-token). All tokens issued with the same entity alias name count as one client. +If you choose to use the [Token Auth Method](/vault/docs/auth/token) without an identity, this will create a non-entity token. Starting with Vault 1.9, any number of non-entity tokens having the same namespace and set of policies assigned, count as one client. In earlier versions, every non-entity token counted as a separate client, which could rapidly drive up client count to unrealistic values. If you are using Vault 1.8 or earlier, and need to address this without upgrading, one option is to create a [Token Role](/vault/api-docs/auth/token#create-update-token-role) first, with allowable entity aliases and create your token with the appropriate [role and entity alias name](/vault/api-docs/auth/token#create-token). All tokens issued with the same entity alias name count as one client. ### Differences between a direct entity and a non-entity token -While the definition of clients appears to be simple on the surface, there are many nuances involved in the computation of clients. As mentioned, clients are unique applications, services, and/or users that authenticate to a Vault cluster. When anything authenticates to Vault, it is associated with a unique identity entity within the [Vault Identity system](/docs/secrets/identity). The name reported to the identity systems by the different types of authentication methods varies, and each entity is created or verified during authorization. +While the definition of clients appears to be simple on the surface, there are many nuances involved in the computation of clients. As mentioned, clients are unique applications, services, and/or users that authenticate to a Vault cluster. When anything authenticates to Vault, it is associated with a unique identity entity within the [Vault Identity system](/vault/docs/secrets/identity). The name reported to the identity systems by the different types of authentication methods varies, and each entity is created or verified during authorization. One thing to note is that Vault clients are a combination of active identities as well as non-entity tokens. Identity entities are unique users, and when identities authenticate to Vault, corresponding tokens are generated. However, there are some situations in which tokens are generated without corresponding identities (e.g., when using the token auth method to create a token for someone else whose identity is unknown). As such, these non-entity tokens also represent users, and are counted towards the overall client aggregates. Here are some situations in which non-entity tokens get created within Vault. -- Tokens within Vault are the core method for authentication. You can use Tokens to authenticate directly, or use the [auth methods](/docs/concepts/auth) to dynamically generate tokens based on external identities. +- Tokens within Vault are the core method for authentication. You can use Tokens to authenticate directly, or use the [auth methods](/vault/docs/concepts/auth) to dynamically generate tokens based on external identities. - There are scenarios where tokens are created outside of the identity system without an associated entity. For this reason, unique identity entities alone cannot always add up to the total unique authentications made to Vault over a stipulated time period. - In a scenario where tokens are created outside of the identity system, these tokens are considered clients. Note that it should be rare for production usage to have any tokens created outside any identity systems. -- There are a few ways of creating tokens without entities: _Token Roles_, _Token Create APIs_, _Wrapping Tokens_, and _Control Groups_. For more information, refer to the [What is a Client?](/docs/concepts/client-count/#what-is-a-client) documentation. +- There are a few ways of creating tokens without entities: _Token Roles_, _Token Create APIs_, _Wrapping Tokens_, and _Control Groups_. For more information, refer to the [What is a Client?](/vault/docs/concepts/client-count/#what-is-a-client) documentation. ## Considerations for Namespaces @@ -77,7 +77,7 @@ Since namespaces represent logical isolations within a single Vault cluster for 1. Move the auth to the parent workspace and any auth to child namespaces would be considered as the same client 2. Place that auth in the root namespace to be considered as 1 client in all namespaces. -See also the guide [Secure Multi-Tenancy with Namespaces | Vault](https://learn.hashicorp.com/tutorials/vault/namespaces). +See also the guide [Secure Multi-Tenancy with Namespaces | Vault](/vault/tutorials/enterprise/namespaces). ## Authentication Methods and how they’re counted in Vault @@ -89,24 +89,24 @@ How does this relate to Vault clients? As outlined above, and as an example, if | **Auth method** | **Name reported by auth method** | | ------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- | -| **[AliCloud](https://www.vaultproject.io/docs/auth/alicloud)** | Principal ID | -| **[AppRole](/api-docs/auth/approle#create-update-approle)** | Role ID | -| **[AWS IAM](https://www.vaultproject.io/docs/auth/aws#iam-auth-method)** | Configurable via iam_alias to one of: Role ID (default), IAM unique ID, Full ARN | -| **[AWS EC2](https://www.vaultproject.io/docs/auth/aws#ec2-auth-method)** | Configurable via ec2_alias to one of: Role ID (default), EC2 instance ID, AMI ID | -| **[Azure](/api-docs/auth/azure#create-role)** | Subject (from JWT claim) | -| **[Cloud Foundry](https://www.vaultproject.io/docs/auth/cf)** | App ID | -| **[GitHub](https://www.vaultproject.io/docs/auth/github)** | User login name associated with token | -| **[Google Cloud](/api-docs/auth/gcp#create-role)** | Configurable via iam_alias to one of: Role ID (default), Service account unique ID | -| **[JWT/OIDC](/api-docs/auth/jwt#create-role)** | Configurable via user_claim to one of the presented claims (no default value) | -| **[Kerberos](https://www.vaultproject.io/docs/auth/kerberos)** | Username | -| **[Kubernetes](/api-docs/auth/kubernetes#create-role)** | Service account UID | -| **[LDAP](https://www.vaultproject.io/docs/auth/ldap)** | Username | -| **[OCI](/api-docs/auth/oci#create-role)** | Rolename | -| **[Okta](/api-docs/auth/okta#register-user)** | Username | -| **[RADIUS](https://www.vaultproject.io/docs/auth/radius)** | Username | -| **[TLS Certificate](/api-docs/auth/cert#create-ca-certificate-role)** | Subject CommonName | -| **[Token](https://www.vaultproject.io/docs/auth/token)** | entity_alias, if provided (Note: please ensure that entity_alias is always used) | -| **[Username/Password](/api-docs/auth/userpass#create-update-user)** | Username | +| **[AliCloud](/vault/docs/auth/alicloud)** | Principal ID | +| **[AppRole](/vault/api-docs/auth/approle#create-update-approle)** | Role ID | +| **[AWS IAM](/vault/docs/auth/aws#iam-auth-method)** | Configurable via iam_alias to one of: Role ID (default), IAM unique ID, Full ARN | +| **[AWS EC2](/vault/docs/auth/aws#ec2-auth-method)** | Configurable via ec2_alias to one of: Role ID (default), EC2 instance ID, AMI ID | +| **[Azure](/vault/api-docs/auth/azure#create-role)** | Subject (from JWT claim) | +| **[Cloud Foundry](/vault/docs/auth/cf)** | App ID | +| **[GitHub](/vault/docs/auth/github)** | User login name associated with token | +| **[Google Cloud](/vault/api-docs/auth/gcp#create-role)** | Configurable via iam_alias to one of: Role ID (default), Service account unique ID | +| **[JWT/OIDC](/vault/api-docs/auth/jwt#create-role)** | Configurable via user_claim to one of the presented claims (no default value) | +| **[Kerberos](/vault/docs/auth/kerberos)** | Username | +| **[Kubernetes](/vault/api-docs/auth/kubernetes#create-role)** | Service account UID | +| **[LDAP](/vault/docs/auth/ldap)** | Username | +| **[OCI](/vault/api-docs/auth/oci#create-role)** | Rolename | +| **[Okta](/vault/api-docs/auth/okta#register-user)** | Username | +| **[RADIUS](/vault/docs/auth/radius)** | Username | +| **[TLS Certificate](/vault/api-docs/auth/cert#create-ca-certificate-role)** | Subject CommonName | +| **[Token](/vault/docs/auth/token)** | entity_alias, if provided (Note: please ensure that entity_alias is always used) | +| **[Username/Password](/vault/api-docs/auth/userpass#create-update-user)** | Username | ## Considerations with CI/CD @@ -118,7 +118,7 @@ A CI/CD workflow can encompass many pipelines. Let us consider your options: 2. **Pipeline Identity**: Or would every CI/CD pipeline be given an identity (e.g. app role, token with an entity alias), authenticate to Vault once and retrieve all the secrets for each application/ infrastructure to be deployed?? 3. **Pipeline and App/ Service/ Infra identity**: Or would every CI/CD pipeline be given an identity (e.g. app role, token with an entity alias), authenticate to Vault once and then give each application/ service/ infrastructure deployed, workflow its own identity, which upon bootstrap, in turn, authenticates to Vault on its own to retrieve a secret? -From a threat model and security assessment perspective, **_option 3_** above, where the pipeline does not have access to any secret, but allows applications, services or infrastructure to get its own secrets upon bootstrapping, is the most secure approach. With **_options 1_** and **_2_**, there is a risk that if someone gets access to your CI/CD workflow **_(option 1)_**, or your pipelines **_(option 2)_**, they would gain access to every or some of the secrets used by your apps and services. Using the [principle of least privilege](https://learn.hashicorp.com/tutorials/vault/pattern-centralized-secrets?in=vault/recommended-patterns#the-principle-of-least-privilege-polp), where you only want to give access to secrets where necessary, there should be little or no gap between your secrets distribution and when it is accessed. Therefore one should avoid inadvertently giving your orchestrator and CI/CD tool god-like privileges where it potentially can access every secret for every app, service or infrastructure you deploy. +From a threat model and security assessment perspective, **_option 3_** above, where the pipeline does not have access to any secret, but allows applications, services or infrastructure to get its own secrets upon bootstrapping, is the most secure approach. With **_options 1_** and **_2_**, there is a risk that if someone gets access to your CI/CD workflow **_(option 1)_**, or your pipelines **_(option 2)_**, they would gain access to every or some of the secrets used by your apps and services. Using the [principle of least privilege](/vault/tutorials/recommended-patterns/pattern-centralized-secrets#the-principle-of-least-privilege-polp), where you only want to give access to secrets where necessary, there should be little or no gap between your secrets distribution and when it is accessed. Therefore one should avoid inadvertently giving your orchestrator and CI/CD tool god-like privileges where it potentially can access every secret for every app, service or infrastructure you deploy. If someone goes wrong in **_option 1_** and you revoke access, all pipelines are affected. If something goes wrong in **_option 2_** and you revoke access to a pipeline, only that pipeline is affected, and you limit your security risk blast radius. If something goes wrong in **_option 3_** you can just revoke an app or service without affecting everything else. Please carefully consider your security options as you manage security in a dynamic world. @@ -137,13 +137,13 @@ The number of active clients using a Vault cluster is the total of: that is not associated with an entity Prior to Vault 1.6, this metric could only be measured from the audit log, using the -[`vault-auditor`](https://learn.hashicorp.com/tutorials/vault/usage-metrics#vault-auditor-tool) tool. Starting with Vault 1.6, the number of clients per month, or for +[`vault-auditor`](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool) tool. Starting with Vault 1.6, the number of clients per month, or for a contiguous sequence of months, can be measured by Vault itself. As of Vault 1.9, the total client count should always be measured using Vault itself. The metrics shown by the Vault UI are the source of truth for this data. -Please refer to [Vault Usage Metrics](https://learn.hashicorp.com/tutorials/vault/usage-metrics) for a +Please refer to [Vault Usage Metrics](/vault/tutorials/monitoring/usage-metrics) for a step-by-step tutorial and description of how to use the UI. ## Measuring clients @@ -216,8 +216,8 @@ entity_id n/a ``` To reduce the number of non-entity tokens in use, consider switching to an authentication method such as -[AppRole](/docs/auth/approle) instead of handing out directly-created tokens. Ensure that entities and -[entity aliases](/api-docs/secret/identity/entity-alias) exist for all login methods used to create batch tokens. +[AppRole](/vault/docs/auth/approle) instead of handing out directly-created tokens. Ensure that entities and +[entity aliases](/vault/api-docs/secret/identity/entity-alias) exist for all login methods used to create batch tokens. ### Tracking non-entity tokens @@ -246,7 +246,7 @@ request; this can happen if the request is unauthenticated, or made with a root ## API and Permissions -Please see [Client Count API](/api-docs/system/internal-counters#client-count) for more details. Note that this API is marked as +Please see [Client Count API](/vault/api-docs/system/internal-counters#client-count) for more details. Note that this API is marked as "internal" so its behavior or format may change without warning. The UI is the preferred means of interacting with the client count feature. @@ -262,7 +262,7 @@ For the UI to be able to modify the configuration settings, it additionally need The billing period for the activity log API can be specified to include the current month for the end date. For more information, please refer to the -[the internal counters API docs](/api-docs/system/internal-counters.mdx) documentation. +[the internal counters API docs](/vault/api-docs/system/internal-counters.mdx) documentation. When the end date is the current month, the `new_clients` counts will be an approximation of the number of new clients for the month, and not an exact value. Note that the `new_clients` counts for the rest diff --git a/website/content/docs/concepts/ha.mdx b/website/content/docs/concepts/ha.mdx index 09d70ab0b5..1a5909cbf4 100644 --- a/website/content/docs/concepts/ha.mdx +++ b/website/content/docs/concepts/ha.mdx @@ -16,7 +16,7 @@ You can tell if a data store supports high availability mode ("HA") by starting the server and seeing if "(HA available)" is output next to the data store information. If it is, then Vault will automatically use HA mode. This information is also available on the -[Configuration](/docs/configuration) page. +[Configuration](/vault/docs/configuration) page. To be highly available, one of the Vault server nodes grabs a lock within the data store. The successful server node then becomes the active node; all other @@ -33,11 +33,11 @@ Certain storage backends can support high availability mode, which enable them to store both Vault's information in addition to the HA lock. However, Vault also supports split data/HA mode, whereby the lock value and the rest of the data live separately. This can be done by specifying both the -[`storage`](/docs/configuration#storage) and -[`ha_storage`](/docs/configuration#ha_storage) stanzas in the configuration file +[`storage`](/vault/docs/configuration#storage) and +[`ha_storage`](/vault/docs/configuration#ha_storage) stanzas in the configuration file with different backends. For instance, a Vault cluster can be set up to use -Consul as the [`ha_storage`](/docs/configuration#ha_storage) to manage the lock, -and use Amazon S3 as the [`storage`](/docs/configuration#storage) for all other +Consul as the [`ha_storage`](/vault/docs/configuration#ha_storage) to manage the lock, +and use Amazon S3 as the [`storage`](/vault/docs/configuration#storage) for all other persisted data. The sections below explain the server communication patterns and each type of @@ -87,35 +87,35 @@ always required for all HA setups. Some HA data store drivers can autodetect the redirect address, but it is often necessary to configure it manually via a top-level value in the configuration -file. The key for this value is [`api_addr`](/docs/configuration#api_addr) and +file. The key for this value is [`api_addr`](/vault/docs/configuration#api_addr) and the value can also be specified by the `VAULT_API_ADDR` environment variable, which takes precedence. -What the [`api_addr`](/docs/configuration#api_addr) value should be set to +What the [`api_addr`](/vault/docs/configuration#api_addr) value should be set to depends on how Vault is set up. There are two common scenarios: Vault servers accessed directly by clients, and Vault servers accessed via a load balancer. -In both cases, the [`api_addr`](/docs/configuration#api_addr) should be a full +In both cases, the [`api_addr`](/vault/docs/configuration#api_addr) should be a full URL including scheme (`http`/`https`), not simply an IP address and port. ### Direct Access When clients are able to access Vault directly, the -[`api_addr`](/docs/configuration#api_addr) for each node should be that node's +[`api_addr`](/vault/docs/configuration#api_addr) for each node should be that node's address. For instance, if there are two Vault nodes: - `A`, accessed via `https://a.vault.mycompany.com:8200` - `B`, accessed via `https://b.vault.mycompany.com:8200` Then node `A` would set its -[`api_addr`](/docs/configuration#api_addr) to +[`api_addr`](/vault/docs/configuration#api_addr) to `https://a.vault.mycompany.com:8200` and node `B` would set its -[`api_addr`](/docs/configuration#api_addr) to +[`api_addr`](/vault/docs/configuration#api_addr) to `https://b.vault.mycompany.com:8200`. This way, when `A` is the active node, any requests received by node `B` will cause it to redirect the client to node `A`'s -[`api_addr`](/docs/configuration#api_addr) at `https://a.vault.mycompany.com`, +[`api_addr`](/vault/docs/configuration#api_addr) at `https://a.vault.mycompany.com`, and vice-versa. ### Behind Load Balancers @@ -126,7 +126,7 @@ case, the Vault servers should actually be set up as described in the above section, since for redirection purposes the clients have direct access. However, if the only access to the Vault servers is via the load balancer, the -[`api_addr`](/docs/configuration#api_addr) on each node should be the same: the +[`api_addr`](/vault/docs/configuration#api_addr) on each node should be the same: the address of the load balancer. Clients that reach a standby node will be redirected back to the load balancer; at that point hopefully the load balancer's configuration will have been updated to know the address of the @@ -135,16 +135,16 @@ setup when it can be avoided. ### Per-Node Cluster Listener Addresses -Each [`listener`](/docs/configuration/listener) block in Vault's configuration -file contains an [`address`](/docs/configuration/listener/tcp#address) value on +Each [`listener`](/vault/docs/configuration/listener) block in Vault's configuration +file contains an [`address`](/vault/docs/configuration/listener/tcp#address) value on which Vault listens for requests. Similarly, each -[`listener`](/docs/configuration/listener) block can contain a -[`cluster_address`](/docs/configuration/listener/tcp#cluster_address) on which +[`listener`](/vault/docs/configuration/listener) block can contain a +[`cluster_address`](/vault/docs/configuration/listener/tcp#cluster_address) on which Vault listens for server-to-server cluster requests. If this value is not set, its IP address will be automatically set to same as the -[`address`](/docs/configuration/listener/tcp#address) value, and its port will +[`address`](/vault/docs/configuration/listener/tcp#address) value, and its port will be automatically set to the same as the -[`address`](/docs/configuration/listener/tcp#address) value plus one (so by +[`address`](/vault/docs/configuration/listener/tcp#address) value plus one (so by default, port `8201`). Note that _only_ active nodes have active listeners. When a node becomes active @@ -152,14 +152,14 @@ it will start cluster listeners, and when it becomes standby it will stop them. ### Per-Node Cluster Address -Similar to the [`api_addr`](/docs/configuration#api_addr), -[`cluster_addr`](/docs/configuration#cluster_addr) is the value that each node, +Similar to the [`api_addr`](/vault/docs/configuration#api_addr), +[`cluster_addr`](/vault/docs/configuration#cluster_addr) is the value that each node, if active, should advertise to the standbys to use for server-to-server communications, and lives as a top-level value in the configuration file. On each node, this should be set to a host name or IP address that a standby can use to reach one of that node's -[`cluster_address`](/docs/configuration#cluster_address) values set in the -[`listener`](/docs/configuration/listener) blocks, including port. (Note that +[`cluster_address`](/vault/docs/configuration#cluster_address) values set in the +[`listener`](/vault/docs/configuration/listener) blocks, including port. (Note that this will always be forced to `https` since only TLS connections are used between servers.) @@ -169,12 +169,12 @@ variable, which takes precedence. ## Storage Support Currently there are several storage backends that support high availability -mode, including [Consul](/docs/configuration/storage/consul), -[ZooKeeper](/docs/configuration/storage/zookeeper) and [etcd](/docs/configuration/storage/etcd). These may -change over time, and the [configuration page](/docs/configuration) should be +mode, including [Consul](/vault/docs/configuration/storage/consul), +[ZooKeeper](/vault/docs/configuration/storage/zookeeper) and [etcd](/vault/docs/configuration/storage/etcd). These may +change over time, and the [configuration page](/vault/docs/configuration) should be referenced. -HashiCorp recommends [Vault Integrated Storage](/docs/configuration/storage/raft) as the default HA backend for new deployments of Vault. [Consul Storage Backend](/docs/configuration/storage/consul) is also a supported option and used by many production deployments. See the [comparison chart](/docs/configuration/storage#integrated-storage-vs-consul-as-vault-storage) for help deciding which option is best for you. +HashiCorp recommends [Vault Integrated Storage](/vault/docs/configuration/storage/raft) as the default HA backend for new deployments of Vault. [Consul Storage Backend](/vault/docs/configuration/storage/consul) is also a supported option and used by many production deployments. See the [comparison chart](/vault/docs/configuration/storage#integrated-storage-vs-consul-as-vault-storage) for help deciding which option is best for you. If you're interested in implementing another backend or adding HA support to another backend, we'd love your contributions. Adding HA support requires diff --git a/website/content/docs/concepts/identity.mdx b/website/content/docs/concepts/identity.mdx index a6d2808983..9b83381d97 100644 --- a/website/content/docs/concepts/identity.mdx +++ b/website/content/docs/concepts/identity.mdx @@ -12,7 +12,7 @@ overview of the various terminologies and their concepts. The idea of Identity is to maintain the clients who are recognized by Vault. As such, Vault provides an identity management solution through the **Identity secrets engine**. For more information about the Identity secrets engine and how it is used, refer to -the [Identity Secrets Engine](/docs/secrets/identity) documentation. +the [Identity Secrets Engine](/vault/docs/secrets/identity) documentation. ## Entities and Aliases @@ -45,7 +45,7 @@ to the authenticated token. When such tokens are used, their entity identifiers are audit logged, marking a trail of actions performed by specific users. ~> Vault Entity is used to count the number of Vault clients. To learn more -about client count, refer to the [Client Count](/docs/concepts/client-count) +about client count, refer to the [Client Count](/vault/docs/concepts/client-count) documentation. ## Entity Management @@ -186,9 +186,9 @@ group and has an alias that maps to the group in LDAP. If the user is removed from the group in LDAP, that change gets reflected in Vault only upon the subsequent login or renewal operation. -For information about Identity Secrets Engine, refer to [Identity Secrets Engine](/docs/secrets/identity). +For information about Identity Secrets Engine, refer to [Identity Secrets Engine](/vault/docs/secrets/identity). ## Tutorial Refer to the [Identity: Entities and -Groups](https://learn.hashicorp.com/tutorials/vault/identity) tutorial to learn how Vault supports mutliple authentication methods and enables the same authentication method to be used with different mount paths. +Groups](/vault/tutorials/auth-methods/identity) tutorial to learn how Vault supports mutliple authentication methods and enables the same authentication method to be used with different mount paths. diff --git a/website/content/docs/concepts/integrated-storage/autopilot.mdx b/website/content/docs/concepts/integrated-storage/autopilot.mdx index 406083de0e..0006f3ef52 100644 --- a/website/content/docs/concepts/integrated-storage/autopilot.mdx +++ b/website/content/docs/concepts/integrated-storage/autopilot.mdx @@ -51,7 +51,7 @@ Raft clusters deployed with older versions of Vault will also transition to use Autopilot automatically. Autopilot exposes a [configuration -API](/api-docs/system/storage/raftautopilot#set-configuration) to manage its +API](/vault/api-docs/system/storage/raftautopilot#set-configuration) to manage its behavior. Autopilot gets initialized with the following default values. - `cleanup_dead_servers` - `false` @@ -115,13 +115,13 @@ increase read scalability. DR secondary and Performance secondary clusters have their own Autopilot configurations, managed independently of their primary. -The [Autopilot API](/api-docs/system/storage/raftautopilot) uses DR operation tokens for +The [Autopilot API](/vault/api-docs/system/storage/raftautopilot) uses DR operation tokens for authorization when executed against a DR secondary cluster. ## Tutorial 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) +- [Integrated Storage Autopilot](/vault/tutorials/raft/raft-autopilot) +- [Fault Tolerance with Redundancy Zones](/vault/tutorials/raft/raft-redundancy-zones) +- [Automate Upgrades with Vault Enterprise](/vault/tutorials/raft/raft-upgrade-automation) diff --git a/website/content/docs/concepts/integrated-storage/index.mdx b/website/content/docs/concepts/integrated-storage/index.mdx index 0e1f24a424..5a9cba5174 100644 --- a/website/content/docs/concepts/integrated-storage/index.mdx +++ b/website/content/docs/concepts/integrated-storage/index.mdx @@ -16,8 +16,8 @@ The option stores Vault's data on the server's filesystem and uses a consensus protocol to replicate data to each server in the cluster. More information on the internals of Integrated Storage can be found in the [Integrated Storage internals -documentation](/docs/internals/integrated-storage/). Additionally, the -[Configuration](/docs/configuration/storage/raft/) docs can help in configuring +documentation](/vault/docs/internals/integrated-storage/). Additionally, the +[Configuration](/vault/docs/configuration/storage/raft/) docs can help in configuring Vault to use Integrated Storage. The sections below go into various details on how to operate Vault with @@ -30,7 +30,7 @@ Vault's cluster port. The cluster port defaults to `8201`. The TLS information is exchanged at join time and is rotated on a cadence. A requirement for Integrated Storage is that the -[`cluster_addr`](/docs/concepts/ha#per-node-cluster-address) configuration option +[`cluster_addr`](/vault/docs/concepts/ha#per-node-cluster-address) configuration option is set. This allows Vault to assign an address to the node ID at join time. ## Cluster Membership @@ -41,7 +41,7 @@ running Integrated Storage. Integrated Storage is bootstrapped during the [initialization process](https://learn.hashicorp.com/vault/getting-started/deploy#initializing-the-vault), and results in a cluster of size 1. Depending on the [desired deployment -size](/docs/internals/integrated-storage/#deployment-table), nodes can be joined +size](/vault/docs/internals/integrated-storage/#deployment-table), nodes can be joined to the active Vault node. ### Joining Nodes @@ -57,7 +57,7 @@ been joined it cannot be re-joined to a different cluster. You can either join the node automatically via the config file or manually through the API (both methods described below). When joining a node, the API address of the leader node must be used. We -recommend setting the [`api_addr`](/docs/concepts/ha#direct-access) configuration +recommend setting the [`api_addr`](/vault/docs/concepts/ha#direct-access) configuration option on all nodes to make joining simpler. #### `retry_join` Configuration @@ -69,7 +69,7 @@ leaders become active this node will successfully join. When using Shamir seal, the joined nodes will still need to be unsealed manually. When using Auto Unseal the node will be able to join and unseal automatically. -An example [`retry_join`](/docs/configuration/storage/raft#retry_join-stanza) +An example [`retry_join`](/vault/docs/configuration/storage/raft#retry_join-stanza) config can be seen below: ```hcl @@ -86,18 +86,18 @@ storage "raft" { } ``` -Note, in each [`retry_join`](/docs/configuration/storage/raft#retry_join-stanza) +Note, in each [`retry_join`](/vault/docs/configuration/storage/raft#retry_join-stanza) stanza, you may provide a single -[`leader_api_addr`](/docs/configuration/storage/raft#leader_api_addr) or -[`auto_join`](/docs/configuration/storage/raft#auto_join) value. When a cloud -[`auto_join`](/docs/configuration/storage/raft#auto_join) configuration value is +[`leader_api_addr`](/vault/docs/configuration/storage/raft#leader_api_addr) or +[`auto_join`](/vault/docs/configuration/storage/raft#auto_join) value. When a cloud +[`auto_join`](/vault/docs/configuration/storage/raft#auto_join) configuration value is provided, Vault will use [go-discover](https://github.com/hashicorp/go-discover) to automatically attempt to discover and resolve potential Raft leader addresses. See the go-discover [README](https://github.com/hashicorp/go-discover/blob/master/README.md) for -details on the format of the [`auto_join`](/docs/configuration/storage/raft#auto_join) value. +details on the format of the [`auto_join`](/vault/docs/configuration/storage/raft#auto_join) value. ```hcl storage "raft" { @@ -111,8 +111,8 @@ storage "raft" { ``` By default, Vault will attempt to reach discovered peers using HTTPS and port 8200. Operators may override these through the -[`auto_join_scheme`](/docs/configuration/storage/raft#auto_join_scheme) and -[`auto_join_port`](/docs/configuration/storage/raft#auto_join_port) fields +[`auto_join_scheme`](/vault/docs/configuration/storage/raft#auto_join_scheme) and +[`auto_join_port`](/vault/docs/configuration/storage/raft#auto_join_port) fields respectively. ```hcl @@ -131,7 +131,7 @@ storage "raft" { #### Join from the CLI Alternatively you can use the [`join` CLI -command](/docs/commands/operator/raft/#join) or the API to join a node. The +command](/vault/docs/commands/operator/raft/#join) or the API to join a node. The active node's API address will need to be specified: ```shell-session @@ -143,7 +143,7 @@ $ vault operator raft join https://node1.vault.local:8200 Nodes that are joined to a cluster can be specified as non-voters. A non-voting node has all of Vault's data replicated to it, but does not contribute to the quorum count. This can be used in conjunction with [Performance -Standby](/docs/enterprise/performance-standby/) nodes to add read scalability to +Standby](/vault/docs/enterprise/performance-standby/) nodes to add read scalability to a cluster in cases where a high volume of reads to servers are needed. ```shell-session @@ -159,7 +159,7 @@ the size of the cluster, or for many other reasons. Removing the peer will ensure the cluster stays at the desired size, and that quorum is maintained. To remove the peer you can issue a -[`remove-peer`](/docs/commands/operator/raft#remove-peer) command and provide the +[`remove-peer`](/vault/docs/commands/operator/raft#remove-peer) command and provide the node ID you wish to remove: ```shell-session @@ -170,7 +170,7 @@ Peer removed successfully! ### Listing Peers To see the current peer set for the cluster you can issue a -[`list-peers`](/docs/commands/operator/raft#list-peers) command. All the voting +[`list-peers`](/vault/docs/commands/operator/raft#list-peers) command. All the voting nodes that are listed here contribute to the quorum and a majority must be alive for Integrated Storage to continue to operate. @@ -198,8 +198,8 @@ these IPs in their IP SANs. Before we explore solutions to this problem, let's recapitulate how Vault nodes speak to one another. -Vault exposes two TCP ports: [the API port](/docs/configuration#api_addr) and -[the cluster port](/docs/configuration#cluster_addr). +Vault exposes two TCP ports: [the API port](/vault/docs/configuration#api_addr) and +[the cluster port](/vault/docs/configuration#cluster_addr). The API port is where clients send their Vault HTTP requests. @@ -238,15 +238,15 @@ All subsequent inter-node communication will use the cluster port. ### Assisted raft join techniques -The simplest option is to do it by hand: issue [`raft join`](/docs/commands/operator/raft#join) commands specifying the explicit names +The simplest option is to do it by hand: issue [`raft join`](/vault/docs/commands/operator/raft#join) commands specifying the explicit names or IPs of the nodes to join to. In this section we look at other TLS-compatible options that lend themselves more to automation. #### Autojoin with TLS servername As of Vault 1.6.2, the simplest option might be to specify a -[`leader_tls_servername`](/docs/configuration/storage/raft#leader_tls_servername) -in the [`retry_join`](/docs/configuration/storage/raft#retry_join-stanza) stanza +[`leader_tls_servername`](/vault/docs/configuration/storage/raft#leader_tls_servername) +in the [`retry_join`](/vault/docs/configuration/storage/raft#retry_join-stanza) stanza which matches a [DNS SAN](https://en.wikipedia.org/wiki/Subject_Alternative_Name) in the certificate. @@ -269,7 +269,7 @@ using non-voting nodes and dynamically scaling clusters. Most Vault instances are going to have a load balancer (LB) between clients and the Vault nodes. In that case, the LB knows how to route traffic to working Vault nodes, and there's no need for auto-join: we can just use -[`retry_join`](/docs/configuration/storage/raft#retry_join-stanza) with the LB +[`retry_join`](/vault/docs/configuration/storage/raft#retry_join-stanza) with the LB address as the target. One potential issue here: some users want a public facing LB for clients to @@ -290,10 +290,10 @@ and have it reconnect to the cluster with the same host address. This will retur the cluster to a fully healthy state. If this is impractical, you need to remove the failed server. Usually, you can -issue a [`remove-peer`](/docs/commands/operator/raft#remove-peer) command to +issue a [`remove-peer`](/vault/docs/commands/operator/raft#remove-peer) command to remove the failed server if it's still a member of the cluster. -If the [`remove-peer`](/docs/commands/operator/raft#remove-peer) command isn't +If the [`remove-peer`](/vault/docs/commands/operator/raft#remove-peer) command isn't possible or you'd rather manually re-write the cluster membership a [`raft/peers.json`](#manual-recovery-using-peers-json) file can be written to the configured data directory. @@ -339,7 +339,7 @@ automated processes that will put the peers file in place on a periodic basis. To begin, stop all remaining servers. The next step is to go to the [configured data -path](/docs/configuration/storage/raft/#path) of each Vault server. Inside that +path](/vault/docs/configuration/storage/raft/#path) of each Vault server. Inside that directory, there will be a `raft/` sub-directory. We need to create a `raft/peers.json` file. The file should be formatted as a JSON array containing the node ID, `address:port`, and suffrage information of each Vault server you @@ -385,4 +385,4 @@ active. ### Other Recovery Methods For other, non-quorum related recovery [Vault's -recovery](/docs/concepts/recovery-mode/) mode can be used. +recovery](/vault/docs/concepts/recovery-mode/) mode can be used. diff --git a/website/content/docs/concepts/lease.mdx b/website/content/docs/concepts/lease.mdx index 707785b2f2..eedd6b76ca 100644 --- a/website/content/docs/concepts/lease.mdx +++ b/website/content/docs/concepts/lease.mdx @@ -26,7 +26,7 @@ to check in routinely. In addition to renewals, a lease can be _revoked_. When a lease is revoked, it invalidates that secret immediately and prevents any further renewals. For -example, with the [AWS secrets engine](/docs/secrets/aws), the +example, with the [AWS secrets engine](/vault/docs/secrets/aws), the access keys will be deleted from AWS the moment a lease is revoked. This renders the access keys invalid from that point forward. @@ -35,7 +35,7 @@ the user interface (UI) under the Access tab, or automatically by Vault. When a is expired, Vault will automatically revoke that lease. When a token is revoked, Vault will revoke all leases that were created using that token. -**Note**: The [Key/Value Backend](/docs/secrets/kv) which stores +**Note**: The [Key/Value Backend](/vault/docs/secrets/kv) which stores arbitrary secrets does not issue leases although it will sometimes return a lease duration; see the documentation for more information. @@ -69,7 +69,7 @@ As a result, the return value of renewals should be carefully inspected to determine what the new lease is. --> To implement token renewal logic in your application code, refer to the [code example in the Authentication doc](/docs/concepts/auth#code-example). +-> To implement token renewal logic in your application code, refer to the [code example in the Authentication doc](/vault/docs/concepts/auth#code-example). ## Prefix-based Revocation @@ -80,7 +80,7 @@ Lease IDs are structured in a way that their prefix is always the path where the secret was requested from. This lets you revoke trees of secrets. For example, to revoke all AWS access keys, you can do `vault lease revoke -prefix aws/`. For more information about revoke command please check -[cli's lease revoke](/docs/commands/lease/revoke#lease-revoke) +[cli's lease revoke](/vault/docs/commands/lease/revoke#lease-revoke) command docs. This is very useful if there is an intrusion within a specific system: all diff --git a/website/content/docs/concepts/oidc-provider.mdx b/website/content/docs/concepts/oidc-provider.mdx index 8f8ec8fbff..1b132257c4 100644 --- a/website/content/docs/concepts/oidc-provider.mdx +++ b/website/content/docs/concepts/oidc-provider.mdx @@ -9,9 +9,9 @@ description: >- This document provides conceptual information about the Vault **OpenID Connect (OIDC) identity provider** feature. This feature enables client applications that speak the OIDC protocol to -leverage Vault's source of [identity](/docs/concepts/identity) and wide range of [authentication methods](/docs/auth) +leverage Vault's source of [identity](/vault/docs/concepts/identity) and wide range of [authentication methods](/vault/docs/auth) when authenticating end-users. For more information about the usage of Vault's OIDC provider, -refer to the [OIDC identity provider](/docs/secrets/identity/oidc-provider) documentation. +refer to the [OIDC identity provider](/vault/docs/secrets/identity/oidc-provider) documentation. ## Configuration Options @@ -23,7 +23,7 @@ Each Vault namespace will contain a built-in provider resource named `default`. provider will allow all client applications within the namespace to use it for OIDC flows. The `default` provider can be modified but not deleted. -Additionally, a Vault namespace may contain several provider resources. Each configured provider will publish the APIs listed within the [OIDC flow](/docs/concepts/oidc-provider#oidc-flow) section. The APIs will be served via backend path-based routing on Vault's listen [address](/docs/configuration/listener/tcp#address). +Additionally, a Vault namespace may contain several provider resources. Each configured provider will publish the APIs listed within the [OIDC flow](/vault/docs/concepts/oidc-provider#oidc-flow) section. The APIs will be served via backend path-based routing on Vault's listen [address](/vault/docs/configuration/listener/tcp#address). A provider has the following configuration parameters: @@ -31,7 +31,7 @@ A provider has the following configuration parameters: * **Allowed client IDs**: limits which clients can access the provider * **Scopes supported**: limits what identity information is available as claims -The issuer URL parameter is necessary for the validation of ID tokens by clients. If an URL parameter is not provided explicitly, it will default to a URL with Vault's [api_addr](/docs/configuration#api_addr) as the `scheme://host:port` component and `/v1/:namespace/identity/oidc/provider/:name` as the path component. This means tokens issued by a provider in a specified Vault cluster must be validated within that same cluster. If the issuer URL is provided explicitly, it must point to a Vault instance that is network-reachable by clients for ID token validation. +The issuer URL parameter is necessary for the validation of ID tokens by clients. If an URL parameter is not provided explicitly, it will default to a URL with Vault's [api_addr](/vault/docs/configuration#api_addr) as the `scheme://host:port` component and `/v1/:namespace/identity/oidc/provider/:name` as the path component. This means tokens issued by a provider in a specified Vault cluster must be validated within that same cluster. If the issuer URL is provided explicitly, it must point to a Vault instance that is network-reachable by clients for ID token validation. The allowed client IDs parameter utilizes the list of client IDs that have been generated by Vault as a part of client registration. By default, all clients will be *disallowed*. Providing `*` as the parameter value will allow all clients to use the provider. @@ -47,7 +47,7 @@ A scope will have the following configuration parameters: * **Template**: maps individual claims to Vault identity information -The template parameter takes advantage of the [JSON-based templating](/api-docs/secret/identity/tokens#template) used by identity tokens for claims mapping. This means the parameter will take a JSON string of arbitrary structure where the values may be replaced with specific identity information. Template parameters that are not present for a Vault identity are omitted from the resulting claims without an error. +The template parameter takes advantage of the [JSON-based templating](/vault/api-docs/secret/identity/tokens#template) used by identity tokens for claims mapping. This means the parameter will take a JSON string of arbitrary structure where the values may be replaced with specific identity information. Template parameters that are not present for a Vault identity are omitted from the resulting claims without an error. Example of a JSON template for a scope: @@ -80,8 +80,8 @@ The full list of template parameters are included in the following table: | `identity.entity.aliases..custom_metadata` | Custom metadata associated with the alias for the given mount | | `identity.entity.aliases..custom_metadata.` | Custom metadata associated with the alias for the given mount and custom metadata key | | `time.now` | Current time as integral seconds since the Epoch | -| `time.now.plus.` | Current time plus a [duration format string](/docs/concepts/duration-format) | -| `time.now.minus.` | Current time minus a [duration format string](/docs/concepts/duration-format) | +| `time.now.plus.` | Current time plus a [duration format string](/vault/docs/concepts/duration-format) | +| `time.now.minus.` | Current time minus a [duration format string](/vault/docs/concepts/duration-format) | Several named scopes can be made available on an individual provider. Note that the top-level keys in a JSON template may conflict with those in another scope. When scopes are made available on a provider, their templates are checked for top-level conflicts. A warning will be issued to the Vault operator if any conflicts are found. This may result in an error if the scopes are requested in an OIDC Authentication Request. @@ -113,7 +113,7 @@ A client has the following configuration parameters: The `key` parameter is optional. The key will be used to sign ID tokens for the client. It cannot be modified after creation. If not supplied, defaults to the built-in -[default key](/docs/concepts/oidc-provider#keys). +[default key](/vault/docs/concepts/oidc-provider#keys). A `client_id` is generated and returned after a successful client registration. The `client_id` uniquely identifies the client. Its value will be a string with 32 random @@ -162,7 +162,7 @@ Each Vault namespace will contain a built-in assignment resource named `allow_al Key resources are referenced by clients via the `key` parameter. This parameter specifies the key that will be used to sign ID tokens for the client. See existing -[documentation](/api-docs/secret/identity/tokens#create-a-named-key) for details on keyring +[documentation](/vault/api-docs/secret/identity/tokens#create-a-named-key) for details on keyring management, supported signing algorithms, rotation periods, and verification TTLs. Currently, a key referenced by a client cannot be changed. @@ -199,7 +199,7 @@ Each provider offers an unauthenticated endpoint that provides the public portio ### Authorization Endpoint -Each provider offers an authenticated [authorization endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint). The authorization endpoint for each provider is added to Vault's [default policy](/docs/concepts/policies#default-policy) using the `identity/oidc/provider/+/authorize` path. The endpoint incorporates all required [authentication request](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) parameters as input. +Each provider offers an authenticated [authorization endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint). The authorization endpoint for each provider is added to Vault's [default policy](/vault/docs/concepts/policies#default-policy) using the `identity/oidc/provider/+/authorize` path. The endpoint incorporates all required [authentication request](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) parameters as input. The endpoint [validates](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequestValidation) client requests and ensures that all required parameters are present and valid. The `redirect_uri` of the request is validated against the client's `redirect_uris`. The requesting Vault entity will be validated against the client's `assignments`. An appropriate [error code](https://openid.net/specs/openid-connect-core-1_0.html#AuthError) is returned for invalid requests. @@ -207,12 +207,12 @@ An authorization code is generated with a successful validation of the request. ### Token Endpoint -Each provider will offer a [token endpoint](/api-docs/secret/identity/oidc-provider#token-endpoint). The endpoint may be unauthenticated in Vault but is authenticated by requiring a `client_secret` as described in [client authentication](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication). The endpoint ingests all required [token request](/api-docs/secret/identity/oidc-provider#parameters-15) parameters as input. The endpoint [validates](https://openid.net/specs/openid-connect-core-1_0.html#TokenRequestValidation) the client requests and exchanges an authorization code for the ID token and access token. The cache of authorization codes will be verified against the code presented in the exchange. The appropriate [error codes](https://openid.net/specs/openid-connect-core-1_0.html#TokenErrorResponse) are returned for all invalid requests. +Each provider will offer a [token endpoint](/vault/api-docs/secret/identity/oidc-provider#token-endpoint). The endpoint may be unauthenticated in Vault but is authenticated by requiring a `client_secret` as described in [client authentication](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication). The endpoint ingests all required [token request](/vault/api-docs/secret/identity/oidc-provider#parameters-15) parameters as input. The endpoint [validates](https://openid.net/specs/openid-connect-core-1_0.html#TokenRequestValidation) the client requests and exchanges an authorization code for the ID token and access token. The cache of authorization codes will be verified against the code presented in the exchange. The appropriate [error codes](https://openid.net/specs/openid-connect-core-1_0.html#TokenErrorResponse) are returned for all invalid requests. The ID token is generated and returned upon successful client authentication and request validation. The ID token will contain a combination of required and configurable claims. The required claims are enumerated in the scopes section above for the `openid` scope. The configurable claims are populated by templates associated with the scopes provided in the authentication request that generated the authorization code. -An access token is also generated and returned upon successful client authentication and request validation. The access token is a Vault [batch token](/docs/concepts/tokens#batch-tokens) with a policy that only provides read access to the issuing provider's [userinfo endpoint](/api-docs/secret/identity/oidc-provider#userinfo-endpoint). The access token is also a TTL as defined by the `access_token_ttl` of the requesting client. +An access token is also generated and returned upon successful client authentication and request validation. The access token is a Vault [batch token](/vault/docs/concepts/tokens#batch-tokens) with a policy that only provides read access to the issuing provider's [userinfo endpoint](/vault/api-docs/secret/identity/oidc-provider#userinfo-endpoint). The access token is also a TTL as defined by the `access_token_ttl` of the requesting client. ### UserInfo Endpoint -Each provider provides an authenticated [userinfo endpoint](/api-docs/secret/identity/oidc-provider#userinfo-endpoint). The endpoint accepts the access token obtained from the token endpoint as a [bearer token](/api-docs#authentication). The userinfo response is a JSON object with the `application/json` content type. The JSON object contains claims for the Vault entity associated with the access token. The claims returned are determined by the scopes requested in the authentication request that produced the access token. The `sub` claim is always returned as the entity ID in the userinfo response. +Each provider provides an authenticated [userinfo endpoint](/vault/api-docs/secret/identity/oidc-provider#userinfo-endpoint). The endpoint accepts the access token obtained from the token endpoint as a [bearer token](/vault/api-docs#authentication). The userinfo response is a JSON object with the `application/json` content type. The JSON object contains claims for the Vault entity associated with the access token. The claims returned are determined by the scopes requested in the authentication request that produced the access token. The `sub` claim is always returned as the entity ID in the userinfo response. diff --git a/website/content/docs/concepts/password-policies.mdx b/website/content/docs/concepts/password-policies.mdx index 1195735ebe..3951172363 100644 --- a/website/content/docs/concepts/password-policies.mdx +++ b/website/content/docs/concepts/password-policies.mdx @@ -13,9 +13,9 @@ generators. These password policies are used in a subset of secret engines to al how a password is generated for that engine. Not all secret engines utilize password policies, so check the documentation for the engine you are using for compatibility. -**Note:** Password policies are unrelated to [Policies](/docs/concepts/policies) other than sharing similar names. +**Note:** Password policies are unrelated to [Policies](/vault/docs/concepts/policies) other than sharing similar names. -Password policies are available in Vault version 1.5+. [API docs can be found here](/api-docs/system/policies-password). +Password policies are available in Vault version 1.5+. [API docs can be found here](/vault/api-docs/system/policies-password). !> Password policies are an advanced usage of Vault. This generates credentials for external systems (databases, LDAP, AWS, etc.) and should be used with caution. @@ -237,7 +237,7 @@ If we do this for uppercase letters as well as numbers, then we get a combined p It should be noted that this probability curve only applies to this specific policy. To understand the performance characteristics of a given policy, you should run your policy with the -[`generate`](/api-docs/system/policies-password) endpoint to see how much time the policy takes to +[`generate`](/vault/api-docs/system/policies-password) endpoint to see how much time the policy takes to produce passwords.
@@ -247,7 +247,7 @@ produce passwords. Password policies are defined in [HCL](https://github.com/hashicorp/hcl) or JSON which defines the length of the password and a set of rules a password must adhere to. -See the [API docs](/api-docs/system/policies-password) for examples of the commands to save/read/etc. +See the [API docs](/vault/api-docs/system/policies-password) for examples of the commands to save/read/etc. password policies Here is a very simple policy which generates 20 character passwords from lowercase characters: diff --git a/website/content/docs/concepts/policies.mdx b/website/content/docs/concepts/policies.mdx index 082e311350..dbae554205 100644 --- a/website/content/docs/concepts/policies.mdx +++ b/website/content/docs/concepts/policies.mdx @@ -18,7 +18,7 @@ system. ## Policy-Authorization Workflow Before a human or machine can gain access, an administrator must configure Vault -with an [auth method](/docs/concepts/auth). Authentication is +with an [auth method](/vault/docs/concepts/auth). Authentication is the process by which human or machine-supplied information is verified against an internal or external system. @@ -84,7 +84,7 @@ user or machine is allowed to access. [hcl]: https://github.com/hashicorp/hcl -Here is a very simple policy which grants read capabilities to the [KVv1](/api-docs/secret/kv/kv-v1) path +Here is a very simple policy which grants read capabilities to the [KVv1](/vault/api-docs/secret/kv/kv-v1) path `"secret/foo"`: ```ruby @@ -205,7 +205,7 @@ control over permitted (or denied) operations. As shown in the examples above, capabilities are always specified as a list of strings, even if there is only one capability. -To determine the capabilities needed to perform a specific operation, the `-output-policy` flag can be added to the CLI subcommand. For an example, refer to the [Print Policy Requirements](/docs/commands#print-policy-requirements) document section. +To determine the capabilities needed to perform a specific operation, the `-output-policy` flag can be added to the CLI subcommand. For an example, refer to the [Print Policy Requirements](/vault/docs/commands#print-policy-requirements) document section. The list of capabilities include the following: @@ -341,11 +341,11 @@ path take precedence over permissions on parameters. ### Parameter Constraints -!> **Note:** The use of [globs](docs/concepts/policies#policy-syntax) (`*`) may result in [surprising or unexpected behavior](#parameter-constraints-limitations). +!> **Note:** The use of [globs](/vault/docs/concepts/policies#policy-syntax) (`*`) may result in [surprising or unexpected behavior](#parameter-constraints-limitations). -~> **Note:** The `allowed_parameters`, `denied_parameters`, and `required_parameters` fields are not supported for policies used with the [version 2 kv secrets engine](/docs/secrets/kv/kv-v2). +~> **Note:** The `allowed_parameters`, `denied_parameters`, and `required_parameters` fields are not supported for policies used with the [version 2 kv secrets engine](/vault/docs/secrets/kv/kv-v2). -See the [API Specification](/api-docs/secret/kv/kv-v2) for more information. +See the [API Specification](/vault/api-docs/secret/kv/kv-v2) for more information. Policies can take into account HTTP request parameters to further constrain requests, using the following options: @@ -381,10 +381,10 @@ constrain requests, using the following options: ``` -> **Usage example:** The [ACL Policy Path - Templating](https://learn.hashicorp.com/tutorials/vault/policy-templating) + Templating](/vault/tutorials/policies/policy-templating) tutorial demonstrates the use of `allowed_parameters` to permit a user to update the user's password when using the [userpass auth - method](/docs/auth/userpass) to log in with Vault. + method](/vault/docs/auth/userpass) to log in with Vault. - Setting a parameter with a value of a populated list allows the parameter to contain only those values. @@ -516,8 +516,8 @@ path "secret/foo" { These parameters can be used to set minimums/maximums on TTLs set by clients when requesting that a response be -[wrapped](/docs/concepts/response-wrapping), with a granularity of a -second. These use [duration format strings](/docs/concepts/duration-format). +[wrapped](/vault/docs/concepts/response-wrapping), with a granularity of a +second. These use [duration format strings](/vault/docs/concepts/duration-format). In practice, setting a minimum TTL of one second effectively makes response wrapping mandatory for a particular path. @@ -618,8 +618,8 @@ $ curl \ For more information, please read: -- [Production Hardening](https://learn.hashicorp.com/tutorials/vault/production-hardening) -- [Generating a Root Token](https://learn.hashicorp.com/tutorials/vault/generate-root) +- [Production Hardening](/vault/tutorials/operations/production-hardening) +- [Generating a Root Token](/vault/tutorials/operations/generate-root) ## Managing Policies diff --git a/website/content/docs/concepts/recovery-mode.mdx b/website/content/docs/concepts/recovery-mode.mdx index a564809096..891f77490c 100644 --- a/website/content/docs/concepts/recovery-mode.mdx +++ b/website/content/docs/concepts/recovery-mode.mdx @@ -72,6 +72,6 @@ This means that after having used recovery mode, part of the procedure for returning to active service must include re-forming the raft cluster. There are two ways to do so: either delete the vault data directory on the other nodes and re-join them to the recovered node, or use the -[Manual Recovery Using peers.json](https://www.vaultproject.io/docs/concepts/integrated-storage#manual-recovery-using-peers-json) +[Manual Recovery Using peers.json](/vault/docs/concepts/integrated-storage#manual-recovery-using-peers-json) approach to get all nodes to agree on what nodes are part of the cluster. diff --git a/website/content/docs/concepts/resource-quotas.mdx b/website/content/docs/concepts/resource-quotas.mdx index a06cd19f1e..1ffa28acad 100644 --- a/website/content/docs/concepts/resource-quotas.mdx +++ b/website/content/docs/concepts/resource-quotas.mdx @@ -21,7 +21,7 @@ developers. Vault provides a feature, resource quotas, that allows Vault operators to specify limits on resources used in Vault. Specifically, Vault allows operators to create and configure API rate limits. Users of Vault Enterprise have a second option, alongside -rate limits, [lease-count quotas](/docs/enterprise/lease-count-quotas), which can +rate limits, [lease-count quotas](/vault/docs/enterprise/lease-count-quotas), which can limit the number of leases that can be in use at one time. ## Rate Limit Quotas @@ -49,7 +49,7 @@ to a non-zero value, any client that hits a rate limit threshold will be blocked from all subsequent requests for a duration of `block_interval` seconds. Vault also allows the inspection of the state of rate limiting in a Vault node -through various [metrics](/docs/internals/telemetry#Resource-Quota-Metrics) exposed +through various [metrics](/vault/docs/internals/telemetry#Resource-Quota-Metrics) exposed and through enabling optional audit logging. ## Exempt Routes @@ -75,4 +75,4 @@ step-by-step tutorial. ## API Rate limit quotas can be managed over the HTTP API. Please see -[Rate Limit Quotas API](/api-docs/system/rate-limit-quotas) for more details. +[Rate Limit Quotas API](/vault/api-docs/system/rate-limit-quotas) for more details. diff --git a/website/content/docs/concepts/response-wrapping.mdx b/website/content/docs/concepts/response-wrapping.mdx index b033570297..f0175557d6 100644 --- a/website/content/docs/concepts/response-wrapping.mdx +++ b/website/content/docs/concepts/response-wrapping.mdx @@ -25,7 +25,7 @@ in persistent storage, you cannot encrypt this key in transit. To help address this problem, Vault includes a feature called _response wrapping_. When requested, Vault can take the response it would have sent to an HTTP client and instead insert it into the -[`cubbyhole`](/docs/secrets/cubbyhole) of a single-use token, +[`cubbyhole`](/vault/docs/secrets/cubbyhole) of a single-use token, returning that single-use token instead. Logically speaking, the response is @@ -134,7 +134,7 @@ If a client requests wrapping: 5. The new response is returned to the caller Note that policies can control minimum/maximum wrapping TTLs; see the [policies -concepts page](/docs/concepts/policies) for +concepts page](/vault/docs/concepts/policies) for more information. ## Response-Wrapping Token Validation diff --git a/website/content/docs/concepts/seal.mdx b/website/content/docs/concepts/seal.mdx index 1fde9ab6ef..37125ae8cb 100644 --- a/website/content/docs/concepts/seal.mdx +++ b/website/content/docs/concepts/seal.mdx @@ -88,7 +88,7 @@ access to the root key shares. -> **Note:** The Seal Wrap functionality is enabled by default. For this reason, the seal provider (HSM or cloud KMS) must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal -Wrap](/docs/enterprise/sealwrap) documentation for more information. +Wrap](/vault/docs/enterprise/sealwrap) documentation for more information. Auto Unseal was developed to aid in reducing the operational complexity of keeping the unseal key secure. This feature delegates the responsibility of @@ -117,7 +117,7 @@ Unseal requires the recovery key fragments instead of the unseal key fragments that would be provided with Shamir. The process remains the same. For a list of examples and supported providers, please see the -[seal documentation](/docs/configuration/seal). +[seal documentation](/vault/docs/configuration/seal). ## Recovery Key @@ -133,7 +133,7 @@ keys for this purpose, rather than the barrier unseal keys, is automatic. ### Initialization When initializing, the split is performed according to the following CLI flags -and their API equivalents in the [/sys/init](/api-docs/system/init) endpoint: +and their API equivalents in the [/sys/init](/vault/api-docs/system/init) endpoint: - `recovery-shares`: The number of shares into which to split the recovery key. This value is equivalent to the `recovery_shares` value in the API @@ -148,7 +148,7 @@ and their API equivalents in the [/sys/init](/api-docs/system/init) endpoint: Additionally, Vault will refuse to initialize if the option has not been set to generate a key, and no key is found. See -[Configuration](/docs/configuration/seal/pkcs11) for more details. +[Configuration](/vault/docs/configuration/seal/pkcs11) for more details. ### Rekeying @@ -168,7 +168,7 @@ this is performed by using the `-target=recovery` flag to `vault operator rekey` Via the API, the rekey operation is performed with the same parameters as the [normal `/sys/rekey` -endpoint](/api-docs/system/rekey); however, the +endpoint](/vault/api-docs/system/rekey); however, the API prefix for this operation is at `/sys/rekey-recovery-key` rather than `/sys/rekey`. @@ -201,7 +201,7 @@ These steps are common for seal migrations between any supported kinds and for any storage backend. 1. Take a standby node down and update the [seal - configuration](/docs/configuration/seal). + configuration](/vault/docs/configuration/seal). - If the migration is from Shamir seal to Auto seal, add the desired new Auto seal block to the configuration. @@ -224,7 +224,7 @@ any storage backend. specifically when Integrated Storage is in use for it helps to retain the quorum. -1. [Step down](https://www.vaultproject.io/docs/commands/operator/step-down) the +1. [Step down](/vault/docs/commands/operator/step-down) the active node. One of the standby nodes will become the new active node. When using Integrated Storage, ensure that quorum is reached and a leader is elected. @@ -250,7 +250,7 @@ any storage backend. #### Migration From Shamir to Auto Unseal To migrate from Shamir keys to Auto Unseal, take your server cluster offline and -update the [seal configuration](/docs/configuration/seal) with the appropriate +update the [seal configuration](/vault/docs/configuration/seal) with the appropriate seal configuration. Bring your server back up and leave the rest of the nodes offline if using multi-server mode, then run the unseal process with the `-migrate` flag and bring the rest of the cluster online. @@ -264,7 +264,7 @@ keys. #### Migration From Auto Unseal to Shamir To migrate from Auto Unseal to Shamir keys, take your server cluster offline -and update the [seal configuration](/docs/configuration/seal) and add `disabled +and update the [seal configuration](/vault/docs/configuration/seal) and add `disabled = "true"` to the seal block. This allows the migration to use this information to decrypt the key but will not unseal Vault. When you bring your server back up, run the unseal process with the `-migrate` flag and use the Recovery Keys @@ -280,7 +280,7 @@ one type of Auto Unseal to a different type (ie Transit -> AWSKMS). To migrate from Auto Unseal to a different Auto Unseal configuration, take your server cluster offline and update the existing [seal -configuration](/docs/configuration/seal) and add `disabled = "true"` to the seal +configuration](/vault/docs/configuration/seal) and add `disabled = "true"` to the seal block. Then add another seal block to describe the new seal. When you bring your server back up, run the unseal process with the `-migrate` diff --git a/website/content/docs/concepts/storage.mdx b/website/content/docs/concepts/storage.mdx index c4f61facc8..a909301088 100644 --- a/website/content/docs/concepts/storage.mdx +++ b/website/content/docs/concepts/storage.mdx @@ -8,7 +8,7 @@ description: >- # Storage -As described on our [Architecture](/docs/internals/architecture) page, Vault's +As described on our [Architecture](/vault/docs/internals/architecture) page, Vault's storage backend is untrusted storage used purely to keep encrypted information. ## Supported Storage Backends @@ -16,11 +16,11 @@ storage backend is untrusted storage used purely to keep encrypted information. @include 'ent-supported-storage.mdx' Many other options for storage are available with community support for open-source Vault - see our -[Storage Configuration](/docs/configuration/storage) section for more +[Storage Configuration](/vault/docs/configuration/storage) section for more information. -> **Choosing a storage backend:** Refer to the [integrated storage vs. external -storage](/docs/configuration/storage#integrated-storage-vs-external-storage) +storage](/vault/docs/configuration/storage#integrated-storage-vs-external-storage) section of the storage configuration page to help make a decision about which storage backend to use. @@ -62,12 +62,12 @@ study](https://www.hashicorp.com/resources/oh-no-i-deleted-my-vault-secret). We do not recommend backups as protection against the failure of an individual machine. Vault servers can run in clusters, so to protect against server failure, we recommend running Vault in [HA -mode](/docs/internals/high-availability). With open source features, a +mode](/vault/docs/internals/high-availability). With open source features, a Vault cluster can extend across multiple availability zones within a region. Vault Enterprise supports replicated clusters and disaster recovery for data center failure. When using OSS Vault in [HA -Mode](/docs/internals/high-availability), a backup can help guard against the +Mode](/vault/docs/internals/high-availability), a backup can help guard against the failure of a data center. Ultimately, backups are not a replacement for running in HA, or for using @@ -80,8 +80,8 @@ 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://developer.hashicorp.com/consul/commands/snapshot) or [Integrated -Storage](/docs/commands/operator/raft#snapshot)). +[Consul](/consul/commands/snapshot) or [Integrated +Storage](/vault/docs/commands/operator/raft#snapshot)). ~> If your storage backend does not support atomic snapshots, we recommend only taking offline backups. @@ -91,13 +91,13 @@ HashiCorp-supported storage backend, see the instructions linked below. For 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://developer.hashicorp.com/consul/commands/snapshot) +- Integrated Storage [snapshots](/vault/docs/commands/operator/raft#snapshot) +- Consul [snapshots](/consul/commands/snapshot) #### Backing up Multiple Clusters If you are using Vault Enterprise [Performance -Replication](/docs/enterprise/replication#performance-replication-and-disaster-recovery-dr-replication), +Replication](/vault/docs/enterprise/replication#performance-replication-and-disaster-recovery-dr-replication), you should plan to take backups of the active node on each of your clusters. ### Configuration diff --git a/website/content/docs/concepts/tokens.mdx b/website/content/docs/concepts/tokens.mdx index 8eada9daed..29b9981e61 100644 --- a/website/content/docs/concepts/tokens.mdx +++ b/website/content/docs/concepts/tokens.mdx @@ -9,7 +9,7 @@ description: Tokens are a core auth method in Vault. Concepts and important feat !> **Warning**: Since tokens are considered opaque values, their structure is undocumented and subject to change. For these reasons, we do not recommend using tokens within your scripts or for automation since it can cause breakage. Tokens are the core method for _authentication_ within Vault. Tokens -can be used directly or [auth methods](/docs/concepts/auth) +can be used directly or [auth methods](/vault/docs/concepts/auth) can be used to dynamically generate tokens based on external identities. If you've gone through the getting started guide, you probably noticed that @@ -17,20 +17,20 @@ If you've gone through the getting started guide, you probably noticed that initial "root token." This is the first method of authentication for Vault. It is also the only auth method that cannot be disabled. -As stated in the [authentication concepts](/docs/concepts/auth), +As stated in the [authentication concepts](/vault/docs/concepts/auth), all external authentication mechanisms, such as GitHub, map down to dynamically created tokens. These tokens have all the same properties as a normal manually created token. Within Vault, tokens map to information. The most important information mapped to a token is a set of one or more attached -[policies](/docs/concepts/policies). These policies control what the token +[policies](/vault/docs/concepts/policies). These policies control what the token holder is allowed to do within Vault. Other mapped information includes metadata that can be viewed and is added to the audit log, such as creation time, last renewal time, and more. Read on for a deeper dive into token concepts. See the -[tokens tutorial](https://learn.hashicorp.com/tutorials/vault/tokens) +[tokens tutorial](/vault/tutorials/tokens/tokens) for details on how these concepts play out in practice. ## Token Types @@ -45,7 +45,7 @@ their applicability to batch tokens is discussed later. Often in documentation or in help channels, the "token store" is referenced. This is the same as the [`token` authentication -backend](/docs/auth/token). This is a special +backend](/vault/docs/auth/token). This is a special backend in that it is responsible for creating and storing tokens, and cannot be disabled. It is also the only auth method that has no login capability -- all actions require existing authenticated tokens. @@ -62,7 +62,7 @@ there are only three ways to create root tokens: expiration 1. By using another root token; a root token with an expiration cannot create a root token that never expires -1. By using `vault operator generate-root` ([example](https://learn.hashicorp.com/tutorials/vault/generate-root)) +1. By using `vault operator generate-root` ([example](/vault/tutorials/operations/generate-root)) with the permission of a quorum of unseal key holders Root tokens are useful in development but should be extremely carefully guarded @@ -71,7 +71,7 @@ used for just enough initial setup (usually, setting up auth methods and policies necessary to allow administrators to acquire more limited tokens) or in emergencies, and are revoked immediately after they are no longer needed. If a new root token is needed, the `operator generate-root` command and associated -[API endpoint](/api-docs/system/generate-root) can be used to generate one on-the-fly. +[API endpoint](/vault/api-docs/system/generate-root) can be used to generate one on-the-fly. It is also good security practice for there to be multiple eyes on a terminal whenever a root token is live. This way multiple people can verify as to the @@ -160,7 +160,7 @@ token's information is looked up. It is based on a combination of factors: 1. The system max TTL, which is 32 days but can be changed in Vault's configuration file. 1. The max TTL set on a mount using [mount - tuning](/api-docs/system/mounts). This value + tuning](/vault/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. 1. A value suggested by the auth method that issued the token. This diff --git a/website/content/docs/concepts/user-lockout.mdx b/website/content/docs/concepts/user-lockout.mdx index 6f769cb5cd..1ecbb66cbb 100644 --- a/website/content/docs/concepts/user-lockout.mdx +++ b/website/content/docs/concepts/user-lockout.mdx @@ -27,11 +27,11 @@ Configuration for "all" auth methods in config file >> Default values. ## Configuration User lockout parameters can be configured using config file for "all" auth methods or a specific auth method (userpass, ldap, or approle). -Please see [user lockout configuration](/docs/configuration/user-lockout#user_lockout-stanza) for more details. +Please see [user lockout configuration](/vault/docs/configuration/user-lockout#user_lockout-stanza) for more details. -The user lockout configuration for the auth method at a given path can be tuned using auth tune. Please see [auth tune command](/docs/commands/auth/tune) -or [auth tune api](/api-docs/system/auth#tune-auth-method) for more details. +The user lockout configuration for the auth method at a given path can be tuned using auth tune. Please see [auth tune command](/vault/docs/commands/auth/tune) +or [auth tune api](/vault/api-docs/system/auth#tune-auth-method) for more details. ## API -Please see [sys/locked-users API](/api-docs/system/user-lockout) for more details. \ No newline at end of file +Please see [sys/locked-users API](/vault/api-docs/system/user-lockout) for more details. \ No newline at end of file diff --git a/website/content/docs/concepts/username-templating.mdx b/website/content/docs/concepts/username-templating.mdx index 034e828b17..53acabb870 100644 --- a/website/content/docs/concepts/username-templating.mdx +++ b/website/content/docs/concepts/username-templating.mdx @@ -73,7 +73,7 @@ number indicating how many characters to generate.
Each secret engine provides a different set of data to the template. Please see the associated secret engine's documentation for details on what values are provided to the template. The examples below are modeled after the -[Database engine's](/docs/secrets/databases) data, however the specific fields that are provided from a given engine +[Database engine's](/vault/docs/secrets/databases) data, however the specific fields that are provided from a given engine may differ from these examples. Additionally, the time is assumed to be 2009-02-13 11:31:30PM GMT (unix timestamp: 1234567890) and random characters are the ordered english alphabet: `abcdefghijklmnopqrstuvwxyz`. @@ -154,5 +154,5 @@ each field. This results in `v_token-wi_my_custo_abcdefghijklmnopqrst_1234567890 Refer to the following tutorials for step-by-step instructions. -- [Database Secrets Engine with MongoDB](https://learn.hashicorp.com/tutorials/vault/database-mongodb#customize-the-generated-username-schema) -- [Dynamic Secrets: Database Secrets Engine](https://learn.hashicorp.com/tutorials/vault/database-secrets#define-a-username-template) +- [Database Secrets Engine with MongoDB](/vault/tutorials/db-credentials/database-mongodb#customize-the-generated-username-schema) +- [Dynamic Secrets: Database Secrets Engine](/vault/tutorials/db-credentials/database-secrets#define-a-username-template) diff --git a/website/content/docs/configuration/entropy-augmentation.mdx b/website/content/docs/configuration/entropy-augmentation.mdx index df4c980b07..880d375e8b 100644 --- a/website/content/docs/configuration/entropy-augmentation.mdx +++ b/website/content/docs/configuration/entropy-augmentation.mdx @@ -9,9 +9,9 @@ description: >- # `Entropy Augmentation` Seal Entropy augmentation enables Vault to sample entropy from external cryptographic modules. -Sourcing external entropy is done by configuring a supported [Seal](/docs/configuration/seal) type which -include: [PKCS11 seal](/docs/configuration/seal/pkcs11), [AWS KMS](/docs/configuration/seal/awskms), and -[Vault Transit](/docs/configuration/seal/transit). +Sourcing external entropy is done by configuring a supported [Seal](/vault/docs/configuration/seal) type which +include: [PKCS11 seal](/vault/docs/configuration/seal/pkcs11), [AWS KMS](/vault/docs/configuration/seal/awskms), and +[Vault Transit](/vault/docs/configuration/seal/transit). Vault Enterprises's external entropy support is activated by the presence of an `entropy "seal"` block in Vault's configuration file. @@ -22,7 +22,7 @@ A valid Vault Enterprise license is required for Entropy Augmentation. ~> **Warning** This feature is not available with FIPS 140-2 Inside variants of Vault. Additionally, the following software packages and enterprise modules are required for sourcing entropy -via the [PKCS11 seal](/docs/configuration/seal/pkcs11): +via the [PKCS11 seal](/vault/docs/configuration/seal/pkcs11): - Vault Enterprise with the Plus package - PKCS#11 compatible HSM integration library. Vault targets version 2.2 or @@ -55,4 +55,4 @@ These parameters apply to the `entropy` stanza in the Vault configuration file: - `mode` `(string: )`: The mode determines which Vault operations requiring entropy will sample entropy from the external source. Currently, the only mode supported - is `augmentation` which sources entropy for [Critical Security Parameters (CSPs)](/docs/enterprise/entropy-augmentation#critical-security-parameters-csps). + is `augmentation` which sources entropy for [Critical Security Parameters (CSPs)](/vault/docs/enterprise/entropy-augmentation#critical-security-parameters-csps). diff --git a/website/content/docs/configuration/index.mdx b/website/content/docs/configuration/index.mdx index 639bc9a5ec..9e958c5de6 100644 --- a/website/content/docs/configuration/index.mdx +++ b/website/content/docs/configuration/index.mdx @@ -60,7 +60,7 @@ to specify where the configuration is. - `user_lockout` `([UserLockout][user-lockout]: nil)` – Configures the user-lockout behaviour for failed logins. For more information, please see the - [user lockout configuration documentation](/docs/configuration/user-lockout). + [user lockout configuration documentation](/vault/docs/configuration/user-lockout). - `seal` `([Seal][seal]: nil)` – Configures the seal type to use for auto-unsealing, as well as for @@ -80,7 +80,7 @@ to specify where the configuration is. - `disable_mlock` `(bool: false)` – Disables the server from executing the `mlock` syscall. `mlock` prevents memory from being swapped to disk. Disabling - `mlock` is not recommended unless using [integrated storage](/docs/internals/integrated-storage). + `mlock` is not recommended unless using [integrated storage](/vault/docs/internals/integrated-storage). Follow the additional security precautions outlined below when disabling `mlock`. This can also be provided via the environment variable `VAULT_DISABLE_MLOCK`. @@ -92,7 +92,7 @@ to specify where the configuration is. automatically disabled on unsupported platforms. Disabling `mlock` is strongly recommended if using [integrated - storage](/docs/internals/integrated-storage) due to + storage](/vault/docs/internals/integrated-storage) due to the fact that `mlock` does not interact well with memory mapped files such as those created by BoltDB, which is used by Raft to track state. When using `mlock`, memory-mapped files get loaded into resident memory which causes @@ -111,7 +111,7 @@ to specify where the configuration is. ~> Note: Since each plugin runs as a separate process, you need to do the same for each plugin in your [plugins - directory](/docs/plugins/plugin-architecture#plugin-directory). + directory](/vault/docs/plugins/plugin-architecture#plugin-directory). If you use a Linux distribution with a modern version of systemd, you can add the following directive to the "[Service]" configuration section: @@ -146,8 +146,8 @@ to specify where the configuration is. duration for tokens and secrets. This is specified using a label suffix like `"30s"` or `"1h"`. Individual mounts can override this value by tuning the mount with the `max-lease-ttl` flag of the - [auth](/docs/commands/auth/tune#max-lease-ttl) or - [secret](/docs/commands/secrets/tune#max-lease-ttl) commands. + [auth](/vault/docs/commands/auth/tune#max-lease-ttl) or + [secret](/vault/docs/commands/secrets/tune#max-lease-ttl) commands. - `default_max_request_duration` `(string: "90s")` – Specifies the default maximum request duration allowed before Vault cancels the request. This can @@ -169,7 +169,7 @@ a negative effect on performance due to the tracking of each lock attempt. listeners (address + port) at the `/ui` path. Browsers accessing the standard Vault API address will automatically redirect there. This can also be provided via the environment variable `VAULT_UI`. For more information, please see the - [ui configuration documentation](/docs/configuration/ui). + [ui configuration documentation](/vault/docs/configuration/ui). - `pid_file` `(string: "")` - Path to the file in which the Vault server's Process ID (PID) should be stored. @@ -199,21 +199,21 @@ a negative effect on performance due to the tracking of each lock attempt. ~> Note: Not all parts of Vault's logging can have its log level be changed dynamically this way; in particular, secrets/auth plugins are currently not updated dynamically. -- `log_format` - Equivalent to the [`-log-format` command-line flag](/docs/commands/server#_log_format). +- `log_format` - Equivalent to the [`-log-format` command-line flag](/vault/docs/commands/server#_log_format). -- `log_file` - Equivalent to the [`-log-file` command-line flag](/docs/commands/server#_log_file). +- `log_file` - Equivalent to the [`-log-file` command-line flag](/vault/docs/commands/server#_log_file). -- `log_rotate_duration` - Equivalent to the [`-log-rotate-duration` command-line flag](/docs/commands/server#_log_rotate_duration). +- `log_rotate_duration` - Equivalent to the [`-log-rotate-duration` command-line flag](/vault/docs/commands/server#_log_rotate_duration). -- `log_rotate_bytes` - Equivalent to the [`-log-rotate-bytes` command-line flag](/docs/commands/server#_log_rotate_bytes). +- `log_rotate_bytes` - Equivalent to the [`-log-rotate-bytes` command-line flag](/vault/docs/commands/server#_log_rotate_bytes). -- `log_rotate_max_files` - Equivalent to the [`-log-rotate-max-files` command-line flag](/docs/commands/server#_log_rotate_max_files). +- `log_rotate_max_files` - Equivalent to the [`-log-rotate-max-files` command-line flag](/vault/docs/commands/server#_log_rotate_max_files). - `experiments` `(string array: [])` - The list of experiments to enable for this node. Experiments should NOT be used in production, and the associated APIs may have backwards incompatible changes between releases. Additional experiments can also be specified via the `VAULT_EXPERIMENTS` environment variable as a comma-separated list, or via the - [`-experiment`](/docs/commands/server#experiment) flag. + [`-experiment`](/vault/docs/commands/server#experiment) flag. ### High Availability Parameters @@ -259,11 +259,11 @@ The following parameters are only used with Vault Enterprise provided via the environment variable `VAULT_LICENSE_PATH`, or the license itself can be provided in the environment variable `VAULT_LICENSE`. -[storage-backend]: /docs/configuration/storage -[listener]: /docs/configuration/listener -[seal]: /docs/configuration/seal -[sealwrap]: /docs/enterprise/sealwrap -[telemetry]: /docs/configuration/telemetry -[sentinel]: /docs/configuration/sentinel -[high-availability]: /docs/concepts/ha -[plugins]: /docs/plugins +[storage-backend]: /vault/docs/configuration/storage +[listener]: /vault/docs/configuration/listener +[seal]: /vault/docs/configuration/seal +[sealwrap]: /vault/docs/enterprise/sealwrap +[telemetry]: /vault/docs/configuration/telemetry +[sentinel]: /vault/docs/configuration/sentinel +[high-availability]: /vault/docs/concepts/ha +[plugins]: /vault/docs/plugins diff --git a/website/content/docs/configuration/listener/index.mdx b/website/content/docs/configuration/listener/index.mdx index d088982030..868ea1d4fc 100644 --- a/website/content/docs/configuration/listener/index.mdx +++ b/website/content/docs/configuration/listener/index.mdx @@ -13,5 +13,5 @@ respond to requests. At this time, there are two listeners: - [TCP][tcp] - [Unix Domain Socket][unix] -[tcp]: /docs/configuration/listener/tcp -[unix]: /docs/configuration/listener/unix +[tcp]: /vault/docs/configuration/listener/tcp +[unix]: /vault/docs/configuration/listener/unix diff --git a/website/content/docs/configuration/listener/tcp.mdx b/website/content/docs/configuration/listener/tcp.mdx index f152137cd5..9627219673 100644 --- a/website/content/docs/configuration/listener/tcp.mdx +++ b/website/content/docs/configuration/listener/tcp.mdx @@ -26,9 +26,9 @@ advertise the correct address to other nodes. As of version 1.9, Vault supports defining custom HTTP response headers for the root path (`/`) and also on API endpoints (`/v1/*`). The headers are defined based on the returned status code. For example, a user can define a list of custom response headers for the `200` status code, and another list of custom response headers for -the `307` status code. There is a `"/sys/config/ui"` [API endpoint](/api-docs/system/config-ui) which allows users +the `307` status code. There is a `"/sys/config/ui"` [API endpoint](/vault/api-docs/system/config-ui) which allows users to set `UI` specific custom headers. If a header is configured in a configuration file, it is not allowed -to be reconfigured through the `"/sys/config/ui"` [API endpoint](/api-docs/system/config-ui). In cases where a +to be reconfigured through the `"/sys/config/ui"` [API endpoint](/vault/api-docs/system/config-ui). In cases where a custom header value needs to be modified or the custom header needs to be removed, the Vault's configuration file needs to be modified accordingly, and a `SIGHUP` signal needs to be sent to the Vault process. @@ -40,11 +40,11 @@ upon start up indicating the header with `X-Vault-` prefix is not accepted. ### Order of precedence If the same header is configured in both the configuration file and -in the `"/sys/config/ui"` [API endpoint](/api-docs/system/config-ui), the header in the configuration file takes precedence. +in the `"/sys/config/ui"` [API endpoint](/vault/api-docs/system/config-ui), the header in the configuration file takes precedence. For example, the `"Content-Security-Policy"` header is defined by default in the -`"/sys/config/ui"` [API endpoint](/api-docs/system/config-ui). If that header is also defined in the configuration file, +`"/sys/config/ui"` [API endpoint](/vault/api-docs/system/config-ui). If that header is also defined in the configuration file, the value in the configuration file is set in the response headers instead of the -default value in the `"/sys/config/ui"` [API endpoint](/api-docs/system/config-ui). +default value in the `"/sys/config/ui"` [API endpoint](/vault/api-docs/system/config-ui). ## `tcp` Listener Parameters @@ -348,6 +348,6 @@ cluster_addr = "https://[2001:1c04:90d:1c00:a00:27ff:fefa:58ec]:8201" ``` [golang-tls]: https://golang.org/src/crypto/tls/cipher_suites.go -[api-addr]: /docs/configuration#api_addr -[cluster-addr]: /docs/configuration#cluster_addr +[api-addr]: /vault/docs/configuration#api_addr +[cluster-addr]: /vault/docs/configuration#cluster_addr [go-tls-blog]: https://go.dev/blog/tls-cipher-suites diff --git a/website/content/docs/configuration/replication.mdx b/website/content/docs/configuration/replication.mdx index 41c78ce03b..f10d226346 100644 --- a/website/content/docs/configuration/replication.mdx +++ b/website/content/docs/configuration/replication.mdx @@ -45,4 +45,4 @@ replication { - `allow_forwarding_via_token` `(string: "")` - When set to `new_token`, requests sent to non-active nodes are forwarded if the node does not yet have the token information in storage. -Support for Server Side Consistent Tokens is now available. Refer to the [Server Side Consistent Token FAQ](/docs/faq/ssct) for details. +Support for Server Side Consistent Tokens is now available. Refer to the [Server Side Consistent Token FAQ](/vault/docs/faq/ssct) for details. diff --git a/website/content/docs/configuration/seal/alicloudkms.mdx b/website/content/docs/configuration/seal/alicloudkms.mdx index 2c6fcc3ac6..5220acd37a 100644 --- a/website/content/docs/configuration/seal/alicloudkms.mdx +++ b/website/content/docs/configuration/seal/alicloudkms.mdx @@ -10,7 +10,7 @@ description: >- # `alicloudkms` Seal --> **Note:** The Seal Wrap functionality is enabled by default. For this reason, the KMS service must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/docs/enterprise/sealwrap) documenation for more information. +-> **Note:** The Seal Wrap functionality is enabled by default. For this reason, the KMS service must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/vault/docs/enterprise/sealwrap) documenation for more information. The AliCloud KMS seal configures Vault to use AliCloud KMS as the seal wrapping mechanism. @@ -63,7 +63,7 @@ These parameters apply to the `seal` stanza in the Vault configuration file: - `disabled` `(string: "")`: Set this to `true` if Vault is migrating from an auto seal configuration. Otherwise, set to `false`. -Refer to the [Seal Migration](/docs/concepts/seal#seal-migration) documentation for more information about the seal migration process. +Refer to the [Seal Migration](/vault/docs/concepts/seal#seal-migration) documentation for more information about the seal migration process. ## Authentication diff --git a/website/content/docs/configuration/seal/awskms.mdx b/website/content/docs/configuration/seal/awskms.mdx index 62af6351db..92d9ece1c5 100644 --- a/website/content/docs/configuration/seal/awskms.mdx +++ b/website/content/docs/configuration/seal/awskms.mdx @@ -8,7 +8,7 @@ description: |- # `awskms` Seal --> **Note:** The Seal Wrap functionality is enabled by default. For this reason, the KMS service must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/docs/enterprise/sealwrap) documenation for more information. +-> **Note:** The Seal Wrap functionality is enabled by default. For this reason, the KMS service must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/vault/docs/enterprise/sealwrap) documenation for more information. The AWS KMS seal configures Vault to use AWS KMS as the seal wrapping mechanism. The AWS KMS seal is activated by one of the following: @@ -67,7 +67,7 @@ These parameters apply to the `seal` stanza in the Vault configuration file: Endpoint](https://docs.aws.amazon.com/kms/latest/developerguide/kms-vpc-endpoint.html). If not set, Vault will use the default API endpoint for your region. -Refer to the [Seal Migration](/docs/concepts/seal#seal-migration) documentation for more information about the seal migration process. +Refer to the [Seal Migration](/vault/docs/concepts/seal#seal-migration) documentation for more information about the seal migration process. ## Authentication diff --git a/website/content/docs/configuration/seal/azurekeyvault.mdx b/website/content/docs/configuration/seal/azurekeyvault.mdx index 5433e24b1e..817a674066 100644 --- a/website/content/docs/configuration/seal/azurekeyvault.mdx +++ b/website/content/docs/configuration/seal/azurekeyvault.mdx @@ -10,7 +10,7 @@ description: >- # `azurekeyvault` Seal --> **Note:** The Seal Wrap functionality is enabled by default. For this reason, the KMS service must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/docs/enterprise/sealwrap) documenation for more information. +-> **Note:** The Seal Wrap functionality is enabled by default. For this reason, the KMS service must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/vault/docs/enterprise/sealwrap) documenation for more information. The Azure Key Vault seal configures Vault to use Azure Key Vault as the seal wrapping mechanism. The Azure Key Vault seal is activated by one of the following: @@ -65,7 +65,7 @@ These parameters apply to the `seal` stanza in the Vault configuration file: - `disabled` `(string: "")`: Set this to `true` if Vault is migrating from an auto seal configuration. Otherwise, set to `false`. -Refer to the [Seal Migration](/docs/concepts/seal#seal-migration) documentation for more information about the seal migration process. +Refer to the [Seal Migration](/vault/docs/concepts/seal#seal-migration) documentation for more information about the seal migration process. ## Authentication diff --git a/website/content/docs/configuration/seal/gcpckms.mdx b/website/content/docs/configuration/seal/gcpckms.mdx index e3d70a877d..c60decf524 100644 --- a/website/content/docs/configuration/seal/gcpckms.mdx +++ b/website/content/docs/configuration/seal/gcpckms.mdx @@ -10,7 +10,7 @@ description: >- # `gcpckms` Seal --> **Note:** The Seal Wrap functionality is enabled by default. For this reason, the KMS service must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/docs/enterprise/sealwrap) documenation for more information. +-> **Note:** The Seal Wrap functionality is enabled by default. For this reason, the KMS service must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/vault/docs/enterprise/sealwrap) documenation for more information. The GCP Cloud KMS seal configures Vault to use GCP Cloud KMS as the seal wrapping mechanism. The GCP Cloud KMS seal is activated by one of the following: @@ -62,7 +62,7 @@ These parameters apply to the `seal` stanza in the Vault configuration file: - `disabled` `(string: "")`: Set this to `true` if Vault is migrating from an auto seal configuration. Otherwise, set to `false`. -Refer to the [Seal Migration](/docs/concepts/seal#seal-migration) documentation for more information about the seal migration process. +Refer to the [Seal Migration](/vault/docs/concepts/seal#seal-migration) documentation for more information about the seal migration process. ## Authentication & Permissions diff --git a/website/content/docs/configuration/seal/index.mdx b/website/content/docs/configuration/seal/index.mdx index 01a82f8ff6..63d09e2e5d 100644 --- a/website/content/docs/configuration/seal/index.mdx +++ b/website/content/docs/configuration/seal/index.mdx @@ -43,4 +43,4 @@ seal "pkcs11" { For configuration options which also read an environment variable, the environment variable will take precedence over values in the configuration file. -[sealwrap]: /docs/enterprise/sealwrap +[sealwrap]: /vault/docs/enterprise/sealwrap diff --git a/website/content/docs/configuration/seal/ocikms.mdx b/website/content/docs/configuration/seal/ocikms.mdx index 4013048e4a..c534e555bf 100644 --- a/website/content/docs/configuration/seal/ocikms.mdx +++ b/website/content/docs/configuration/seal/ocikms.mdx @@ -8,7 +8,7 @@ description: |- # `ocikms` Seal --> **Note:** The Seal Wrap functionality is enabled by default. For this reason, the KMS service must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/docs/enterprise/sealwrap) documenation for more information. +-> **Note:** The Seal Wrap functionality is enabled by default. For this reason, the KMS service must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/vault/docs/enterprise/sealwrap) documenation for more information. The OCI KMS seal configures Vault to use OCI KMS as the seal wrapping mechanism. The OCI KMS seal is activated by one of the following: @@ -51,14 +51,14 @@ These parameters apply to the `seal` stanza in the Vault configuration file: - `disabled` `(string: "")`: Set this to `true` if Vault is migrating from an auto seal configuration. Otherwise, set to `false`. -Refer to the [Seal Migration](/docs/concepts/seal#seal-migration) documentation for more information about the seal migration process. +Refer to the [Seal Migration](/vault/docs/concepts/seal#seal-migration) documentation for more information about the seal migration process. ## Authentication Authentication-related values must be provided, either as environment variables or as configuration parameters. -If you want to use Instance Principal, add section configuration below and add further configuration settings as detailed in the [configuration docs](/docs/configuration/). +If you want to use Instance Principal, add section configuration below and add further configuration settings as detailed in the [configuration docs](/vault/docs/configuration/). ```hcl seal "ocikms" { diff --git a/website/content/docs/configuration/seal/pkcs11.mdx b/website/content/docs/configuration/seal/pkcs11.mdx index c743cd3d42..05e9ed5963 100644 --- a/website/content/docs/configuration/seal/pkcs11.mdx +++ b/website/content/docs/configuration/seal/pkcs11.mdx @@ -8,7 +8,7 @@ description: |- # `pkcs11` Seal --> **Note:** The Seal Wrap functionality is enabled by default. For this reason, HSM must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/docs/enterprise/sealwrap) documentation for more information. +-> **Note:** The Seal Wrap functionality is enabled by default. For this reason, HSM must be available throughout Vault's runtime and not just during the unseal process. Refer to the [Seal Wrap](/vault/docs/enterprise/sealwrap) documentation for more information. The PKCS11 seal configures Vault to use an HSM with PKCS11 as the seal wrapping mechanism. Vault Enterprise's HSM PKCS11 support is activated by one of the @@ -154,7 +154,7 @@ These parameters apply to the `seal` stanza in the Vault configuration file: - `disabled` `(string: "")`: Set this to `true` if Vault is migrating from an auto seal configuration. Otherwise, set to `false`. -Refer to the [Seal Migration](/docs/concepts/seal#seal-migration) documentation for more information about the seal migration process. +Refer to the [Seal Migration](/vault/docs/concepts/seal#seal-migration) documentation for more information about the seal migration process. ### Mechanism Specific Flags diff --git a/website/content/docs/configuration/seal/transit.mdx b/website/content/docs/configuration/seal/transit.mdx index 1c7e12aae8..3db075f777 100644 --- a/website/content/docs/configuration/seal/transit.mdx +++ b/website/content/docs/configuration/seal/transit.mdx @@ -89,7 +89,7 @@ These parameters apply to the `seal` stanza in the Vault configuration file: - `disabled` `(string: "")`: Set this to `true` if Vault is migrating from an auto seal configuration. Otherwise, set to `false`. -Refer to the [Seal Migration](/docs/concepts/seal#seal-migration) documentation for more information about the seal migration process. +Refer to the [Seal Migration](/vault/docs/concepts/seal#seal-migration) documentation for more information about the seal migration process. ## Authentication @@ -114,15 +114,15 @@ path "/decrypt/" { ``` Other considerations for the token used: -* it should probably be an [orphan token](/docs/concepts/tokens#token-hierarchies-and-orphan-tokens), +* it should probably be an [orphan token](/vault/docs/concepts/tokens#token-hierarchies-and-orphan-tokens), otherwise when the parent token expires or gets revoked the seal will break. -* consider making it a [periodic token](/docs/concepts/tokens#periodic-tokens) +* consider making it a [periodic token](/vault/docs/concepts/tokens#periodic-tokens) and not setting an explicit max TTL, otherwise at some point it will cease to be renewable. ## Key Rotation This seal supports key rotation using the Transit Secret Engine's key rotation endpoints. See -[doc](/api-docs/secret/transit#rotate-key). Old keys must not be disabled or deleted and are +[doc](/vault/api-docs/secret/transit#rotate-key). Old keys must not be disabled or deleted and are used to decrypt older data. ## Tutorial diff --git a/website/content/docs/configuration/sentinel.mdx b/website/content/docs/configuration/sentinel.mdx index 50c5bfa18b..5a61f5dedd 100644 --- a/website/content/docs/configuration/sentinel.mdx +++ b/website/content/docs/configuration/sentinel.mdx @@ -8,7 +8,7 @@ description: |- # `sentinel` Stanza The sentinel stanza specifies configurations for -[Vault's Sentinel](https://www.vaultproject.io/docs/enterprise/sentinel) integration. +[Vault's Sentinel](/vault/docs/enterprise/sentinel) integration. ```hcl sentinel { diff --git a/website/content/docs/configuration/service-registration/consul.mdx b/website/content/docs/configuration/service-registration/consul.mdx index 0795babc12..eab82c0a23 100644 --- a/website/content/docs/configuration/service-registration/consul.mdx +++ b/website/content/docs/configuration/service-registration/consul.mdx @@ -93,17 +93,17 @@ connection. You can read more about encrypting Consul connections on the - `tls_ca_file` `(string: "")` – Specifies the path to the CA certificate used for Consul communication. This defaults to system bundle if not specified. This should be set according to the - [`ca_file`](https://developer.hashicorp.com/consul/docs/agent/config/config-files#ca_file) setting in + [`ca_file`](/consul/docs/agent/config/config-files#ca_file) setting in Consul. - `tls_cert_file` `(string: "")` (optional) – Specifies the path to the certificate for Consul communication. This should be set according to the - [`cert_file`](https://developer.hashicorp.com/consul/docs/agent/config/config-files#cert_file) setting + [`cert_file`](/consul/docs/agent/config/config-files#cert_file) setting in Consul. - `tls_key_file` `(string: "")` – Specifies the path to the private key for Consul communication. This should be set according to the - [`key_file`](https://developer.hashicorp.com/consul/docs/agent/config/config-files#key_file) setting + [`key_file`](/consul/docs/agent/config/config-files#key_file) setting in Consul. - `tls_min_version` `(string: "tls12")` – Specifies the minimum TLS version to @@ -176,6 +176,6 @@ service_registration "consul" { ``` [consul]: https://www.consul.io/ 'Consul by HashiCorp' -[consul-acl]: https://www.consul.io/docs/guides/acl.html 'Consul ACLs' -[consul-encryption]: https://www.consul.io/docs/agent/encryption.html 'Consul Encryption' -[consul-translate-wan-addrs]: https://www.consul.io/docs/agent/options.html#translate_wan_addrs 'Consul Configuration' +[consul-acl]: /consul/docs/guides/acl 'Consul ACLs' +[consul-encryption]: /consul/docs/agent/encryption 'Consul Encryption' +[consul-translate-wan-addrs]: /consul/docs/agent/options#translate_wan_addrs 'Consul Configuration' diff --git a/website/content/docs/configuration/service-registration/index.mdx b/website/content/docs/configuration/service-registration/index.mdx index daaf2d8bde..1bd5cf4663 100644 --- a/website/content/docs/configuration/service-registration/index.mdx +++ b/website/content/docs/configuration/service-registration/index.mdx @@ -60,8 +60,8 @@ file. [consul]: https://www.consul.io/ [consul-discovery]: https://www.consul.io/ -[storage-backend]: /docs/configuration/storage -[consul-backend]: /docs/configuration/storage/consul -[raft-backend]: /docs/configuration/storage/raft -[consul-service-registration]: /docs/configuration/service-registration/consul -[kubernetes-service-registration]: /docs/configuration/service-registration/kubernetes +[storage-backend]: /vault/docs/configuration/storage +[consul-backend]: /vault/docs/configuration/storage/consul +[raft-backend]: /vault/docs/configuration/storage/raft +[consul-service-registration]: /vault/docs/configuration/service-registration/consul +[kubernetes-service-registration]: /vault/docs/configuration/service-registration/kubernetes diff --git a/website/content/docs/configuration/service-registration/kubernetes.mdx b/website/content/docs/configuration/service-registration/kubernetes.mdx index 7db97a82f6..0eb7403187 100644 --- a/website/content/docs/configuration/service-registration/kubernetes.mdx +++ b/website/content/docs/configuration/service-registration/kubernetes.mdx @@ -10,7 +10,7 @@ description: >- Kubernetes Service Registration tags Vault pods with their current status for use with selectors. Service registration is only available when Vault is running in -[High Availability mode](/docs/concepts/ha). +[High Availability mode](/vault/docs/concepts/ha). - **HashiCorp Supported** – Kubernetes Service Registration is officially supported by HashiCorp. diff --git a/website/content/docs/configuration/storage/consul.mdx b/website/content/docs/configuration/storage/consul.mdx index 96713dc0bb..00d3607087 100644 --- a/website/content/docs/configuration/storage/consul.mdx +++ b/website/content/docs/configuration/storage/consul.mdx @@ -76,7 +76,7 @@ and [`cluster_addr`][cluster-addr] ([example][listener-example]). - `max_parallel` `(string: "128")` – Specifies the maximum number of concurrent requests to Consul. Make sure that your Consul agents are configured to support this level of parallelism, see - [http_max_conns_per_client](https://developer.hashicorp.com/consul/docs/agent/config/config-files#http_max_conns_per_client). + [http_max_conns_per_client](/consul/docs/agent/config/config-files#http_max_conns_per_client). - `path` `(string: "vault/")` – Specifies the path in Consul's key-value store where Vault data will be stored. @@ -122,17 +122,17 @@ connection. You can read more about encrypting Consul connections on the - `tls_ca_file` `(string: "")` – Specifies the path to the CA certificate used for Consul communication. This defaults to system bundle if not specified. This should be set according to the - [`ca_file`](https://developer.hashicorp.com/consul/docs/agent/config/config-files#ca_file) setting in + [`ca_file`](/consul/docs/agent/config/config-files#ca_file) setting in Consul. - `tls_cert_file` `(string: "")` (optional) – Specifies the path to the certificate for Consul communication. This should be set according to the - [`cert_file`](https://developer.hashicorp.com/consul/docs/agent/config/config-files#cert_file) setting + [`cert_file`](/consul/docs/agent/config/config-files#cert_file) setting in Consul. - `tls_key_file` `(string: "")` – Specifies the path to the private key for Consul communication. This should be set according to the - [`key_file`](https://developer.hashicorp.com/consul/docs/agent/config/config-files#key_file) setting + [`key_file`](/consul/docs/agent/config/config-files#key_file) setting in Consul. - `tls_min_version` `(string: "tls12")` – Specifies the minimum TLS version to @@ -260,12 +260,12 @@ storage "consul" { ``` [consul]: https://www.consul.io/ 'Consul by HashiCorp' -[consul-acl]: https://www.consul.io/docs/guides/acl.html 'Consul ACLs' -[consul-consistency]: https://www.consul.io/api-docs/features/consistency 'Consul Consistency Modes' -[consul-encryption]: https://www.consul.io/docs/agent/encryption.html 'Consul Encryption' -[consul-translate-wan-addrs]: https://www.consul.io/docs/agent/options.html#translate_wan_addrs 'Consul Configuration' -[consul-token]: https://www.consul.io/docs/commands/acl/set-agent-token.html#token-lt-value-gt- 'Consul Token' -[consul-session-ttl]: https://www.consul.io/docs/agent/options.html#session_ttl_min 'Consul Configuration' -[api-addr]: /docs/configuration#api_addr -[cluster-addr]: /docs/configuration#cluster_addr -[listener-example]: /docs/configuration/listener/tcp#listening-on-multiple-interfaces +[consul-acl]: /consul/docs/guides/acl 'Consul ACLs' +[consul-consistency]: /consul/api-docs/features/consistency 'Consul Consistency Modes' +[consul-encryption]: /consul/docs/agent/encryption 'Consul Encryption' +[consul-translate-wan-addrs]: /consul/docs/agent/options#translate_wan_addrs 'Consul Configuration' +[consul-token]: /consul/docs/commands/acl/set-agent-token#token-lt-value-gt- 'Consul Token' +[consul-session-ttl]: /consul/docs/agent/options#session_ttl_min 'Consul Configuration' +[api-addr]: /vault/docs/configuration#api_addr +[cluster-addr]: /vault/docs/configuration#cluster_addr +[listener-example]: /vault/docs/configuration/listener/tcp#listening-on-multiple-interfaces diff --git a/website/content/docs/configuration/storage/etcd.mdx b/website/content/docs/configuration/storage/etcd.mdx index 00665513af..d7a5fe5532 100644 --- a/website/content/docs/configuration/storage/etcd.mdx +++ b/website/content/docs/configuration/storage/etcd.mdx @@ -16,9 +16,9 @@ based on the version of the Etcd cluster. ~> The Etcd v2 API has been deprecated with the release of Etcd v3.5, and will be decommissioned by Etcd v3.6. It will be removed from Vault in Vault 1.10. Users of the Etcd storage backend should prepare to -[migrate](/docs/commands/operator/migrate) Vault storage to an Etcd v3 cluster +[migrate](/vault/docs/commands/operator/migrate) Vault storage to an Etcd v3 cluster prior to upgrading to Vault 1.10. All storage migrations should have -[backups](/docs/concepts/storage#backing-up-vault-s-persisted-data) taken prior +[backups](/vault/docs/concepts/storage#backing-up-vault-s-persisted-data) taken prior to migration. - **High Availability** – the Etcd storage backend supports high availability. diff --git a/website/content/docs/configuration/storage/index.mdx b/website/content/docs/configuration/storage/index.mdx index e21d83f7ee..fbb00a5b29 100644 --- a/website/content/docs/configuration/storage/index.mdx +++ b/website/content/docs/configuration/storage/index.mdx @@ -44,7 +44,7 @@ file. ## Integrated Storage vs. External Storage HashiCorp recommends using Vault's [integrated -storage](/docs/configuration/storage/raft) for most use cases rather than +storage](/vault/docs/configuration/storage/raft) for most use cases rather than configuring another system to store Vault data externally. (Integrated Storage is an **embedded Vault data storage** available in Vault 1.4 or later.) Prior to Vault 1.4, Consul was the recommended Vault storage. @@ -52,7 +52,7 @@ an **embedded Vault data storage** available in Vault 1.4 or later.) Prior to Va use Integrated Storage as their storage backend. The table below compares the characteristics of Integrated Storage and External -Storage. Suppose you decide that the additional operational complexity of external storage is worth it for your use case. In that case, there are several external storage options to choose from (e.g., [Consul](/docs/configuration/storage/consul), [DynamoDB](/docs/configuration/storage/dynamodb), etc.). +Storage. Suppose you decide that the additional operational complexity of external storage is worth it for your use case. In that case, there are several external storage options to choose from (e.g., [Consul](/vault/docs/configuration/storage/consul), [DynamoDB](/vault/docs/configuration/storage/dynamodb), etc.). | | Integrated Storage | External Storage | | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -61,36 +61,36 @@ Storage. Suppose you decide that the additional operational complexity of extern | Networking | One less network hop. | Extra network hop between Vault and the external storage system (e.g., Consul cluster). | | Troubleshooting and monitoring | Integrated Storage is a part of Vault; therefore, Vault is the only system you need to monitor and troubleshoot. | The source of failure could be the external storage; therefore, you need to check the health of both Vault and the external storage. This requires expertise in the chosen storage backend and additional monitoring of that storage. | | Data location | The encrypted Vault data is stored on the same host where the Vault server process runs. | The encrypted Vault data is stored where the external storage is located. Therefore, the Vault server and the data storage are hosted on physically separate hosts. | -| System requirements | Avoid "burstable" CPU and storage options. SSDs should be used for the hard drive.

See the [Reference Architecture](https://learn.hashicorp.com/tutorials/vault/raft-reference-architecture#system-requirements) guide. | Follow the system requirements given by your chosen storage backend. | +| System requirements | Avoid "burstable" CPU and storage options. SSDs should be used for the hard drive.

See the [Reference Architecture](/vault/tutorials/day-one-raft/raft-reference-architecture#system-requirements) guide. | Follow the system requirements given by your chosen storage backend. | ### Integrated Storage vs. Consul as Vault Storage -[HashiCorp Consul](https://developer.hashicorp.com/consul/docs/intro) is a comprehensive +[HashiCorp Consul](/consul/docs/intro) is a comprehensive multi-cloud service networking solution including service mesh, service discovery, and network infrastructure automation. Vault can leverage -Consul's [KV Store](https://developer.hashicorp.com/consul/api-docs/kv) to persist Vault data. +Consul's [KV Store](/consul/api-docs/kv) to persist Vault data. The table below highlights the differences between Integrated Storage and Consul. | | Integrated Storage | Consul | | ------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Deployment | Vault cluster is all you need. | Vault cluster & Consul cluster.

Use a dedicated Consul cluster for Vault storage, and it should not be used for other purposes (e.g., service discovery, service mesh).

See the [Vault with Consul Storage Reference Architecture](https://learn.hashicorp.com/tutorials/vault/reference-architecture#recommended-architecture) guide. | +| Deployment | Vault cluster is all you need. | Vault cluster & Consul cluster.

Use a dedicated Consul cluster for Vault storage, and it should not be used for other purposes (e.g., service discovery, service mesh).

See the [Vault with Consul Storage Reference Architecture](/vault/tutorials/day-one-consul/reference-architecture#recommended-architecture) guide. | | 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) | +| System requirements | [System requirements](/vault/tutorials/day-one-raft/raft-reference-architecture#system-requirements) | [System requirements](/vault/tutorials/day-one-consul/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://developer.hashicorp.com/consul/docs/agent/config/config-files#kv_max_value_size) parameter) | +| Max message size | 1 MiB (Configurable using the [`max_entry_size`](/vault/docs/configuration/storage/raft#max_entry_size) parameter) | 512 KiB (Configurable using the [`kv_max_value_size`](/consul/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: 1. [Preflight Checklist - Migrating to Integrated - Storage](https://learn.hashicorp.com/tutorials/vault/storage-migration-checklist) + Storage](/vault/tutorials/raft/storage-migration-checklist) 1. [Storage Migration tutorial - Consul to Integrated - Storage](https://learn.hashicorp.com/tutorials/vault/raft-migration) + Storage](/vault/tutorials/raft/raft-migration) ## Tutorial Refer to the [Integrated -Storage](https://learn.hashicorp.com/collections/vault/raft) tutorials +Storage](/vault/tutorials/raft) tutorials to learn more about Integrated Storage. diff --git a/website/content/docs/configuration/storage/raft.mdx b/website/content/docs/configuration/storage/raft.mdx index 28476736ef..cc399f6ebd 100644 --- a/website/content/docs/configuration/storage/raft.mdx +++ b/website/content/docs/configuration/storage/raft.mdx @@ -32,15 +32,15 @@ cluster_addr = "http://127.0.0.1:8201" ``` ~> **Note:** When using the Integrated Storage backend, it is required to provide -[`cluster_addr`](/docs/concepts/ha#per-node-cluster-address) to indicate the address and port to be used for communication +[`cluster_addr`](/vault/docs/concepts/ha#per-node-cluster-address) to indicate the address and port to be used for communication between the nodes in the Raft cluster. ~> **Note:** When using the Integrated Storage backend, a separate -[`ha_storage`](/docs/configuration#ha_storage) +[`ha_storage`](/vault/docs/configuration#ha_storage) backend cannot be declared. ~> **Note:** When using the Integrated Storage backend, it is strongly recommended to -set [`disable_mlock`](/docs/configuration#disable_mlock) to `true`, and to disable memory swapping on the system. +set [`disable_mlock`](/vault/docs/configuration#disable_mlock) to `true`, and to disable memory swapping on the system. ## `raft` Parameters @@ -99,7 +99,7 @@ set [`disable_mlock`](/docs/configuration#disable_mlock) to `true`, and to disab config to join the Raft cluster as a non-voter. The node will not participate in the Raft quorum but will still receive the data replication stream, adding read scalability to a cluster. This option has the same effect as the - [`-non-voter`](/docs/commands/operator/raft#non-voter) flag for the + [`-non-voter`](/vault/docs/commands/operator/raft#non-voter) flag for the `vault operator raft join` command, but only affects voting status when joining via `retry_join` config. This setting can be overridden to true by setting the `VAULT_RAFT_RETRY_JOIN_AS_NON_VOTER` environment variable to any non-empty value. @@ -132,13 +132,13 @@ set [`disable_mlock`](/docs/configuration#disable_mlock) to `true`, and to disab - `autopilot_upgrade_version` `(string: "")` - This is an optional string that, if provided, will be used reported to autopilot as Vault's version. This is then used by autopilot when it makes decisions regarding - [automated upgrades](/docs/enterprise/automated-upgrades). If omitted, the + [automated upgrades](/vault/docs/enterprise/automated-upgrades). If omitted, the version of Vault currently in use will be used. Note that this string must conform to [Semantic Versioning](https://semver.org). Use of this feature requires Vault Enterprise. - `autopilot_redundancy_zone` `(string: "")` - This is an optional string that specifies - Vault's [redundancy zone](/docs/enterprise/redundancy-zones). This is reported to autopilot + Vault's [redundancy zone](/vault/docs/enterprise/redundancy-zones). This is reported to autopilot and is used to enhance scaling and resiliency. Use of this feature requires Vault Enterprise. ### `retry_join` stanza @@ -159,7 +159,7 @@ set [`disable_mlock`](/docs/configuration#disable_mlock) to `true`, and to disab Should match one of the names in the [DNS SANs](https://en.wikipedia.org/wiki/Subject_Alternative_Name) of the remote server certificate. - See also [Integrated Storage and TLS](https://www.vaultproject.io/docs/concepts/integrated-storage#autojoin-with-tls-servername) + See also [Integrated Storage and TLS](/vault/docs/concepts/integrated-storage#autojoin-with-tls-servername) - `leader_ca_cert_file` `(string: "")` - File path to the CA cert of the possible leader node. @@ -228,6 +228,6 @@ storage "raft" { ## Tutorial Refer to the [Integrated -Storage](https://learn.hashicorp.com/collections/vault/raft) series of tutorials to learn more about implementing Vault using Integrated Storage. +Storage](/vault/tutorials/raft) series of tutorials to learn more about implementing Vault using Integrated Storage. [raft]: https://raft.github.io/ 'The Raft Consensus Algorithm' diff --git a/website/content/docs/configuration/telemetry.mdx b/website/content/docs/configuration/telemetry.mdx index 1b8bcd864b..9aa2eb1b97 100644 --- a/website/content/docs/configuration/telemetry.mdx +++ b/website/content/docs/configuration/telemetry.mdx @@ -10,7 +10,7 @@ description: |- The `telemetry` stanza specifies various configurations for Vault to publish metrics to upstream systems. Available Vault metrics can be found in the -[Telemetry internals documentation](/docs/internals/telemetry). +[Telemetry internals documentation](/vault/docs/internals/telemetry). ```hcl telemetry { @@ -29,7 +29,7 @@ The following options are available on all telemetry configurations. - `usage_gauge_period` `(string: "10m")` - Specifies the interval at which high-cardinality usage data is collected, such as token counts, entity counts, and secret counts. - A value of "none" disables the collection. Uses [duration format strings](/docs/concepts/duration-format). + A value of "none" disables the collection. Uses [duration format strings](/vault/docs/concepts/duration-format). - `maximum_gauge_cardinality` `(int: 500)` - The maximum cardinality of gauge labels. - `disable_hostname` `(bool: false)` - Specifies if gauge values should be prefixed with the local hostname. @@ -42,7 +42,7 @@ The following options are available on all telemetry configurations. Note that leases are put into buckets by rounding. For example, if `lease_metrics_epsilon` is set to 1h and lease A expires 25 minutes from now, and lease B expires 35 minutes from now, then lease A will be in the first bucket, which corresponds to 0-30 minutes, and lease B will be in the second bucket, which corresponds to 31-90 - minutes. Uses [duration format strings](/docs/concepts/duration-format). + minutes. Uses [duration format strings](/vault/docs/concepts/duration-format). - `num_lease_metrics_buckets` `(int: 168)` - The number of expiry buckets for leases. For the default value, for example, 168 value labels for the `vault.expire.leases.by_expiration` metric will be reported, where each value each bucket is separated in time by the `lease_metrics_epsilon` parameter. For the default 1 hour value of @@ -263,4 +263,4 @@ Metrics from Vault can be found in [Metrics Explorer](https://cloud.google.com/m All those metrics are shown with a resource type of `generic_task`, and the metric name is prefixed with `custom.googleapis.com/go-metrics/`. -[telemetry-tcp]: /docs/configuration/listener/tcp#telemetry-parameters +[telemetry-tcp]: /vault/docs/configuration/listener/tcp#telemetry-parameters diff --git a/website/content/docs/configuration/ui.mdx b/website/content/docs/configuration/ui.mdx index 393df129cf..0d1224d08a 100644 --- a/website/content/docs/configuration/ui.mdx +++ b/website/content/docs/configuration/ui.mdx @@ -30,7 +30,7 @@ listener "tcp" { ``` For more information, please see the -[Vault configuration options](/docs/configuration). +[Vault configuration options](/vault/docs/configuration). ## Accessing the Vault UI diff --git a/website/content/docs/configuration/user-lockout.mdx b/website/content/docs/configuration/user-lockout.mdx index 3e4381eecc..f76d31594c 100644 --- a/website/content/docs/configuration/user-lockout.mdx +++ b/website/content/docs/configuration/user-lockout.mdx @@ -54,8 +54,8 @@ Here, user lockout feature will be disabled for ldap auth methods. Userpass auth lockout duration of 5 minutes, lockout counter reset of 10 minutes. Approle auth methods will have a lockout threshold of 5 (considers default as this value is not configured), lockout duration of 10 minutes and lockout counter reset of 10 minutes. -The user lockout configuration for the auth method at a given path can be tuned using auth tune. Please see [auth tune command](/docs/commands/auth/tune) -or [auth tune api](/api-docs/system/auth#tune-auth-method) for more details. +The user lockout configuration for the auth method at a given path can be tuned using auth tune. Please see [auth tune command](/vault/docs/commands/auth/tune) +or [auth tune api](/vault/api-docs/system/auth#tune-auth-method) for more details. ## `user_lockout` Parameters diff --git a/website/content/docs/deprecation/faq.mdx b/website/content/docs/deprecation/faq.mdx index 6296aeaf86..88fc18b175 100644 --- a/website/content/docs/deprecation/faq.mdx +++ b/website/content/docs/deprecation/faq.mdx @@ -8,7 +8,7 @@ description: |- # Feature Deprecation FAQ -This page provides frequently asked questions concerning decisions made about Vault feature deprecations. If you are looking for information about Vault licensing, refer to the [Licensing FAQ](/docs/enterprise/license/faq) page. Pleaser refer to the [Feature Deprecation Notice and Plans](/docs/deprecation) document for up-to-date information on Vault feature deprecations and notice. +This page provides frequently asked questions concerning decisions made about Vault feature deprecations. If you are looking for information about Vault licensing, refer to the [Licensing FAQ](/vault/docs/enterprise/license/faq) page. Pleaser refer to the [Feature Deprecation Notice and Plans](/vault/docs/deprecation) document for up-to-date information on Vault feature deprecations and notice. - [Q: What is the impact on anyone using the legacy MFA feature?](#q-what-is-the-impact-on-anyone-using-the-legacy-mfa-feature) - [Q: I'm currently using the Etcd storage backend feature. How does the deprecation impact me?](#q-i-m-currently-using-the-etcd-storage-backend-feature-how-does-the-deprecation-impact-me) @@ -34,9 +34,9 @@ These features were deprecated in prior releases of Vault. We are targeting the | Deprecated Feature | Alternative Feature | | --------------------- | ------------------------------------------------------------------------------------------------------------------- | -| Mount Filters | [Path Filters](https://www.vaultproject.io/api-docs/system/replication/replication-performance#create-paths-filter) | -| AppID | [AppRole auth method](/docs/auth/approle) | -| Standalone DB engines | [Combined DB engines](/docs/secrets/databases) | +| Mount Filters | [Path Filters](/vault/api-docs/system/replication/replication-performance#create-paths-filter) | +| AppID | [AppRole auth method](/vault/docs/auth/approle) | +| Standalone DB engines | [Combined DB engines](/vault/docs/secrets/databases) | **Note:** After upgrading to 1.12, any attempt to unseal a core with one of the following features enabled will result in a core shutdown. This may temporarily be overridden using the `VAULT_ALLOW_PENDING_REMOVAL_MOUNTS` environment variable when launching the Vault server. These features will be officially removed from Vault in version 1.13 and this environment variable will not work. In order to upgrade to 1.13, you will have to completely disable all removed features. @@ -63,31 +63,31 @@ Here are the use cases that may still use certificates with SHA-1: #### Auth Methods -- [AWS Auth Method](/docs/auth/aws): [AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-identity-documents.html) can use SHA-1-based PKCS7 signatures for DSA key pairs. -- [Cloud Foundry (CF) Auth Method ](/docs/auth/cf) -- [Kerberos Auth Method](/docs/auth/kerberos) -- [Kubernetes Auth Method](/docs/auth/kubernetes) -- [LDAP Auth Method](/docs/auth/ldap) -- [JWT/OIDC Auth Method](/docs/auth/jwt/) -- [TLS Certificates Auth Method](/docs/auth/cert) +- [AWS Auth Method](/vault/docs/auth/aws): [AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-identity-documents.html) can use SHA-1-based PKCS7 signatures for DSA key pairs. +- [Cloud Foundry (CF) Auth Method ](/vault/docs/auth/cf) +- [Kerberos Auth Method](/vault/docs/auth/kerberos) +- [Kubernetes Auth Method](/vault/docs/auth/kubernetes) +- [LDAP Auth Method](/vault/docs/auth/ldap) +- [JWT/OIDC Auth Method](/vault/docs/auth/jwt/) +- [TLS Certificates Auth Method](/vault/docs/auth/cert) #### Database Secrets Engines -- [Cassandra Database Secrets Engine](/docs/secrets/databases/cassandra) -- [Couchbase Database Secrets Engine](/docs/secrets/databases/couchbase) -- [Elasticsearch Database Secrets Engine](/docs/secrets/databases/elasticdb) -- [InfluxDB Database Secrets Engine](/docs/secrets/databases/influxdb) -- [MongoDB Database Secrets Engine](/docs/secrets/databases/mongodb) -- [MySQL/MariaDB Database Secrets Engine](/docs/secrets/databases/mysql-maria) +- [Cassandra Database Secrets Engine](/vault/docs/secrets/databases/cassandra) +- [Couchbase Database Secrets Engine](/vault/docs/secrets/databases/couchbase) +- [Elasticsearch Database Secrets Engine](/vault/docs/secrets/databases/elasticdb) +- [InfluxDB Database Secrets Engine](/vault/docs/secrets/databases/influxdb) +- [MongoDB Database Secrets Engine](/vault/docs/secrets/databases/mongodb) +- [MySQL/MariaDB Database Secrets Engine](/vault/docs/secrets/databases/mysql-maria) #### Secrets Engines -- [Active Directory Secrets Engine](/docs/secrets/ad) -- [Consul Secrets Engine](/docs/secrets/consul) -- [Kubernetes Secrets Engine](/docs/secrets/kubernetes) -- [Nomad Secrets Engine](/docs/secrets/nomad) -- [LDAP Secrets Engine](/docs/secrets/ldap) -- [PKI Secrets Engine](/docs/secrets/pki/) +- [Active Directory Secrets Engine](/vault/docs/secrets/ad) +- [Consul Secrets Engine](/vault/docs/secrets/consul) +- [Kubernetes Secrets Engine](/vault/docs/secrets/kubernetes) +- [Nomad Secrets Engine](/vault/docs/secrets/nomad) +- [LDAP Secrets Engine](/vault/docs/secrets/ldap) +- [PKI Secrets Engine](/vault/docs/secrets/pki/) ### Q: What are the phases of deprecation? @@ -123,7 +123,7 @@ This status reflects a feature which has been officially deprecated in this rele ##### VAULT_ALLOW_PENDING_REMOVAL_MOUNTS -The `Pending Removal` behavior may be overriden using a new environment variable: [`VAULT_ALLOW_PENDING_REMOVAL_MOUNTS`](/docs/commands/server#vault_allow_pending_removal_mounts). This environment variable effectively allows all `Pending Removal` features to be treated as `Deprecated`. +The `Pending Removal` behavior may be overriden using a new environment variable: [`VAULT_ALLOW_PENDING_REMOVAL_MOUNTS`](/vault/docs/commands/server#vault_allow_pending_removal_mounts). This environment variable effectively allows all `Pending Removal` features to be treated as `Deprecated`. #### Removed diff --git a/website/content/docs/deprecation/index.mdx b/website/content/docs/deprecation/index.mdx index bca40e9603..057783250d 100644 --- a/website/content/docs/deprecation/index.mdx +++ b/website/content/docs/deprecation/index.mdx @@ -8,7 +8,7 @@ description: |- # Feature Deprecation Notice and Plans -This announcement page is maintained and updated periodically to communicate important decisions made concerning End of Support(EoS) for Vault features as well as features we have removed or disabled from the product. We document the removal of features, enable the community with a plan and timeline for eventual deprecations, and supply alternative paths to explore and evaluate to minimize business disruptions. If you have questions or concerns about a deprecated feature, please create a topic on [the community forum](https://discuss.hashicorp.com/c/vault/30) or raise a ticket with your support team. Please refer to the [FAQ](/docs/deprecation/faq) page for frequently asked questions concerning Vault feature deprecations. +This announcement page is maintained and updated periodically to communicate important decisions made concerning End of Support(EoS) for Vault features as well as features we have removed or disabled from the product. We document the removal of features, enable the community with a plan and timeline for eventual deprecations, and supply alternative paths to explore and evaluate to minimize business disruptions. If you have questions or concerns about a deprecated feature, please create a topic on [the community forum](https://discuss.hashicorp.com/c/vault/30) or raise a ticket with your support team. Please refer to the [FAQ](/vault/docs/deprecation/faq) page for frequently asked questions concerning Vault feature deprecations. **Deprecation Announcement**: This indicates the release version during which the announcement was made to deprecate a feature. @@ -20,19 +20,19 @@ This announcement page is maintained and updated periodically to communicate imp | Feature | Deprecation announcement | End of Support | Feature Removal | Migration Path/Impact | Resources | | ------------------------------------------------- | ------------------------ | -------------- | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Vault Enterprise storage backend | N/A | v1.12 | N/A | Use [Integrated Storage](/docs/configuration/storage/raft) or [Consul](/docs/configuration/storage/consul) as your Vault's storage backend. Vault Enterprise will no longer start up if configured to use a storage backend other than Integrated Storage or Consul. | [Upgrade Guide](/docs/upgrading/upgrade-to-1.12.x) | -| Vault generation of Dynamic SSH Keys | v0.7.1 | N/A | v1.13 | Use the alternative [signed SSH certificates](/docs/secrets/ssh/signed-ssh-certificates) feature which supports key pair generation as of Vault 1.12. SSH certificates do not require an external connection from Vault to provision the key/certificate and more secure than having Vault provision dynamic SSH keys. | [SSH Certificates](/docs/secrets/ssh/signed-ssh-certificates) | +| Vault Enterprise storage backend | N/A | v1.12 | N/A | Use [Integrated Storage](/vault/docs/configuration/storage/raft) or [Consul](/vault/docs/configuration/storage/consul) as your Vault's storage backend. Vault Enterprise will no longer start up if configured to use a storage backend other than Integrated Storage or Consul. | [Upgrade Guide](/vault/docs/upgrading/upgrade-to-1.12.x) | +| Vault generation of Dynamic SSH Keys | v0.7.1 | N/A | v1.13 | Use the alternative [signed SSH certificates](/vault/docs/secrets/ssh/signed-ssh-certificates) feature which supports key pair generation as of Vault 1.12. SSH certificates do not require an external connection from Vault to provision the key/certificate and more secure than having Vault provision dynamic SSH keys. | [SSH Certificates](/vault/docs/secrets/ssh/signed-ssh-certificates) | | [Duplicative Docker Images](https://hub.docker.com/_/vault) | v1.12 | 1.13 | v1.14 | Upon feature removal, the `vault` Docker image will no longer be updated. Only the [Verified Publisher](https://hub.docker.com/r/hashicorp/vault) `hashicorp/vault` image will be updated on DockerHub. Users of [Official Images](https://hub.docker.com/_/vault) will need to use `docker pull hashicorp/vault:` instead of `docker pull vault:version` to get newer versions of Vault in Docker images. Currently, HashiCorp publishes and updates identical Docker images of Vault as Verified Publisher and Official images separately. | [The Verified Publisher Program](https://docs.docker.com/docker-hub/publish/) -| Etcd V2 API (OSS) | v1.9 | N/A | v1.10 | The Etcd v2 has been deprecated with the release of Etcd v3.5, and will be decomissioned by Etcd v3.6. Etcd v2 API has been removed in Vaut 1.10. Users of Etcd storage backend must migrate Vault storage to an Etcd V3 cluster prior to upgrading to Vault 1.10. All storage migrations should be backed up prior to migration. | [Etcd Storage Backend](/docs/configuration/storage/etcd) | -| Licenses in storage (ENT) | v1.8 | v1.10 | v1.11 | Migrate to [Autoloading](/docs/enterprise/license/autoloading) by v1.11. | [Vault License](/docs/enterprise/license) [System Backend](https://www.vaultproject.io/api-docs/system/license) [FAQ](/docs/enterprise/license/faq) | -| Mount Filters (ENT) | v1.3 | v1.10 | v1.11 | Use the alternative feature: [Path Filters](https://www.vaultproject.io/api-docs/system/replication/replication-performance#create-paths-filter). | [API Deprecation Notice](https://www.vaultproject.io/api-docs/system/replication/replication-performance#create-mounts-filter-deprecated) [Filter Mount Replication Deprecation Notice](/docs/upgrading/upgrade-to-1.3.0#filtered-mount-replication-deprecation) | -| Legacy MFA (OSS) | v1.0 | N/A | v1.11 | Based on your use case, use the Policy-based Enterprise MFA or Login MFA supported in Vault OSS as of v1.10. | [Multi-Factor Authentication](https://www.vaultproject.io/docs/v1.10.x/auth/mfa) | -| *****Standalone DB Engines (OSS) | v0.8 | N/A | v1.13 | Use the alternative DB secrets engine feature. | [DB secrets engine](/docs/secrets/databases) | -| *****AppID (OSS) | v0.6 | N/A | v1.13 | Use the alternative feature: [AppRole auth method](https://www.vaultproject.io/docs/auth/approle). | [AppID Auth Method Deprecation Notice](/docs/auth/app-id) | +| Etcd V2 API (OSS) | v1.9 | N/A | v1.10 | The Etcd v2 has been deprecated with the release of Etcd v3.5, and will be decomissioned by Etcd v3.6. Etcd v2 API has been removed in Vaut 1.10. Users of Etcd storage backend must migrate Vault storage to an Etcd V3 cluster prior to upgrading to Vault 1.10. All storage migrations should be backed up prior to migration. | [Etcd Storage Backend](/vault/docs/configuration/storage/etcd) | +| Licenses in storage (ENT) | v1.8 | v1.10 | v1.11 | Migrate to [Autoloading](/vault/docs/enterprise/license/autoloading) by v1.11. | [Vault License](/vault/docs/enterprise/license) [System Backend](/vault/api-docs/system/license) [FAQ](/vault/docs/enterprise/license/faq) | +| Mount Filters (ENT) | v1.3 | v1.10 | v1.11 | Use the alternative feature: [Path Filters](/vault/api-docs/system/replication/replication-performance#create-paths-filter). | [API Deprecation Notice](/vault/api-docs/system/replication/replication-performance#create-mounts-filter-deprecated) [Filter Mount Replication Deprecation Notice](/vault/docs/upgrading/upgrade-to-1.3.0#filtered-mount-replication-deprecation) | +| Legacy MFA (OSS) | v1.0 | N/A | v1.11 | Based on your use case, use the Policy-based Enterprise MFA or Login MFA supported in Vault OSS as of v1.10. | [Multi-Factor Authentication](/vault/docs/v1.10.x/auth/mfa) | +| *****Standalone DB Engines (OSS) | v0.8 | N/A | v1.13 | Use the alternative DB secrets engine feature. | [DB secrets engine](/vault/docs/secrets/databases) | +| *****AppID (OSS) | v0.6 | N/A | v1.13 | Use the alternative feature: [AppRole auth method](/vault/docs/auth/approle). | [AppID Auth Method Deprecation Notice](/vault/docs/auth/app-id) | | AAD Graph on Azure Secrets Engine | v1.10 | 1.11 | v1.12 | Microsoft will end its support of the [AAD Graph API on June 30, 2022](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview). Support for Microsoft Graph API was introduced in Vault 1.9. If your Vault deployment is on a prior release, you may use the Azure Secrets Engine as an external plugin while you plan to upgrade. | [AAD (Azure Active Directory](https://vault-git-post-1-10-doc-changes-hashicorp.vercel.app/docs/secrets/azure#aad-azure-active-directory) | -| Optional `api_token` parameter in Okta Auth Method | v1.4 | 1.11 | v1.12 | The `api_token` parameter on the Okta Auth Method will change from being optional to being required. | [API Documentation](https://www.vaultproject.io/api-docs/auth/okta#api_token) | -| SHA-1 certificate signing | v1.11 | v1.11 | v1.12 | Go version 1.18 removes support for SHA-1 by default. As Vault updates its Go version to 1.18, you should plan to move off SHA-1 for certficate signing. Operators can set a Go [environmental variable](/docs/deprecation/faq#q-what-is-the-impact-of-removing-support-for-x-509-certificates-with-signatures-that-use-sha-1) to restore SHA-1 support if they need to continue using SHA-1. It is unknown at this time when Go will remove the environmental variable support. Therefore, we highly encourage you to migrate off of SHA-1 for certificate signing. |[FAQ](/docs/deprecation/faq#q-what-is-the-impact-of-removing-support-for-x-509-certificates-with-signatures-that-use-sha-1)| -| Consul secrets engine parameter changes | v1.11 | N/A | N/A | The `policies` parameter on the Consul secrets engine has been changed in favor of `consul_policies`. The `token_type` and `policy` parameters have been deprecated as the latest versions of Consul no longer support the older ACL system they were used for. | [Consul secrets engine API documentation](/api-docs/secret/consul) | +| Optional `api_token` parameter in Okta Auth Method | v1.4 | 1.11 | v1.12 | The `api_token` parameter on the Okta Auth Method will change from being optional to being required. | [API Documentation](/vault/api-docs/auth/okta#api_token) | +| SHA-1 certificate signing | v1.11 | v1.11 | v1.12 | Go version 1.18 removes support for SHA-1 by default. As Vault updates its Go version to 1.18, you should plan to move off SHA-1 for certficate signing. Operators can set a Go [environmental variable](/vault/docs/deprecation/faq#q-what-is-the-impact-of-removing-support-for-x-509-certificates-with-signatures-that-use-sha-1) to restore SHA-1 support if they need to continue using SHA-1. It is unknown at this time when Go will remove the environmental variable support. Therefore, we highly encourage you to migrate off of SHA-1 for certificate signing. |[FAQ](/vault/docs/deprecation/faq#q-what-is-the-impact-of-removing-support-for-x-509-certificates-with-signatures-that-use-sha-1)| +| Consul secrets engine parameter changes | v1.11 | N/A | N/A | The `policies` parameter on the Consul secrets engine has been changed in favor of `consul_policies`. The `token_type` and `policy` parameters have been deprecated as the latest versions of Consul no longer support the older ACL system they were used for. | [Consul secrets engine API documentation](/vault/api-docs/secret/consul) | *If you use **Standalone DB Engines** or **AppID (OSS)**, you should actively plan to migrate away from their usage. If you use these features and upgrade to Release 1.12, Vault will log error messages and shut down, and any attempts to add new mounts will result in an error. diff --git a/website/content/docs/enterprise/automated-integrated-storage-snapshots.mdx b/website/content/docs/enterprise/automated-integrated-storage-snapshots.mdx index ef6a489244..2dee6c4be5 100644 --- a/website/content/docs/enterprise/automated-integrated-storage-snapshots.mdx +++ b/website/content/docs/enterprise/automated-integrated-storage-snapshots.mdx @@ -54,5 +54,5 @@ that all Vault Enterprise users would be running Consul or an orchestrator. # See also -Refer to the [API docs](/api-docs/system/storage/raftautosnapshots) for the specifics +Refer to the [API docs](/vault/api-docs/system/storage/raftautosnapshots) for the specifics of how to configure automated snapshots and query their status. diff --git a/website/content/docs/enterprise/automated-upgrades.mdx b/website/content/docs/enterprise/automated-upgrades.mdx index 44b64f4cee..ba9704aa9e 100644 --- a/website/content/docs/enterprise/automated-upgrades.mdx +++ b/website/content/docs/enterprise/automated-upgrades.mdx @@ -37,7 +37,7 @@ Below is a flowchart depicting Autopilot's automated upgrade state machine. ![Automated Upgrade State Machine](/img/autopilot-automated-upgrade.png) -The status of the automated upgrade can be monitored by consulting the [Autopilot state API endpoint](/api-docs/system/storage/raftautopilot#get-cluster-state). +The status of the automated upgrade can be monitored by consulting the [Autopilot state API endpoint](/vault/api-docs/system/storage/raftautopilot#get-cluster-state). ## Examples ### Using Vault's built-in version diff --git a/website/content/docs/enterprise/consistency.mdx b/website/content/docs/enterprise/consistency.mdx index a0be208daf..50f6eee991 100644 --- a/website/content/docs/enterprise/consistency.mdx +++ b/website/content/docs/enterprise/consistency.mdx @@ -87,7 +87,7 @@ node completes the request anyway, returning a warning in the response. This mitigation option still exists in Vault 1.7, though now there is a configuration option to adjust the wait time: -[best_effort_wal_wait_duration](/docs/configuration/replication). +[best_effort_wal_wait_duration](/vault/docs/configuration/replication). ## Vault 1.7 Mitigations @@ -103,7 +103,7 @@ The remainder of this document describes the tradeoffs of these mitigations and how to use them. Note that any headers requesting forwarding are disabled by default, and must -be enabled using [allow_forwarding_via_header](/docs/configuration/replication). +be enabled using [allow_forwarding_via_header](/vault/docs/configuration/replication). ### Unconditional Forwarding (Performance standbys only) @@ -175,7 +175,7 @@ to build equivalent functionality into their client library. ### Vault Agent and consistency headers -When configured, the [Vault Agent API Proxy](/docs/agent/apiproxy) will proxy incoming requests to Vault. There is +When configured, the [Vault Agent API Proxy](/vault/docs/agent/apiproxy) will proxy incoming requests to Vault. There is Agent configuration available in the `api_proxy` stanza that allows making use of some of the above mitigations without modifying clients. @@ -202,11 +202,11 @@ a 412 status code. The Vault Go API automatically retries when receiving 412s, s unless there is a considerable replication delay, users will experience read-after-write consistency. -The replication option [allow_forwarding_via_token](/docs/configuration/replication) +The replication option [allow_forwarding_via_token](/vault/docs/configuration/replication) can be used to enforce requests that would have returned 412s in the aforementioned way will be forwarded instead to the active node. -Refer to the [Server Side Consistent Token FAQ](/docs/faq/ssct) for details. +Refer to the [Server Side Consistent Token FAQ](/vault/docs/faq/ssct) for details. ## Client API helpers diff --git a/website/content/docs/enterprise/control-groups.mdx b/website/content/docs/enterprise/control-groups.mdx index 11c1739005..b6ae246d3b 100644 --- a/website/content/docs/enterprise/control-groups.mdx +++ b/website/content/docs/enterprise/control-groups.mdx @@ -171,7 +171,7 @@ to go through the control group workflow in order to execute a read operation ag ## Control Groups in Sentinel Control Groups are also supported in Sentinel policies using the `controlgroup` -import. See [Sentinel Documentation](/docs/enterprise/sentinel) for more +import. See [Sentinel Documentation](/vault/docs/enterprise/sentinel) for more details on available properties. ### Sample Sentinel Policy @@ -212,4 +212,4 @@ tutorial to learn how to implement dual controller authorization within your pol ## API Control Groups can be managed over the HTTP API. Please see -[Control Groups API](/api-docs/system/control-group) for more details. +[Control Groups API](/vault/api-docs/system/control-group) for more details. diff --git a/website/content/docs/enterprise/entropy-augmentation.mdx b/website/content/docs/enterprise/entropy-augmentation.mdx index b04ec6f351..e56f6acfe3 100644 --- a/website/content/docs/enterprise/entropy-augmentation.mdx +++ b/website/content/docs/enterprise/entropy-augmentation.mdx @@ -13,7 +13,7 @@ description: |- ~> **Warning** This feature is not available with FIPS 140-2 Inside variants of Vault. Vault Enterprise features a mechanism to sample entropy (or randomness for -cryptographic operations) from external cryptographic modules via the [seals](/docs/configuration/seal) +cryptographic operations) from external cryptographic modules via the [seals](/vault/docs/configuration/seal) interface. While the system entropy used by Vault is more than capable of operating in most threat models, there are some situations where additional entropy from hardware-based random number generators is desirable. @@ -43,20 +43,20 @@ and include the following: - JWT token wrapping keys - Root tokens - DR operation tokens -- [Transit](/docs/secrets/transit) backend key generation and `/random` endpoint (`/random` only on Vault 1.11+) -- [PKI](/docs/secrets/pki) issuer key generation, but not for leaf certificate private keys -- [`/sys/tools/random`](/api-docs/system/tools#generate-random-bytes) endpoint (Vault 1.11+) -- [SSH](/docs/secrets/ssh) CA key generation, but not for key pair generation -- [KMIP](/docs/secrets/kmip) uses EA for its TLS CA, server, and client +- [Transit](/vault/docs/secrets/transit) backend key generation and `/random` endpoint (`/random` only on Vault 1.11+) +- [PKI](/vault/docs/secrets/pki) issuer key generation, but not for leaf certificate private keys +- [`/sys/tools/random`](/vault/api-docs/system/tools#generate-random-bytes) endpoint (Vault 1.11+) +- [SSH](/vault/docs/secrets/ssh) CA key generation, but not for key pair generation +- [KMIP](/vault/docs/secrets/kmip) uses EA for its TLS CA, server, and client certificates. ## Enabling/Disabling Entropy augmentation is disabled by default. To enable entropy augmentation Vault's -[configuration file][configuration] must include a properly configured [entropy and seal stanza](/docs/configuration/entropy-augmentation) +[configuration file][configuration] must include a properly configured [entropy and seal stanza](/vault/docs/configuration/entropy-augmentation) for a supported seal type. -[configuration]: /docs/configuration +[configuration]: /vault/docs/configuration ## Tutorial diff --git a/website/content/docs/enterprise/fips/index.mdx b/website/content/docs/enterprise/fips/index.mdx index 9fcc96d3a7..42428a78a8 100644 --- a/website/content/docs/enterprise/fips/index.mdx +++ b/website/content/docs/enterprise/fips/index.mdx @@ -15,10 +15,10 @@ Hashicorp's Vault Enterprise supports the modes of FIPS compliance documented be Vault Enterprise now includes release flavors with FIPS 140-2 compliant cryptography built into the Vault binary. More information on these releases -can be found on the [FIPS 140-2 Inside](/docs/enterprise/fips/fips1402) page. +can be found on the [FIPS 140-2 Inside](/vault/docs/enterprise/fips/fips1402) page. ## Seal Wrap Before our FIPS Inside effort, Vault [depended on](https://www.hashicorp.com/vault-compliance) -an external HSM for FIPS 140-2 compliance. This uses the [Seal Wrap](/docs/enterprise/fips/sealwrap) +an external HSM for FIPS 140-2 compliance. This uses the [Seal Wrap](/vault/docs/enterprise/fips/sealwrap) functionality to wrap security relevant keys in an extra layer of encryption. diff --git a/website/content/docs/enterprise/fips/sealwrap.mdx b/website/content/docs/enterprise/fips/sealwrap.mdx index 8f442e275f..3094f631a0 100644 --- a/website/content/docs/enterprise/fips/sealwrap.mdx +++ b/website/content/docs/enterprise/fips/sealwrap.mdx @@ -12,7 +12,7 @@ description: |- -> **Note**: This feature requires [Vault Enterprise Plus](https://www.hashicorp.com/products/vault/). Vault Enterprise features a mechanism to wrap values with an extra layer of -encryption for supporting [seals](/docs/configuration/seal). This adds an +encryption for supporting [seals](/vault/docs/configuration/seal). This adds an extra layer of protection and is useful in some compliance and regulatory environments, including FIPS 140-2 environments. @@ -22,7 +22,7 @@ sales](mailto:sales@hashicorp.com). ## Using Seal Wrap -See [the Enterprise documentation](/docs/enterprise/sealwrap) for instructions +See [the Enterprise documentation](/vault/docs/enterprise/sealwrap) for instructions on how to use and enable Seal Wrap. ## FIPS 140-2 Compliance @@ -34,7 +34,7 @@ KeyStorage and KeyTransit requirements. This is on by default for many parts of Vault and opt-in for each individual mount; see the Activating Seal Wrapping section below for details. -[Download the current compliance letter](/docs/enterprise/sealwrap/Vault_Compliance_Letter_signed.pdf) +[Download the current compliance letter](/vault/docs/enterprise/sealwrap/Vault_Compliance_Letter_signed.pdf) ### Updates Since The Latest FIPS Compliance Audit @@ -60,4 +60,4 @@ certified FIPS 140-2 TLS (such as [stunnel](https://www.stunnel.org/index.html)) can be used for replication traffic if meeting KeyTransit requirements for replication is necessary. -[configuration]: /docs/configuration +[configuration]: /vault/docs/configuration diff --git a/website/content/docs/enterprise/hsm/behavior.mdx b/website/content/docs/enterprise/hsm/behavior.mdx index c5daf6e7f2..f9f0757e79 100644 --- a/website/content/docs/enterprise/hsm/behavior.mdx +++ b/website/content/docs/enterprise/hsm/behavior.mdx @@ -15,7 +15,7 @@ effect when using Vault with an HSM. Normally, Vault uses a single set of unseal keys to perform both decryption of the cryptographic barrier and to authorize recovery operations, such as the -[`generate-root`](/api-docs/system/generate-root) +[`generate-root`](/vault/api-docs/system/generate-root) functionality. When using an HSM, because the HSM automatically unseals the barrier but @@ -23,7 +23,7 @@ recovery operations should still have human oversight, Vault instead uses two sets of keys: unseal keys and recovery keys. -> **Recovery keys:** Refer to the - [Seal/Unseal](/docs/concepts/seal#recovery-key) documentation to learn more + [Seal/Unseal](/vault/docs/concepts/seal#recovery-key) documentation to learn more about recovery keys. ## Unseal (Root) Key @@ -32,7 +32,7 @@ Vault usually generates a root key and splits it using [Shamir's Secret Sharing](https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing) to prevent a single operator from being able to modify and unseal Vault (see more information about Vault's security model -[here](/docs/internals/security)). +[here](/vault/docs/internals/security)). When using an HSM, Vault instead stores the root key, encrypted by the HSM, into its internal storage. As a result, during an `init` command, the number of diff --git a/website/content/docs/enterprise/hsm/index.mdx b/website/content/docs/enterprise/hsm/index.mdx index 2add06d2b6..1e96b8f27a 100644 --- a/website/content/docs/enterprise/hsm/index.mdx +++ b/website/content/docs/enterprise/hsm/index.mdx @@ -14,9 +14,9 @@ description: >- the HSM for encryption rather than splitting into key shares - Automatic Unsealing: Vault stores its HSM-wrapped root key in storage, allowing for automatic unsealing -- [Seal Wrapping](/docs/enterprise/sealwrap) to provide FIPS +- [Seal Wrapping](/vault/docs/enterprise/sealwrap) to provide FIPS KeyStorage-conforming functionality for Critical Security Parameters -- [Entropy Augmentation](/docs/enterprise/entropy-augmentation) to +- [Entropy Augmentation](/vault/docs/enterprise/entropy-augmentation) to allow Vault to sample entropy from an external cryptographic module. HSM support is available for devices that support PKCS#11 version 2.20+ @@ -31,11 +31,11 @@ within PKCS#11 vary depending on HSM model and configuration. Consult your HSM's documentation for more details. Some parts of Vault work differently when using an HSM. Please see the -[Behavioral Changes](/docs/enterprise/hsm/behavior) page for +[Behavioral Changes](/vault/docs/enterprise/hsm/behavior) page for important information on these differences. -The [Configuration](/docs/configuration/seal/pkcs11) page contains +The [Configuration](/vault/docs/configuration/seal/pkcs11) page contains configuration information. -Finally, the [Security](/docs/enterprise/hsm/security) page contains +Finally, the [Security](/vault/docs/enterprise/hsm/security) page contains information about deploying Vault's HSM support in a secure fashion. diff --git a/website/content/docs/enterprise/hsm/security.mdx b/website/content/docs/enterprise/hsm/security.mdx index cc42e5832c..bb7c1cc635 100644 --- a/website/content/docs/enterprise/hsm/security.mdx +++ b/website/content/docs/enterprise/hsm/security.mdx @@ -20,7 +20,7 @@ stored in Vault's configuration file, read access to the file should be tightly controlled to appropriate users. (Vault's configuration file should always have tight write controls.) Rather than storing these values into Vault's configuration file, they can also be supplied via the environment; see the -[Configuration](/docs/configuration/seal/pkcs11) page for more details. +[Configuration](/vault/docs/configuration/seal/pkcs11) page for more details. The attack surface of stolen PKCS#11 credentials depends highly on the individual HSM, but generally speaking, it should be assumed that if an diff --git a/website/content/docs/enterprise/index.mdx b/website/content/docs/enterprise/index.mdx index 9bdea81d9e..871018a861 100644 --- a/website/content/docs/enterprise/index.mdx +++ b/website/content/docs/enterprise/index.mdx @@ -18,5 +18,5 @@ These features are part of [Vault Enterprise](https://www.hashicorp.com/vault?ut A Vault Enterprise license needs to be applied to a Vault cluster in order to use Vault Enterprise features. See -[Vault License](/docs/enterprise/license) for details. +[Vault License](/vault/docs/enterprise/license) for details. diff --git a/website/content/docs/enterprise/lease-count-quotas.mdx b/website/content/docs/enterprise/lease-count-quotas.mdx index 62149bc453..ffe7c778bf 100644 --- a/website/content/docs/enterprise/lease-count-quotas.mdx +++ b/website/content/docs/enterprise/lease-count-quotas.mdx @@ -44,7 +44,7 @@ further restrict usages in a specific namespace or mount, that can be done using the precedence model too. Vault also allows the inspection into the state of lease count quotas in a Vault -cluster through various [metrics](/docs/internals/telemetry#Resource-Quota-Metrics) +cluster through various [metrics](/vault/docs/internals/telemetry#Resource-Quota-Metrics) exposed and through enabling optional audit logging. ## Tutorial @@ -56,4 +56,4 @@ step-by-step tutorial. ## API Lease count quotas can be managed over the HTTP API. Please see -[Lease Count Quotas API](/api-docs/system/lease-count-quotas) for more details. +[Lease Count Quotas API](/vault/api-docs/system/lease-count-quotas) for more details. diff --git a/website/content/docs/enterprise/license/autoloading.mdx b/website/content/docs/enterprise/license/autoloading.mdx index d7444cd988..dafd15bec2 100644 --- a/website/content/docs/enterprise/license/autoloading.mdx +++ b/website/content/docs/enterprise/license/autoloading.mdx @@ -8,7 +8,7 @@ description: An overview of license autoloading. Prior to Vault 1.8, Vault Enterprise would be licensed using special binaries that contained embedded licenses, or via a license written into Vault storage -using the [POST sys/license API](/api-docs/system/license#install-license). +using the [POST sys/license API](/vault/api-docs/system/license#install-license). As of Vault 1.8 those options still exist but are deprecated, and the recommended mechanism for managing licenses is called License Autoloading. New clusters are @@ -18,9 +18,9 @@ License Autoloading can be done using one of these mechanisms, in decreasing ord of priority (i.e. `VAULT_LICENSE` takes precedence over `VAULT_LICENSE_PATH`, which takes precedence over `license_path` in config.) -- [VAULT_LICENSE environment variable](/docs/commands#vault_license) -- [VAULT_LICENSE_PATH environment variable](/docs/commands#vault_license_path) -- [license_path in config](/docs/configuration#license_path) +- [VAULT_LICENSE environment variable](/vault/docs/commands#vault_license) +- [VAULT_LICENSE_PATH environment variable](/vault/docs/commands#vault_license_path) +- [license_path in config](/vault/docs/configuration#license_path) Nodes within a cluster should be consistently licensed. All nodes in a cluster should use autoloading, or none should. If autoloading is used, all nodes should diff --git a/website/content/docs/enterprise/license/faq.mdx b/website/content/docs/enterprise/license/faq.mdx index aaa717a6cf..4538645f7b 100644 --- a/website/content/docs/enterprise/license/faq.mdx +++ b/website/content/docs/enterprise/license/faq.mdx @@ -30,14 +30,14 @@ This FAQ section is for license changes and updates introduced for Vault Enterpr ### Q: What is the product behavior change introduced by the licensing changes? -Per the [feature deprecation plans](/docs/deprecation), Vault will no longer support licenses in storage. An [auto-loaded license](/docs/enterprise/license/autoloading) must be used instead. If you are using stored licenses, you must migrate to auto-loaded licenses prior to upgrading to Vault 1.11 +Per the [feature deprecation plans](/vault/docs/deprecation), Vault will no longer support licenses in storage. An [auto-loaded license](/vault/docs/enterprise/license/autoloading) must be used instead. If you are using stored licenses, you must migrate to auto-loaded licenses prior to upgrading to Vault 1.11 Vault 1.12 will also introduce different termination behavior for evaluation licenses versus non-evaluation licenses. An evaluation license will include a 30-day trial period after which a running Vault server will terminate. Vault servers using a non-evaluation license will not terminate. ### Q: How do the license termination changes affect upgrades? Vault 1.12 will introduce changes to the license termination behavior. Upgrades when using expired licenses will now be limited. -Vault will not startup if the build date of the binary is _after_ the expiration date of a license. License expiration date and binary build date compatibility can be verified using the [Check for Autoloaded License](/docs/commands/operator/diagnose#check-for-autoloaded-license) check performed by the `vault operator diagnose` command. -The build date of a binary can also be found using the [vault version](/docs/commands/version#version) command. +Vault will not startup if the build date of the binary is _after_ the expiration date of a license. License expiration date and binary build date compatibility can be verified using the [Check for Autoloaded License](/vault/docs/commands/operator/diagnose#check-for-autoloaded-license) check performed by the `vault operator diagnose` command. +The build date of a binary can also be found using the [vault version](/vault/docs/commands/version#version) command. A user can expect the following to occur based on the following scenarios: @@ -74,28 +74,28 @@ No, these changes will not impact HCP Vault. ### Q: What is the product behavior change introduced by the licensing changes? -With Vault 1.11, the use of an [auto-loaded license](/docs/enterprise/license/autoloading) is required for Vault to start successfully. +With Vault 1.11, the use of an [auto-loaded license](/vault/docs/enterprise/license/autoloading) is required for Vault to start successfully. ### Q: How will Vault behave at startup when a license expires or terminates? When a license expires, Vault continues to function until the license terminates. This behavior exists today and remains unchanged in Vault 1.11. The grace period, defined as the time between license expiration and license termination, is one day for evaluation licenses (as of 1.8), and ten years for non-evaluation licenses. -Customers must provide a valid license before the grace period expires. This license is required to be [auto-loaded](/docs/enterprise/license/autoloading). When license terminates (upon grace period expiry), Vault will seal itself and customers will need a valid license in order to successfully bring-up Vault. If a valid license was not installed after license expiry, customers will need to provide one, and this license will need to be auto-loaded. +Customers must provide a valid license before the grace period expires. This license is required to be [auto-loaded](/vault/docs/enterprise/license/autoloading). When license terminates (upon grace period expiry), Vault will seal itself and customers will need a valid license in order to successfully bring-up Vault. If a valid license was not installed after license expiry, customers will need to provide one, and this license will need to be auto-loaded. Vault 1.12 changes the license expiration and termination behavior. Evaluation licenses include a 30-day trial period after which a running Vault server will terminate. Non-evaluation licenses, however, will no longer terminate. When a non-evaluation license expires, Vault will continue to function but upgrades will be limited. The build date of the upgrade binary must be before the expiration date of the license. -Vault will not start when attempting to use an expired license and binary with a build date _after_ the license expiration date. Attempting to [reload](/api-docs/system/config-reload#reload-license-file) an expired license will result in an error if the build date of the running Vault server is _after_ the license expiration date. +Vault will not start when attempting to use an expired license and binary with a build date _after_ the license expiration date. Attempting to [reload](/vault/api-docs/system/config-reload#reload-license-file) an expired license will result in an error if the build date of the running Vault server is _after_ the license expiration date. -License expiration date and binary build date compatibility can be verified using the [Check for Autoloaded License](/docs/commands/operator/diagnose#check-for-autoloaded-license) check performed by the `vault operator diagnose` command. The build date of a binary can also be found using the [vault version](/docs/commands/version#version) command. +License expiration date and binary build date compatibility can be verified using the [Check for Autoloaded License](/vault/docs/commands/operator/diagnose#check-for-autoloaded-license) check performed by the `vault operator diagnose` command. The build date of a binary can also be found using the [vault version](/vault/docs/commands/version#version) command. ### Q: What is the impact on evaluation licenses due to this change? -As of Vault 1.8, any Vault cluster deployed must have a valid [auto-loaded](/docs/enterprise/license/autoloading) license. +As of Vault 1.8, any Vault cluster deployed must have a valid [auto-loaded](/vault/docs/enterprise/license/autoloading) license. Vault 1.12 introduces [expiration and termination behavior changes](#q-how-will-vault-behave-at-startup-when-a-license-expires-or-terminates) for non-evaluation licenses. Evaluation licenses will continue to have a 1-day grace period upon license expiry after which they will terminate. Vault will seal itself and shutdown once an evaluation license terminates. ### Q: Are there any changes to existing methods for manual license loading (API or CLI)? -The [`/sys/license`](/api-docs/v1.10.x/system/license#install-license) and [`/sys/license/signed`](/api-docs/v1.10.x/system/license#read-signed-license) endpoints have been removed as of Vault 1.11. With that said, it is no longer possible to provide a license via the `/sys/license` endpoint. License [auto-loading](/docs/enterprise/license/autoloading) must be used instead. -The [`/sys/config/reload/license`](/api-docs/system/config-reload#reload-license-file) endpoint can be used to reload an auto-loaded license provided as a path via an environment variable or configuration. +The [`/sys/license`](/vault/api-docs/v1.10.x/system/license#install-license) and [`/sys/license/signed`](/vault/api-docs/v1.10.x/system/license#read-signed-license) endpoints have been removed as of Vault 1.11. With that said, it is no longer possible to provide a license via the `/sys/license` endpoint. License [auto-loading](/vault/docs/enterprise/license/autoloading) must be used instead. +The [`/sys/config/reload/license`](/vault/api-docs/system/config-reload#reload-license-file) endpoint can be used to reload an auto-loaded license provided as a path via an environment variable or configuration. ### Q: Is there a grace period when evaluation licenses expire? @@ -110,40 +110,40 @@ The changes to licenses apply to all nodes in a cluster. The license files are n Yes, starting with Vault 1.8, ENT binaries will be subjected to a EULA check. The release of Vault 1.8 introduces the EULA check for evaluation licenses (non-evaluation licenses are evaluated with a EULA check during contractual agreement) . Although the agreement to a EULA occurs only once (when the user receives their license), Vault will check for the presence of a valid license every time a node is restarted. -Starting Vault 1.11, when customers deploy new Vault clusters, or upgrade existing Vault clusters, a valid [auto-loaded](/docs/enterprise/license/autoloading) license must exist for the upgrade to be successful. +Starting Vault 1.11, when customers deploy new Vault clusters, or upgrade existing Vault clusters, a valid [auto-loaded](/vault/docs/enterprise/license/autoloading) license must exist for the upgrade to be successful. ### Q: What scenarios should a customer plan for due to these license changes? -- **New Cluster Deployment**: When a customer deploys new clusters to Vault 1.11 or later, a valid license must exist to successfully deploy. This valid license must be on-disk ([auto-loaded](/docs/enterprise/license/autoloading)). +- **New Cluster Deployment**: When a customer deploys new clusters to Vault 1.11 or later, a valid license must exist to successfully deploy. This valid license must be on-disk ([auto-loaded](/vault/docs/enterprise/license/autoloading)). - **Eventual Migration**: Vault 1.11 removes support for in-storage licenses. Migrating to an auto-loaded license is required for Vault to start successfully using version 1.11 or greater. Pre-existing license storage entries will be automatically removed from storage upon startup. ### Q: What is the migration path for customers who want to migrate from their existing license-as-applied-via-the-CLI flow to the license on disk flow? -If a Vault cluster using a stored license is planned to be upgraded to Vault 1.11 or greater, the operator must migrate to using an auto-loaded license. The [`vault license get -signed`](/docs/v1.10.x/commands/license/get) command (or underlying [`/sys/license/signed`](/api-docs/v1.10.x/system/license#read-signed-license) endpoint) can be used to retrieve the license from storage in a running cluster. -It is not necessary to remove the stored license entry. That will occur automatically upon startup in Vault 1.11 or greater. Prior to completing the [recommended upgrade steps](/docs/upgrading), perform the following to ensure your license is properly configured: +If a Vault cluster using a stored license is planned to be upgraded to Vault 1.11 or greater, the operator must migrate to using an auto-loaded license. The [`vault license get -signed`](/vault/docs/v1.10.x/commands/license/get) command (or underlying [`/sys/license/signed`](/vault/api-docs/v1.10.x/system/license#read-signed-license) endpoint) can be used to retrieve the license from storage in a running cluster. +It is not necessary to remove the stored license entry. That will occur automatically upon startup in Vault 1.11 or greater. Prior to completing the [recommended upgrade steps](/vault/docs/upgrading), perform the following to ensure your license is properly configured: 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`](/docs/commands#vault_license_path) environment variable. +3. Configure license auto-loading by specifying the [`license_path`](/vault/docs/configuration#license_path) config option or setting the [`VAULT_LICENSE`](/vault/docs/commands#vault_license) or [`VAULT_LICENSE_PATH`](/vault/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)? -The downgrade procedure remains the same for Vault customers who are currently on Vault 1.11 or later, have a license installed via auto-loading, and would like to downgrade their cluster to a pre-1.11 version. Please refer to the [upgrade procedures](https://learn.hashicorp.com/tutorials/vault/sop-upgrade?in=vault/standard-procedures) that remind the customers that they must take a snapshot before the upgrade. Customers will need to restore their version from the snapshot, apply the pre-1.11 enterprise binary version they wish to roll back, and bring up the clusters. +The downgrade procedure remains the same for Vault customers who are currently on Vault 1.11 or later, have a license installed via auto-loading, and would like to downgrade their cluster to a pre-1.11 version. Please refer to the [upgrade procedures](/vault/tutorials/standard-procedures/sop-upgrade) that remind the customers that they must take a snapshot before the upgrade. Customers will need to restore their version from the snapshot, apply the pre-1.11 enterprise binary version they wish to roll back, and bring up the clusters. ### Q: Is there a limited time for support of licenses that are in storage? -The support of licenses installed by alternative means often leads to difficulties providing the appropriate support. To provide the support expected by our customers, as we have announced in [Vault feature deprecations and plans](/docs/deprecation) we are removing support for licenses in storage with Vault 1.11. This implies licensing endpoints that deal with licenses in storage will be removed, and Vault will no longer check for valid licenses in storage. This change requires that all customers have [auto-loaded](/docs/enterprise/license/autoloading) licenses to upgrade to 1.11(+) successfully. +The support of licenses installed by alternative means often leads to difficulties providing the appropriate support. To provide the support expected by our customers, as we have announced in [Vault feature deprecations and plans](/vault/docs/deprecation) we are removing support for licenses in storage with Vault 1.11. This implies licensing endpoints that deal with licenses in storage will be removed, and Vault will no longer check for valid licenses in storage. This change requires that all customers have [auto-loaded](/vault/docs/enterprise/license/autoloading) licenses to upgrade to 1.11(+) successfully. ### Q: What are the steps to upgrade from one autoloaded license to another autoloaded license? Follow these steps to migrate from one autoloaded license to another autoloaded license. -1. Use the [`vault license inspect`](/docs/commands/license/inspect) command to compare the new license against the output of the [`vault license get`](/docs/commands/license/get) command. This is to ensure that you have the correct license. +1. Use the [`vault license inspect`](/vault/docs/commands/license/inspect) command to compare the new license against the output of the [`vault license get`](/vault/docs/commands/license/get) command. This is to ensure that you have the correct license. 1. Backup the old license file in a safe location. 1. Replace the old license file on each Vault server with the new one. -1. Invoke the [reload command](/api-docs/system/config-reload#reload-license-file) on each individual Vault server, starting with the standbys and doing the leader last. Invoking in this manner reduces possible disruptions if something was performed incorrectly with the above steps. You can either use the [reload command](/api-docs/system/config-reload#reload-license-file) or send a SIGHUP. -1. On each node, ensure that the new license is in use by using the [`vault license get`](/docs/commands/license/get) command and/or checking the logs. +1. Invoke the [reload command](/vault/api-docs/system/config-reload#reload-license-file) on each individual Vault server, starting with the standbys and doing the leader last. Invoking in this manner reduces possible disruptions if something was performed incorrectly with the above steps. You can either use the [reload command](/vault/api-docs/system/config-reload#reload-license-file) or send a SIGHUP. +1. On each node, ensure that the new license is in use by using the [`vault license get`](/vault/docs/commands/license/get) command and/or checking the logs. # ADP Licensing @@ -155,13 +155,13 @@ As of Vault Enterprise 1.8, the functionality formerly sold as the Vault ADP mod **ADP-KM** includes: -- [Key Management Secrets Engine (KMSE)](/docs/secrets/key-management) -- [Key Management Interoperability (KMIP)](/docs/secrets/kmip) +- [Key Management Secrets Engine (KMSE)](/vault/docs/secrets/key-management) +- [Key Management Interoperability (KMIP)](/vault/docs/secrets/kmip) - [MSSQL Transparent Data Encryption (TDE)](https://www.hashicorp.com/blog/enabling-transparent-data-encryption-for-microsoft-sql-with-vault) **ADP-Transform** includes: -- [Transform Secrets Engine (TSE)](/docs/secrets/transform) +- [Transform Secrets Engine (TSE)](/vault/docs/secrets/transform) ### Q: How can the new ADP modules be purchased and what features are customer entitled to as part of that purchase? diff --git a/website/content/docs/enterprise/license/index.mdx b/website/content/docs/enterprise/license/index.mdx index 60b9c506da..596fc4a68f 100644 --- a/website/content/docs/enterprise/license/index.mdx +++ b/website/content/docs/enterprise/license/index.mdx @@ -6,6 +6,6 @@ description: An overview of license. # Vault License -Licenses and EULA enhancements have been introduced in Vault 1.8 release. Please refer to the [FAQ](/docs/enterprise/license/faq) for common questions concerning these changes. +Licenses and EULA enhancements have been introduced in Vault 1.8 release. Please refer to the [FAQ](/vault/docs/enterprise/license/faq) for common questions concerning these changes. -The [Install a HashiCorp Enterprise License](https://learn.hashicorp.com/tutorials/nomad/hashicorp-enterprise-license?in=vault/enterprise) tutorial provides the instruction to load your Vault license. +The [Install a HashiCorp Enterprise License](/vault/tutorials/enterprise/hashicorp-enterprise-license) tutorial provides the instruction to load your Vault license. diff --git a/website/content/docs/enterprise/managed-keys.mdx b/website/content/docs/enterprise/managed-keys.mdx index a81d9ef2c6..9a9e3c9a5b 100644 --- a/website/content/docs/enterprise/managed-keys.mdx +++ b/website/content/docs/enterprise/managed-keys.mdx @@ -17,11 +17,11 @@ To satisfy these requirements, Vault has a centralized abstraction called delegate these operations to a trusted external KMS. Minimally, a managed key consists of a named managed key entry managed by the -[`sys/managed-key`](/api-docs/system/managed-keys) API. Besides a name, +[`sys/managed-key`](/vault/api-docs/system/managed-keys) API. Besides a name, there are backend specific configurations to access the key in question. For PKCS#11 (HSM) backed managed keys, the managed key configuration must -reference a [kms library stanza](/docs/configuration/kms-library) which points +reference a [kms library stanza](/vault/docs/configuration/kms-library) which points to a PKCS#11 access library on the host machine. Note that a configured, named managed key corresponds to a single key within @@ -42,7 +42,7 @@ Cloud KMS. Support for additional integrations may be added in the future. ## Secret and Auth Engine Support -The [PKI Secrets Engine](/api-docs/secret/pki#managed-keys) has been integrated +The [PKI Secrets Engine](/vault/api-docs/secret/pki#managed-keys) has been integrated with Managed Keys to offer certificate generation, both root and intermediary PKI paths, leveraging private keys from an external trusted KMS. @@ -51,7 +51,7 @@ More engines may leverage managed keys in the future. ## API Managed Keys can be managed over the HTTP API. Please see -[Managed Keys API](/api-docs/system/managed-keys) for more details. +[Managed Keys API](/vault/api-docs/system/managed-keys) for more details. To configure PKI secrets engine with Managed Keys please see -[PKI Secret API](/api-docs/secret/pki#managed-keys) +[PKI Secret API](/vault/api-docs/secret/pki#managed-keys) diff --git a/website/content/docs/enterprise/mfa/index.mdx b/website/content/docs/enterprise/mfa/index.mdx index 295c62e120..cd9d9953c8 100644 --- a/website/content/docs/enterprise/mfa/index.mdx +++ b/website/content/docs/enterprise/mfa/index.mdx @@ -41,7 +41,7 @@ MFA in Vault can be of the following types. ## Configuring MFA Methods MFA methods are globally managed within the `System Backend` using the HTTP API. -Please see [MFA API](/api-docs/system/mfa) for details on how to configure an MFA +Please see [MFA API](/vault/api-docs/system/mfa) for details on how to configure an MFA method. ## MFA Methods In Policies @@ -68,7 +68,7 @@ referenced from ACL and Sentinel policies in any namespace via the method name and can be tied to a mount accessor in any namespace. When using [Sentinel -EGPs](/docs/enterprise/sentinel#endpoint-governing-policies-egps), +EGPs](/vault/docs/enterprise/sentinel#endpoint-governing-policies-egps), any MFA configuration specified must be satisfied by all requests affected by the policy, which can be difficult if the configured paths spread across namespaces. One way to address this is to use a policy similar to the @@ -112,4 +112,4 @@ $ curl \ ### API -MFA can be managed entirely over the HTTP API. Please see [MFA API](/api-docs/system/mfa) for more details. +MFA can be managed entirely over the HTTP API. Please see [MFA API](/vault/api-docs/system/mfa) for more details. diff --git a/website/content/docs/enterprise/namespaces.mdx b/website/content/docs/enterprise/namespaces.mdx index 2e37addb1a..c0ca92408a 100644 --- a/website/content/docs/enterprise/namespaces.mdx +++ b/website/content/docs/enterprise/namespaces.mdx @@ -96,7 +96,7 @@ of delegate admins. Child namespaces can share policies from their parent namespaces. For example, a child namespace may refer to parent identities (entities and groups) when writing policies that function only within that child namespace. Similarly, a parent namespace can have policies asserted on child -identities. This behavior can be configured using the [group-policy-application](/api-docs/system/config-group-policy-application) API, and +identities. This behavior can be configured using the [group-policy-application](/vault/api-docs/system/config-group-policy-application) API, and can be set to allow policies to be applied irrespective of namespace hierarchy, allowing sharing across any namespace. diff --git a/website/content/docs/enterprise/performance-standby.mdx b/website/content/docs/enterprise/performance-standby.mdx index 7882e0ff69..3f33d3199d 100644 --- a/website/content/docs/enterprise/performance-standby.mdx +++ b/website/content/docs/enterprise/performance-standby.mdx @@ -11,7 +11,7 @@ description: Performance Standby Nodes - Vault Enterprise Vault supports a multi-server mode for high availability. This mode protects against outages by running multiple Vault servers. High availability mode is automatically enabled when using a data store that supports it. You can -learn more about HA mode on the [Concepts](/docs/concepts/ha) page. +learn more about HA mode on the [Concepts](/vault/docs/concepts/ha) page. Vault Enterprise offers additional features that allow HA nodes to service read-only requests on the local standby node. Read-only requests are requests @@ -20,7 +20,7 @@ that do not modify Vault's storage. ## Server-to-Server Communication Performance Standbys require the request forwarding method described in the [HA -Server-to-Server](/docs/concepts/ha#server-to-server-communication) docs. +Server-to-Server](/vault/docs/concepts/ha#server-to-server-communication) docs. A performance standby will connect to the active node over the existing request forwarding connection. If selected by the active node to be promoted to a @@ -53,7 +53,7 @@ based on consul configuration). Additionally, if you wish to point your load balancers at performance standby nodes, the `sys/health` endpoint can be used to determine if a node is a -performance standby. See the [sys/health API](/api-docs/system/health) docs for +performance standby. See the [sys/health API](/vault/api-docs/system/health) docs for more info. ## Disabling Performance Standbys diff --git a/website/content/docs/enterprise/pkcs11-provider/aws-xks.mdx b/website/content/docs/enterprise/pkcs11-provider/aws-xks.mdx index 276922deb7..2168b70658 100644 --- a/website/content/docs/enterprise/pkcs11-provider/aws-xks.mdx +++ b/website/content/docs/enterprise/pkcs11-provider/aws-xks.mdx @@ -10,7 +10,7 @@ description: |- ~> **Note**: AWS [`xks-proxy`](https://github.com/aws-samples/aws-kms-xks-proxy) is used in this document as a sample implementation. Vault's KMIP Secrets Engine can be used as an external key store for the AWS KMS [External Key Store (XKS)](https://aws.amazon.com/blogs/aws/announcing-aws-kms-external-key-store-xks/) protocol using the AWS [`xks-proxy`](https://github.com/aws-samples/aws-kms-xks-proxy) along -with the [Vault PKCS#11 Provider](https://developer.hashicorp.com/vault/docs/enterprise/pkcs11-provider). +with the [Vault PKCS#11 Provider](/vault/docs/enterprise/pkcs11-provider). ## Overview @@ -35,9 +35,9 @@ to the desired KMS region. ## Vault Setup -On the Vault server, we need to [setup the KMIP Secrets Engine](/docs/secrets/kmip): +On the Vault server, we need to [setup the KMIP Secrets Engine](/vault/docs/secrets/kmip): -1. Start the [KMIP Secrets Engine](/docs/secrets/kmip) and listener: +1. Start the [KMIP Secrets Engine](/vault/docs/secrets/kmip) and listener: ```sh vault secrets enable kmip @@ -176,11 +176,11 @@ to the XKS proxy. This helps to quickly setup a valid domain and TLS endpoint fo ``` This file is used by `libvault-pkcs11.so` to know how to find and communicate with the KMIP server. - See [the Vault docs](https://developer.hashicorp.com/vault/docs/enterprise/pkcs11-provider) for all available parameters and their usage. + See [the Vault docs](/vault/docs/enterprise/pkcs11-provider) for all available parameters and their usage. 1. If you want to view the Vault logs (helpful when trying to find error messages), you can specify the `VAULT_LOG_FILE` (default is stdout) and `VAULT_LOG_LEVEL` (default is `INFO`). We'd recommend setting `VAULT_LOG_FILE` to something like `/tmp/vault.log` or `/var/log/vault.log`. Other useful log levels are `WARN` (quieter) and `TRACE` (very verbose, could possibly contain sensitive information, like raw network packets). -1. Create an AES-256 key in KMIP, for example, using `pkcs11-tool` (usually installed with the OpenSC package). See the [Vault docs](https://developer.hashicorp.com/vault/docs/enterprise/pkcs11-provider) for the full setup. +1. Create an AES-256 key in KMIP, for example, using `pkcs11-tool` (usually installed with the OpenSC package). See the [Vault docs](/vault/docs/enterprise/pkcs11-provider) for the full setup. ```sh VAULT_LOG_FILE=/dev/null pkcs11-tool --module ./libvault-pkcs11.so --keygen -a abc123 --key-type AES:32 \ --extractable --allow-sw diff --git a/website/content/docs/enterprise/pkcs11-provider/index.mdx b/website/content/docs/enterprise/pkcs11-provider/index.mdx index c344bfb5f5..ce556fdcf2 100644 --- a/website/content/docs/enterprise/pkcs11-provider/index.mdx +++ b/website/content/docs/enterprise/pkcs11-provider/index.mdx @@ -15,7 +15,7 @@ For example, it is often used to access a Hardware Security Module (HSM) (like a Vault provides a PKCS#11 library (or provider) so that Vault can be used as an SSM (Software Security Module). This allows a user to treat Vault like any other PKCS#11 device to manage keys, objects, and perform encryption and decryption in Vault using PKCS#11 calls. -The PKCS#11 library connects to Vault's [KMIP Secrets Engine](/docs/secrets/kmip) to provide cryptographic operations and object storage. +The PKCS#11 library connects to Vault's [KMIP Secrets Engine](/vault/docs/secrets/kmip) to provide cryptographic operations and object storage. ## Platform Support @@ -51,7 +51,7 @@ It can be downloaded from [releases.hashicorp.com](https://releases.hashicorp.co server -dev -dev-root-token-id root -dev-listen-address 0.0.0.0:8200 ``` -1. Configure the [KMIP Secrets Engine](/docs/secrets/kmip) and a KMIP *scope*. The scope is used to hold keys and objects. +1. Configure the [KMIP Secrets Engine](/vault/docs/secrets/kmip) and a KMIP *scope*. The scope is used to hold keys and objects. ~> **Note**: These commands will output the credentials in plaintext. @@ -64,7 +64,7 @@ It can be downloaded from [releases.hashicorp.com](https://releases.hashicorp.co ``` ~> **Important**: When configuring KMIP in production, you will probably need to set the - `server_hostnames` and `server_ips` [configuration parameters](/api-docs/secret/kmip#parameters), + `server_hostnames` and `server_ips` [configuration parameters](/vault/api-docs/secret/kmip#parameters), otherwise the TLS connection to the KMIP Secrets Engine will fail due to certification validation errors. This last line will generate a JSON file with the certificate, key, and CA certificate chain to connect @@ -146,7 +146,7 @@ Most programs will use only one slot. - `tls_cert_path` (required): the location of the client TLS certificate used to authenticate to the KMIP engine. - `tls_key_path` (optional, defaults to the value of `tls_cert_path`): the location of the encrypted or unencrypted TLS key used to authenticate to the KMIP engine. - `ca_path` (required): the location of the CA bundle that will be used to verify the server's certificate. -- `scope` (required): the [KMIP scope](/docs/secrets/kmip#scopes-and-roles) to authenticate against and where the TDE master keys and associated metadata will be stored. +- `scope` (required): the [KMIP scope](/vault/docs/secrets/kmip#scopes-and-roles) to authenticate against and where the TDE master keys and associated metadata will be stored. - `cache` (optional, default `true`): if the provider uses a cache to improve the performance of `C_GetAttributeValue` (KMIP: `GetAttributes`) calls. - `emulate_hardware` (optional, default `false`): specifies if the provider should report that it is connected to a hardware device. diff --git a/website/content/docs/enterprise/pkcs11-provider/oracle-tde.mdx b/website/content/docs/enterprise/pkcs11-provider/oracle-tde.mdx index 7926b6ffc1..b67407f53f 100644 --- a/website/content/docs/enterprise/pkcs11-provider/oracle-tde.mdx +++ b/website/content/docs/enterprise/pkcs11-provider/oracle-tde.mdx @@ -8,7 +8,7 @@ description: |- # Oracle TDE [Oracle Transparent Data Encryption](https://docs.oracle.com/database/121/ASOAG/introduction-to-transparent-data-encryption.htm#ASOAG10270) (TDE) -is supported with the [Vault PKCS#11 provider](/docs/enterprise/pkcs11-provider). +is supported with the [Vault PKCS#11 provider](/vault/docs/enterprise/pkcs11-provider). In this setup, Vault's KMIP engine generates and store the "TDE Master Encryption Key" that the Oracle Database uses to encrypt and decrypt the "TDE Table Keys". Oracle will not have access to the TDE Master Encryption Key itself. @@ -23,7 +23,7 @@ To setup Oracle TDE backed by Vault, the following are required: ## Vault Setup -On the Vault server, we need to [setup the KMIP Secrets Engine](/docs/secrets/kmip): +On the Vault server, we need to [setup the KMIP Secrets Engine](/vault/docs/secrets/kmip): 1. Start the KMIP Secrets Engine and listener: @@ -33,7 +33,7 @@ On the Vault server, we need to [setup the KMIP Secrets Engine](/docs/secrets/km ``` ~> **Important**: When configuring KMIP for Oracle, you will probably need to set the - `server_hostnames` and `server_ips` [configuration parameters](/api-docs/secret/kmip#parameters), + `server_hostnames` and `server_ips` [configuration parameters](/vault/api-docs/secret/kmip#parameters), otherwise the TLS connection to the KMIP Secrets Engine will fail due to certification validation errors. When configuring Oracle TDE, this error can manifest as the `sqlplus` session silently hanging. diff --git a/website/content/docs/enterprise/redundancy-zones.mdx b/website/content/docs/enterprise/redundancy-zones.mdx index 42cb025e05..07a9148a38 100644 --- a/website/content/docs/enterprise/redundancy-zones.mdx +++ b/website/content/docs/enterprise/redundancy-zones.mdx @@ -36,4 +36,4 @@ ensure that Vault is never moving from a more healthy state to a less healthy st wait to begin leadership transfer until it can ensure that there will be as much redundancy on the new Vault version as there was on the old Vault version. -The status of redundancy zones can be monitored by consulting the [Autopilot state API endpoint](/api-docs/system/storage/raftautopilot#get-cluster-state). +The status of redundancy zones can be monitored by consulting the [Autopilot state API endpoint](/vault/api-docs/system/storage/raftautopilot#get-cluster-state). diff --git a/website/content/docs/enterprise/replication.mdx b/website/content/docs/enterprise/replication.mdx index 9f15236c1c..23f1498526 100644 --- a/website/content/docs/enterprise/replication.mdx +++ b/website/content/docs/enterprise/replication.mdx @@ -26,7 +26,7 @@ applications that need to interoperate. Vault replication addresses both of these needs in providing consistency, scalability, and highly-available disaster recovery. -Note: Using replication requires a storage backend that supports transactional updates, such as [Integrated Storage](/docs/concepts/integrated-storage) or Consul. +Note: Using replication requires a storage backend that supports transactional updates, such as [Integrated Storage](/vault/docs/concepts/integrated-storage) or Consul. ## Architecture @@ -107,7 +107,7 @@ $ vault secrets enable -local -path=us_west_data kv-v2 ``` -> **Learn:** Refer to the [Performance Replication with Paths -Filter](https://learn.hashicorp.com/tutorials/vault/paths-filter) tutorial for +Filter](/vault/tutorials/enterprise/paths-filter) tutorial for step-by-step instructions. @@ -125,7 +125,7 @@ They do not forward service read or write requests until they are elected and be -> **Note**: Unlike with Performance Replication, local secret engines, auth methods and audit devices are replicated to a DR secondary. -For more information on the capabilities of performance and disaster recovery replication, see the Vault Replication [API Documentation](/api-docs/system/replication). +For more information on the capabilities of performance and disaster recovery replication, see the Vault Replication [API Documentation](/vault/api-docs/system/replication). ## Primary and Secondary Cluster Compatibility @@ -136,7 +136,7 @@ There is no requirement that both clusters use the same storage engine. ### Seals There is no requirement that both clusters use the same seal type, but see -[sealwrap](/docs/enterprise/sealwrap#seal-wrap-and-replication) for the full +[sealwrap](/vault/docs/enterprise/sealwrap#seal-wrap-and-replication) for the full details. Also note that enabling replication will modify the secondary seal. @@ -158,7 +158,7 @@ Note: Clusters with Shamir seal config do not have separate recovery keys. Auto ### Vault versions Vault changes are designed and tested to ensure that the -[upgrade instructions](/docs/upgrading#replication-installations) are viable, i.e. +[upgrade instructions](/vault/docs/upgrading#replication-installations) are viable, i.e. that a secondary can run a newer Vault version than its primary. That said, we do not recommend running replicated Vault clusters with different @@ -167,7 +167,7 @@ versions any longer than necessary to perform the upgrade. ## Internals Details on the internal design of the replication feature can be found in the -[replication internals](/docs/internals/replication) document. +[replication internals](/vault/docs/internals/replication) document. ## Security Model @@ -233,11 +233,11 @@ Refer to the following tutorials replication setup and best practices: - [Setting up Performance Replication](https://learn.hashicorp.com/vault/operations/ops-replication) - [Disaster Recovery Replication Setup](https://learn.hashicorp.com/vault/operations/ops-disaster-recovery) -- [Performance Replication with Paths Filters](https://learn.hashicorp.com/tutorials/vault/paths-filter) +- [Performance Replication with Paths Filters](/vault/tutorials/enterprise/paths-filter) - [Monitoring Vault Replication](https://learn.hashicorp.com/vault/operations/monitor-replication) ## API The Vault replication component has a full HTTP API. Please see the -[Vault Replication API](/api-docs/system/replication) for more +[Vault Replication API](/vault/api-docs/system/replication) for more details. diff --git a/website/content/docs/enterprise/sealwrap.mdx b/website/content/docs/enterprise/sealwrap.mdx index eb47303ce5..762b12424c 100644 --- a/website/content/docs/enterprise/sealwrap.mdx +++ b/website/content/docs/enterprise/sealwrap.mdx @@ -11,7 +11,7 @@ description: |- -> **Note**: This feature requires [Vault Enterprise Plus](https://www.hashicorp.com/products/vault/). Vault Enterprise features a mechanism to wrap values with an extra layer of -encryption for supporting [seals](/docs/configuration/seal). This adds an +encryption for supporting [seals](/vault/docs/configuration/seal). This adds an extra layer of protection and is useful in some compliance and regulatory environments, including FIPS 140-2 environments. @@ -80,20 +80,20 @@ Seal Wrapping does incur some performance overhead. Some examples of places where seal wrapping is used include: -- The [LDAP](/docs/auth/ldap), [RADIUS](/docs/auth/radius), - [Okta](/docs/auth/okta), and [AWS](/docs/auth/aws) auth methods, +- The [LDAP](/vault/docs/auth/ldap), [RADIUS](/vault/docs/auth/radius), + [Okta](/vault/docs/auth/okta), and [AWS](/vault/docs/auth/aws) auth methods, for storing their config. -- [PKI](/docs/secrets/pki) for storing the issuers and their keys, -- [SSH](/docs/secrets/ssh) for storing the CA's keys, -- [KMIP](/docs/secrets/kmip) for storing managed objects (externally-provided +- [PKI](/vault/docs/secrets/pki) for storing the issuers and their keys, +- [SSH](/vault/docs/secrets/ssh) for storing the CA's keys, +- [KMIP](/vault/docs/secrets/kmip) for storing managed objects (externally-provided keys) and its CA keys. -- [Transit](/docs/secrets/transit) for storing keys and their policy. +- [Transit](/vault/docs/secrets/transit) for storing keys and their policy. ## FIPS Status -See the [FIPS-specific Seal Wrap documentation](/docs/enterprise/fips/sealwrap) +See the [FIPS-specific Seal Wrap documentation](/vault/docs/enterprise/fips/sealwrap) for more information about using Seal Wrapping to achieve FIPS 140-2 compliance. -Note that there are additional [FIPS considerations](/docs/enterprise/sealwrap#seal-wrap-and-replication) +Note that there are additional [FIPS considerations](/vault/docs/enterprise/sealwrap#seal-wrap-and-replication) regarding Seal Wrap usage and Vault Replication. -[configuration]: /docs/configuration +[configuration]: /vault/docs/configuration diff --git a/website/content/docs/enterprise/sentinel/index.mdx b/website/content/docs/enterprise/sentinel/index.mdx index bf621b7f97..a2a995c9ca 100644 --- a/website/content/docs/enterprise/sentinel/index.mdx +++ b/website/content/docs/enterprise/sentinel/index.mdx @@ -19,7 +19,7 @@ the form of multiple types of policies and a fixed evaluation order. Vault's policy system has been expanded to support three types of policies: - `ACLs` - These are the [traditional Vault - policies](/docs/concepts/policies) and remain unchanged. + policies](/vault/docs/concepts/policies) and remain unchanged. - `Role Governing Policies (RGPs)` - RGPs are Sentinel policies that are tied to particular tokens, Identity entities, or Identity groups. They have access @@ -35,7 +35,7 @@ to root token generation cannot support EGPs because it's already the mechanism of last resort if, for instance, all clients are locked out of Vault due to misconfigured EGPs. -Like with ACLs, [root tokens](/docs/concepts/tokens#root-tokens) +Like with ACLs, [root tokens](/vault/docs/concepts/tokens#root-tokens) are not subject to Sentinel policy checks. Sentinel execution should be considered to be significantly slower than normal @@ -71,7 +71,7 @@ logged as warnings in Vault's server logs. ## MFA Sentinel policies support the [Identity-based MFA -system](/docs/enterprise/mfa) in Vault Enterprise. Within a single +system](/vault/docs/enterprise/mfa) in Vault Enterprise. Within a single request, multiple checks of any named MFA method will only trigger authentication behavior for that method once, regardless of whether its validity is checked via ACLs, RGPs, or EGPs. @@ -89,7 +89,7 @@ able to glean from the original request alone. Sentinel policies can be configured via the `sys/policies/rgp/` and `sys/policies/egp/` endpoints; see [the -documentation](/api-docs/system/policies) for more information. +documentation](/vault/api-docs/system/policies) for more information. Once set, RGPs can be assigned to Identity entities and groups or to tokens just like ACL policies. As a result, they cannot share names with ACL policies. @@ -105,9 +105,9 @@ effect on all requests. ## Properties and Examples -See the [Examples](/docs/enterprise/sentinel/examples) page for examples +See the [Examples](/vault/docs/enterprise/sentinel/examples) page for examples of Sentinel in action, and the -[Properties](/docs/enterprise/sentinel/properties) page for detailed +[Properties](/vault/docs/enterprise/sentinel/properties) page for detailed property documentation. ## Tutorial diff --git a/website/content/docs/faq/ssct.mdx b/website/content/docs/faq/ssct.mdx index 4cc01d94b7..9225a41e11 100644 --- a/website/content/docs/faq/ssct.mdx +++ b/website/content/docs/faq/ssct.mdx @@ -23,11 +23,11 @@ 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](/vault/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. -To help with such cases, we’ve now added support for the Server Side Consistent Tokens feature in Vault version 1.10. See [Replication](/docs/configuration/replication), [Vault Eventual Consistency](/docs/enterprise/consistency), and [Upgrade to 1.10](/docs/upgrading/upgrade-to-1.10.x). +To help with such cases, we’ve now added support for the Server Side Consistent Tokens feature in Vault version 1.10. See [Replication](/vault/docs/configuration/replication), [Vault Eventual Consistency](/vault/docs/enterprise/consistency), and [Upgrade to 1.10](/vault/docs/upgrading/upgrade-to-1.10.x). This feature provides a way for Service tokens, returned from logins (or token create requests), to have the relevant minimum WAL state information embedded within the token itself. Clients can then use this token to authenticate subsequent requests. Thus, clients can obtain read-after-write consistency for the token without typically having to make changes to their code or architecture. If a performance standby does not have the state required to authenticate the token, it returns a 412 error to allow the client to retry. If client retry is not possible, there is a server config to allow for the consistency. @@ -39,7 +39,7 @@ For the sake of standardization between OSS and Enterprise, and due to the value Server Side Consistent Tokens introduces the following key changes: -- Token length : Server side consistent tokens are longer, being 95+ characters as opposed to 27+ characters. Since the token can be subject to change (see [Token](/docs/concepts/tokens)), we recommend that you plan for a maximum length of 255 bytes to future proof yourself if you have workflows that rely on the token size. +- Token length : Server side consistent tokens are longer, being 95+ characters as opposed to 27+ characters. Since the token can be subject to change (see [Token](/vault/docs/concepts/tokens)), we recommend that you plan for a maximum length of 255 bytes to future proof yourself if you have workflows that rely on the token size. - By default, Vault 1.10 will use the new token prefixes and new token format. - Tokens don't visibly have a ".namespaceID" suffix - Token prefix: Token prefixes are being changed as follows: @@ -73,25 +73,25 @@ Yes, there are several considerations to keep in mind, and possibly things that - As stated earlier, if a performance standby does not have the state required to authenticate the token, it returns a 412 error allowing the client to retry. - Ensure that your clients can retry for the best experience. -- Starting with Go api version [1.1.0](https://pkg.go.dev/github.com/hashicorp/vault/api@v1.1.0), the Go client library enables automatic retries for 412 errors. By default, retries=2, or use client method [SetMaxRetries](https://pkg.go.dev/github.com/hashicorp/vault/api#Client.SetMaxRetries). Or, you can use the Vault environment variable [VAULT_MAX_RETRIES](/docs/commands#vault_max_retries) to achieve the same result. +- Starting with Go api version [1.1.0](https://pkg.go.dev/github.com/hashicorp/vault/api@v1.1.0), the Go client library enables automatic retries for 412 errors. By default, retries=2, or use client method [SetMaxRetries](https://pkg.go.dev/github.com/hashicorp/vault/api#Client.SetMaxRetries). Or, you can use the Vault environment variable [VAULT_MAX_RETRIES](/vault/docs/commands#vault_max_retries) to achieve the same result. - If you use a client library other than Go, you may still need to ensure that your client can handle 412 retries in order to achieve consistency. - If your client cannot retry, you can use the Vault server replication configuration `allow_forwarding_via_token = ["new_token"]` to allow for consistency. As stated earlier, this will incur extra load on the server due to forwarding of requests that don't have the up-to-date WAL-state to the server. -~> **Note:** If you are generating root tokens or recovery tokens without using the Vault CLI, you will need to modify the OTP length used. refer [here](/docs/upgrading/upgrade-to-1.10.x) for details. +~> **Note:** If you are generating root tokens or recovery tokens without using the Vault CLI, you will need to modify the OTP length used. refer [here](/vault/docs/upgrading/upgrade-to-1.10.x) for details. ### Q: What do I need to be paying attention to if I rely on tokens for some of my workflows? -Our documentation on [tokens](/docs/concepts/tokens) clearly identifies that the token body itself is subject to change between versions and should not be relied on. We strongly recommend that you consider this while architecting your environment. +Our documentation on [tokens](/vault/docs/concepts/tokens) clearly identifies that the token body itself is subject to change between versions and should not be relied on. We strongly recommend that you consider this while architecting your environment. -However, if you use scripting and tooling to help in the authentication process for Vault-dependent applications, it is important that you take time to understand the changes (see [Replication](/docs/configuration/replication), [Vault Eventual Consistency](/docs/enterprise/consistency), and [Upgrade to 1.10](/docs/upgrading/upgrade-to-1.10.x)), and test these changes in your specific dev environments before deploying this in production. +However, if you use scripting and tooling to help in the authentication process for Vault-dependent applications, it is important that you take time to understand the changes (see [Replication](/vault/docs/configuration/replication), [Vault Eventual Consistency](/vault/docs/enterprise/consistency), and [Upgrade to 1.10](/vault/docs/upgrading/upgrade-to-1.10.x)), and test these changes in your specific dev environments before deploying this in production. -If your workflow used the embedded NamespaceID suffix, you will need to perform a [token lookup](/docs/commands/token/lookup) because this is currently absent in the new tokens. +If your workflow used the embedded NamespaceID suffix, you will need to perform a [token lookup](/vault/docs/commands/token/lookup) because this is currently absent in the new tokens. ### Q: What are the main mitigation options that Vault offers to achieve consistency, and what are the differences between them? Vault offers the following options to achieve consistency: -- [Client based mitigations](/docs/enterprise/consistency#vault-1-7-mitigations), which was added in Vault Release 1.7, depend on some modifications to clients to include per request header options to ‘always forward the request to the active node’ OR to ‘conditionally forward the request to the active node’ if it would otherwise result in a stale read OR to ‘fail requests’ with error 412 if they might result in a stale read. +- [Client based mitigations](/vault/docs/enterprise/consistency#vault-1-7-mitigations), which was added in Vault Release 1.7, depend on some modifications to clients to include per request header options to ‘always forward the request to the active node’ OR to ‘conditionally forward the request to the active node’ if it would otherwise result in a stale read OR to ‘fail requests’ with error 412 if they might result in a stale read. - The Vault Agent can also be leveraged for proxied requests to achieve consistency via the above mitigations without client modifications - Server Side Consistent Tokens, added in Vault version 1.10, provide a more implicit way to achieve consistency, but only addresses consistency for new tokens. @@ -113,4 +113,4 @@ Finally, when speaking of performance implications above, there are two kinds th ### Q: Is this feature something I need with Consul Storage? -Consul has a [default consistency model](https://developer.hashicorp.com/consul/api-docs/features/consistency) and this feature is not relevant with Consul storage. +Consul has a [default consistency model](/consul/api-docs/features/consistency) and this feature is not relevant with Consul storage. diff --git a/website/content/docs/get-started/developer-qs.mdx b/website/content/docs/get-started/developer-qs.mdx index b19a37bb9d..4cc34f86cf 100644 --- a/website/content/docs/get-started/developer-qs.mdx +++ b/website/content/docs/get-started/developer-qs.mdx @@ -20,14 +20,14 @@ For an out-of-the-box runnable demo application showcasing these concepts and mo ## Prerequisites -- [Docker](https://docs.docker.com/get-docker/) or a [local installation](https://learn.hashicorp.com/tutorials/vault/getting-started-install?in=vault/getting-started) of the Vault binary +- [Docker](https://docs.docker.com/get-docker/) or a [local installation](/vault/tutorials/getting-started/getting-started-install) of the Vault binary - A development environment applicable to one of the languages in this quick start (currently **Go**, **Ruby**, **C#**, **Python**, **Java (Spring)**, and **Bash (curl)**) -> **Note**: Make sure you are using the [latest version](https://docs.docker.com/engine/release-notes/) of Docker. Older versions may not work. As of 1.12.0, the recommended version of Docker is 20.10.17 or higher. ## Step 1: Start Vault -!> **Warning**: This in-memory “dev” server is useful for practicing with Vault locally for the first time, but is insecure and **should never be used in production**. For developers who need to manage their own production Vault installations, this [page](https://learn.hashicorp.com/tutorials/vault/production-hardening) provides some guidance on how to make your setup more production-friendly. +!> **Warning**: This in-memory “dev” server is useful for practicing with Vault locally for the first time, but is insecure and **should never be used in production**. For developers who need to manage their own production Vault installations, this [page](/vault/tutorials/operations/production-hardening) provides some guidance on how to make your setup more production-friendly. Run the Vault server in a non-production "dev" mode in one of the following ways: @@ -45,7 +45,7 @@ $ vault server -dev -dev-root-token-id="dev-only-token" The `-dev-root-token-id` flag for dev servers tells the Vault server to allow full root access to anyone who presents a token with the specified value (in this case "dev-only-token"). -!> **Warning**: The [root token](https://www.vaultproject.io/docs/concepts/tokens#root-tokens) is useful for development, but allows full access to all data and functionality of Vault, so it must be carefully guarded in production. Ideally, even an administrator of Vault would use their own token with limited privileges instead of the root token. +!> **Warning**: The [root token](/vault/docs/concepts/tokens#root-tokens) is useful for development, but allows full access to all data and functionality of Vault, so it must be carefully guarded in production. Ideally, even an administrator of Vault would use their own token with limited privileges instead of the root token. Vault is now listening over HTTP on port **8200**. With all the setup out of the way, it's time to get coding! @@ -174,7 +174,7 @@ import org.springframework.vault.core.VaultTemplate; ## Step 3: Authenticate to Vault -A variety of [authentication methods](/docs/auth) can be used to prove your application's identity to the Vault server. To explore more secure authentication methods, such as via Kubernetes or your cloud provider, see the auth code snippets in the [vault-examples](https://github.com/hashicorp/vault-examples) repository. +A variety of [authentication methods](/vault/docs/auth) can be used to prove your application's identity to the Vault server. To explore more secure authentication methods, such as via Kubernetes or your cloud provider, see the auth code snippets in the [vault-examples](https://github.com/hashicorp/vault-examples) repository. To keep things simple for our example, we'll just use the root token created in **Step 1**. Paste the following code to initialize a new Vault client that will use token-based authentication for all its requests: @@ -306,7 +306,7 @@ curl \ -A common way of storing secrets is as key-value pairs using the [KV secrets engine (v2)](/docs/secrets/kv/kv-v2). In the code we've just added, `password` is the key in the key-value pair, and `Hashi123` is the value. +A common way of storing secrets is as key-value pairs using the [KV secrets engine (v2)](/vault/docs/secrets/kv/kv-v2). In the code we've just added, `password` is the key in the key-value pair, and `Hashi123` is the value. We also provided the path to our secret in Vault. We will reference this path in a moment when we learn how to retrieve our secret. @@ -428,4 +428,4 @@ For more secure examples of client authentication, see the auth snippets in the For a runnable demo app that demonstrates more features, for example, how to keep your connection to Vault alive and how to connect to a database using Vault's dynamic database credentials, see the sample application hello-vault ([Go](https://github.com/hashicorp/hello-vault-go), [C#](https://github.com/hashicorp/hello-vault-dotnet)). -To learn how to integrate applications with Vault without needing to always change your application code, see the [Vault Agent](https://www.vaultproject.io/docs/agent) documentation. +To learn how to integrate applications with Vault without needing to always change your application code, see the [Vault Agent](/vault/docs/agent) documentation. diff --git a/website/content/docs/glossary.mdx b/website/content/docs/glossary.mdx index c189393c54..88e751a93d 100644 --- a/website/content/docs/glossary.mdx +++ b/website/content/docs/glossary.mdx @@ -53,7 +53,7 @@ policies. This token is passed via HTTP headers. ### Plugin Plugins are a feature of Vault that can be enabled, disabled, and customized to -some degree. All Vault [auth methods](/docs/auth) and [secrets engines](/docs/secrets) +some degree. All Vault [auth methods](/vault/docs/auth) and [secrets engines](/vault/docs/secrets) are considered plugins. #### Built-in Plugin @@ -72,7 +72,7 @@ spawned. #### External Multiplexed Plugin -An external plugin may make use of [plugin multiplexing](/docs/plugins/plugin-architecture#plugin-multiplexing). +An external plugin may make use of [plugin multiplexing](/vault/docs/plugins/plugin-architecture#plugin-multiplexing). A multiplexed plugin allows a single plugin process to be used for multiple mounts of the same type. diff --git a/website/content/docs/index.mdx b/website/content/docs/index.mdx index 287db76901..c18e1198c4 100644 --- a/website/content/docs/index.mdx +++ b/website/content/docs/index.mdx @@ -7,4 +7,4 @@ description: |- # 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](https://learn.hashicorp.com/tutorials/vault/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](/vault/docs/what-is-vault) instead, and work your way up to the [Getting Started](/vault/tutorials/getting-started/getting-started-install) guide. diff --git a/website/content/docs/install.mdx b/website/content/docs/install.mdx index 9e7946e883..be2f480b43 100644 --- a/website/content/docs/install.mdx +++ b/website/content/docs/install.mdx @@ -15,7 +15,7 @@ There are several options to install Vault: 1. Install [from source](#compiling-from-source). -1. [Helm for Kubernetes](https://www.vaultproject.io/docs/platform/k8s/helm) +1. [Helm for Kubernetes](/vault/docs/platform/k8s/helm) ## Package Manager @@ -27,7 +27,7 @@ install. ## Precompiled Binaries -To install the precompiled binary, [download](/downloads) the applicable +To install the precompiled binary, [download](/vault/downloads) the applicable package for your system. Vault is packaged as a zip file. Once the zip is downloaded, unzip the file into your designated directory. The `vault` binary diff --git a/website/content/docs/internals/architecture.mdx b/website/content/docs/internals/architecture.mdx index 742384aadc..1abe2c7617 100644 --- a/website/content/docs/internals/architecture.mdx +++ b/website/content/docs/internals/architecture.mdx @@ -32,7 +32,7 @@ which is then used to decrypt the Vault's root key. ![Unseal keys](/img/vault-shamir-seal.png) -Refer to the [Seal/Unseal](/docs/concepts/seal#seal-unseal) documentation for +Refer to the [Seal/Unseal](/vault/docs/concepts/seal#seal-unseal) documentation for further details. The number of shares and the minimum number of shards required can both be specified. @@ -43,7 +43,7 @@ Vault loads the configured audit devices, auth methods, and secrets engines. ~> **Note:** The default Vault configuration uses a Shamir seal; however, Vault can be [auto -unsealed](/docs/concepts/seal#auto-unseal) by a trusted cloud key management +unsealed](/vault/docs/concepts/seal#auto-unseal) by a trusted cloud key management system (KMS) or hardware security module (HSM) to increase security. The configuration of the audit devices, auth methods, and secrets engines are security sensitive and are stored in Vault. Users with permissions can modify them and cannot be specified outside of the barrier. By storing them in Vault, changes are protected by the ACL system and tracked by audit logs. @@ -84,4 +84,4 @@ flow, the core performs specific background activities. Lease management is crit - To learn more about each components and sub-systems within Vault, select a topic from the left-navigation menu. - For in depth details, consult the code. -- To get started with Vault, try out our [Getting Started](https://learn.hashicorp.com/collections/vault/getting-started) tutorial. +- To get started with Vault, try out our [Getting Started](/vault/tutorials/getting-started) tutorial. diff --git a/website/content/docs/internals/high-availability.mdx b/website/content/docs/internals/high-availability.mdx index e68ac468b8..f597b5cdb5 100644 --- a/website/content/docs/internals/high-availability.mdx +++ b/website/content/docs/internals/high-availability.mdx @@ -52,8 +52,8 @@ network connectivity. Refer to the following tutorials to learn more. -- [Vault with Integrated Storage Reference Architecture](https://learn.hashicorp.com/tutorials/vault/raft-reference-architecture) -- [Vault HA Cluster with Integrated Storage](https://learn.hashicorp.com/tutorials/vault/raft-storage) -- [Vault High Availability with Consul](https://learn.hashicorp.com/tutorials/vault/ha-with-consul) -- [Performance Standby Nodes](https://learn.hashicorp.com/tutorials/vault/performance-standbys) +- [Vault with Integrated Storage Reference Architecture](/vault/tutorials/day-one-raft/raft-reference-architecture) +- [Vault HA Cluster with Integrated Storage](/vault/tutorials/raft/raft-storage) +- [Vault High Availability with Consul](/vault/tutorials/day-one-consul/ha-with-consul) +- [Performance Standby Nodes](/vault/tutorials/enterprise/performance-standbys) diff --git a/website/content/docs/internals/integrated-storage.mdx b/website/content/docs/internals/integrated-storage.mdx index c6ccf78b0c..c49aba3ca6 100644 --- a/website/content/docs/internals/integrated-storage.mdx +++ b/website/content/docs/internals/integrated-storage.mdx @@ -41,7 +41,7 @@ There are a few key terms to know when discussing Raft: - **Leader** - At any given time, the peer set elects a single node to be the leader. The leader is responsible for ingesting new log entries, replicating to followers, -and managing when an entry is committed. The leader node is also the active Vault node and followers are standby nodes. Refer to the [High Availability](/docs/internals/high-availability#design-overview) document for more information. +and managing when an entry is committed. The leader node is also the active Vault node and followers are standby nodes. Refer to the [High Availability](/vault/docs/internals/high-availability#design-overview) document for more information. - **Log** - An ordered sequence of entries (replicated log) to keep track of any cluster changes. The leader is responsible for _log replication_. When new data is written, for example, a new event creates a log entry. The leader then sends the new log entry to its followers. Any inconsistency within the replicated log entries will indicate an issue. @@ -118,7 +118,7 @@ Thus, performance is bound by disk I/O and network latency. ### Raft in Vault When getting started, a single Vault server is -[initialized](/docs/commands/operator/init/#operator-init). At this point, the +[initialized](/vault/docs/commands/operator/init/#operator-init). At this point, the cluster is of size 1, which allows the node to self-elect as a leader. Once a leader is elected, other servers can be added to the peer set in a way that preserves consistency and safety. @@ -140,13 +140,13 @@ will be encrypted by Vault's barrier. Vault does not currently offer automated dead server cleanup. If you wish to decommission a node, or a node dies and must be replaced, the node must manually -be removed from the cluster with the `remove peer` [command](/docs/commands/operator/raft#remove-peer). +be removed from the cluster with the `remove peer` [command](/vault/docs/commands/operator/raft#remove-peer). ### Quorum Management #### Autopilot -An [Autopilot feature](https://www.vaultproject.io/docs/concepts/integrated-storage/autopilot) +An [Autopilot feature](/vault/docs/concepts/integrated-storage/autopilot) is available since 1.7.x & later versions that include configurable parameters for when a node is treated as healthy before it's considered an eligible voter in the quorum list. Other features which may be enabled include the ability to remove nodes @@ -164,9 +164,9 @@ counted as voters before they are capable of voting. As of Vault 1.7, a dead server cleanup capability is available. With this feature enabled, unhealthy nodes are automatically removed from the Raft cluster without -manual operator intervention. This is enabled via the [Autopilot API](/api-docs/system/storage/raftautopilot). +manual operator intervention. This is enabled via the [Autopilot API](/vault/api-docs/system/storage/raftautopilot). If you wish to decommission a node manually, this can be done with the -`remove peer` [command](/docs/commands/operator/raft#remove-peer). +`remove peer` [command](/vault/docs/commands/operator/raft#remove-peer). #### Without Autopilot @@ -250,7 +250,7 @@ failure scenario. ### Minimums & Scaling -The [Vault Reference Architecture](https://learn.hashicorp.com/tutorials/vault/raft-reference-architecture#recommended-architecture) +The [Vault Reference Architecture](/vault/tutorials/day-one-raft/raft-reference-architecture#recommended-architecture) recommends a 5 node cluster to ensure a minimum failure tolerance of at least 2. It is good practise, wherever possible, to retain a failure tolerance of 2 or diff --git a/website/content/docs/internals/limits.mdx b/website/content/docs/internals/limits.mdx index 86c52edb08..1f4550deac 100644 --- a/website/content/docs/internals/limits.mdx +++ b/website/content/docs/internals/limits.mdx @@ -24,11 +24,11 @@ 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://developer.hashicorp.com/consul/docs/agent/config/config-files#kv_max_value_size) parameter, introduced in version 1.5.3. +[`kv_max_value_size`](/consul/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 -the [storage stanza](/docs/configuration/storage/raft#max_entry_size). +the [storage stanza](/vault/docs/configuration/storage/raft#max_entry_size). Many of the other limits within Vault derive from the maximum size of a storage entry, as described in the next sections. It is possible to @@ -58,8 +58,8 @@ Specifying distinct per-mount options, or using long mount point paths, can increase the space required per mount. The number of mount points can be monitored by reading the -[`sys/auth`](/api-docs/system/auth) and -[`sys/mounts`](/api-docs/system/mounts) endpoints from the root namespace and +[`sys/auth`](/vault/api-docs/system/auth) and +[`sys/mounts`](/vault/api-docs/system/mounts) endpoints from the root namespace and similar sub-paths for namespaces respectively, like: `namespace1/sys/auth`, `namespace1/sys/mounts`, etc. @@ -81,7 +81,7 @@ path element. 160 nested paths = 160 namespaces ranging from 40 bytes to 6400 bytes. The number of namespaces can be monitored by querying -[`sys/namespaces`](/api-docs/system/namespaces). +[`sys/namespaces`](/vault/api-docs/system/namespaces). To estimate the number of namespaces that can be created, divide the mount point limit by the larger of the number of auth mounts per namespace @@ -132,7 +132,7 @@ group has a large number of members. | Maximum number of groups (100 entities per group) | ~22,000 | ~50,000 | | Maximum number of members in a group | ~11,500 | ~23,000 | -The number of entities can be monitored using Vault's [telemetry](/docs/internals/telemetry#token-identity-and-lease-metrics); see `vault.identity.num_entities` (total) or `vault.identity.entities.count` (by namespace). +The number of entities can be monitored using Vault's [telemetry](/vault/docs/internals/telemetry#token-identity-and-lease-metrics); see `vault.identity.num_entities` (total) or `vault.identity.entities.count` (by namespace). The cost of entity and group updates grows as the number of objects in each shard increases. This cost can be monitored via the @@ -141,7 +141,7 @@ the `vault.identity.upsert_group_txn` metrics. Very large internal groups should be avoided (more than 1000 members), because the membership list in a group must reside in a single storage entry. -Instead, consider using [external groups](/docs/concepts/identity#external-vs-internal-groups) or split the group up into multiple sub-groups. +Instead, consider using [external groups](/vault/docs/concepts/identity#external-vs-internal-groups) or split the group up into multiple sub-groups. ### Token limits @@ -175,7 +175,7 @@ policies attached to that token, to the entity, to any groups that the entity belongs to, and recursively to any groups that contain those groups. Very large numbers of policies are possible, but can cause Vault’s response time to increase. You can monitor the -[`vault.core.fetch_acl_and_token`](/docs/internals/telemetry#core-metrics) +[`vault.core.fetch_acl_and_token`](/vault/docs/internals/telemetry#core-metrics) metric to determine if the time required to assemble an access control list is becoming excessive. @@ -229,18 +229,18 @@ This limit depends on the key size. ### Request size The maximum size of an HTTP request sent to Vault is limited by -the `max_request_size` option in the [listener stanza](/docs/configuration/listener/tcp). It defaults to 32 MiB. This value, minus the overhead of +the `max_request_size` option in the [listener stanza](/vault/docs/configuration/listener/tcp). It defaults to 32 MiB. This value, minus the overhead of the HTTP request itself, places an upper bound on any Transit operation, and on the maximum size of any key-value secrets. ### Request duration The maximum duration of a Vault operation is -[`max_request_duration`](/docs//configuration/listener/tcp), which defaults to +[`max_request_duration`](/vault/docs//configuration/listener/tcp), which defaults to 90 seconds. If a particular secret engine takes longer than this to perform an operation on a remote service, the Vault client will see a failure. -The environment variable [`VAULT_CLIENT_TIMEOUT`](https://www.vaultproject.io/docs/commands#vault_client_timeout) sets a client-side maximum duration as well, +The environment variable [`VAULT_CLIENT_TIMEOUT`](/vault/docs/commands#vault_client_timeout) sets a client-side maximum duration as well, which is 60 seconds by default. ### Cluster and replication limits @@ -263,8 +263,8 @@ maximum number of replicas has been exceeded. ### Lease limits -A systemwide [maximum TTL](/docs/configuration#max_lease_ttl), and a -[maximum TTL per mount point](/api-docs/system/mounts#max_lease_ttl-1) can be +A systemwide [maximum TTL](/vault/docs/configuration#max_lease_ttl), and a +[maximum TTL per mount point](/vault/api-docs/system/mounts#max_lease_ttl-1) can be configured. Although no technical maximum exists, high lease counts can cause @@ -278,17 +278,17 @@ unexpired leases, or a large number of simultaneous expirations. | Maximum duration of lease or token | 768 hours by default | The current number of unexpired leases can be monitored via the -[`vault.expire.num_leases`](/docs/internals/telemetry#token-identity-and-lease-metrics) metric. +[`vault.expire.num_leases`](/vault/docs/internals/telemetry#token-identity-and-lease-metrics) metric. ### Transform limits The Transform secret engine obeys the [FF3-1 minimum and maximum sizes -on the length of an input](/docs/secrets/transform#input-limits), which +on the length of an input](/vault/docs/secrets/transform#input-limits), which are a function of the alphabet size. ### External plugin limits -The [plugin system](/docs/plugins) launches a separate process +The [plugin system](/vault/docs/plugins) launches a separate process initiated by Vault that communicates over RPC. For each secret engine and auth method that's enabled as an external plugin, Vault will spawn a process on the host system. For the Database Secrets Engines, external database plugins will diff --git a/website/content/docs/internals/replication.mdx b/website/content/docs/internals/replication.mdx index 933d8fb706..b8b2d55677 100644 --- a/website/content/docs/internals/replication.mdx +++ b/website/content/docs/internals/replication.mdx @@ -215,7 +215,7 @@ primary. version of Vault to an older version. When upgrading replicated clusters, ensure that upstream clusters are always on older version of Vault than downstream clusters. See -[Upgrading Vault](/docs/upgrading#replication-installations) for an example. +[Upgrading Vault](/vault/docs/upgrading#replication-installations) for an example. - **Read-After-Write Consistency**: All write requests are forwarded from secondaries to the primary cluster in order to avoid potential conflicts. @@ -225,7 +225,7 @@ downstream clusters. See client making subsequent requests by stalling write requests until the write is replicated or a timeout is reached (2 seconds). If the timeout is reached, the client will receive a warning. Clients can also take steps to protect - against this, see [Consistency](/docs/enterprise/consistency#mitigations). + against this, see [Consistency](/vault/docs/enterprise/consistency#mitigations). - **Stale Reads**: Secondary clusters service reads based on their locally-replicated data. During normal operation updates from a primary are diff --git a/website/content/docs/internals/rotation.mdx b/website/content/docs/internals/rotation.mdx index c0de2a4805..519b50b8be 100644 --- a/website/content/docs/internals/rotation.mdx +++ b/website/content/docs/internals/rotation.mdx @@ -9,7 +9,7 @@ description: Learn about the details of key rotation within Vault. Vault has multiple encryption keys that are used for various purposes. These keys support rotation so that they can be periodically changed or in response to a potential leak or compromise. It is useful to first understand the -[high-level architecture](/docs/internals/architecture) before learning about key rotation. +[high-level architecture](/vault/docs/internals/architecture) before learning about key rotation. As a review, Vault starts in a _sealed_ state. Vault is unsealed by providing the unseal keys. By default, Vault uses a technique known as [Shamir's secret sharing algorithm](https://en.wikipedia.org/wiki/Shamir's_Secret_Sharing) diff --git a/website/content/docs/internals/security.mdx b/website/content/docs/internals/security.mdx index a23565889e..c8bac254a3 100644 --- a/website/content/docs/internals/security.mdx +++ b/website/content/docs/internals/security.mdx @@ -95,8 +95,8 @@ All server-to-server traffic between Vault instances within a cluster (i.e, high availability, enterprise replication or integrated storage) uses mutually-authenticated TLS to ensure the confidentiality and integrity of data in transit. Nodes are authenticated prior to joining the cluster by an -[unseal challenge](/docs/concepts/integrated-storage#vault-networking-recap) or -a [one-time-use activation token](/docs/enterprise/replication#security-model). +[unseal challenge](/vault/docs/concepts/integrated-storage#vault-networking-recap) or +a [one-time-use activation token](/vault/docs/enterprise/replication#security-model). The storage backends used by Vault are also untrusted by design. Vault uses a security barrier for all requests made to the backend. The security barrier @@ -141,7 +141,7 @@ client), the highest access level permitted is used. For example, if the "ops" policy permits read access to the "ops/" path, then the user gets the union of those. Policy is matched using the most specific defined policy, which may be an exact match or the longest-prefix match glob pattern. See -[Policy Syntax](/docs/concepts/policies#policy-syntax) for more details. +[Policy Syntax](/vault/docs/concepts/policies#policy-syntax) for more details. Certain operations are only permitted by "root" users, which is a distinguished policy built into Vault. This is similar to the concept of a root user on a diff --git a/website/content/docs/internals/telemetry.mdx b/website/content/docs/internals/telemetry.mdx index 304ba1c8c8..9d0c293bc0 100644 --- a/website/content/docs/internals/telemetry.mdx +++ b/website/content/docs/internals/telemetry.mdx @@ -232,7 +232,7 @@ These metrics are emitted on standbys when talking to the active node, and in so ## Replication Metrics -These metrics relate to [Vault Enterprise Replication](/docs/enterprise/replication). The following metrics are not available in telemetry unless replication is in an unhealthy state: `replication.fetchRemoteKeys`, `replication.merkleDiff`, and `replication.merkleSync`. +These metrics relate to [Vault Enterprise Replication](/vault/docs/enterprise/replication). The following metrics are not available in telemetry unless replication is in an unhealthy state: `replication.fetchRemoteKeys`, `replication.merkleDiff`, and `replication.merkleSync`. | Metric | Description | Unit | Type | | :------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------- | :-------------- | :------ | @@ -509,7 +509,7 @@ indicate flapping leadership. ## Integrated Storage (Raft) Automated Snapshots -These metrics related to the Enterprise feature [Raft Automated Snapshots](/docs/enterprise/automated-integrated-storage-snapshots). +These metrics related to the Enterprise feature [Raft Automated Snapshots](/vault/docs/enterprise/automated-integrated-storage-snapshots). | Metric | Description | Unit | Type | | :------------------------------------------ | :-------------------------------------------------------------------------------------------- | :--------- | :------ | @@ -538,48 +538,48 @@ These metrics related to the Enterprise feature [Raft Automated Snapshots](/docs | `node_id` | Unique identifier of a raft peer, same as peer_id. | `node-1` | | `snapshot_config_name` | For automated snapshots, the name of the configuration | `config1` | -[secrets-engines]: /docs/secrets +[secrets-engines]: /vault/docs/secrets -[storage-backends]: /docs/configuration/storage +[storage-backends]: /vault/docs/configuration/storage -[telemetry-stanza]: /docs/configuration/telemetry +[telemetry-stanza]: /vault/docs/configuration/telemetry -[cubbyhole-secrets-engine]: /docs/secrets/cubbyhole +[cubbyhole-secrets-engine]: /vault/docs/secrets/cubbyhole -[kv-secrets-engine]: /docs/secrets/kv +[kv-secrets-engine]: /vault/docs/secrets/kv -[ldap-auth-backend]: /docs/auth/ldap +[ldap-auth-backend]: /vault/docs/auth/ldap -[token-auth-backend]: /docs/auth/token +[token-auth-backend]: /vault/docs/auth/token -[azure-storage-backend]: /docs/configuration/storage/azure +[azure-storage-backend]: /vault/docs/configuration/storage/azure -[cassandra-storage-backend]: /docs/configuration/storage/cassandra +[cassandra-storage-backend]: /vault/docs/configuration/storage/cassandra -[cockroachdb-storage-backend]: /docs/configuration/storage/cockroachdb +[cockroachdb-storage-backend]: /vault/docs/configuration/storage/cockroachdb -[consul-storage-backend]: /docs/configuration/storage/consul +[consul-storage-backend]: /vault/docs/configuration/storage/consul -[couchdb-storage-backend]: /docs/configuration/storage/couchdb +[couchdb-storage-backend]: /vault/docs/configuration/storage/couchdb -[dynamodb-storage-backend]: /docs/configuration/storage/dynamodb +[dynamodb-storage-backend]: /vault/docs/configuration/storage/dynamodb -[etcd-storage-backend]: /docs/configuration/storage/etcd +[etcd-storage-backend]: /vault/docs/configuration/storage/etcd -[gcs-storage-backend]: /docs/configuration/storage/google-cloud-storage +[gcs-storage-backend]: /vault/docs/configuration/storage/google-cloud-storage -[spanner-storage-backend]: /docs/configuration/storage/google-cloud-spanner +[spanner-storage-backend]: /vault/docs/configuration/storage/google-cloud-spanner -[mssql-storage-backend]: /docs/configuration/storage/mssql +[mssql-storage-backend]: /vault/docs/configuration/storage/mssql -[mysql-storage-backend]: /docs/configuration/storage/mysql +[mysql-storage-backend]: /vault/docs/configuration/storage/mysql -[postgresql-storage-backend]: /docs/configuration/storage/postgresql +[postgresql-storage-backend]: /vault/docs/configuration/storage/postgresql -[s3-storage-backend]: /docs/configuration/storage/s3 +[s3-storage-backend]: /vault/docs/configuration/storage/s3 -[swift-storage-backend]: /docs/configuration/storage/swift +[swift-storage-backend]: /vault/docs/configuration/storage/swift -[zookeeper-storage-backend]: /docs/configuration/storage/zookeeper +[zookeeper-storage-backend]: /vault/docs/configuration/storage/zookeeper -[integrated-storage]: /docs/configuration/storage/raft +[integrated-storage]: /vault/docs/configuration/storage/raft diff --git a/website/content/docs/interoperability-matrix.mdx b/website/content/docs/interoperability-matrix.mdx index 3705e64310..f817b3ae65 100644 --- a/website/content/docs/interoperability-matrix.mdx +++ b/website/content/docs/interoperability-matrix.mdx @@ -6,7 +6,7 @@ description: Guide to viewing which partners Vault integrates with. # Vault Interoperability Matrix -Vault integrates with various appliances, platforms and applications for different use cases. Below are two tables indicating the partner’s product that has been verified to work with Vault for [Auto Unsealing](/docs/concepts/seal#auto-unseal) / [HSM Support](/docs/enterprise/hsm) and [External Key Management](/use-cases/key-management). +Vault integrates with various appliances, platforms and applications for different use cases. Below are two tables indicating the partner’s product that has been verified to work with Vault for [Auto Unsealing](/vault/docs/concepts/seal#auto-unseal) / [HSM Support](/vault/docs/enterprise/hsm) and [External Key Management](https://vaultproject.io/use-cases/key-management). Auto Unseal and HSM Support was developed to aid in reducing the operational complexity of keeping the unseal key secure. This feature delegates the responsibility of securing the unseal key from users to a trusted device or service. At startup Vault will connect to the device or service implementing the seal and ask it to decrypt the root key Vault read from storage. @@ -84,4 +84,4 @@ Vault Secrets Engine Key: K/V = K/V secrets engine **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](/vault/docs/concepts/storage) backend, [auto auth](/vault/docs/agent/autoauth), and [auto unseal](/vault/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. ### HCP Vault HCP Vault is a managed version of Vault which is operated by HashiCorp to allow customers to quickly get up and running. HCP Vault uses the same binary as self-managed Vault Enterprise, and offers a consistent user experience. You can use the same Vault clients to communicate with HCP Vault as you use to communicate with Vault. Most runtime integrations can be verified with HCP Vault. -Sign up for HCP Vault [here](https://portal.cloud.hashicorp.com/) and check out [this](https://learn.hashicorp.com/collections/vault/cloud) learn guide for quickly getting started. +Sign up for HCP Vault [here](https://portal.cloud.hashicorp.com/) and check out [this](/vault/tutorials/cloud) learn guide for quickly getting started. ### Vault Integration Badges @@ -98,7 +98,7 @@ While not mandatory, HashiCorp encourages partners to sign an MNDA (Mutual Non-D In an effort to support our self-serve model, we’ve included links to resources, documentation, examples and best practices to guide you through the Vault integration development and testing process. -- [Vault Tutorial and Learn Site](https://learn.hashicorp.com/vault) +- [Vault Tutorial and Learn Site](/vault/tutorials) - Sample development implemented by a [partner](https://www.hashicorp.com/integrations/venafi/vault/) - Example runtime integrations for reference: [F5](https://www.hashicorp.com/integrations/f5/vault), [ServiceNow](https://www.hashicorp.com/integrations/servicenow/vault) - [Vault Community Forum](https://discuss.hashicorp.com/c/vault) @@ -107,46 +107,46 @@ We encourage partners to closely follow the above guidance. Adopting the same st ### 3. Develop and Test -For our partners who are building runtime integrations with Vault, we encourage them to support multiple [authentication](/docs/auth) methods (e.g. Approle, JWT, K8s) besides tokens. Additionally we encourage them to add as much flexibility when specifying paths for secrets engines. For our partners who want to build a plugin, the only knowledge necessary to write a plugin is basic command-line skills and knowledge of the Go programming language. When writing in Go-Language, HashiCorp has found the integration development process to be straightforward and simple when partners pay close attention and follow the resources by adopting the same structure and coding patterns to help expedite the review and release cycles. +For our partners who are building runtime integrations with Vault, we encourage them to support multiple [authentication](/vault/docs/auth) methods (e.g. Approle, JWT, K8s) besides tokens. Additionally we encourage them to add as much flexibility when specifying paths for secrets engines. For our partners who want to build a plugin, the only knowledge necessary to write a plugin is basic command-line skills and knowledge of the Go programming language. When writing in Go-Language, HashiCorp has found the integration development process to be straightforward and simple when partners pay close attention and follow the resources by adopting the same structure and coding patterns to help expedite the review and release cycles. Please remember that all integrations should have the appropriate documentation to assist Vault users in configuring the integrations. **Auth Methods** -- [Auth Methods documentation](/docs/auth) +- [Auth Methods documentation](/vault/docs/auth) - [Example of how to build, install, and maintain auth method plugins plugin](https://www.hashicorp.com/blog/building-a-vault-secure-plugin) - [Sample plugin code](https://github.com/hashicorp/vault-auth-plugin-example) **Runtime Integration** -- [Vault Tutorial and Learn Site](https://learn.hashicorp.com/vault) -- [Auth Methods documentation](/docs/auth) -- [HSM documentation](/docs/enterprise/hsm) -- [HSM Configuration information](/docs/configuration/seal/pkcs11) +- [Vault Tutorial and Learn Site](/vault/tutorials) +- [Auth Methods documentation](/vault/docs/auth) +- [HSM documentation](/vault/docs/enterprise/hsm) +- [HSM Configuration information](/vault/docs/configuration/seal/pkcs11) **Audit, Monitoring & Compliance Integration** -- [Audit devices documentation](/docs/audit) +- [Audit devices documentation](/vault/docs/audit) **Secrets Engine Integration** -- [Secret engine documentation](/docs/secrets) -- [Custom Secrets Engines | Vault - HashiCorp Learn](https://learn.hashicorp.com/collections/vault/custom-secrets-engine) +- [Secret engine documentation](/vault/docs/secrets) +- [Custom Secrets Engines | Vault - HashiCorp Learn](/vault/tutorials/custom-secrets-engine) **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/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. +The process to spin up a testing instance of HCP Vault is very [straightforward](/vault/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. -- Since HCP Vault is running Vault Enterprise, the integration will need to be aware of [Namespaces](https://learn.hashicorp.com/tutorials/vault/namespaces). This is important as the main namespace in HCP Vault is called 'admin' which is different from the standard ‘root’ namespace in a self managed Vault instance. If the integration currently doesn't support namespaces, then an additional benefit of adding Namespace support iis that this will also enable it to work with all self managed Vault Enterprise installations. -- HCP Vault is currently only deployed on AWS and so the partner’s application should be able to be deployed or run in AWS. This is vital so that HCP Vault is able to communicate with the application using a [private peered](https://learn.hashicorp.com/tutorials/cloud/amazon-peering-hcp) connection via a [HashiCorp Virtual Network](https://cloud.hashicorp.com/docs/hcp/network). +- Since HCP Vault is running Vault Enterprise, the integration will need to be aware of [Namespaces](/vault/tutorials/enterprise/namespaces). This is important as the main namespace in HCP Vault is called 'admin' which is different from the standard ‘root’ namespace in a self managed Vault instance. If the integration currently doesn't support namespaces, then an additional benefit of adding Namespace support iis that this will also enable it to work with all self managed Vault Enterprise installations. +- HCP Vault is currently only deployed on AWS and so the partner’s application should be able to be deployed or run in AWS. This is vital so that HCP Vault is able to communicate with the application using a [private peered](/hcp/tutorials/networking/amazon-peering-hcp) connection via a [HashiCorp Virtual Network](/hcp/docs/hcp/network). Additional resources: -- [HCP Sign up](https://cloud.hashicorp.com/docs/hcp/network) -- [Namespaces - Vault Enterprise](/docs/enterprise/namespaces) -- [Create a Vault Cluster on HCP | HashiCorp Learn](https://learn.hashicorp.com/tutorials/cloud/get-started-vault) +- [HCP Sign up](/hcp/docs/hcp/network) +- [Namespaces - Vault Enterprise](/vault/docs/enterprise/namespaces) +- [Create a Vault Cluster on HCP | HashiCorp Learn](/vault/tutorials/cloud/get-started-vault) ### 4. Review @@ -160,7 +160,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 verified 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 Auth or Secret Engine plugins specifically, once the plugin has been verified 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](/vault/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 verifications, the partner will be issued an HCP Vault Verified badge and will have this displayed on their partner page. diff --git a/website/content/docs/platform/aws/index.mdx b/website/content/docs/platform/aws/index.mdx index df214cf4c5..7934aae56e 100644 --- a/website/content/docs/platform/aws/index.mdx +++ b/website/content/docs/platform/aws/index.mdx @@ -20,4 +20,4 @@ The AWS Marketplace listings can be found below. The Vault AMIs listed in the AWS Marketplace are intended to serve as an easy starting point for a Vault installation. Vault AMIs are built on top of a minimal Ubuntu distribution and contain up to date packages for both Vault and the underlying operating system dependencies. -The Open Source Vault AMI is intended for development and test use cases. This listing will launch a non-HA Vault instance with Vault running and the Vault UI available. For production use cases, please see the [Architecture](/docs/platform/aws/run#architecture) section of this documentation. +The Open Source Vault AMI is intended for development and test use cases. This listing will launch a non-HA Vault instance with Vault running and the Vault UI available. For production use cases, please see the [Architecture](/vault/docs/platform/aws/run#architecture) section of this documentation. diff --git a/website/content/docs/platform/aws/lambda-extension.mdx b/website/content/docs/platform/aws/lambda-extension.mdx index 7597b9589b..6ae1a6f401 100644 --- a/website/content/docs/platform/aws/lambda-extension.mdx +++ b/website/content/docs/platform/aws/lambda-extension.mdx @@ -34,7 +34,7 @@ Where region may be any of `af-south-1`, `ap-east-1`, `ap-northeast-1`, `eu-west-1`, `eu-west-2`, `eu-west-3`, `me-south-1`, `sa-east-1`, `us-east-1`, `us-east-2`, `us-west-1`, `us-west-2`. -The extension authenticates with Vault using [AWS IAM auth](/docs/auth/aws), +The extension authenticates with Vault using [AWS IAM auth](/vault/docs/auth/aws), and all configuration is supplied via environment variables. There are two methods to read secrets, which can both be used side-by-side: @@ -164,7 +164,7 @@ to communicate with Vault if configured to do so as detailed below. ## Configuration The extension is configured via [Lambda environment variables](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html). -Most of the [Vault CLI client's environment variables](/docs/commands#environment-variables) are available, +Most of the [Vault CLI client's environment variables](/vault/docs/commands#environment-variables) are available, as well as some additional variables to configure auth, which secret(s) to read and where to write secrets. @@ -174,7 +174,7 @@ where to write secrets. | `VAULT_ADDR` | Vault address to connect to if `VLE_VAULT_ADDR` is not set. Required if `VLE_VAULT_ADDR` is not set | No | `https://x.x.x.x:8200` | | `VAULT_AUTH_PROVIDER` | Name of the configured AWS IAM auth route on Vault | Yes | `aws` | | `VAULT_AUTH_ROLE` | Vault role to authenticate as | Yes | `lambda-app` | -| `VAULT_IAM_SERVER_ID` | Value to pass to the Vault server via the [`X-Vault-AWS-IAM-Server-ID` HTTP Header for AWS Authentication](/api-docs/auth/aws#iam_server_id_header_value) | No | `vault.example.com` | +| `VAULT_IAM_SERVER_ID` | Value to pass to the Vault server via the [`X-Vault-AWS-IAM-Server-ID` HTTP Header for AWS Authentication](/vault/api-docs/auth/aws#iam_server_id_header_value) | No | `vault.example.com` | | `VAULT_SECRET_PATH` | Secret path to read, written to `/tmp/vault/secret.json` unless `VAULT_SECRET_FILE` is specified | No | `database/creds/lambda-app` | | `VAULT_SECRET_FILE` | Path to write the JSON response for `VAULT_SECRET_PATH` | No | `/tmp/db.json` | | `VAULT_SECRET_PATH_FOO` | Additional secret path to read, where FOO can be any name, as long as a matching `VAULT_SECRET_FILE_FOO` is specified | No | `secret/lambda-app/token` | @@ -183,7 +183,7 @@ where to write secrets. | `VAULT_STS_ENDPOINT_REGION` | The region of the STS regional endpoint to authenticate with. If the AWS IAM auth mount specified uses a regional STS endpoint, then this needs to match the region of that endpoint. Defaults to using the global endpoint, or the region the Lambda resides in if `AWS_STS_REGIONAL_ENDPOINTS` is set to `regional` | No | `eu-west-1` | The remaining environment variables are not required, and function exactly as -described in the [Vault Commands (CLI)](/docs/commands#environment-variables) documentation. However, +described in the [Vault Commands (CLI)](/vault/docs/commands#environment-variables) documentation. However, note that `VAULT_CLIENT_TIMEOUT` cannot extend the timeout beyond the 10s initialization timeout imposed by the Extensions API when writing files to disk. @@ -195,9 +195,9 @@ initialization timeout imposed by the Extensions API when writing files to disk. | `VAULT_CLIENT_KEY` | Path to an unencrypted, PEM-encoded private key on disk which corresponds to the matching client certificate | No | `/tmp/client.key` | | `VAULT_CLIENT_TIMEOUT` | Timeout for Vault requests. Default value is 60s. Ignored by proxy server. **Any value over 10s will exceed the Extensions API timeout and therefore have no effect** | No | `5s` | | `VAULT_MAX_RETRIES` | Maximum number of retries on `5xx` error codes. Defaults to 2. Ignored by proxy server | No | `2` | -| `VAULT_SKIP_VERIFY` | Do not verify Vault's presented certificate before communicating with it. Setting this variable is not recommended and voids Vault's [security model](/docs/internals/security) | No | `true` | +| `VAULT_SKIP_VERIFY` | Do not verify Vault's presented certificate before communicating with it. Setting this variable is not recommended and voids Vault's [security model](/vault/docs/internals/security) | No | `true` | | `VAULT_TLS_SERVER_NAME` | Name to use as the SNI host when connecting via TLS | No | `vault.example.com` | -| `VAULT_RATE_LIMIT` | Only applies to a single invocation of the extension. See [Vault Commands (CLI)](/docs/commands#environment-variables) documentation for details. Ignored by proxy server | No | `10` | +| `VAULT_RATE_LIMIT` | Only applies to a single invocation of the extension. See [Vault Commands (CLI)](/vault/docs/commands#environment-variables) documentation for details. Ignored by proxy server | No | `10` | | `VAULT_NAMESPACE` | The namespace to use for pre-configured secrets. Ignored by proxy server | No | `education` | | `VAULT_DEFAULT_CACHE_TTL` | The time to live configuration (aka, TTL) of the cache used by proxy server. Must have a unit and be parsable as a time.Duration. Required for caching to be enabled. | No | `15m` | | `VAULT_DEFAULT_CACHE_ENABLED` | Enable caching for all requests, without needing to set the X-Vault-Cache-Control header for each request. Must be set to a boolean value. | No | `true` | @@ -315,4 +315,4 @@ $ aws lambda publish-layer-version \ ## Tutorial -For step-by-step instructions, refer to the [Vault AWS Lambda Extension](https://learn.hashicorp.com/tutorials/vault/aws-lambda) tutorial for details on how to create an AWS Lambda function and use the Vault Lambda Extension to authenticate with Vault. +For step-by-step instructions, refer to the [Vault AWS Lambda Extension](/vault/tutorials/app-integration/aws-lambda) tutorial for details on how to create an AWS Lambda function and use the Vault Lambda Extension to authenticate with Vault. diff --git a/website/content/docs/platform/aws/run.mdx b/website/content/docs/platform/aws/run.mdx index 6dbe325ea7..f3b4836492 100644 --- a/website/content/docs/platform/aws/run.mdx +++ b/website/content/docs/platform/aws/run.mdx @@ -10,11 +10,11 @@ description: >- ## Launching the Vault AMI -When Vault is first launched from an official Marketplace AMI, it will come up in an uninitialized state and must be initialized via the [API](/api-docs/system/init), [CLI](/docs/commands/operator/init), or UI. The Marketplace AMI listens on port 8200 by default. It is recommended to restrict ingress networking to the Vault instance as much as possible when initially deploying Vault (through EC2 security groups or otherwise) because anyone with network access to Vault will be able to initialize it. To learn more about the default listener configuration, or to make changes, please see the [Vault Deployment Guide](https://learn.hashicorp.com/vault/operations/ops-deployment-guide#listener-stanza). +When Vault is first launched from an official Marketplace AMI, it will come up in an uninitialized state and must be initialized via the [API](/vault/api-docs/system/init), [CLI](/vault/docs/commands/operator/init), or UI. The Marketplace AMI listens on port 8200 by default. It is recommended to restrict ingress networking to the Vault instance as much as possible when initially deploying Vault (through EC2 security groups or otherwise) because anyone with network access to Vault will be able to initialize it. To learn more about the default listener configuration, or to make changes, please see the [Vault Deployment Guide](https://learn.hashicorp.com/vault/operations/ops-deployment-guide#listener-stanza). -Additionally on first launch, a new self-signed [certificate](/docs/configuration/listener/tcp#tls_cert_file) and [key](/docs/configuration/listener/tcp#tls_key_file) (unique to the EC2 instance) will be generated to secure Vault traffic using TLS. This is provided as a “more secure” (vs. unencrypted TCP traffic) temporary solution, but it is strongly recommended to replace these with your own certificate and key. Please note that when using a self-signed certificate, Vault clients will need to [skip](/docs/commands#vault_skip_verify) the verification of Vault’s certificate, which voids Vault’s [security model](/docs/internals/security). +Additionally on first launch, a new self-signed [certificate](/vault/docs/configuration/listener/tcp#tls_cert_file) and [key](/vault/docs/configuration/listener/tcp#tls_key_file) (unique to the EC2 instance) will be generated to secure Vault traffic using TLS. This is provided as a “more secure” (vs. unencrypted TCP traffic) temporary solution, but it is strongly recommended to replace these with your own certificate and key. Please note that when using a self-signed certificate, Vault clients will need to [skip](/vault/docs/commands#vault_skip_verify) the verification of Vault’s certificate, which voids Vault’s [security model](/vault/docs/internals/security). -In order to begin using a newly launched Vault instance or cluster, it must be [unsealed](/docs/concepts/seal) first. HashiCorp generally recommends using the [AWS KMS Seal](/docs/configuration/seal/awskms) when running Vault on AWS. +In order to begin using a newly launched Vault instance or cluster, it must be [unsealed](/vault/docs/concepts/seal) first. HashiCorp generally recommends using the [AWS KMS Seal](/vault/docs/configuration/seal/awskms) when running Vault on AWS. ## Viewing the Vault UI @@ -24,11 +24,11 @@ The Vault UI is enabled by default. You can view the UI by navigating to `https: New Vault AMIs are added to the AWS Marketplace listing regularly and contain the latest versions of Vault and updated operating system packages. However, new AMIs are not built and tested to support in-place upgrades of your existing Vault installation. -To upgrade a Vault instance launched from an official AWS Marketplace AMI, please follow the normal upgrade instructions for a [non-HA installation](/docs/upgrading#non-ha-installations). +To upgrade a Vault instance launched from an official AWS Marketplace AMI, please follow the normal upgrade instructions for a [non-HA installation](/vault/docs/upgrading#non-ha-installations). # Architecture -HashiCorp’s AWS Marketplace offerings provide an easy way to deploy Vault in a single-instance configuration using the [Filesystem storage backend](/docs/configuration/storage/filesystem), but for production use, we recommend running Vault on AWS with the same [general architecture](/docs/internals/architecture) as running it anywhere else. While the Filesystem storage backend is officially supported by HashiCorp, it does not support High Availability. Because Vault data is stored on disk in this configuration, it is subject to the durability and availability of Amazon Elastic Block Store (EBS) and should be backed up accordingly. +HashiCorp’s AWS Marketplace offerings provide an easy way to deploy Vault in a single-instance configuration using the [Filesystem storage backend](/vault/docs/configuration/storage/filesystem), but for production use, we recommend running Vault on AWS with the same [general architecture](/vault/docs/internals/architecture) as running it anywhere else. While the Filesystem storage backend is officially supported by HashiCorp, it does not support High Availability. Because Vault data is stored on disk in this configuration, it is subject to the durability and availability of Amazon Elastic Block Store (EBS) and should be backed up accordingly. For additional guidance on best practices for running Vault in production, please refer to the [Production Hardening](https://learn.hashicorp.com/vault/day-one/production-hardening) tutorial. diff --git a/website/content/docs/platform/github-actions.mdx b/website/content/docs/platform/github-actions.mdx index d6244c2736..f218608003 100644 --- a/website/content/docs/platform/github-actions.mdx +++ b/website/content/docs/platform/github-actions.mdx @@ -43,4 +43,4 @@ This example will authenticate to Vault instance at `https://vault.example.com:8 For more information on using the `vault-action` GitHub Action, visit: - [`vault-secrets` GitHub action documentation](https://github.com/marketplace/actions/vault-secrets) -- [Vault GitHub actions tutorial](https://learn.hashicorp.com/tutorials/vault/github-actions) \ No newline at end of file +- [Vault GitHub actions tutorial](/vault/tutorials/app-integration/github-actions) \ No newline at end of file diff --git a/website/content/docs/platform/k8s/csi/configurations.mdx b/website/content/docs/platform/k8s/csi/configurations.mdx index 1d61729f87..acbf114aec 100644 --- a/website/content/docs/platform/k8s/csi/configurations.mdx +++ b/website/content/docs/platform/k8s/csi/configurations.mdx @@ -69,13 +69,13 @@ If installing via the helm chart, they can be set using e.g. The following parameters are supported by the Vault provider. Each parameter is an entry under `spec.parameters` in a SecretProviderClass object. The full -structure is illustrated in the [examples](/docs/platform/k8s/csi/examples). +structure is illustrated in the [examples](/vault/docs/platform/k8s/csi/examples). - `roleName` `(string: "")` - Name of the role to be used during login with Vault. - `vaultAddress` `(string: "")` - The address of the Vault server. -- `vaultNamespace` `(string: "")` - The Vault [namespace](/docs/enterprise/namespaces) to use. +- `vaultNamespace` `(string: "")` - The Vault [namespace](/vault/docs/enterprise/namespaces) to use. - `vaultSkipTLSVerify` `(string: "false")` - When set to true, skips verification of the Vault server certificate. Setting this to true is not recommended for production. @@ -101,7 +101,7 @@ structure is illustrated in the [examples](/docs/platform/k8s/csi/examples). generated using the [TokenRequest API](https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-request-v1/#TokenRequestSpec). The resulting token is used to authenticate to Vault, so if you specify an - [audience](https://www.vaultproject.io/api-docs/auth/kubernetes#audience) for your Kubernetes auth + [audience](/vault/api-docs/auth/kubernetes#audience) for your Kubernetes auth role, it must match the audience specified here. If not set, the token audiences will default to the Kubernetes cluster's default API audiences. @@ -114,7 +114,7 @@ structure is illustrated in the [examples](/docs/platform/k8s/csi/examples). - `secretPath` `(string: "")` - The path in Vault where the secret is located. For secrets that are retrieved via HTTP GET method, the `secretPath` can include optional URI parameters, - for example, the [version of the KV2 secret](https://www.vaultproject.io/api-docs/secret/kv/kv-v2#read-secret-version): + for example, the [version of the KV2 secret](/vault/api-docs/secret/kv/kv-v2#read-secret-version): ```yaml objects: | @@ -137,5 +137,5 @@ structure is illustrated in the [examples](/docs/platform/k8s/csi/examples). ``` ~> `secretArgs` are sent as part of the HTTP request body. Therefore, they are only effective for HTTP PUT/POST requests, for instance, - the [request used to generate a new certificate](https://www.vaultproject.io/api-docs/secret/pki#generate-certificate). + the [request used to generate a new certificate](/vault/api-docs/secret/pki#generate-certificate). To supply additional parameters for secrets retrieved via HTTP GET, include optional URI parameters in [`secretPath`](#secretpath). diff --git a/website/content/docs/platform/k8s/csi/index.mdx b/website/content/docs/platform/k8s/csi/index.mdx index b84d696752..3e83d4631b 100644 --- a/website/content/docs/platform/k8s/csi/index.mdx +++ b/website/content/docs/platform/k8s/csi/index.mdx @@ -33,7 +33,7 @@ The following features are supported by the Vault CSI Provider: - TLS/mTLS communications with Vault. - Rendering Vault secrets to files. - Syncing secrets to Kubernetes secrets to be used as environment variables. -- Installation via [Vault Helm](/docs/platform/k8s/helm) +- Installation via [Vault Helm](/vault/docs/platform/k8s/helm) ## Authenticating with Vault @@ -41,7 +41,7 @@ The primary method of authentication with Vault when using the Vault CSI Provide is the service account attached to the pod. At this time no other authentication methods are supported. -For [Kubernetes authentication](/docs/auth/kubernetes), the service account must be bound to a Vault role and a +For [Kubernetes authentication](/vault/docs/auth/kubernetes), the service account must be bound to a Vault role and a policy granting access to the secrets desired. A service account must be present to use the Vault CSI Provider with the Kubernetes @@ -52,7 +52,7 @@ account provided to pods if no service account is defined. -> **Deprecated:** The `issuer` parameter has been deprecated as of Vault 1.9 and will be removed in a future release. -If running Vault prior to version 1.9, you will likely need to set [`issuer`](/api-docs/auth/kubernetes#issuer) when +If running Vault prior to version 1.9, you will likely need to set [`issuer`](/vault/api-docs/auth/kubernetes#issuer) when configuring Kubernetes authentication for the Vault CSI Provider. Vault CSI Provider does not use the default token associated with service accounts. Instead, it creates a token with a short TTL whose lifetime is also bound to the @@ -61,7 +61,7 @@ ephemeral tokens is the JWT issuer. Default tokens use `kubernetes/serviceaccoun which is the default value that Kubernetes auth will try to validate. However, ephemeral tokens use the value of `kube-apiserver`'s `--service-account-issuer` flag as the issuer, which is normally a URL instead. See the [Kubernetes auth -docs](/docs/auth/kubernetes#discovering-the-service-account-issuer) for +docs](/vault/docs/auth/kubernetes#discovering-the-service-account-issuer) for ways to check the issuer using the Kubernetes API. Importantly, this means most common configurations of Vault Agent Injector and @@ -147,5 +147,5 @@ the Secret Provider Class named `vault-db-creds`. ## Tutorial -Refer to the [Vault CSI Provider](https://learn.hashicorp.com/tutorials/vault/kubernetes-secret-store-driver?in=vault/kubernetes) +Refer to the [Vault CSI Provider](/vault/tutorials/kubernetes/kubernetes-secret-store-driver) tutorial to learn how to set up Vault and its depedencies with a Helm chart. diff --git a/website/content/docs/platform/k8s/csi/installation.mdx b/website/content/docs/platform/k8s/csi/installation.mdx index eca82caaf9..ccce536564 100644 --- a/website/content/docs/platform/k8s/csi/installation.mdx +++ b/website/content/docs/platform/k8s/csi/installation.mdx @@ -16,7 +16,7 @@ description: The Vault CSI Provider can be installed using Vault Helm. ## Installation using helm -The [Vault Helm chart](/docs/platform/k8s/helm) is the recommended way to +The [Vault Helm chart](/vault/docs/platform/k8s/helm) is the recommended way to install and configure the Vault CSI Provider in Kubernetes. To install a new instance of Vault and the Vault CSI Provider, first add the @@ -40,13 +40,13 @@ always run Helm with `--dry-run` before any install or upgrade to verify changes. You can see all the available values settings by running `helm inspect values hashicorp/vault` or by reading the [Vault Helm Configuration -Docs](/docs/platform/k8s/helm/configuration). Commonly used values in the Helm +Docs](/vault/docs/platform/k8s/helm/configuration). Commonly used values in the Helm chart include limiting the namespaces the Vault CSI Provider runs in, TLS options and more. ## Installation on OpenShift -We recommend using the [Vault agent injector on Openshift](/docs/platform/k8s/helm/openshift) +We recommend using the [Vault agent injector on Openshift](/vault/docs/platform/k8s/helm/openshift) instead of the Secrets Store CSI driver. OpenShift [does not recommend](https://docs.openshift.com/container-platform/4.9/storage/persistent_storage/persistent-storage-hostpath.html) using `hostPath` mounting in production or diff --git a/website/content/docs/platform/k8s/helm/configuration.mdx b/website/content/docs/platform/k8s/helm/configuration.mdx index a4ff6e3735..e91b6872a1 100644 --- a/website/content/docs/platform/k8s/helm/configuration.mdx +++ b/website/content/docs/platform/k8s/helm/configuration.mdx @@ -58,14 +58,14 @@ and consider if they're appropriate for your deployment. - `serverTelemetry` - Values that configure metrics and telemetry - `prometheusOperator` (`boolean: false`) - When set to `true`, enables integration with the - Prometheus Operator. Be sure to configure the top-level [`serverTelemetry`](/docs/platform/k8s/helm/configuration#servertelemetry-1) section for more details + Prometheus Operator. Be sure to configure the top-level [`serverTelemetry`](/vault/docs/platform/k8s/helm/configuration#servertelemetry-1) section for more details and required configuration values. - `injector` - Values that configure running a Vault Agent Injector Admission Webhook Controller within Kubernetes. - `enabled` (`boolean or string: "-"`) - When set to `true`, the Vault Agent Injector Admission Webhook controller will be created. When set to `"-"`, defaults to the value of `global.enabled`. - - `externalVaultAddr` (`string: ""`) - Deprecated: Please use [global.externalVaultAddr](/docs/platform/k8s/helm/configuration#externalvaultaddr) instead. + - `externalVaultAddr` (`string: ""`) - Deprecated: Please use [global.externalVaultAddr](/vault/docs/platform/k8s/helm/configuration#externalvaultaddr) instead. - `replicas` (`int: 1`) - The number of pods to deploy to create a highly available cluster of Vault Agent Injectors. Requires Vault K8s 0.7.0 to have more than 1 replica. @@ -100,7 +100,7 @@ and consider if they're appropriate for your deployment. - `template` (`string: "map"`) - The default template type for rendered secrets if no custom templates are defined. Possible values include `map` and `json`. - - `templateConfig` - Default values within Agent's [`template_config` stanza](/docs/agent/template). + - `templateConfig` - Default values within Agent's [`template_config` stanza](/vault/docs/agent/template). - `exitOnRetryFailure` (`boolean: true`) - Controls whether Vault Agent exits after it has exhausted its number of template retry attempts due to failures. @@ -176,9 +176,9 @@ and consider if they're appropriate for your deployment. - `annotations` (`string or object: {}`) - Defines additional annotations to attach to the webhook. This can either be YAML or a YAML-formatted multi-line templated string. - - `namespaceSelector` (`dictionary: {}`) - Deprecated: please use [`webhook.namespaceSelector`](/docs/platform/k8s/helm/configuration#namespaceselector) instead. + - `namespaceSelector` (`dictionary: {}`) - Deprecated: please use [`webhook.namespaceSelector`](/vault/docs/platform/k8s/helm/configuration#namespaceselector) instead. - - `objectSelector` (`dictionary: {}`) - Deprecated: please use [`webhook.objectSelector`](/docs/platform/k8s/helm/configuration#objectselector) instead. + - `objectSelector` (`dictionary: {}`) - Deprecated: please use [`webhook.objectSelector`](/vault/docs/platform/k8s/helm/configuration#objectselector) instead. - `extraLabels` (`dictionary: {}`) - This value defines additional labels for Vault Agent Injector pods. @@ -243,9 +243,9 @@ and consider if they're appropriate for your deployment. "sample/annotation2": "bar" ``` - - `failurePolicy` (`string: "Ignore"`) - Deprecated: please use [`webhook.failurePolicy`](/docs/platform/k8s/helm/configuration#failurepolicy) instead. + - `failurePolicy` (`string: "Ignore"`) - Deprecated: please use [`webhook.failurePolicy`](/vault/docs/platform/k8s/helm/configuration#failurepolicy) instead. - - `webhookAnnotations` (`dictionary: {}`) - Deprecated: please use [`webhook.annotations`](/docs/platform/k8s/helm/configuration#annotations-1) instead. + - `webhookAnnotations` (`dictionary: {}`) - Deprecated: please use [`webhook.annotations`](/vault/docs/platform/k8s/helm/configuration#annotations-1) instead. - `service` - The service section configures the Kubernetes service for the Vault Agent Injector. @@ -334,7 +334,7 @@ and consider if they're appropriate for your deployment. - `ingress` - Values that configure Ingress services for Vault. ~> If deploying on OpenShift, these ingress settings are ignored. Use the [`route`](#route) configuration to expose Vault on OpenShift.

- If [`ha`](#ha) is enabled the Ingress will point to the active vault server via the `active` Service. This requires vault 1.4+ and [service_registration](https://www.vaultproject.io/docs/configuration/service-registration/kubernetes) to be set in the vault config. + If [`ha`](#ha) is enabled the Ingress will point to the active vault server via the `active` Service. This requires vault 1.4+ and [service_registration](/vault/docs/configuration/service-registration/kubernetes) to be set in the vault config. - `enabled` (`boolean: false`) - When set to `true`, an [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) service will be created. @@ -395,7 +395,7 @@ and consider if they're appropriate for your deployment. - `route` - Values that configure Route services for Vault in OpenShift - ~> If [`ha`](#ha) is enabled the Route will point to the active vault server via the `active` Service (requires vault 1.4+ and [service_registration](https://www.vaultproject.io/docs/configuration/service-registration/kubernetes) to be set in the vault config). + ~> If [`ha`](#ha) is enabled the Route will point to the active vault server via the `active` Service (requires vault 1.4+ and [service_registration](/vault/docs/configuration/service-registration/kubernetes) to be set in the vault config). - `enabled` (`boolean: false`) - When set to `true`, a Route for Vault will be created. @@ -411,7 +411,7 @@ and consider if they're appropriate for your deployment. - `authDelegator` - Values that configure the Cluster Role Binding attached to the Vault service account. - - `enabled` (`boolean: true`) - When set to `true`, a Cluster Role Binding will be bound to the Vault service account. This Cluster Role Binding has the necessary privileges for Vault to use the [Kubernetes Auth Method](/docs/auth/kubernetes). + - `enabled` (`boolean: true`) - When set to `true`, a Cluster Role Binding will be bound to the Vault service account. This Cluster Role Binding has the necessary privileges for Vault to use the [Kubernetes Auth Method](/vault/docs/auth/kubernetes). - `readinessProbe` - Values that configure the readiness probe for the Vault pods. @@ -718,7 +718,7 @@ and consider if they're appropriate for your deployment. - `serviceDiscovery` - Values that configure permissions required for Vault Server to automatically discover and join a Vault cluster using pod metadata. - - `enabled` (`boolean: true`) - Enable or disable a service account role binding with the permissions required for Vault's Kubernetes [`service_registration`](https://developer.hashicorp.com/vault/docs/configuration/service-registration/kubernetes) config option. + - `enabled` (`boolean: true`) - Enable or disable a service account role binding with the permissions required for Vault's Kubernetes [`service_registration`](/vault/docs/configuration/service-registration/kubernetes) config option. - `dataStorage` - This configures the volume used for storing Vault data when not using external storage such as Consul. @@ -749,7 +749,7 @@ and consider if they're appropriate for your deployment. kubernetes.io/my-pvc: foobar ``` - - `auditStorage` - This configures the volume used for storing Vault's audit logs. See the [Vault documentation](/docs/audit) for more information. + - `auditStorage` - This configures the volume used for storing Vault's audit logs. See the [Vault documentation](/vault/docs/audit) for more information. - `enabled` (`boolean: false`) - Enables a persistent volume to be created for storing Vault's audit logs. @@ -793,7 +793,7 @@ and consider if they're appropriate for your deployment. Enables `standalone` mode for the Vault server. This mode uses the `file` storage backend and requires a volume for persistence (`dataStorage`). - `config` (`string or object: "{}"`) - - A raw string of extra HCL or JSON [configuration](/docs/configuration) for Vault servers. + A raw string of extra HCL or JSON [configuration](/vault/docs/configuration) for Vault servers. This will be saved as-is into a ConfigMap that is read by the Vault servers. This can be used to add additional configuration that isn't directly exposed by the chart. If an object is provided, it will be written as JSON. @@ -822,12 +822,12 @@ and consider if they're appropriate for your deployment. - `ha` - This configures `ha` mode for the Vault server. - `enabled` (`boolean: false`) - - Enables `ha` mode for the Vault server. This mode uses a highly available backend storage (such as Consul) to store Vault's data. By default this is configured to use [Consul Helm](https://github.com/hashicorp/consul-helm). For a complete list of storage backends, see the [Vault documentation](/docs/configuration). + Enables `ha` mode for the Vault server. This mode uses a highly available backend storage (such as Consul) to store Vault's data. By default this is configured to use [Consul Helm](https://github.com/hashicorp/consul-helm). For a complete list of storage backends, see the [Vault documentation](/vault/docs/configuration). - `apiAddr`: (`string: "{}"`) - Set the API address configuration for a Vault cluster. If set to an empty string, the pod IP address is used. - - `clusterAddr` (`string: null`) - Set the [`cluster_addr`](https://www.vaultproject.io/docs/configuration#cluster_addr) configuration for Vault HA. + - `clusterAddr` (`string: null`) - Set the [`cluster_addr`](/vault/docs/configuration#cluster_addr) configuration for Vault HA. If null, defaults to `https://$(HOSTNAME).{{ template "vault.fullname" . }}-internal:8201`. - `raft` - This configures `raft` integrated storage mode for the Vault server. @@ -838,7 +838,7 @@ and consider if they're appropriate for your deployment. - `setNodeId` (`boolean: false`) - Set the Node Raft ID to the name of the pod. - `config` (`string or object: "{}"`) - - A raw string of extra HCL or JSON [configuration](/docs/configuration) for Vault servers. + A raw string of extra HCL or JSON [configuration](/vault/docs/configuration) for Vault servers. This will be saved as-is into a ConfigMap that is read by the Vault servers. This can be used to add additional configuration that isn't directly exposed by the chart. If an object is provided, it will be written as JSON. @@ -850,7 +850,7 @@ and consider if they're appropriate for your deployment. If an updatePartition is specified, all Pods with an ordinal that is greater than or equal to the partition will be updated when the StatefulSet’s `.spec.template` is updated. If set to `0`, this disables partition updates. For more information see the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#rolling-updates). - `config` (`string or object: "{}"`) - - A raw string of extra HCL or JSON [configuration](/docs/configuration) for Vault servers. + A raw string of extra HCL or JSON [configuration](/vault/docs/configuration) for Vault servers. This will be saved as-is into a ConfigMap that is read by the Vault servers. This can be used to add additional configuration that isn't directly exposed by the chart. If an object is provided, it will be written as JSON. @@ -1105,11 +1105,11 @@ and consider if they're appropriate for your deployment. - `debug` (`bool: false`) - When set to true, enables debug logging on the Vault CSI Provider daemonset. - - `extraArgs` (`string: array`) - The extra arguments to be applied to the CSI pod startup command. See [here](/docs/platform/k8s/csi/configurations#command-line-arguments) for available flags. + - `extraArgs` (`string: array`) - The extra arguments to be applied to the CSI pod startup command. See [here](/vault/docs/platform/k8s/csi/configurations#command-line-arguments) for available flags. - `serverTelemetry` - Values the configure metrics and telemetry. Enabling these features requires setting - the `telemetry {}` stanza in the Vault configuration. See the [telemetry](/docs/configuration/telemetry) - [docs](/docs/internals/telemetry) for more on the Vault configuration. + the `telemetry {}` stanza in the Vault configuration. See the [telemetry](/vault/docs/configuration/telemetry) + [docs](/vault/docs/internals/telemetry) for more on the Vault configuration. Currently, this chart does not support authenticating to Vault's metrics endpoint, so the following `telemetry {}` block must be included in the `listener "tcp" {}` stanza of the Vault configuration: diff --git a/website/content/docs/platform/k8s/helm/enterprise.mdx b/website/content/docs/platform/k8s/helm/enterprise.mdx index 89b36a377b..1505a81f68 100644 --- a/website/content/docs/platform/k8s/helm/enterprise.mdx +++ b/website/content/docs/platform/k8s/helm/enterprise.mdx @@ -9,7 +9,7 @@ description: >- You can use this Helm chart to deploy Vault Enterprise by following a few extra steps around licensing. -~> **Note:** As of Vault Enterprise 1.8, the license must be specified via HCL configuration or environment variables on startup, unless the Vault cluster was created with an older Vault version and the license was stored. More information is available in the [Vault Enterprise License docs](/docs/enterprise/license). +~> **Note:** As of Vault Enterprise 1.8, the license must be specified via HCL configuration or environment variables on startup, unless the Vault cluster was created with an older Vault version and the license was stored. More information is available in the [Vault Enterprise License docs](/vault/docs/enterprise/license). @include 'helm/version.mdx' @@ -26,7 +26,7 @@ kubectl create secret generic vault-ent-license --from-literal="license=${secret -> **Note:** If you cannot find your `.hclic` file, please contact your sales team or Technical Account Manager. -In your chart overrides, set the values of [`server.image`](/docs/platform/k8s/helm/configuration#image-2) to one of the enterprise [release tags](https://hub.docker.com/r/hashicorp/vault-enterprise/tags). Also set the name of the secret you just created in [`server.enterpriseLicense`](/docs/platform/k8s/helm/configuration#enterpriselicense). +In your chart overrides, set the values of [`server.image`](/vault/docs/platform/k8s/helm/configuration#image-2) to one of the enterprise [release tags](https://hub.docker.com/r/hashicorp/vault-enterprise/tags). Also set the name of the secret you just created in [`server.enterpriseLicense`](/vault/docs/platform/k8s/helm/configuration#enterpriselicense). ```yaml # config.yaml @@ -44,7 +44,7 @@ Now run `helm install`: $ helm install hashicorp hashicorp/vault -f config.yaml ``` -Once the cluster is [initialized and unsealed](/docs/platform/k8s/helm/run), you may check the license status using the `vault license get` command: +Once the cluster is [initialized and unsealed](/vault/docs/platform/k8s/helm/run), you may check the license status using the `vault license get` command: ```shell kubectl exec -ti vault-0 -- vault license get @@ -67,7 +67,7 @@ EOF kubectl patch secret vault-ent-license --patch "$(cat patch-license.yaml)" ``` -- Wait until [`vault license inspect`](/docs/commands/license/inspect) shows the updated license +- Wait until [`vault license inspect`](/vault/docs/commands/license/inspect) shows the updated license Since the `inspect` command is reading the license file from the mounted secret, this tells you when the updated secret has been propagated to the mount on the Vault pod. @@ -77,7 +77,7 @@ kubectl exec vault-0 -- vault license inspect - Reload Vault's license config - You may use the [`sys/config/reload/license` API endpoint](/api-docs/system/config-reload#reload-license-file): + You may use the [`sys/config/reload/license` API endpoint](/vault/api-docs/system/config-reload#reload-license-file): ```shell kubectl exec vault-0 -- vault write -f sys/config/reload/license @@ -89,7 +89,7 @@ Or you may issue an HUP signal directly to Vault: kubectl exec vault-0 -- pkill -HUP vault ``` -- Verify that [`vault license get`](/docs/commands/license/get) shows the updated license +- Verify that [`vault license get`](/vault/docs/commands/license/get) shows the updated license ```shell kubectl exec vault-0 -- vault license get @@ -97,7 +97,7 @@ kubectl exec vault-0 -- vault license get ## Vault Enterprise prior to 1.8 -In your chart overrides, set the values of `server.image` to one of the enterprise [release tags](https://hub.docker.com/r/hashicorp/vault-enterprise/tags). Install the chart, and initialize and unseal vault as described in [Running Vault](/docs/platform/k8s/helm/run). +In your chart overrides, set the values of `server.image` to one of the enterprise [release tags](https://hub.docker.com/r/hashicorp/vault-enterprise/tags). Install the chart, and initialize and unseal vault as described in [Running Vault](/vault/docs/platform/k8s/helm/run). After Vault has been initialized and unsealed, setup a port-forward tunnel to the Vault Enterprise cluster: diff --git a/website/content/docs/platform/k8s/helm/examples/enterprise-dr-with-raft.mdx b/website/content/docs/platform/k8s/helm/examples/enterprise-dr-with-raft.mdx index dfc618d437..d3a83866d8 100644 --- a/website/content/docs/platform/k8s/helm/examples/enterprise-dr-with-raft.mdx +++ b/website/content/docs/platform/k8s/helm/examples/enterprise-dr-with-raft.mdx @@ -12,9 +12,9 @@ description: |- The following is an example of creating a disaster recovery cluster using Vault Helm. -For more information on Disaster Recovery, [see the official documentation](/docs/enterprise/replication/). +For more information on Disaster Recovery, [see the official documentation](/vault/docs/enterprise/replication/). --> For license configuration refer to [Running Vault Enterprise](/docs/platform/k8s/helm/enterprise). +-> For license configuration refer to [Running Vault Enterprise](/vault/docs/platform/k8s/helm/enterprise). ## Primary Cluster diff --git a/website/content/docs/platform/k8s/helm/examples/enterprise-perf-with-raft.mdx b/website/content/docs/platform/k8s/helm/examples/enterprise-perf-with-raft.mdx index 27084840ab..6a4bc04359 100644 --- a/website/content/docs/platform/k8s/helm/examples/enterprise-perf-with-raft.mdx +++ b/website/content/docs/platform/k8s/helm/examples/enterprise-perf-with-raft.mdx @@ -12,9 +12,9 @@ description: |- The following is an example of creating a performance cluster using Vault Helm. -For more information on Disaster Recovery, [see the official documentation](/docs/enterprise/replication/). +For more information on Disaster Recovery, [see the official documentation](/vault/docs/enterprise/replication/). --> For license configuration refer to [Running Vault Enterprise](/docs/platform/k8s/helm/enterprise). +-> For license configuration refer to [Running Vault Enterprise](/vault/docs/platform/k8s/helm/enterprise). ## Primary Cluster diff --git a/website/content/docs/platform/k8s/helm/examples/enterprise-with-raft.mdx b/website/content/docs/platform/k8s/helm/examples/enterprise-with-raft.mdx index 728a3b9cbe..fd7437e00c 100644 --- a/website/content/docs/platform/k8s/helm/examples/enterprise-with-raft.mdx +++ b/website/content/docs/platform/k8s/helm/examples/enterprise-with-raft.mdx @@ -20,7 +20,7 @@ helm install vault hashicorp/vault \ --set='server.ha.raft.enabled=true' ``` --> For license configuration refer to [Running Vault Enterprise](/docs/platform/k8s/helm/enterprise). +-> For license configuration refer to [Running Vault Enterprise](/vault/docs/platform/k8s/helm/enterprise). Next, initialize and unseal `vault-0` pod: diff --git a/website/content/docs/platform/k8s/helm/examples/index.mdx b/website/content/docs/platform/k8s/helm/examples/index.mdx index 14931057a9..4863496ebb 100644 --- a/website/content/docs/platform/k8s/helm/examples/index.mdx +++ b/website/content/docs/platform/k8s/helm/examples/index.mdx @@ -18,5 +18,5 @@ deployment models. You can view the different examples from the list on the left ## Tutorial Refer to the [Run Vault on -Kubernetes](https://learn.hashicorp.com/collections/vault/kubernetes) +Kubernetes](/vault/tutorials/kubernetes) tutorial series to learn how to run Vault on Kubernetes. diff --git a/website/content/docs/platform/k8s/helm/examples/kubernetes-auth.mdx b/website/content/docs/platform/k8s/helm/examples/kubernetes-auth.mdx index 5599b4351f..9f208e80aa 100644 --- a/website/content/docs/platform/k8s/helm/examples/kubernetes-auth.mdx +++ b/website/content/docs/platform/k8s/helm/examples/kubernetes-auth.mdx @@ -10,7 +10,7 @@ description: |- @include 'helm/version.mdx' -In this example, we will walk through how to set up the [Kubernetes Auth Method](/docs/auth/kubernetes). +In this example, we will walk through how to set up the [Kubernetes Auth Method](/vault/docs/auth/kubernetes). This assumes the following commands will be run inside a Vault pod running in Kubernetes. @@ -43,4 +43,4 @@ vault write auth/kubernetes/config \ kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt ``` -From here you can continue to configure Vault from the [Kubernetes Auth Method](/docs/auth/kubernetes) documentation. +From here you can continue to configure Vault from the [Kubernetes Auth Method](/vault/docs/auth/kubernetes) documentation. diff --git a/website/content/docs/platform/k8s/helm/index.mdx b/website/content/docs/platform/k8s/helm/index.mdx index 300016e0d6..bfbea1118d 100644 --- a/website/content/docs/platform/k8s/helm/index.mdx +++ b/website/content/docs/platform/k8s/helm/index.mdx @@ -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-consul) tutorial. +Helm](/vault/tutorials/kubernetes/kubernetes-minikube-consul) tutorial. To use the Helm chart, add the Hashicorp helm repository and check that you have access to the chart: @@ -54,10 +54,10 @@ secure and less resilient installation that is **NOT** appropriate for a production setup. It is highly recommended to use a [properly secured Kubernetes cluster](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/), [learn the available configuration -options](/docs/platform/k8s/helm/configuration), and read the [production deployment -checklist](/docs/platform/k8s/helm/run#architecture). +options](/vault/docs/platform/k8s/helm/configuration), and read the [production deployment +checklist](/vault/docs/platform/k8s/helm/run#architecture). ## Tutorial -Refer to the [Kubernetes](https://learn.hashicorp.com/collections/vault/kubernetes) +Refer to the [Kubernetes](/vault/tutorials/kubernetes) tutorials series to learn how to run Vault on Kubernetes. diff --git a/website/content/docs/platform/k8s/helm/openshift.mdx b/website/content/docs/platform/k8s/helm/openshift.mdx index 3373cb44cd..3704f083aa 100644 --- a/website/content/docs/platform/k8s/helm/openshift.mdx +++ b/website/content/docs/platform/k8s/helm/openshift.mdx @@ -21,7 +21,7 @@ using `hostPath` mounting in production or [certify Helm charts](https://github.com/redhat-certification/chart-verifier/blob/dbf89bff2d09142e4709d689a9f4037a739c2244/docs/helm-chart-checks.md#table-2-helm-chart-default-checks) using CSI objects because pods must run as privileged. If you would like to run the Secrets Store CSI driver on a development or testing cluster, refer to -[installation instructions for the Vault CSI provider](/docs/platform/k8s/csi/installation). +[installation instructions for the Vault CSI provider](/vault/docs/platform/k8s/csi/installation). ## Requirements @@ -42,8 +42,8 @@ deployments, Raft integrated storage is recommended. The documentation, configuration and examples for Vault Helm and Vault K8s Agent Injector are applicable to OpenShift installations. For more examples see the existing documentation: -- [Vault Helm documentation](/docs/platform/k8s/helm) -- [Vault K8s documentation](/docs/platform/k8s/injector) +- [Vault Helm documentation](/vault/docs/platform/k8s/helm) +- [Vault K8s documentation](/vault/docs/platform/k8s/injector) ## Helm Chart @@ -64,8 +64,8 @@ secure and less resilient installation that is **NOT** appropriate for a production setup. It is highly recommended to use a [properly secured Kubernetes cluster](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/), [learn the available configuration -options](/docs/platform/k8s/helm/configuration), and read the [production deployment -checklist](/docs/platform/k8s/helm/run#architecture). +options](/vault/docs/platform/k8s/helm/configuration), and read the [production deployment +checklist](/vault/docs/platform/k8s/helm/run#architecture). ## How-To diff --git a/website/content/docs/platform/k8s/helm/run.mdx b/website/content/docs/platform/k8s/helm/run.mdx index bf2cf70de4..82d62cac5a 100644 --- a/website/content/docs/platform/k8s/helm/run.mdx +++ b/website/content/docs/platform/k8s/helm/run.mdx @@ -33,8 +33,8 @@ secure and less resilient installation that is **NOT** appropriate for a production setup. It is highly recommended to use a [properly secured Kubernetes cluster](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/), [learn the available configuration -options](/docs/platform/k8s/helm/configuration), and read the [production deployment -checklist](/docs/platform/k8s/helm/run#architecture). +options](/vault/docs/platform/k8s/helm/configuration), and read the [production deployment +checklist](/vault/docs/platform/k8s/helm/run#architecture). ## How-To @@ -150,7 +150,7 @@ tutorial to learn how to use an external Vault within a Kubernetes cluster. The Vault UI is enabled but NOT exposed as service for security reasons. The Vault UI can also be exposed via port-forwarding or through a [`ui` -configuration value](/docs/platform/k8s/helm/configuration/#ui). +configuration value](/vault/docs/platform/k8s/helm/configuration/#ui). Expose the Vault UI with port-forwarding: @@ -165,9 +165,9 @@ Forwarding from [::1]:8200 -> 8200 After the Vault Helm chart is installed in `standalone` or `ha` mode one of the Vault servers need to be -[initialized](/docs/commands/operator/init). The +[initialized](/vault/docs/commands/operator/init). The initialization generates the credentials necessary to -[unseal](/docs/concepts/seal#why) all the Vault +[unseal](/vault/docs/concepts/seal#why) all the Vault servers. #### CLI initialize and unseal @@ -222,7 +222,7 @@ vault-2 1/1 Running 0 1m49s #### Google KMS Auto Unseal The Helm chart may be run with [Google KMS for Auto -Unseal](/docs/configuration/seal/gcpckms). This enables Vault server pods to +Unseal](/vault/docs/configuration/seal/gcpckms). This enables Vault server pods to auto unseal if they are rescheduled. Vault Helm requires the Google Cloud KMS credentials stored in @@ -292,7 +292,7 @@ server: #### Amazon KMS Auto Unseal The Helm chart may be run with [AWS KMS for Auto -Unseal](/docs/configuration/seal/awskms). This enables Vault server pods to auto +Unseal](/vault/docs/configuration/seal/awskms). This enables Vault server pods to auto unseal if they are rescheduled. Vault Helm requires the AWS credentials stored as environment variables that @@ -353,7 +353,7 @@ Probes are essential for detecting failures, rescheduling and using pods in Kubernetes. The helm chart offers configurable readiness and liveliness probes which can be customized for a variety of use cases. -Vault's [/sys/health`](/api-docs/system/health) endpoint can be customized to +Vault's [/sys/health`](/vault/api-docs/system/health) endpoint can be customized to change the behavior of the health check. For example, we can change the Vault readiness probe to show the Vault pods are ready even if they're still uninitialized and sealed using the following probe: @@ -371,9 +371,9 @@ pod is ready for additional setup. ### Upgrading Vault on Kubernetes To upgrade Vault on Kubernetes, we follow the same pattern as -[generally upgrading Vault](/docs/upgrading), except we can use +[generally upgrading Vault](/vault/docs/upgrading), except we can use the Helm chart to update the Vault server StatefulSet. It is important to understand -how to [generally upgrade Vault](/docs/upgrading) before reading this +how to [generally upgrade Vault](/vault/docs/upgrading) before reading this section. The Vault StatefulSet uses `OnDelete` update strategy. It is critical to use `OnDelete` instead @@ -530,7 +530,7 @@ $ helm install vault hashicorp/vault \ ## Architecture We recommend running Vault on Kubernetes with the same -[general architecture](/docs/internals/architecture) +[general architecture](/vault/docs/internals/architecture) as running it anywhere else. There are some benefits Kubernetes can provide that eases operating a Vault cluster and we document those below. The standard [production deployment](https://learn.hashicorp.com/vault/day-one/production-hardening) tutorial is still an @@ -542,14 +542,14 @@ _End-to-End TLS._ Vault should always be used with TLS in production. If intermediate load balancers or reverse proxies are used to front Vault, they should not terminate TLS. This way traffic is always encrypted in transit to Vault and minimizes risks introduced by intermediate layers. See the -[official documentation](/docs/platform/k8s/helm/examples/standalone-tls/) +[official documentation](/vault/docs/platform/k8s/helm/examples/standalone-tls/) for example on configuring Vault Helm to use TLS. _Single Tenancy._ Vault should be the only main process running on a machine. This reduces the risk that another process running on the same machine is compromised and can interact with Vault. This can be accomplished by using Vault Helm's `affinity` configurable. See the -[official documentation](/docs/platform/k8s/helm/examples/ha-with-consul/) +[official documentation](/vault/docs/platform/k8s/helm/examples/ha-with-consul/) for example on configuring Vault Helm to use affinity rules. _Enable Auditing._ Vault supports several auditing backends. Enabling auditing @@ -558,7 +558,7 @@ trail in the case of misuse or compromise. Audit logs securely hash any sensitiv data, but access should still be restricted to prevent any unintended disclosures. Vault Helm includes a configurable `auditStorage` option that provisions a persistent volume to store audit logs. See the -[official documentation](/docs/platform/k8s/helm/examples/standalone-audit/) +[official documentation](/vault/docs/platform/k8s/helm/examples/standalone-audit/) for an example on configuring Vault Helm to use auditing. _Immutable Upgrades._ Vault relies on an external storage backend for persistence, diff --git a/website/content/docs/platform/k8s/helm/terraform.mdx b/website/content/docs/platform/k8s/helm/terraform.mdx index e0ac12e0f0..8e0f8ec3db 100644 --- a/website/content/docs/platform/k8s/helm/terraform.mdx +++ b/website/content/docs/platform/k8s/helm/terraform.mdx @@ -10,7 +10,7 @@ description: |- Terraform may also be used to configure and deploy the Vault Helm chart, by using the [Helm provider](https://registry.terraform.io/providers/hashicorp/helm/latest/docs). -For example, to configure the chart to deploy [HA Vault with integrated storage (raft)](/docs/platform/k8s/helm/examples/ha-with-raft), the values overrides can be set on the command-line, in a values yaml file, or with a Terraform configuration: +For example, to configure the chart to deploy [HA Vault with integrated storage (raft)](/vault/docs/platform/k8s/helm/examples/ha-with-raft), the values overrides can be set on the command-line, in a values yaml file, or with a Terraform configuration: diff --git a/website/content/docs/platform/k8s/index.mdx b/website/content/docs/platform/k8s/index.mdx index 38c9058681..dcf5906617 100644 --- a/website/content/docs/platform/k8s/index.mdx +++ b/website/content/docs/platform/k8s/index.mdx @@ -22,19 +22,19 @@ Kubernetes, as long as they can communicate to the server via the network. **Accessing and Storing Secrets:** Applications using the Vault service running in Kubernetes can access and store secrets from Vault using a number of different -[secret engines](/docs/secrets) and [authentication methods](/docs/auth). +[secret engines](/vault/docs/secrets) and [authentication methods](/vault/docs/auth). **Running a Highly Available Vault Service:** By using pod affinities, highly available -backend storage (such as Consul) and [auto-unseal](/docs/concepts/seal#auto-unseal), +backend storage (such as Consul) and [auto-unseal](/vault/docs/concepts/seal#auto-unseal), Vault can become a highly available service in Kubernetes. **Encryption as a Service:** Applications using the Vault service running in Kubernetes -can leverage the [Transit secret engine](/docs/secrets/transit) +can leverage the [Transit secret engine](/vault/docs/secrets/transit) as "encryption as a service". This allows applications to offload encryption needs to Vault before storing data at rest. **Audit Logs for Vault:** Operators can choose to attach a persistent volume -to the Vault cluster which can be used to [store audit logs](/docs/audit). +to the Vault cluster which can be used to [store audit logs](/vault/docs/audit). **And more!** Vault can run directly on Kubernetes, so in addition to the native integrations provided by Vault itself, any other tool built for @@ -46,16 +46,16 @@ There are several ways to try Vault with Kubernetes in different environments. ### Guides -- [Vault Installation to Minikube via Helm with Integrated Storage](https://learn.hashicorp.com/tutorials/vault/kubernetes-minikube-raft) covers installing Vault locally using Minikube and the official Helm chart. +- [Vault Installation to Minikube via Helm with Integrated Storage](/vault/tutorials/kubernetes/kubernetes-minikube-raft) covers installing Vault locally using Minikube and the official Helm chart. -- [Vault Installation to Red Hat OpenShift via Helm](https://learn.hashicorp.com/tutorials/vault/kubernetes-openshift) covers installing Vault using Helm on Red Hat's OpenShift platform. +- [Vault Installation to Red Hat OpenShift via Helm](/vault/tutorials/kubernetes/kubernetes-openshift) covers installing Vault using Helm on Red Hat's OpenShift platform. -- [Integrate a Kubernetes Cluster with an External Vault](https://learn.hashicorp.com/tutorials/vault/kubernetes-external-vault) provides an example of making Vault accessible via a Kubernetes service and endpoint. +- [Integrate a Kubernetes Cluster with an External Vault](/vault/tutorials/kubernetes/kubernetes-external-vault) provides an example of making Vault accessible via a Kubernetes service and endpoint. -- [Vault on Kubernetes Deployment Guide](https://learn.hashicorp.com/tutorials/vault/kubernetes-raft-deployment-guide) covers the steps required to install and configure a single HashiCorp Vault cluster as defined in the [Vault on Kubernetes Reference Architecture](https://learn.hashicorp.com/tutorials/vault/kubernetes-reference-architecture). +- [Vault on Kubernetes Deployment Guide](/vault/tutorials/kubernetes/kubernetes-raft-deployment-guide) covers the steps required to install and configure a single HashiCorp Vault cluster as defined in the [Vault on Kubernetes Reference Architecture](/vault/tutorials/kubernetes/kubernetes-reference-architecture). ### Documentation -- [Vault on Kubernetes Reference Architecture](https://learn.hashicorp.com/tutorials/vault/kubernetes-reference-architecture) provides recommended practices for running Vault on Kubernetes in production. +- [Vault on Kubernetes Reference Architecture](/vault/tutorials/kubernetes/kubernetes-reference-architecture) provides recommended practices for running Vault on Kubernetes in production. -- [Vault on Kubernetes Security Considerations](https://learn.hashicorp.com/tutorials/vault/kubernetes-security-concerns) provides recommendations specific to securely running Vault in a production Kubernetes environment. +- [Vault on Kubernetes Security Considerations](/vault/tutorials/kubernetes/kubernetes-security-concerns) provides recommendations specific to securely running Vault in a production Kubernetes environment. diff --git a/website/content/docs/platform/k8s/injector-csi.mdx b/website/content/docs/platform/k8s/injector-csi.mdx index de2771a9d1..b6aef28e7e 100644 --- a/website/content/docs/platform/k8s/injector-csi.mdx +++ b/website/content/docs/platform/k8s/injector-csi.mdx @@ -12,13 +12,13 @@ Information contained within this document details the contrast between the Agen ## Vault Sidecar Agent Injector -The [Vault Sidecar Agent Injector](/docs/platform/k8s/injector) leverages the [sidecar pattern](https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar) to alter pod specifications to include a Vault Agent container that renders Vault secrets to a shared memory volume. By rendering secrets to a shared volume, containers within the pod can consume Vault secrets without being Vault-aware. The injector is a Kubernetes mutating webhook controller. The controller intercepts pod events and applies mutations to the pod if annotations exist within the request. This functionality is provided by the [vault-k8s](https://github.com/hashicorp/vault-k8s) project and can be automatically installed and configured using the Vault Helm chart. +The [Vault Sidecar Agent Injector](/vault/docs/platform/k8s/injector) leverages the [sidecar pattern](https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar) to alter pod specifications to include a Vault Agent container that renders Vault secrets to a shared memory volume. By rendering secrets to a shared volume, containers within the pod can consume Vault secrets without being Vault-aware. The injector is a Kubernetes mutating webhook controller. The controller intercepts pod events and applies mutations to the pod if annotations exist within the request. This functionality is provided by the [vault-k8s](https://github.com/hashicorp/vault-k8s) project and can be automatically installed and configured using the Vault Helm chart. ![Vault Sidecar Injection Workflow](/img/vault-sidecar-inject-workflow.png) ## Vault CSI Provider -The [Vault CSI provider](/docs/platform/k8s/csi) allows pods to consume Vault secrets by using ephemeral [CSI Secrets Store](https://github.com/kubernetes-sigs/secrets-store-csi-driver) volumes. At a high level, the CSI Secrets Store driver enables users to create `SecretProviderClass` objects. These objects define which secret provider to use and what secrets to retrieve. When pods requesting CSI volumes are made, the CSI Secrets Store driver sends the request to the Vault CSI provider if the provider is `vault`. The Vault CSI provider then uses the specified `SecretProviderClass` and the pod’s service account to retrieve the secrets from Vault and mount them into the pod’s CSI volume. Note that the secret is retrieved from Vault and populated to the CSI secrets store volume during the `ContainerCreation` phase. Therefore, pods are blocked from starting until the secrets are read from Vault and written to the volume. +The [Vault CSI provider](/vault/docs/platform/k8s/csi) allows pods to consume Vault secrets by using ephemeral [CSI Secrets Store](https://github.com/kubernetes-sigs/secrets-store-csi-driver) volumes. At a high level, the CSI Secrets Store driver enables users to create `SecretProviderClass` objects. These objects define which secret provider to use and what secrets to retrieve. When pods requesting CSI volumes are made, the CSI Secrets Store driver sends the request to the Vault CSI provider if the provider is `vault`. The Vault CSI provider then uses the specified `SecretProviderClass` and the pod’s service account to retrieve the secrets from Vault and mount them into the pod’s CSI volume. Note that the secret is retrieved from Vault and populated to the CSI secrets store volume during the `ContainerCreation` phase. Therefore, pods are blocked from starting until the secrets are read from Vault and written to the volume. ![Vault Sidecar Injection Workflow](/img/vault-csi-workflow.png) @@ -52,7 +52,7 @@ Both Agent Injection and Vault CSI solutions have the following similarities: - They simplify retrieving different types of secrets stored in Vault and expose them to the target pod running on Kubernetes without knowing the not-so-trivial Vault processes. It’s important to note that there is no need to change the application logic or code to use these solutions, therefore, making it easier to migrate brownfield applications into Kubernetes. Developers working on greenfield applications can leverage the Vault SDKs to integrate with Vault directly. -- They support all types of Vault [secrets engines](/docs/secrets). This support allows you to leverage an extensive set of secret types, ranging from static key-value secrets to dynamically generated database credentials and TLS certs with customized TTL. +- They support all types of Vault [secrets engines](/vault/docs/secrets). This support allows you to leverage an extensive set of secret types, ranging from static key-value secrets to dynamically generated database credentials and TLS certs with customized TTL. - They leverage the application’s Kubernetes pod service account token as [Secret Zero](https://www.hashicorp.com/resources/secret-zero-mitigating-the-risk-of-secret-introduction-with-vault) to authenticate with Vault via the Kubernetes auth method. With this method, there is no need to manage yet another separate identity to identify the application pods when authenticating to Vault. @@ -81,21 +81,21 @@ Now that you understand the similarities, there are differences between these tw - In contrast, the Vault CSI Driver is deployed as a daemonset on every node in the Kubernetes cluster and uses the Secret Provider Class specified and the pod’s service account to retrieve the secrets from Vault and mount them into the pod’s CSI volume. -- The Sidecar Agent Injector supports [all](/docs/platform/k8s/injector/annotations#vault-hashicorp-com-auth-path) Vault [auto-auth](/docs/agent/autoauth/methods) methods. The Sidecar CSI driver supports only Vault’s [Kubernetes auth method](/docs/platform/k8s/csi/configurations#vaultkubernetesmountpath). +- The Sidecar Agent Injector supports [all](/vault/docs/platform/k8s/injector/annotations#vault-hashicorp-com-auth-path) Vault [auto-auth](/vault/docs/agent/autoauth/methods) methods. The Sidecar CSI driver supports only Vault’s [Kubernetes auth method](/vault/docs/platform/k8s/csi/configurations#vaultkubernetesmountpath). - The Sidecar container launched with every application pod uses [Vault Agent](https://www.hashicorp.com/blog/why-use-the-vault-agent-for-secrets-management), which provides a powerful set of capabilities such as auto-auth, templating, and caching. The CSI driver does not use the Vault Agent and therefore lacks these functionalities. -- The Vault CSI driver supports rendering Vault secrets into Kubernetes secrets and environment variables. Sidecar Injector Service does not support rendering secrets into Kubernetes secrets; however, there are ways to [agent templating](/docs/platform/k8s/injector/examples#environment-variable-example) to render secrets into environment variables. +- The Vault CSI driver supports rendering Vault secrets into Kubernetes secrets and environment variables. Sidecar Injector Service does not support rendering secrets into Kubernetes secrets; however, there are ways to [agent templating](/vault/docs/platform/k8s/injector/examples#environment-variable-example) to render secrets into environment variables. - The CSI driver uses `hostPath` to mount ephemeral volumes into the pods, which some container platforms (e.g., OpenShift) disable by default. On the other hand, Sidecar Agent Service uses in-memory _tmpfs_ volumes. -- Sidecar Injector Service [automatically](/docs/agent/template#renewals-and-updating-secrets) renews, rotates, and fetches secrets/tokens while the CSI Driver does not support that. +- Sidecar Injector Service [automatically](/vault/docs/agent/template#renewals-and-updating-secrets) renews, rotates, and fetches secrets/tokens while the CSI Driver does not support that. ## Comparison chart The below chart provides a high-level comparison between the two solutions. -~> **Note:** Shared Memory Volume Environment Variable can be achieved through [Agent templating](/docs/platform/k8s/injector/examples#environment-variable-example). +~> **Note:** Shared Memory Volume Environment Variable can be achieved through [Agent templating](/vault/docs/platform/k8s/injector/examples#environment-variable-example). ![Comparison Chart](/img/comparison-table.png) @@ -119,10 +119,10 @@ Designing secrets management in Kubernetes is an intricate task. There are multi - [Retrieve HashiCorp Vault Secrets with Kubernetes CSI](https://www.hashicorp.com/blog/retrieve-hashicorp-vault-secrets-with-kubernetes-csi) -- [Mount Vault Secrets Through Container Storage Interface (CSI) Volume](https://learn.hashicorp.com/tutorials/vault/kubernetes-secret-store-driver?in=vault/kubernetes) +- [Mount Vault Secrets Through Container Storage Interface (CSI) Volume](/vault/tutorials/kubernetes/kubernetes-secret-store-driver) -- [Injecting Secrets into Kubernetes Pods via Vault Agent Containers](https://learn.hashicorp.com/tutorials/vault/kubernetes-sidecar) +- [Injecting Secrets into Kubernetes Pods via Vault Agent Containers](/vault/tutorials/kubernetes/kubernetes-sidecar) -- [Vault Sidecar Injector Configurations and Examples](/docs/platform/k8s/injector/annotations) +- [Vault Sidecar Injector Configurations and Examples](/vault/docs/platform/k8s/injector/annotations) -- [Vault CSI Driver Configurations and Examples](/docs/platform/k8s/csi/configurations) +- [Vault CSI Driver Configurations and Examples](/vault/docs/platform/k8s/csi/configurations) diff --git a/website/content/docs/platform/k8s/injector/annotations.mdx b/website/content/docs/platform/k8s/injector/annotations.mdx index af9ae12567..dd09f8eab3 100644 --- a/website/content/docs/platform/k8s/injector/annotations.mdx +++ b/website/content/docs/platform/k8s/injector/annotations.mdx @@ -95,11 +95,11 @@ them, optional commands to run, etc. - `vault.hashicorp.com/template-config-exit-on-retry-failure` - controls whether Vault Agent exits after it has exhausted its number of template retry attempts due to failures. Defaults to `true`. See [Vault Agent Template - Config](/docs/agent/template#template-configurations) for more details. + Config](/vault/docs/agent/template#template-configurations) for more details. - `vault.hashicorp.com/template-static-secret-render-interval` - If specified, configures how often Vault Agent Template should render non-leased secrets such as KV v2. - See [Vault Agent Template Config](/docs/agent/template#template-configurations) for more details. + See [Vault Agent Template Config](/vault/docs/agent/template#template-configurations) for more details. - `vault.hashicorp.com/agent-extra-secret` - mounts Kubernetes secret as a volume at `/vault/custom` in the sidecar/init containers. Useful for custom Agent configs with @@ -193,7 +193,7 @@ them, optional commands to run, etc. (uid 0), the `run-as-same-user` annotation will fail injection with an error. - `vault.hashicorp.com/agent-cache-enable` - configures Vault Agent to enable - [caching](/docs/agent/caching). In Vault 1.7+ this annotation will also enable + [caching](/vault/docs/agent/caching). In Vault 1.7+ this annotation will also enable a Vault Agent persistent cache. This persistent cache will be shared between the init and sidecar container to reuse tokens and leases retrieved by the init container. Defaults to `false`. @@ -211,7 +211,7 @@ them, optional commands to run, etc. - `vault.hashicorp.com/agent-service-account-token-volume-name` - the optional name of a projected volume containing a service account token for use with auto-auth against Vault's Kubernetes auth method. If the volume is mounted to another container in the deployment, the token volume will be mounted to the same location in the vault-agent containers. Otherwise it will be mounted at the default location of `/var/run/secrets/vault.hashicorp.com/serviceaccount/`. -- `vault.hashicorp.com/agent-enable-quit` - enable the [`/agent/v1/quit` endpoint](/docs/agent#quit) on an injected agent. This option defaults to false, and if true will be set on the existing cache listener, or a new localhost listener with a basic cache stanza configured. The [agent-cache-listener-port annotation](/docs/platform/k8s/injector/annotations#vault-hashicorp-com-agent-cache-listener-port) can be used to change the port. +- `vault.hashicorp.com/agent-enable-quit` - enable the [`/agent/v1/quit` endpoint](/vault/docs/agent#quit) on an injected agent. This option defaults to false, and if true will be set on the existing cache listener, or a new localhost listener with a basic cache stanza configured. The [agent-cache-listener-port annotation](/vault/docs/platform/k8s/injector/annotations#vault-hashicorp-com-agent-cache-listener-port) can be used to change the port. - `vault.hashicorp.com/go-max-procs` - set the `GOMAXPROCS` environment variable for injected agents @@ -235,20 +235,20 @@ etc. This annotation can be reused multiple times to configure multiple settings for the authentication method. Some authentication methods may require additional secrets and should be mounted via the `vault.hashicorp.com/agent-extra-secret` annotation. For a list of valid authentication configurations, - see the Vault Agent [auto-auth documentation](/docs/agent/autoauth/methods). + see the Vault Agent [auto-auth documentation](/vault/docs/agent/autoauth/methods). - `vault.hashicorp.com/auth-path` - configures the authentication path for the Kubernetes auth method. Defaults to `auth/kubernetes`. - `vault.hashicorp.com/auth-type` - configures the authentication type for Vault Agent. Defaults to `kubernetes`. For a list of valid authentication methods, see the Vault Agent - [auto-auth documentation](/docs/agent/autoauth/methods). + [auto-auth documentation](/vault/docs/agent/autoauth/methods). -- `vault.hashicorp.com/auth-min-backoff` - set the [min_backoff](/docs/agent/autoauth#min_backoff) option in the auto-auth config. Requires Vault 1.11+. +- `vault.hashicorp.com/auth-min-backoff` - set the [min_backoff](/vault/docs/agent/autoauth#min_backoff) option in the auto-auth config. Requires Vault 1.11+. -- `vault.hashicorp.com/auth-max-backoff` - set the [max_backoff](/docs/agent/autoauth#max_backoff) option in the auto-auth config +- `vault.hashicorp.com/auth-max-backoff` - set the [max_backoff](/vault/docs/agent/autoauth#max_backoff) option in the auto-auth config -- `vault.hashicorp.com/agent-auto-auth-exit-on-err` - set the [exit_on_err](/docs/agent/autoauth#exit_on_err) option in the auto-auth config +- `vault.hashicorp.com/agent-auto-auth-exit-on-err` - set the [exit_on_err](/vault/docs/agent/autoauth#exit_on_err) option in the auto-auth config - `vault.hashicorp.com/ca-cert` - path of the CA certificate used to verify Vault's TLS. @@ -305,14 +305,14 @@ etc. value to true in a production environment. - `vault.hashicorp.com/agent-disable-idle-connections` - Comma-separated [list - of Vault Agent features](/docs/agent#disable_idle_connections) where idle + of Vault Agent features](/vault/docs/agent#disable_idle_connections) where idle connections should be disabled. Also available as a command-line option (`-disable-idle-connections`) or environment variable (`AGENT_INJECT_DISABLE_IDLE_CONNECTIONS`) to set the default for all injected Agents. - `vault.hashicorp.com/agent-disable-keep-alives` - Comma-separated [list of - Vault Agent features](/docs/agent#disable_keep_alives) where keep-alives + Vault Agent features](/vault/docs/agent#disable_keep_alives) where keep-alives should be disabled. Also available as a command-line option (`-disable-keep-alives`) or environment variable (`AGENT_INJECT_DISABLE_KEEP_ALIVES`) to set the default for all injected diff --git a/website/content/docs/platform/k8s/injector/examples.mdx b/website/content/docs/platform/k8s/injector/examples.mdx index 1e397c0797..fdf729ded2 100644 --- a/website/content/docs/platform/k8s/injector/examples.mdx +++ b/website/content/docs/platform/k8s/injector/examples.mdx @@ -40,7 +40,7 @@ which is on port `8080`. - the service account should be bound to a Vault role with a policy enabling access to desired secrets. For more information on configuring the Vault Kubernetes auth method, -[see the official documentation](/docs/auth/kubernetes#configuration). +[see the official documentation](/vault/docs/auth/kubernetes#configuration). ## Debugging @@ -144,7 +144,7 @@ spec: The following example creates a deployment that mounts a Kubernetes ConfigMap containing Vault Agent configuration files. For a complete list of the Vault -Agent configuration settings, [see the Agent documentation](/docs/agent/template#vault-agent-templates). +Agent configuration settings, [see the Agent documentation](/vault/docs/agent/template#vault-agent-templates). ```yaml --- diff --git a/website/content/docs/platform/k8s/injector/index.mdx b/website/content/docs/platform/k8s/injector/index.mdx index 043dd0e443..1358d3e7c3 100644 --- a/website/content/docs/platform/k8s/injector/index.mdx +++ b/website/content/docs/platform/k8s/injector/index.mdx @@ -10,7 +10,7 @@ description: >- The Vault Agent Injector alters pod specifications to include Vault Agent containers that render Vault secrets to a shared memory volume using -[Vault Agent Templates](/docs/agent/template). +[Vault Agent Templates](/vault/docs/agent/template). By rendering secrets to a shared volume, containers within the pod can consume Vault secrets without being Vault aware. @@ -186,7 +186,7 @@ username: v-kubernet-pg-app-q0Z7WPfVNqqTJuoDqCTY-1576529094 ### Renewals and Updating Secrets For more information on when Vault Agent fetches and renews secrets, see the -[Agent documentation](/docs/agent/template#renewals-and-updating-secrets). +[Agent documentation](/vault/docs/agent/template#renewals-and-updating-secrets). ### Vault Agent Configuration Map @@ -200,7 +200,7 @@ The configuration map must contain either one or both of the following files: - **config-init.hcl** used by the init container. This must have `exit_after_auth` set to `true`. - **config.hcl** used by the sidecar container. This must have `exit_after_auth` set to `false`. -An example of mounting a Vault Agent configmap [can be found here](/docs/platform/k8s/injector/examples#configmap-example). +An example of mounting a Vault Agent configmap [can be found here](/vault/docs/platform/k8s/injector/examples#configmap-example). ## Tutorial diff --git a/website/content/docs/platform/k8s/injector/installation.mdx b/website/content/docs/platform/k8s/injector/installation.mdx index 15c5f3e4bf..4cffe808b1 100644 --- a/website/content/docs/platform/k8s/injector/installation.mdx +++ b/website/content/docs/platform/k8s/injector/installation.mdx @@ -6,7 +6,7 @@ description: The Vault Agent Sidecar Injector can be installed using Vault Helm. # Installing the Agent Injector -The [Vault Helm chart](/docs/platform/k8s/helm) is the recommended way to +The [Vault Helm chart](/vault/docs/platform/k8s/helm) is the recommended way to install and configure the Agent Injector in Kubernetes. ~> The Vault Agent Injector requires Vault 1.3.1 or greater. @@ -28,7 +28,7 @@ always run Helm with `--dry-run` before any install or upgrade to verify changes. You can see all the available values settings by running `helm inspect values hashicorp/vault` or by reading the [Vault Helm Configuration -Docs](/docs/platform/k8s/helm/configuration). Commonly used values in the Helm +Docs](/vault/docs/platform/k8s/helm/configuration). Commonly used values in the Helm chart include limiting the namespaces the injector runs in, TLS options and more. @@ -47,7 +47,7 @@ the following environment variables: ~> **Warning**: TLS 1.1 and lower are generally considered insecure. These may be set in a Helm chart deployment via the -[injector.extraEnvironmentVars](/docs/platform/k8s/helm/configuration#extraenvironmentvars) +[injector.extraEnvironmentVars](/vault/docs/platform/k8s/helm/configuration#extraenvironmentvars) option: ```bash @@ -76,17 +76,17 @@ The following is required to configure TLS manually: - Server certificate/key - Base64 PEM encoded Certificate Authority bundle -For more information on configuring manual TLS, see the [Vault Helm cert values](/docs/platform/k8s/helm/configuration#certs). +For more information on configuring manual TLS, see the [Vault Helm cert values](/vault/docs/platform/k8s/helm/configuration#certs). -This option may also be used in conjunction with [cert-manager for certificate management](/docs/platform/k8s/helm/examples/injector-tls-cert-manager). +This option may also be used in conjunction with [cert-manager for certificate management](/vault/docs/platform/k8s/helm/examples/injector-tls-cert-manager). ## Multiple Replicas and TLS The Vault Agent Injector can be run with multiple replicas if using [Manual -TLS](#manual-tls) or [cert-manager](/docs/platform/k8s/helm/examples/injector-tls-cert-manager), and as of v0.7.0 multiple replicas are also supported with +TLS](#manual-tls) or [cert-manager](/vault/docs/platform/k8s/helm/examples/injector-tls-cert-manager), and as of v0.7.0 multiple replicas are also supported with [Auto TLS](#auto-tls). The number of replicas is controlled in the Vault Helm chart by the [injector.replicas -value](/docs/platform/k8s/helm/configuration#replicas). +value](/vault/docs/platform/k8s/helm/configuration#replicas). With Auto TLS and multiple replicas, a leader replica is determined by ownership of a ConfigMap named `vault-k8s-leader`. Another replica can become the leader @@ -98,7 +98,7 @@ certificate and key needed for the webhook service listener from a Kubernetes Secret, which is updated by the leader when a certificate is near expiration. With Manual TLS and multiple replicas, -[injector.leaderElector.enabled](/docs/platform/k8s/helm/configuration#enabled-2) +[injector.leaderElector.enabled](/vault/docs/platform/k8s/helm/configuration#enabled-2) can be set to `false` since leader determination is not necessary in this case. ## Namespace Selector @@ -108,6 +108,6 @@ the system namespaces `kube-system` and `kube-public`. To limit what namespaces the injector can work in a namespace selector can be defined to match labels attached to namespaces. -For more information on configuring namespace selection, see the [Vault Helm namespaceSelector value](/docs/platform/k8s/helm/configuration#namespaceselector). +For more information on configuring namespace selection, see the [Vault Helm namespaceSelector value](/vault/docs/platform/k8s/helm/configuration#namespaceselector). [tls-suites]: https://golang.org/src/crypto/tls/cipher_suites.go diff --git a/website/content/docs/platform/mssql/changelog.mdx b/website/content/docs/platform/mssql/changelog.mdx index 04b6167d76..3ba5d8bd7d 100644 --- a/website/content/docs/platform/mssql/changelog.mdx +++ b/website/content/docs/platform/mssql/changelog.mdx @@ -27,4 +27,4 @@ IMPROVEMENTS Initial release. -[config]: /docs/platform/mssql/configuration +[config]: /vault/docs/platform/mssql/configuration diff --git a/website/content/docs/platform/mssql/configuration.mdx b/website/content/docs/platform/mssql/configuration.mdx index 2efd0e2710..36a5e1a19e 100644 --- a/website/content/docs/platform/mssql/configuration.mdx +++ b/website/content/docs/platform/mssql/configuration.mdx @@ -18,7 +18,7 @@ The following options are supported: - `vaultApiBaseUrl` `(string: required)` - Address of Vault server, e.g. `https://vault.example.com:8200` - `enableTrace` `(bool: false)` - Enable trace logging. Logs are viewable from - the event viewer. See [troubleshooting](/docs/platform/mssql/troubleshooting) + the event viewer. See [troubleshooting](/vault/docs/platform/mssql/troubleshooting) for further details. - `namespace` `(string: "")` - Set the Vault namespace to use. Applies to both AppRole and Transit. diff --git a/website/content/docs/platform/mssql/index.mdx b/website/content/docs/platform/mssql/index.mdx index 74a71e4b90..0946587389 100644 --- a/website/content/docs/platform/mssql/index.mdx +++ b/website/content/docs/platform/mssql/index.mdx @@ -17,10 +17,10 @@ Keys (KEK) managed by Vault's [Transit][transit] secret engine using SQL Server' [tde]: https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption?view=sql-server-ver15 [ekm]: https://docs.microsoft.com/sql/relational-databases/security/encryption/extensible-key-management-ekm?view=sql-server-ver15 -[transit]: https://www.vaultproject.io/docs/secrets/transit +[transit]: /vault/docs/secrets/transit -See [installation](/docs/platform/mssql/installation) and [configuration](/docs/platform/mssql/configuration) +See [installation](/vault/docs/platform/mssql/installation) and [configuration](/vault/docs/platform/mssql/configuration) for help getting started with the Vault EKM provider for SQL Server. ## Features diff --git a/website/content/docs/platform/mssql/installation.mdx b/website/content/docs/platform/mssql/installation.mdx index 562ec964bf..a19d9394f0 100644 --- a/website/content/docs/platform/mssql/installation.mdx +++ b/website/content/docs/platform/mssql/installation.mdx @@ -7,7 +7,7 @@ description: Installation steps for the Vault EKM Provider for Microsoft SQL Ser # Installing the Vault EKM Provider This guide assumes you are installing the Vault EKM Provider for the first time. -For upgrade instructions, see [upgrading](/docs/platform/mssql/upgrading). +For upgrade instructions, see [upgrading](/vault/docs/platform/mssql/upgrading). ## Prerequisites @@ -98,7 +98,7 @@ The remaining steps are all run on the database server. [releases.hashicorp.com](https://releases.hashicorp.com/vault-mssql-ekm-provider/) 1. Enter your Vault server's address when prompted and complete the installer 1. If you need to configure non-default namespace or mount paths for your AppRole and - Transit engines, see [configuration](/docs/platform/mssql/configuration). + Transit engines, see [configuration](/vault/docs/platform/mssql/configuration). ### Configure the EKM provider using SQL @@ -161,7 +161,7 @@ installation. -> **Note:** This is the first step at which the EKM provider will communicate with Vault. If Vault is misconfigured, this step is likely to fail. See - [troubleshooting](/docs/platform/mssql/troubleshooting) for tips on specific error codes. + [troubleshooting](/vault/docs/platform/mssql/troubleshooting) for tips on specific error codes. 1. Create another login from the new asymmetric key: @@ -233,7 +233,7 @@ SELECT * FROM sys.dm_database_encryption_keys; ``` To rotate the asymmetric key in Vault's Transit, you can use the standard -[`/rotate`](/api-docs/secret/transit#rotate-key) endpoint: +[`/rotate`](/vault/api-docs/secret/transit#rotate-key) endpoint: ```shell-session $ vault write -f transit/keys/ekm-encryption-key/rotate diff --git a/website/content/docs/platform/mssql/troubleshooting.mdx b/website/content/docs/platform/mssql/troubleshooting.mdx index e1bb6ca794..bad4d06f78 100644 --- a/website/content/docs/platform/mssql/troubleshooting.mdx +++ b/website/content/docs/platform/mssql/troubleshooting.mdx @@ -14,7 +14,7 @@ Logs from the Vault EKM provider will appear in Windows Event Viewer under ### Enable trace logging If the logs in the Event Viewer don't give enough information to help debug -your issue, you can [enable trace logging](/docs/platform/mssql/configuration#enabletrace). +your issue, you can [enable trace logging](/vault/docs/platform/mssql/configuration#enabletrace). Restart SQL Server for the config change to take effect, and you should see more detailed logs in the same section of Windows Event Viewer. @@ -28,13 +28,13 @@ During installation, the EKM provider registers a manifest of coded event logs t The EKM provider was unable to verify that Vault has the correct license features. This could be due to: -- An incompatible Vault Enterprise license - see the installation [prerequisites](/docs/platform/mssql/installation#prerequisites) for the required license feature. +- An incompatible Vault Enterprise license - see the installation [prerequisites](/vault/docs/platform/mssql/installation#prerequisites) for the required license feature. - Lack of network connectivity - Check Vault's audit logs to see if any requests are made to authenticate via AppRole or query the `/sys/license/status` API. - Misconfigured AppRole auth - Ensure you provided the correct Role ID and Secret ID when configuring the SQL Server `CREDENTIAL`. See the - [installation instructions](/docs/platform/mssql/installation) for an end-to-end working example. + [installation instructions](/vault/docs/platform/mssql/installation) for an end-to-end working example. - Incorrect policy permissions - The EKM provider requires the `read` capability on the path `sys/license/status`. See the `tde-policy` created in the - [installation instructions](/docs/platform/mssql/installation#configuring-vault) + [installation instructions](/vault/docs/platform/mssql/installation#configuring-vault) for an example of a working policy. diff --git a/website/content/docs/platform/servicenow/configuration.mdx b/website/content/docs/platform/servicenow/configuration.mdx index e9d9aeac88..22ebd9bbf2 100644 --- a/website/content/docs/platform/servicenow/configuration.mdx +++ b/website/content/docs/platform/servicenow/configuration.mdx @@ -32,10 +32,10 @@ To consume Vault credentials from your MID server, you will need to: The credential resolver supports reading credentials from the following secret engines: -* [Active Directory](/docs/secrets/ad) -* [AWS](/docs/secrets/aws) -* [K/V v1](/docs/secrets/kv/kv-v1) -* [K/V v2](/docs/secrets/kv/kv-v2) +* [Active Directory](/vault/docs/secrets/ad) +* [AWS](/vault/docs/secrets/aws) +* [K/V v1](/vault/docs/secrets/kv/kv-v1) +* [K/V v2](/vault/docs/secrets/kv/kv-v2) When creating K/V secrets, you must use the following keys for each component to ensure it is correctly mapped to ServiceNow's credential fields: @@ -79,7 +79,7 @@ In the ServiceNow UI: * Fill in a meaningful name * Set "Credential ID" to the path in Vault where your secret is located, e.g. for a KV v2 secret engine mounted at "secret", you might have a secret stored - under "ssh": `secret/data/ssh`. Check the [API docs](/api-docs/secret/) for + under "ssh": `secret/data/ssh`. Check the [API docs](/vault/api-docs/secret/) for your secret engine if you are unsure of the path to use * **Optional:** Click "Test credential" and select a MID server and a target to test against to test everything is working diff --git a/website/content/docs/platform/servicenow/index.mdx b/website/content/docs/platform/servicenow/index.mdx index a440f126de..8af7b938a3 100644 --- a/website/content/docs/platform/servicenow/index.mdx +++ b/website/content/docs/platform/servicenow/index.mdx @@ -9,8 +9,8 @@ description: >- ServiceNow® MID servers can use the Vault Credential Resolver to consume secrets directly from Vault for the purpose of performing discovery. See -[installation](/docs/platform/servicenow/installation) and -[configuration](/docs/platform/servicenow/configuration) for help getting started +[installation](/vault/docs/platform/servicenow/installation) and +[configuration](/vault/docs/platform/servicenow/configuration) for help getting started with the Vault Credential Resolver. ## Overview diff --git a/website/content/docs/platform/servicenow/installation.mdx b/website/content/docs/platform/servicenow/installation.mdx index 334c5d7b4e..9d52b2e16e 100644 --- a/website/content/docs/platform/servicenow/installation.mdx +++ b/website/content/docs/platform/servicenow/installation.mdx @@ -15,7 +15,7 @@ description: Installation steps for the Vault ServiceNow Credential Resolver. ## Installing Vault Agent -* Select your desired auth method from Agent's [supported auth methods](/docs/agent/autoauth/methods) +* Select your desired auth method from Agent's [supported auth methods](/vault/docs/agent/autoauth/methods) and set it up in Vault * For example, to set up AppRole auth and a role called `role1` with the `demo` policy attached: @@ -65,7 +65,7 @@ description: Installation steps for the Vault ServiceNow Credential Resolver. ``` * Install Vault Agent as a service running `vault agent -config=/path/to/agent.hcl` - * Documentation for Windows service installation [here](/docs/agent/winsvc) + * Documentation for Windows service installation [here](/vault/docs/agent/winsvc) ## Uploading JAR file to MID server @@ -84,5 +84,5 @@ description: Installation steps for the Vault ServiceNow Credential Resolver. ## Next steps -See [configuration](/docs/platform/servicenow/configuration) for details on +See [configuration](/vault/docs/platform/servicenow/configuration) for details on configuring the resolver and using credentials for discovery. diff --git a/website/content/docs/platform/servicenow/troubleshooting.mdx b/website/content/docs/platform/servicenow/troubleshooting.mdx index 4eacd8db50..1f976a9ae5 100644 --- a/website/content/docs/platform/servicenow/troubleshooting.mdx +++ b/website/content/docs/platform/servicenow/troubleshooting.mdx @@ -18,7 +18,7 @@ from the fields you expected. You will also find any exceptions that the resolver throws in the logs, including if it didn't find the minimum set of required fields as specified in -[configuration](/docs/platform/servicenow/configuration#creating-a-secret-in-vault), +[configuration](/vault/docs/platform/servicenow/configuration#creating-a-secret-in-vault), or if it couldn't communicate with Vault. [log files]: https://docs.servicenow.com/bundle/quebec-servicenow-platform/page/product/mid-server/reference/r_MIDServerTroubleshooting.html diff --git a/website/content/docs/plugins/index.mdx b/website/content/docs/plugins/index.mdx index c0b0ec04db..4eaf15e434 100644 --- a/website/content/docs/plugins/index.mdx +++ b/website/content/docs/plugins/index.mdx @@ -18,7 +18,7 @@ A plugin is uniquely identified by its type (one of `secret`, `auth`, or implies either the built-in plugin or the single unversioned plugin that can be registered. -See [Plugin Upgrade Procedure](/docs/upgrading/plugins#plugin-upgrade-procedure) +See [Plugin Upgrade Procedure](/vault/docs/upgrading/plugins#plugin-upgrade-procedure) for details on how to upgrade a built-in plugin in-place. ## Built-In Plugins @@ -33,12 +33,12 @@ intervention to run. To run an external plugin, a binary of the plugin is required. Plugin binaries can be obtained from [releases.hashicorp.com](https://releases.hashicorp.com/) -or they can be [built from source](/docs/plugins/plugin-development#building-a-plugin-from-source). +or they can be [built from source](/vault/docs/plugins/plugin-development#building-a-plugin-from-source). Vault's external plugins are completely separate, standalone applications that Vault executes and communicates with over RPC. Each time a Vault secret engine, auth method, or database plugin is mounted, a new process is spawned. However, -plugins can be made to implement [plugin multiplexing](/docs/plugins/plugin-architecture#plugin-multiplexing) +plugins can be made to implement [plugin multiplexing](/vault/docs/plugins/plugin-architecture#plugin-multiplexing) to improve performance. Plugin multiplexing allows plugin processes to be reused across all mounts of a given type. diff --git a/website/content/docs/plugins/plugin-architecture.mdx b/website/content/docs/plugins/plugin-architecture.mdx index 4e1f1c7ff3..d89914e4fd 100644 --- a/website/content/docs/plugins/plugin-architecture.mdx +++ b/website/content/docs/plugins/plugin-architecture.mdx @@ -45,7 +45,7 @@ loaded when a request that requires the plugin is received by Vault. ### External Plugin Scaling Characteristics -External plugins can leverage [Performance Standbys](/docs/enterprise/performance-standby) +External plugins can leverage [Performance Standbys](/vault/docs/enterprise/performance-standby) without any explicit action by a plugin author. The default behavior of Vault Enterprise is to attempt to handle all requests, including requests to plugins, on performance standbys. If the plugin request makes any attempt to modify @@ -62,7 +62,7 @@ plugin's RPC server. Plugins make use of the AutoMTLS feature of [go-plugin](https://www.github.com/hashicorp/go-plugin) which will automatically negotiate mutual TLS for transport authentication. -The [`api_addr`](/docs/configuration#api_addr) must be set in order for the +The [`api_addr`](/vault/docs/configuration#api_addr) must be set in order for the plugin process to establish communication with the Vault server during mount time. If the storage backend has HA enabled and supports automatic host address detection (e.g. Consul), Vault will automatically attempt to determine the @@ -81,7 +81,7 @@ plugin directory and the plugin catalog entry. ### Plugin Directory The plugin directory is a configuration option of Vault and can be specified in -the [configuration file](/docs/configuration). +the [configuration file](/vault/docs/configuration). This setting specifies a directory in which all plugin binaries must live; _this value cannot be a symbolic link_. A plugin cannot be added to Vault unless it exists in the plugin directory. There is no @@ -100,7 +100,7 @@ ensure the executable referenced in the command exists in the plugin directory. When added to the catalog, the plugin is not automatically executed, but becomes visible to backends and can be executed by them. For more information on the plugin catalog please see the [Plugin Catalog API -docs](/api-docs/system/plugins-catalog). +docs](/vault/api-docs/system/plugins-catalog). An example of plugin registration in current versions of Vault: @@ -129,17 +129,17 @@ When a backend wants to run a plugin, it first looks up the plugin, by name, in the catalog. It then checks the executable's SHA256 sum against the one configured in the plugin catalog. Finally Vault runs the command configured in the catalog, sending along the JWT formatted response wrapping token and mlock -settings. Like Vault, plugins support [the use of mlock when available](/docs/configuration#disable_mlock). +settings. Like Vault, plugins support [the use of mlock when available](/vault/docs/configuration#disable_mlock). ~> Note: If Vault is configured with `mlock` enabled, then the Vault executable -and each plugin executable in your [plugins directory](/docs/plugins/plugin-architecture#plugin-directory) +and each plugin executable in your [plugins directory](/vault/docs/plugins/plugin-architecture#plugin-directory) must be given the ability to use the `mlock` syscall. ### Plugin Upgrades External plugins may be updated by registering and reloading them. More details on the upgrade procedure can be found in -[Upgrading Vault Plugins](/docs/upgrading/plugins). +[Upgrading Vault Plugins](/vault/docs/upgrading/plugins). ## Plugin Multiplexing @@ -157,8 +157,8 @@ multiplexing. To use a non-multiplexed plugin, run an older version of the plugin, i.e., the plugin calls the `Serve` function. More resources on implementing plugin multiplexing: -* [Database secrets engines](/docs/secrets/databases/custom#serving-a-plugin-with-multiplexing) -* [Secrets engines and auth methods](/docs/plugins/plugin-development) +* [Database secrets engines](/vault/docs/secrets/databases/custom#serving-a-plugin-with-multiplexing) +* [Secrets engines and auth methods](/vault/docs/plugins/plugin-development) ## Troubleshooting diff --git a/website/content/docs/plugins/plugin-development.mdx b/website/content/docs/plugins/plugin-development.mdx index 32bca6fbda..94d02fc8b2 100644 --- a/website/content/docs/plugins/plugin-development.mdx +++ b/website/content/docs/plugins/plugin-development.mdx @@ -88,24 +88,24 @@ Let's take a closer look at a snippet from the above main package. The call to `plugin.ServeMultiplex` ensures that the plugin will use Vault's [plugin -multiplexing](/docs/plugins/plugin-architecture#plugin-multiplexing) feature. +multiplexing](/vault/docs/plugins/plugin-architecture#plugin-multiplexing) feature. However, this plugin will not be multiplexed if it is run by a version of Vault that does not support multiplexing. Vault will simply fall back to a plugin version that it can run. Additionally, we set the `TLSProviderFunc` to ensure that our plugin is backwards compatible with versions of Vault that do not support automatic mutual TLS for secure [plugin -communication](/docs/plugins/plugin-architecture#plugin-communication). If you +communication](/vault/docs/plugins/plugin-architecture#plugin-communication). If you are certain your plugin does not need backwards compatibility, this field can be omitted. -[api_addr]: /docs/configuration#api_addr +[api_addr]: /vault/docs/configuration#api_addr ## Building a Plugin from Source To build a plugin from source, first navigate to the location holding the desired plugin version. Next, run `go build` to obtain a new binary for the plugin. Finally, -[register](/docs/plugins/plugin-architecture#plugin-registration) the +[register](/vault/docs/plugins/plugin-architecture#plugin-registration) the plugin and enable it. ## Plugin Development - Resources @@ -117,10 +117,10 @@ tutorial. Other HashiCorp plugin development resources: * [vault-auth-plugin-example](https://github.com/hashicorp/vault-auth-plugin-example) -* [Custom Secrets Engines](https://learn.hashicorp.com/collections/vault/custom-secrets-engine) +* [Custom Secrets Engines](/vault/tutorials/custom-secrets-engine) ### Plugin Development - Resources - Community -See the [Plugin Portal](/docs/plugins/plugin-portal#community) to find +See the [Plugin Portal](/vault/docs/plugins/plugin-portal#community) to find Community plugin examples/guides developed by community members. HashiCorp does not validate these for correctness. diff --git a/website/content/docs/plugins/plugin-management.mdx b/website/content/docs/plugins/plugin-management.mdx index 3a51c7b827..1f949babc5 100644 --- a/website/content/docs/plugins/plugin-management.mdx +++ b/website/content/docs/plugins/plugin-management.mdx @@ -18,12 +18,12 @@ backend has HA enabled and supports automatic host address detection (e.g. Consul), Vault will automatically attempt to determine the `api_addr` as well. Detailed information regarding the plugin system can be found in the -[internals documentation](/docs/plugins). +[internals documentation](/vault/docs/plugins). ## Registering External Plugins Before an external plugin can be mounted, it needs to be -[registered](/docs/plugins/plugin-architecture#plugin-registration) in the +[registered](/vault/docs/plugins/plugin-architecture#plugin-registration) in the plugin catalog to ensure the plugin invoked by Vault is authentic and maintains integrity: @@ -65,5 +65,5 @@ $ vault secrets disable my-secrets Upgrade instructions can be found in the [Upgrading Plugins - Guides][upgrading_plugins] page. -[api_addr]: /docs/configuration#api_addr -[upgrading_plugins]: /docs/upgrading/plugins +[api_addr]: /vault/docs/configuration#api_addr +[upgrading_plugins]: /vault/docs/upgrading/plugins diff --git a/website/content/docs/plugins/plugin-portal.mdx b/website/content/docs/plugins/plugin-portal.mdx index 241526110c..ae2321ed31 100644 --- a/website/content/docs/plugins/plugin-portal.mdx +++ b/website/content/docs/plugins/plugin-portal.mdx @@ -7,10 +7,10 @@ description: A curated collection of official, partner, and community Vault plug # Plugin Portal This page contains a curated collection of official, partner, and community -[Vault plugins](/docs/plugins). +[Vault plugins](/vault/docs/plugins). For more information about plugin development, refer to this [documentation -section](/docs/plugins/plugin-development). In addition, the [Custom Secrets Engines](https://learn.hashicorp.com/collections/vault/custom-secrets-engine) tutorial series demonstrates the plugin development workflow in more detail. +section](/vault/docs/plugins/plugin-development). In addition, the [Custom Secrets Engines](/vault/tutorials/custom-secrets-engine) tutorial series demonstrates the plugin development workflow in more detail. ## Official @@ -22,28 +22,28 @@ if necessary. If a plugin exists separately under its own repository, follow the instructions within that repository to develop, test, and build the plugin. If a repository exists within the Vault repository, the plugin can be built as instructed in -[here](/docs/plugins#built-in-plugins). +[here](/vault/docs/plugins#built-in-plugins). ### Auth - [AliCloud](https://github.com/hashicorp/vault-plugin-auth-alicloud) -- [AppRole](/api-docs/auth/approle) -- [Amazon Web Services (AWS)](/api-docs/auth/aws) +- [AppRole](/vault/api-docs/auth/approle) +- [Amazon Web Services (AWS)](/vault/api-docs/auth/aws) - [Azure](https://github.com/hashicorp/vault-plugin-auth-azure) - [Centrify](https://github.com/hashicorp/vault-plugin-auth-centrify) - [Cloud Foundry](https://github.com/hashicorp/vault-plugin-auth-cf) -- [GitHub](/api-docs/auth/github) +- [GitHub](/vault/api-docs/auth/github) - [Google Cloud Platform (GCP)](https://github.com/hashicorp/vault-plugin-auth-gcp) - [JWT/OIDC](https://github.com/hashicorp/vault-plugin-auth-jwt) - [Kerberos](https://github.com/hashicorp/vault-plugin-auth-kerberos) - [Kubernetes](https://github.com/hashicorp/vault-plugin-auth-kubernetes) -- [Okta](/api-docs/auth/okta) +- [Okta](/vault/api-docs/auth/okta) - [Oracle Cloud Infrastructure (OCI)](https://github.com/hashicorp/vault-plugin-auth-oci) -- [RADIUS](/api-docs/auth/radius) -- [TLS Certificates](/api-docs/auth/cert) -- [Username/Password](/api-docs/auth/userpass) +- [RADIUS](/vault/api-docs/auth/radius) +- [TLS Certificates](/vault/api-docs/auth/cert) +- [Username/Password](/vault/api-docs/auth/userpass) @@ -51,20 +51,20 @@ exists within the Vault repository, the plugin can be built as instructed in -- [Cassandra](/api-docs/secret/databases/cassandra) +- [Cassandra](/vault/api-docs/secret/databases/cassandra) - [Couchbase](https://github.com/hashicorp/vault-plugin-database-couchbase) - [Elasticsearch](https://github.com/hashicorp/vault-plugin-database-elasticsearch) -- [InfluxDB](/api-docs/secret/databases/influxdb) -- [HanaDB](/api-docs/secret/databases/hanadb) -- [MongoDB](/api-docs/secret/databases/mongodb) +- [InfluxDB](/vault/api-docs/secret/databases/influxdb) +- [HanaDB](/vault/api-docs/secret/databases/hanadb) +- [MongoDB](/vault/api-docs/secret/databases/mongodb) - [MongoDB Atlas](https://github.com/hashicorp/vault-plugin-database-mongodbatlas) -- [MSSQL](/api-docs/secret/databases/mssql) -- [MySQL/MariaDB](/api-docs/secret/databases/mysql-maria) +- [MSSQL](/vault/api-docs/secret/databases/mssql) +- [MySQL/MariaDB](/vault/api-docs/secret/databases/mysql-maria) - [Oracle Database](https://github.com/hashicorp/vault-plugin-database-oracle) -- [PostgreSQL](/api-docs/secret/databases/postgresql) -- [Redis](/api-docs/secret/databases/redis) -- [Redis ElastiCache](/api-docs/secret/databases/rediselasticache) -- [Redshift](/api-docs/secret/databases/redshift) +- [PostgreSQL](/vault/api-docs/secret/databases/postgresql) +- [Redis](/vault/api-docs/secret/databases/redis) +- [Redis ElastiCache](/vault/api-docs/secret/databases/rediselasticache) +- [Redshift](/vault/api-docs/secret/databases/redshift) - [Snowflake](https://github.com/hashicorp/vault-plugin-database-snowflake) @@ -75,24 +75,24 @@ exists within the Vault repository, the plugin can be built as instructed in - [Active Directory](https://github.com/hashicorp/vault-plugin-secrets-ad) - [AliCloud](https://github.com/hashicorp/vault-plugin-secrets-alicloud) -- [Amazon Web Services AWS](/api-docs/secret/aws) +- [Amazon Web Services AWS](/vault/api-docs/secret/aws) - [Azure](https://github.com/hashicorp/vault-plugin-secrets-azure) -- [Consul](/api-docs/secret/consul) +- [Consul](/vault/api-docs/secret/consul) - [Google Cloud Platform (GCP)](https://github.com/hashicorp/vault-plugin-secrets-gcp) - [GCP KMS](https://github.com/hashicorp/vault-plugin-secrets-gcpkms) -- [KMIP](/api-docs/secret/kmip) ENTERPRISE -- [Key Management](/api-docs/secret/key-management) ENTERPRISE +- [KMIP](/vault/api-docs/secret/kmip) ENTERPRISE +- [Key Management](/vault/api-docs/secret/key-management) ENTERPRISE - [Key/Value (KV)](https://github.com/hashicorp/vault-plugin-secrets-kv) - [Kubernetes](https://github.com/hashicorp/vault-plugin-secrets-kubernetes) - [MongoDB Atlas](https://github.com/hashicorp/vault-plugin-secrets-mongodbatlas) -- [Nomad](/api-docs/secret/nomad) +- [Nomad](/vault/api-docs/secret/nomad) - [LDAP](https://github.com/hashicorp/vault-plugin-secrets-openldap) -- [PKI](/api-docs/secret/pki) -- [RabbitMQ](/api-docs/secret/rabbitmq) -- [SSH](/api-docs/secret/ssh) -- [TOTP](/api-docs/secret/totp) -- [Transform](/api-docs/secret/transform) ENTERPRISE -- [Transit](/api-docs/secret/transit) +- [PKI](/vault/api-docs/secret/pki) +- [RabbitMQ](/vault/api-docs/secret/rabbitmq) +- [SSH](/vault/api-docs/secret/ssh) +- [TOTP](/vault/api-docs/secret/totp) +- [Transform](/vault/api-docs/secret/transform) ENTERPRISE +- [Transit](/vault/api-docs/secret/transit) diff --git a/website/content/docs/release-notes/1.10.0.mdx b/website/content/docs/release-notes/1.10.0.mdx index ef9be72fd8..bff701f242 100644 --- a/website/content/docs/release-notes/1.10.0.mdx +++ b/website/content/docs/release-notes/1.10.0.mdx @@ -28,13 +28,13 @@ This section describes the new features introduced as part of Vault ### Multi-Factor Authentication (MFA) for Vault OSS -Vault has had support for the [Step-up Enterprise MFA](/docs/enterprise/mfa) as part of its Enterprise edition. The Step-up Enterprise MFA allows having an MFA on login, or for step-up access to sensitive resources in Vault. +Vault has had support for the [Step-up Enterprise MFA](/vault/docs/enterprise/mfa) as part of its Enterprise edition. The Step-up Enterprise MFA allows having an MFA on login, or for step-up access to sensitive resources in Vault. -With Vault 1.10.0, MFA as part of [login](/docs/auth/login-mfa) is now supported for Vault OSS. This demonstrates HashiCorp’s thought leadership in security and its continued endeavor to enable all Vault users to employ strong security policies with Vault. +With Vault 1.10.0, MFA as part of [login](/vault/docs/auth/login-mfa) is now supported for Vault OSS. This demonstrates HashiCorp’s thought leadership in security and its continued endeavor to enable all Vault users to employ strong security policies with Vault. -~> **Note:** The Legacy MFA in Vault OSS is a [deprecated](/docs/deprecation) feature and will be removed in Vault 1.11. +~> **Note:** The Legacy MFA in Vault OSS is a [deprecated](/vault/docs/deprecation) feature and will be removed in Vault 1.11. -Refer to the [Login MFA FAQ](/docs/auth/login-mfa/faq) to understand the various MFA workflows that are supported in Vault 1.10.0. +Refer to the [Login MFA FAQ](/vault/docs/auth/login-mfa/faq) to understand the various MFA workflows that are supported in Vault 1.10.0. ### Vault OIDC provider with PKCE support @@ -50,11 +50,11 @@ We have introduced three new resources to enable configuration of the [KMIP secr ### KV Secrets Engine v2 patch operations -We now support an additional method for managing [KV v2 secrets](/api-docs/secret/kv/kv-v2) to maintain least privilege security in certain types of automated environments. This feature creates a new PATCH capability that enables partial updates to KV v2 secrets without requiring the READ privilege to the entire endpoint for an entity. +We now support an additional method for managing [KV v2 secrets](/vault/api-docs/secret/kv/kv-v2) to maintain least privilege security in certain types of automated environments. This feature creates a new PATCH capability that enables partial updates to KV v2 secrets without requiring the READ privilege to the entire endpoint for an entity. ### DB2 Dynamic Secrets support -Vault operators can leverage the openldap secrets engine to manage credentials for IBM DB2 and the LDAP security plugin for Db2. This allows Db2 to offload authentication and authorization to the LDAP security plugin and allows Vault to manage static credentials or even generate dynamic users. For more details, refer to the For more details, refer to the [IBM Db2 Credentials Management](https://learn.hashicorp.com/tutorials/vault/ibm-db2-openldap) tutorial. +Vault operators can leverage the openldap secrets engine to manage credentials for IBM DB2 and the LDAP security plugin for Db2. This allows Db2 to offload authentication and authorization to the LDAP security plugin and allows Vault to manage static credentials or even generate dynamic users. For more details, refer to the For more details, refer to the [IBM Db2 Credentials Management](/vault/tutorials/secrets-management/ibm-db2-openldap) tutorial. ### Temporal Transit Key rotation @@ -70,23 +70,23 @@ The work done above to support HSM-backed PKI operations inspired us to consider ### Server Side Consistent Tokens -Vault’s [eventual consistency](/docs/enterprise/consistency) model precludes read-after-write guarantees when clients interact with performance standbys or performance replication clusters. The [Client Controlled Consistency](/docs/enterprise/consistency#vault-1-7-mitigations) mitigations supported with Vault 1.7 provide ways to achieve consistency through client modifications or by using the agent for proxied requests, which is not possible in all cases. The Server Side Consistent Tokens feature provides an implicit way to achieve consistency by embedding the minimum Write-Ahead-Log state information in the Service tokens returned from logins or token-create requests. This feature introduces changes in the token format and the new tokesn will be the default tokens starting in Vault 1.10.0. Vault 1.10.0 is backwards compatible with old tokens. +Vault’s [eventual consistency](/vault/docs/enterprise/consistency) model precludes read-after-write guarantees when clients interact with performance standbys or performance replication clusters. The [Client Controlled Consistency](/vault/docs/enterprise/consistency#vault-1-7-mitigations) mitigations supported with Vault 1.7 provide ways to achieve consistency through client modifications or by using the agent for proxied requests, which is not possible in all cases. The Server Side Consistent Tokens feature provides an implicit way to achieve consistency by embedding the minimum Write-Ahead-Log state information in the Service tokens returned from logins or token-create requests. This feature introduces changes in the token format and the new tokesn will be the default tokens starting in Vault 1.10.0. Vault 1.10.0 is backwards compatible with old tokens. -See [Replication](/docs/configuration/replication), [Vault Eventual Consistency](/docs/enterprise/consistency), [Upgrade to 1.10.0](/docs/upgrading/upgrade-to-1.10.x) and [Server Side Consistent Token FAQ](/docs/faq/ssct) to understand the various consistency options available with Vault 1.10.0 and the considerations to be aware of prior to selecting an option for your use case. +See [Replication](/vault/docs/configuration/replication), [Vault Eventual Consistency](/vault/docs/enterprise/consistency), [Upgrade to 1.10.0](/vault/docs/upgrading/upgrade-to-1.10.x) and [Server Side Consistent Token FAQ](/vault/docs/faq/ssct) to understand the various consistency options available with Vault 1.10.0 and the considerations to be aware of prior to selecting an option for your use case. ## Vault Agent Features ### Support for Telemetry -Starting with Vault 1.10.0, the Vault Agent supports a new metrics endpoint and [Telemetry](/docs/agent#telemetry-stanza) metrics around run time, authentication success, authentication failures, cache hits, cache misses, proxy succes, and proxy client errors. This Vault Agent Telemetry should greatly help with the retrieval of key operational insights for Vault Agent deployments. +Starting with Vault 1.10.0, the Vault Agent supports a new metrics endpoint and [Telemetry](/vault/docs/agent#telemetry-stanza) metrics around run time, authentication success, authentication failures, cache hits, cache misses, proxy succes, and proxy client errors. This Vault Agent Telemetry should greatly help with the retrieval of key operational insights for Vault Agent deployments. ### User-assigned managed identities for auto auth in Azure -With this [enhancement](/docs/agent/autoauth/methods/azure), users can specify user-assigned managed identities via the `object_id` and `client_id` when configuring Vault agent auto-auth for Azure. This enables users that have more than one user-assigned managed identity associated with their VM to specify which one they'd like to use when authenticating via the Vault's Azure auth method. Note that providing these parameters is an "exclusive or" operation. +With this [enhancement](/vault/docs/agent/autoauth/methods/azure), users can specify user-assigned managed identities via the `object_id` and `client_id` when configuring Vault agent auto-auth for Azure. This enables users that have more than one user-assigned managed identity associated with their VM to specify which one they'd like to use when authenticating via the Vault's Azure auth method. Note that providing these parameters is an "exclusive or" operation. ### Quit API endpoint with config -Previously, for instances where the Agent is a sidecar in a Kubernetes job and the job hangs, you must either use `shareProcessNamespace: true` for the container so that the process kill signals can be sent, or avoid the sidecar container entirely and solely rely on an init container. With this [enhancement](/docs/agent#quit), we have added support for a Quit API endpoint to automatically shut down the Vault Agent, therefore eliminating the need to perform the workarounds. +Previously, for instances where the Agent is a sidecar in a Kubernetes job and the job hangs, you must either use `shareProcessNamespace: true` for the container so that the process kill signals can be sent, or avoid the sidecar container entirely and solely rely on an init container. With this [enhancement](/vault/docs/agent#quit), we have added support for a Quit API endpoint to automatically shut down the Vault Agent, therefore eliminating the need to perform the workarounds. ## Other Features and Enhancements @@ -96,21 +96,21 @@ This section describes other features and enhancements introduced as part of the We have introduced auth mount-based attribution of clients to help better understand where clients are being used within a cluster. This is available via UI and API. This is an enhancement on top of the namespace attribution capability we introduced in Vault 1.9. -We have also introduced the ability to view changes to clients month over month via the client count API, and made other UI enhancements. Refer to [What is a Client?](/docs/concepts/client-count) and [Client Count FAQ](/docs/concepts/client-count/faq) for more details. +We have also introduced the ability to view changes to clients month over month via the client count API, and made other UI enhancements. Refer to [What is a Client?](/vault/docs/concepts/client-count) and [Client Count FAQ](/vault/docs/concepts/client-count/faq) for more details. ### Mount Migration -We have made improvements to the `sys/remount` API endpoint to simplify the complexities of moving data, such as secret engine and authentication method configuration from one mount to another, within a namespace or across namespaces. This can help with restructuring namespaces and mounts for various reasons, including migrating mounts from root to other namespaces when transitioning to using namespaces for the first time. For step-by-step instructions, refer to the [Mount Move](https://learn.hashicorp.com/tutorials/vault/mount-move) tutorial. +We have made improvements to the `sys/remount` API endpoint to simplify the complexities of moving data, such as secret engine and authentication method configuration from one mount to another, within a namespace or across namespaces. This can help with restructuring namespaces and mounts for various reasons, including migrating mounts from root to other namespaces when transitioning to using namespaces for the first time. For step-by-step instructions, refer to the [Mount Move](/vault/tutorials/enterprise/mount-move) tutorial. ### Scaling External Database plugins -Database plugins can now implement [plugin multiplexing](/docs/plugins/plugin-architecture#plugin-multiplexing) which allows a single plugin process to be used for multiple database connections. Database plugin multiplexing will be enabled on the Oracle Database plugin starting in v0.6.0. We will extend this functionality to additional database plugins in subsequent releases. +Database plugins can now implement [plugin multiplexing](/vault/docs/plugins/plugin-architecture#plugin-multiplexing) which allows a single plugin process to be used for multiple database connections. Database plugin multiplexing will be enabled on the Oracle Database plugin starting in v0.6.0. We will extend this functionality to additional database plugins in subsequent releases. Any external database plugins that want to adopt multiplexing support will have to update their main.go call from [dbplugin.Serve()](https://github.com/hashicorp/vault/blob/sdk/v0.4.1/sdk/database/dbplugin/v5/plugin_server.go#L13) to [dbplugin.ServeMultiplex()](https://github.com/hashicorp/vault/blob/sdk/v0.4.1/sdk/database/dbplugin/v5/plugin_server.go#L42). Multiplexable database plugins are compatible with older versions of Vault down to Vault 1.6. Refer to this [Oracle Database PR](https://github.com/hashicorp/vault-plugin-database-oracle/pull/74) as an example of the upgrade process. ### Consul Secrets Engine enhancements -Consul has supported [namespace](https://developer.hashicorp.com/consul/docs/enterprise/namespaces), [admin partitions](https://developer.hashicorp.com/consul/docs/enterprise/admin-partitions) and [ACL roles](https://developer.hashicorp.com/consul/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](/consul/docs/enterprise/namespaces), [admin partitions](/consul/docs/enterprise/admin-partitions) and [ACL roles](/consul/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 @@ -118,7 +118,7 @@ Prior to Vault 1.10.0, the Vault UI used localStorage to store authentication in ### Advanced I/O Handling for Transform FPE -The Transform Secrets Engine allows users to securely encrypt data while providing control over the output format. In Vault 1.9, we introduced [additional format fields](/docs/release-notes/1.9.0#advanced-i-o-handling-for-tranform-fpe-adp-transform) on the templates used for this workflow. In Vault 1.10.0, we have now added those two new fields, `encode_format` and `decode_format`, to the Create Template page on the UI under Advanced Templating. +The Transform Secrets Engine allows users to securely encrypt data while providing control over the output format. In Vault 1.9, we introduced [additional format fields](/vault/docs/release-notes/1.9.0#advanced-i-o-handling-for-tranform-fpe-adp-transform) on the templates used for this workflow. In Vault 1.10.0, we have now added those two new fields, `encode_format` and `decode_format`, to the Create Template page on the UI under Advanced Templating. ## Breaking changes @@ -126,7 +126,7 @@ The following section details breaking changes introduced in Vault 1.10.0. ### LDAP auth method entity alias mapping -In Vault 1.9, we added support to provide custom user filters through the [userfilter](/api-docs/auth/ldap#userfilter) parameter. This support changed the way that entity alias was mapped to an entity. Prior to Vault 1.9, alias names were always based on the [login username](/api-docs/auth/ldap#username-3) (which in turn is based on the value of the [userattr](/api-docs/auth/ldap#userattr)). In Vault 1.9, alias names no longer mapped to the login username. Instead, the mapping depends on other config values as well, such as [updomain](/api-docs/auth/ldap#upndomain), [binddn](/api-docs/auth/ldap#binddn), [discoverydn](/api-docs/auth/ldap#discoverdn), and [userattr](/api-docs/auth/ldap#userattr). +In Vault 1.9, we added support to provide custom user filters through the [userfilter](/vault/api-docs/auth/ldap#userfilter) parameter. This support changed the way that entity alias was mapped to an entity. Prior to Vault 1.9, alias names were always based on the [login username](/vault/api-docs/auth/ldap#username-3) (which in turn is based on the value of the [userattr](/vault/api-docs/auth/ldap#userattr)). In Vault 1.9, alias names no longer mapped to the login username. Instead, the mapping depends on other config values as well, such as [updomain](/vault/api-docs/auth/ldap#upndomain), [binddn](/vault/api-docs/auth/ldap#binddn), [discoverydn](/vault/api-docs/auth/ldap#discoverdn), and [userattr](/vault/api-docs/auth/ldap#userattr). With Vault 1.10.0, we re-introduced the option to force the alias name to map to the login username with the optional parameter username_as_alias. Users that have the LDAP auth method enabled prior to Vault 1.9 may want to consider setting this to true to revert back to the old behavior. Otherwise, depending on the other aforementioned config values, logins may generate a new and different entity for an existing user with a previous entity associated in Vault. This in turn affects client counts since there may be more than one entity tied to this user. The username_as_alias flag was also made available in subsequent Vault 1.8.x and Vault 1.9.x releases to allow for this to be set prior to a Vault 1.10.0 upgrade. @@ -134,9 +134,9 @@ With Vault 1.10.0, we re-introduced the option to force the alias name to map to ### Single Vault follower restart causes election even with established quorum -We now support Server Side Consistent Tokens (See [Replication](/docs/configuration/replication), [Vault Eventual Consistency](/docs/enterprise/consistency), and [Upgrade to 1.10.0](/docs/upgrading/upgrade-to-1.10.x).), which introduces a new token format that can only be used on nodes of 1.10 or higher version. This new format is enabled by default upon upgrading to the new version. Old format tokens can be read by Vault 1.10.0, but the new format Vault 1.10 tokens cannot be read by older Vault versions. +We now support Server Side Consistent Tokens (See [Replication](/vault/docs/configuration/replication), [Vault Eventual Consistency](/vault/docs/enterprise/consistency), and [Upgrade to 1.10.0](/vault/docs/upgrading/upgrade-to-1.10.x).), which introduces a new token format that can only be used on nodes of 1.10 or higher version. This new format is enabled by default upon upgrading to the new version. Old format tokens can be read by Vault 1.10.0, but the new format Vault 1.10 tokens cannot be read by older Vault versions. -For more details, see the [Server Side Consistent Tokens FAQ](/docs/faq/ssct). +For more details, see the [Server Side Consistent Tokens FAQ](/vault/docs/faq/ssct). Since service tokens are always created on the leader, as long as the leader is not upgraded before performance standbys, service tokens will be of the old format and still be usable during the upgrade process. However, the usual upgrade process we recommend can't be relied upon to always upgrade the leader last. Due to this known [issue](https://github.com/hashicorp/vault/issues/14153), a Vault cluster using Integrated Storage may result in a leader not being upgraded last, and this can trigger a re-election. This re-election can cause the upgraded node to become the leader, resulting in the newly created tokens on the leader to be unusable on nodes that have not yet been upgraded. Note that this issue does not impact Vault OSS users. @@ -154,7 +154,7 @@ When adding or modifying a Duo MFA method for step-up Enterprise MFA using the ` Signing in to the Vault UI using an OIDC auth mount listed in the "tabs" of the form will result in the following error: "Authentication failed: role with oidc role_type is not allowed". -The auth mounts listed in the "tabs" of the form are those that have [listing_visibility](/api-docs/system/auth#listing_visibility-1) +The auth mounts listed in the "tabs" of the form are those that have [listing_visibility](/vault/api-docs/system/auth#listing_visibility-1) set to `unauth`. There is a workaround for this error that will allow you to sign in to Vault using the OIDC @@ -167,4 +167,4 @@ When trying to start Vault server 1.10.0 on Windows, and there is less than 100G ## Feature Deprecations and EOL -Please refer to the [Deprecation Plans and Notice](/docs/deprecation) page for up-to-date information on feature deprecations and plans. An [Feature Deprecation FAQ](/docs/deprecation/faq) page is also available to address questions concerning decisions made about Vault feature deprecations. +Please refer to the [Deprecation Plans and Notice](/vault/docs/deprecation) page for up-to-date information on feature deprecations and plans. An [Feature Deprecation FAQ](/vault/docs/deprecation/faq) page is also available to address questions concerning decisions made about Vault feature deprecations. diff --git a/website/content/docs/release-notes/1.11.0.mdx b/website/content/docs/release-notes/1.11.0.mdx index 2b2ef67354..4639166744 100644 --- a/website/content/docs/release-notes/1.11.0.mdx +++ b/website/content/docs/release-notes/1.11.0.mdx @@ -32,16 +32,16 @@ This section describes the new features introduced as part of Vault 1.11.0. ### Configure GCP auth to target non-public good API addresses -The GCP auth method only allows for public API endpoints to be configured for authentication purposes. Workloads running in GCP that do not have external internet access need the ability to authenticate using [Private Google Access](https://cloud.google.com/vpc/docs/private-google-access#pga). In Vault 1.11.0, we allow for customization of certain service endpoints. For more information, refer to the [GCP auth method](/api-docs/auth/gcp#custom_endpoint) documentation. +The GCP auth method only allows for public API endpoints to be configured for authentication purposes. Workloads running in GCP that do not have external internet access need the ability to authenticate using [Private Google Access](https://cloud.google.com/vpc/docs/private-google-access#pga). In Vault 1.11.0, we allow for customization of certain service endpoints. For more information, refer to the [GCP auth method](/vault/api-docs/auth/gcp#custom_endpoint) documentation. ### Support for key/pair based authentication for Snowflake -In Vault 1.11.0, the Snowflake Database Engine supports an additional credential type that can be generated. For users not wanting to rely on the standard user/pass authentication to Snowflake, Vault can now dynamically generate RSA key pairs that allow users to authenticate into Snowflake. For more information, refer to the [Snowflake Database Secrets Engine](/docs/secrets/databases/snowflake) and [Database Secrets Engine (API)](/api-docs/secret/databases) documentation. +In Vault 1.11.0, the Snowflake Database Engine supports an additional credential type that can be generated. For users not wanting to rely on the standard user/pass authentication to Snowflake, Vault can now dynamically generate RSA key pairs that allow users to authenticate into Snowflake. For more information, refer to the [Snowflake Database Secrets Engine](/vault/docs/secrets/databases/snowflake) and [Database Secrets Engine (API)](/vault/api-docs/secret/databases) documentation. ### Dynamic Kubernetes service account secrets -Kubernetes service accounts must be manually generated and passed to a Kubernetes configuration file or the command line using a CLI tool such as kubectl to interact with Kubernetes clusters. With this method, service account credentials, which contain static secrets, can be exposed and would require a periodic manual rotation. To address this issue, we now support generating short-lived dynamic service accounts and associate role bindings to specific Kubernetes namespaces. For more information, refer to the [Kubernetes Auth Method](/docs/auth/kubernetes) and [Kubernetes Auth Method (API)](/api-docs/auth/kubernetes) documentation. +Kubernetes service accounts must be manually generated and passed to a Kubernetes configuration file or the command line using a CLI tool such as kubectl to interact with Kubernetes clusters. With this method, service account credentials, which contain static secrets, can be exposed and would require a periodic manual rotation. To address this issue, we now support generating short-lived dynamic service accounts and associate role bindings to specific Kubernetes namespaces. For more information, refer to the [Kubernetes Auth Method](/vault/docs/auth/kubernetes) and [Kubernetes Auth Method (API)](/vault/api-docs/auth/kubernetes) documentation. ### New KV secrets engine (v2) utilities @@ -51,15 +51,15 @@ The KV version 2 secrets engine now includes a set of utilities and enhancements * New flag to output a sample policy in HCL (`-output-policy`) for any Vault CLI command. * New KV convenience/helper methods (GET and PUT) added to the Go client library. -For more details, refer to the [Version Key/Value Secrets Engine](https://learn.hashicorp.com/tutorials/vault/versioned-kv) tutorial. +For more details, refer to the [Version Key/Value Secrets Engine](/vault/tutorials/secrets-management/versioned-kv) tutorial. ### Support for node identity and service identity for Vault Consul secrets engine -Within the Consul secrets engine, practitioners writing a Vault role can specify node-identity or service-identity. You can also specify multiples of each identity on a Vault role. For more information, refer to the [Consul Secrets Engine](/docs/secrets/consul) and [Consul Secrets Engine (API)](/api-docs/secret/consul) documentation. +Within the Consul secrets engine, practitioners writing a Vault role can specify node-identity or service-identity. You can also specify multiples of each identity on a Vault role. For more information, refer to the [Consul Secrets Engine](/vault/docs/secrets/consul) and [Consul Secrets Engine (API)](/vault/api-docs/secret/consul) documentation. ### Autopilot (Vault Enterprise) -Vault release 1.7 introduced the Autopilot feature to Integrated Storage. In this release, new Autopilot features are added to Vault Enterprise to perform seamless automatic upgrades and support redundancy zones for improved cluster resiliency. Refer to the [autopilot endpoint](/api-docs/system/storage/raftautopilot#sys-storage-raft-autopilot), [operator raft](/docs/commands/operator/raft), [Autopilot](/docs/concepts/integrated-storage/autopilot), [Automated Upgrades](/docs/enterprise/automated-upgrades), and [Redundancy Zones](/docs/enterprise/redundancy-zones) documentation for more information. +Vault release 1.7 introduced the Autopilot feature to Integrated Storage. In this release, new Autopilot features are added to Vault Enterprise to perform seamless automatic upgrades and support redundancy zones for improved cluster resiliency. Refer to the [autopilot endpoint](/vault/api-docs/system/storage/raftautopilot#sys-storage-raft-autopilot), [operator raft](/vault/docs/commands/operator/raft), [Autopilot](/vault/docs/concepts/integrated-storage/autopilot), [Automated Upgrades](/vault/docs/enterprise/automated-upgrades), and [Redundancy Zones](/vault/docs/enterprise/redundancy-zones) documentation for more information. ## Other Features and Enhancements @@ -77,12 +77,12 @@ PKI secrets engine users have sought a way to rotate root or intermediate CAs wi We have made the following improvements to the Client Count tooling: -* Provide the ability to export the unique clients that contribute to the client count aggregate for the selected billing period via a new [activity export API endpoint](/api-docs/system/internal-counters#activity-export). This feature is available in tech preview mode. +* Provide the ability to export the unique clients that contribute to the client count aggregate for the selected billing period via a new [activity export API endpoint](/vault/api-docs/system/internal-counters#activity-export). This feature is available in tech preview mode. * Provide the ability to view changes to client counts month over month in the UI. ### MFA Enhancements -Vault 1.10 introduced [Login MFA](/docs/auth/login-mfa) support for Vault OSS. In this release, we included additional enhancements to the Login MFA feature by introducing the ability to configure Login MFA via the UI and providing an enhanced TOTP configuration experience via the QR code scan. +Vault 1.10 introduced [Login MFA](/vault/docs/auth/login-mfa) support for Vault OSS. In this release, we included additional enhancements to the Login MFA feature by introducing the ability to configure Login MFA via the UI and providing an enhanced TOTP configuration experience via the QR code scan. ### Vault Agent: Support for using an existing valid certificate upon re-authentication @@ -94,11 +94,11 @@ With Terraform Vault provider v3.7.0, we have made enhancements where it’s now ### ADP-Tranform enhancements -Two new enhancements were made to the Transform secrets engine. The first is Convergent Tokenization, which allows tokenization transformations to be configured as _convergent_. When enabled, this guarantees that tokenizing a given plaintext and expiration more than once always results in the same token value being produced. Please refer to the [Convergent Tokenization](/docs/secrets/transform/tokenization#convergence) document for more information. Token Lookup allows you to look up the value of a token given its plaintext. While this is not typically encouraged from a security perspective, it may be necessary for particular circumstances that require this operation. Note that token lookup is only supported when convergence is enabled. For more information on the endpoint, refer to the [Lookup Token](/api-docs/secret/transform#lookup-token) documentation. +Two new enhancements were made to the Transform secrets engine. The first is Convergent Tokenization, which allows tokenization transformations to be configured as _convergent_. When enabled, this guarantees that tokenizing a given plaintext and expiration more than once always results in the same token value being produced. Please refer to the [Convergent Tokenization](/vault/docs/secrets/transform/tokenization#convergence) document for more information. Token Lookup allows you to look up the value of a token given its plaintext. While this is not typically encouraged from a security perspective, it may be necessary for particular circumstances that require this operation. Note that token lookup is only supported when convergence is enabled. For more information on the endpoint, refer to the [Lookup Token](/vault/api-docs/secret/transform#lookup-token) documentation. ### KMIP support for import, query, encryption and decryption -Previously, KMIP did not support certain operations such as import, decrypt, encrypt, and query. These operations are now supported. For a complete list of supported KMIP operations, please refer to the [Supported KMIP Operations](/docs/secrets/kmip) documentation. +Previously, KMIP did not support certain operations such as import, decrypt, encrypt, and query. These operations are now supported. For a complete list of supported KMIP operations, please refer to the [Supported KMIP Operations](/vault/docs/secrets/kmip) documentation. @include 'pgx-params.mdx' @@ -110,4 +110,4 @@ When you use Vault 1.11.0+ as a Consul's Connect CA, you may encounter an issue ## Feature Deprecations and EOL -Please refer to the [Deprecation Plans and Notice](/docs/deprecation) page for up-to-date information on feature deprecations and plans. An [Feature Deprecation FAQ](/docs/deprecation/faq) page is also available to address questions concerning decisions made about Vault feature deprecations. +Please refer to the [Deprecation Plans and Notice](/vault/docs/deprecation) page for up-to-date information on feature deprecations and plans. An [Feature Deprecation FAQ](/vault/docs/deprecation/faq) page is also available to address questions concerning decisions made about Vault feature deprecations. diff --git a/website/content/docs/release-notes/1.12.0.mdx b/website/content/docs/release-notes/1.12.0.mdx index f048f16677..796eefd1aa 100644 --- a/website/content/docs/release-notes/1.12.0.mdx +++ b/website/content/docs/release-notes/1.12.0.mdx @@ -27,7 +27,7 @@ Some of these enhancements and changes in this release include the following: - **Redis Database Secrets Engine** is now available to manage static roles or generation of dynamic credentials, as well as root credential rotation on a stand-alone Redis server. - **AWS Elasticache Database Secrets Engine** is introduced to manage static credentials for AWS Elasticache instances. -~> **Vault Enterprise:** Use [Integrated Storage](/docs/configuration/storage/raft) or [Consul](/docs/configuration/storage/consul) as your Vault's storage backend. Vault Enterprise will no longer start up if configured to use a storage backend other than Integrated Storage or Consul. (See the [Upgrade Guide](/docs/upgrading/upgrade-to-1.12.x).) +~> **Vault Enterprise:** Use [Integrated Storage](/vault/docs/configuration/storage/raft) or [Consul](/vault/docs/configuration/storage/consul) as your Vault's storage backend. Vault Enterprise will no longer start up if configured to use a storage backend other than Integrated Storage or Consul. (See the [Upgrade Guide](/vault/docs/upgrading/upgrade-to-1.12.x).) ## New Features @@ -44,13 +44,13 @@ We are extending that support to the Vault Transform Secrets Engine in this rel #### MSSQL Support -An MSSQL store is now available to be used as an external storage engine with tokenization Transform Secrets Engine. Refer to the following documents, [Transform Secrets Engine(API)](/api-docs/secret/transform), [Transform Secrets Engine](/docs/secrets/transform), and [Tokenization Transform](/docs/secrets/transform/tokenization) for more information. +An MSSQL store is now available to be used as an external storage engine with tokenization Transform Secrets Engine. Refer to the following documents, [Transform Secrets Engine(API)](/vault/api-docs/secret/transform), [Transform Secrets Engine](/vault/docs/secrets/transform), and [Tokenization Transform](/vault/docs/secrets/transform/tokenization) for more information. #### Key Auto Rotation Periodic rotation of encryption keys is a recommended key management practice for a good security posture. In Vault release 1.10, we added support for Auto key rotation for Transit Secrets Engine. In Vault 1.12, the Transform secrets engine is now enhanced, allowing users to set the rotation policy during key creation in a time interval, which will cause Vault to rotate the Transform keys when the time interval elapses automatically. -Refer to the following documentation [Tokenization Transform](/docs/secrets/transform/tokenization) and [Transform Secrets Engine(API)](/api-docs/secret/transform#rotate-tokenization-key) for more information. +Refer to the following documentation [Tokenization Transform](/vault/docs/secrets/transform/tokenization) and [Transform Secrets Engine(API)](/vault/api-docs/secret/transform#rotate-tokenization-key) for more information. ### PKI Secrets Engine Improvements @@ -60,7 +60,7 @@ We are improving Vault PKI Engine’s revocation capabilities by adding support #### PKI and Managed Key support for RSA-PSS Signatures -Since its initial release, Vault's PKI secrets engine only supported RSA-PKCS#1v1.5 (Public Key Cryptographic Standards) signatures for issuers and leaves. To conform with NIST's guidance around key transport and for compatibility with newer HSM Firmware, we have included support for RSA-PSS signatures (Probabilistic Signature Scheme). See the section on [PSS Support in the PKI documentation](https://www.vaultproject.io/docs/secrets/pki/considerations#pss-support) for limitations of this feature. +Since its initial release, Vault's PKI secrets engine only supported RSA-PKCS#1v1.5 (Public Key Cryptographic Standards) signatures for issuers and leaves. To conform with NIST's guidance around key transport and for compatibility with newer HSM Firmware, we have included support for RSA-PSS signatures (Probabilistic Signature Scheme). See the section on [PSS Support in the PKI documentation](/vault/docs/secrets/pki/considerations#pss-support) for limitations of this feature. #### PKI Telemetry Improvements @@ -86,18 +86,18 @@ This was a community contributed enhancement. ### Path and Role-Based Resource Quotas -In this release, the existing resource quota functionality has been enhanced. In addition to applying the API rate limiting and lease quotas at the namespace or mount level, you can now use the quotas to the [API path suffixes and auth mount roles](/docs/enterprise/lease-count-quotas). This enhancement provides users with more control over issued certificates. +In this release, the existing resource quota functionality has been enhanced. In addition to applying the API rate limiting and lease quotas at the namespace or mount level, you can now use the quotas to the [API path suffixes and auth mount roles](/vault/docs/enterprise/lease-count-quotas). This enhancement provides users with more control over issued certificates. ### Client Count Improvements -The billing period for client counting API can now be specified with the [current month](/docs/concepts/client-count) for the end date parameter. When this is done the "new_clients" field will have an hyperlog approximate value indicating the number of new clients that came in the current month. Note that for the previous months, the number will be an exact value. +The billing period for client counting API can now be specified with the [current month](/vault/docs/concepts/client-count) for the end date parameter. When this is done the "new_clients" field will have an hyperlog approximate value indicating the number of new clients that came in the current month. Note that for the previous months, the number will be an exact value. ### Redis Database Secrets Engine -With the support of the Redis database secrets engine, users can use Vault to manage static and dynamic credentials for Redis OSS. The engine works similarly to other database secrets engines. Refer to the [Redis](/docs/secrets/databases/redis) documentation for more information. Huge thanks to [Francis Hitchens](https://github.com/fhitchen), who contributed their repository to HashiCorp +With the support of the Redis database secrets engine, users can use Vault to manage static and dynamic credentials for Redis OSS. The engine works similarly to other database secrets engines. Refer to the [Redis](/vault/docs/secrets/databases/redis) documentation for more information. Huge thanks to [Francis Hitchens](https://github.com/fhitchen), who contributed their repository to HashiCorp ### AWS Elasticache Database Secrets Engine -With the support of the AWS ElastiCache database secrets engine, users may use Vault to manage static credentials for AWS Elasticache instances. The engine will work similarly to other database secrets engines. Refer to the [elasticache](/docs/secrets/databases/rediselasticache) documentation for more information. +With the support of the AWS ElastiCache database secrets engine, users may use Vault to manage static credentials for AWS Elasticache instances. The engine will work similarly to other database secrets engines. Refer to the [elasticache](/vault/docs/secrets/databases/rediselasticache) documentation for more information. ### LDAP Secrets Engine @@ -137,10 +137,10 @@ Vault can now act as an OIDC provider for applications that wish to delegate aut ### License Termination Behavior -The Licensing termination behavior has changed where non-evaluation licenses (production licenses) no longer have a termination date, making Vault more robust for Vault Enterprise customers. Also refer to the updated [licensing FAQ](/docs/enterprise/license/faq) for more information. +The Licensing termination behavior has changed where non-evaluation licenses (production licenses) no longer have a termination date, making Vault more robust for Vault Enterprise customers. Also refer to the updated [licensing FAQ](/vault/docs/enterprise/license/faq) for more information. ### Namespace Custom Metadata -Customers can now specify [custom metadata](/api-docs/system/namespaces) on the namespaces. The new `vault namespace patch` [command](/docs/commands/namespace) can be used to update existing namespaces with custom metadata as well. This will make it possible to tag namespaces with additional fields (For example: owner, region department) describing it. +Customers can now specify [custom metadata](/vault/api-docs/system/namespaces) on the namespaces. The new `vault namespace patch` [command](/vault/docs/commands/namespace) can be used to update existing namespaces with custom metadata as well. This will make it possible to tag namespaces with additional fields (For example: owner, region department) describing it. ### Vault Agent Improvements @@ -158,4 +158,4 @@ There are no known issues documented for this release. ## Feature Deprecations and EOL -Please refer to the [Deprecation Plans and Notice](/docs/deprecation) page for up-to-date information on feature deprecations and plans. A [Feature Deprecation FAQ](/docs/deprecation/faq) page addresses questions about decisions made about Vault feature deprecations. +Please refer to the [Deprecation Plans and Notice](/vault/docs/deprecation) page for up-to-date information on feature deprecations and plans. A [Feature Deprecation FAQ](/vault/docs/deprecation/faq) page addresses questions about decisions made about Vault feature deprecations. diff --git a/website/content/docs/release-notes/1.8.0.mdx b/website/content/docs/release-notes/1.8.0.mdx index 99470f0ac4..642419acaf 100644 --- a/website/content/docs/release-notes/1.8.0.mdx +++ b/website/content/docs/release-notes/1.8.0.mdx @@ -55,7 +55,7 @@ description: |- The following API endpoints have been deprecated and will be removed in a future release: - `POST sys/license` to store licenses in storage; it is recommended to use - [License Autoloading](/docs/enterprise/license/autoloading) instead. + [License Autoloading](/vault/docs/enterprise/license/autoloading) instead. - `/gcp/token/:roleset` and `/gcp/key/:roleset` paths for generating secrets for rolesets diff --git a/website/content/docs/release-notes/1.9.0.mdx b/website/content/docs/release-notes/1.9.0.mdx index 4a0f1a6f60..d19e54d8e1 100644 --- a/website/content/docs/release-notes/1.9.0.mdx +++ b/website/content/docs/release-notes/1.9.0.mdx @@ -35,7 +35,7 @@ The following section provides details about the ADP module features added in th #### Advanced I/O handling for Tranform FPE (ADP-Transform) -Users of the Format Preserving Encryption (FPE) feature of ADP Transform will now benefit from increased flexibility with regards to formatting the input and output of their data. [Transformation templates](https://learn.hashicorp.com/tutorials/vault/transform#advanced-handling) are receiving two new fields- **encode_format** and **decode_formats** -that allow users to specify and format individual [capturing groups](https://www.regular-expressions.info/refcapture.html) within the regular expressions that define their formats. +Users of the Format Preserving Encryption (FPE) feature of ADP Transform will now benefit from increased flexibility with regards to formatting the input and output of their data. [Transformation templates](/vault/tutorials/adp/transform#advanced-handling) are receiving two new fields- **encode_format** and **decode_formats** -that allow users to specify and format individual [capturing groups](https://www.regular-expressions.info/refcapture.html) within the regular expressions that define their formats. #### MS SQL TDE (ADP-KM) @@ -43,7 +43,7 @@ We added support to Vault Enterprise for customers who want Vault to manage encr #### Key Management Secrets(KMS) engine - GCP (ADP-KM) -The [KMS Engine for GCP](https://www.vaultproject.io/docs/secrets/gcpkms) provides key management via the Google Cloud KMS to assist with automating many GCP key management functions. +The [KMS Engine for GCP](/vault/docs/secrets/gcpkms) provides key management via the Google Cloud KMS to assist with automating many GCP key management functions. ## Other Features and Enhancements @@ -51,7 +51,7 @@ This section describes other features and enhancements introduced as part of the ### Vault Agent improvements -Improvements were made to the Vault Agent Cache to ensure that [consul-template is always routed through the Vault Agent cache](/docs/agent/template), therefore, eliminating the need for listeners to be defined in the Vault Agent for just templating. +Improvements were made to the Vault Agent Cache to ensure that [consul-template is always routed through the Vault Agent cache](/vault/docs/agent/template), therefore, eliminating the need for listeners to be defined in the Vault Agent for just templating. ### Customized username generation for database dynamic credentials @@ -59,7 +59,7 @@ This feature enables customization of username for database dynamic credentials. ### Customizable HTTP headers for Vault -This feature allows security operators to configure [custom response headers](/docs/configuration/listener/tcp) to HTTP root path (`/`) and API endpoints (`/v1/*`), in addition to the previously supported UI paths through the server HCL configuration file. +This feature allows security operators to configure [custom response headers](/vault/docs/configuration/listener/tcp) to HTTP root path (`/`) and API endpoints (`/v1/*`), in addition to the previously supported UI paths through the server HCL configuration file. ### Support for IBM s390X CPU architecture @@ -67,11 +67,11 @@ This feature adds support for Vault to run on the IBM s390x architecture via the ### Namespace API lock -This [feature](/docs/concepts/namespace-api-lock) allows namespace administrators to flexibly control operations such as locking APIs from child namespaces to which they have access. This enables them to restrict access to their domain in a multi-tenant environment and perform break-glass procedures in times of emergency to protect a cluster from within their child namespace. +This [feature](/vault/docs/concepts/namespace-api-lock) allows namespace administrators to flexibly control operations such as locking APIs from child namespaces to which they have access. This enables them to restrict access to their domain in a multi-tenant environment and perform break-glass procedures in times of emergency to protect a cluster from within their child namespace. ### 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/plugin/sdkv2) 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](/terraform/plugin/sdkv2) to leverage new features. ### Azure Secrets Engine @@ -82,26 +82,26 @@ The following enhancement are included: ### Customized metadata for KV -This [enhancement](https://www.vaultproject.io/api-docs/secret/kv/kv-v2) provides the ability to set version-agnostic custom key metadata for Vault KVv2 secrets via a metadata endpoint. This custom metadata is also visible in the UI. +This [enhancement](/vault/api-docs/secret/kv/kv-v2) provides the ability to set version-agnostic custom key metadata for Vault KVv2 secrets via a metadata endpoint. This custom metadata is also visible in the UI. ## UI Enhancements ### Expanding the UI for more DB secrets engines -We have been adding support for DB secrets engines in the UI over the past few releases. In the Vault 1.9 release, we have added support for [Oracle](/docs/secrets/databases/oracle) and [ElasticSearch](/docs/secrets/databases/elasticdb) and [PostgresSQL](/docs/secrets/databases/postgresql) database secrets engines in the UI. +We have been adding support for DB secrets engines in the UI over the past few releases. In the Vault 1.9 release, we have added support for [Oracle](/vault/docs/secrets/databases/oracle) and [ElasticSearch](/vault/docs/secrets/databases/elasticdb) and [PostgresSQL](/vault/docs/secrets/databases/postgresql) database secrets engines in the UI. ### PKI certificate metadata -The [PKI Secrets Engine](/docs/secrets/pki) now displays additional PKI certificate metadata in the UI, such as date issued, date of expiry, serial number, and subject/name. +The [PKI Secrets Engine](/vault/docs/secrets/pki) now displays additional PKI certificate metadata in the UI, such as date issued, date of expiry, serial number, and subject/name. ## Tech Preview Features ### KV Secrets Engine v2 patch operations -This feature provides a more streamlined method for managing [KV v2 secrets](https://www.vaultproject.io/api-docs/secret/kv/kv-v2), enabling customers to better maintain least privilege security in automated environments. This feature allows performing partial updates to KV v2 secrets without requiring to read the full KV secret's key/value pairs. +This feature provides a more streamlined method for managing [KV v2 secrets](/vault/api-docs/secret/kv/kv-v2), enabling customers to better maintain least privilege security in automated environments. This feature allows performing partial updates to KV v2 secrets without requiring to read the full KV secret's key/value pairs. ### Vault as an OIDC Provider -Vault can now act as an OIDC Provider so applications can leverage the pre-existing [Vault identities](/api-docs/secret/identity) to authenticate into applications. +Vault can now act as an OIDC Provider so applications can leverage the pre-existing [Vault identities](/vault/api-docs/secret/identity) to authenticate into applications. ## Breaking Changes @@ -109,11 +109,11 @@ 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.x) for more information. +In Vault 1.9, the [internal HTTP Request count API](/vault/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](/vault/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. ## Feature Deprecations and EOL -Please refer to the [Deprecation Plans and Notice](/docs/deprecation) page for up-to-date information on feature deprecations and plans. An [FAQ](/docs/deprecation/faq) page is also available to address questions concerning decisions made about Vault feature deprecations. +Please refer to the [Deprecation Plans and Notice](/vault/docs/deprecation) page for up-to-date information on feature deprecations and plans. An [FAQ](/vault/docs/deprecation/faq) page is also available to address questions concerning decisions made about Vault feature deprecations. diff --git a/website/content/docs/secrets/ad.mdx b/website/content/docs/secrets/ad.mdx index fe44877440..09bd22086a 100644 --- a/website/content/docs/secrets/ad.mdx +++ b/website/content/docs/secrets/ad.mdx @@ -17,9 +17,9 @@ This is designed for a high-load environment where many instances may be accessi a shared password simultaneously. With a simple set up and a simple creds API, it doesn't require instances to be manually registered in advance to gain access. As long as access has been granted to the creds path via a method like -[AppRole](/api-docs/auth/approle), they're available. Passwords are +[AppRole](/vault/api-docs/auth/approle), they're available. Passwords are lazily rotated based on preset TTLs and can have a length configured to meet your needs. Additionally, -passwords can be manually rotated using the [rotate-role](/api-docs/secret/ad#rotate-role-credentials) endpoint. +passwords can be manually rotated using the [rotate-role](/vault/api-docs/secret/ad#rotate-role-credentials) endpoint. The second feature (service account check-out) is where a library of service accounts can be checked out by a person or by machines. Vault will automatically rotate the password @@ -32,8 +32,8 @@ will check them in when their lending period (or, "ttl", in Vault's language) en There are two ways of customizing how passwords are generated in the Active Directory secret engine: -1. [Password Policies](/docs/concepts/password-policies) -2. `length` and `formatter` fields within the [configuration](/api-docs/secret/ad#password-parameters) +1. [Password Policies](/vault/docs/concepts/password-policies) +2. `length` and `formatter` fields within the [configuration](/vault/api-docs/secret/ad#password-parameters) Utilizing password policies is the recommended path as the `length` and `formatter` fields have been deprecated in favor of password policies. The `password_policy` field within the configuration @@ -125,7 +125,7 @@ management tool. ``` 4. Grant "my-application" access to its creds at `ad/creds/my-application` using an - auth method like [AppRole](/api-docs/auth/approle). + auth method like [AppRole](/vault/api-docs/auth/approle). ### FAQ @@ -191,7 +191,7 @@ In this example, the service account names of `fizz@example.com` and `buzz@examp already been created on the remote AD server. They've been set aside solely for Vault to handle. The `ttl` is how long each check-out will last before Vault checks in a service account, rotating its password during check-in. The `max_ttl` is the maximum amount of time it can live -if it's renewed. These default to `24h`, and both use [duration format strings](/docs/concepts/duration-format). +if it's renewed. These default to `24h`, and both use [duration format strings](/vault/docs/concepts/duration-format). Also by default, a service account must be checked in by the same Vault entity or client token that checked it out. However, if this behavior causes problems, set `disable_check_in_enforcement=true`. @@ -356,5 +356,5 @@ Refer to the [Active Directory Service Account Check-out](https://learn.hashicor ## API The Active Directory secrets engine has a full HTTP API. Please see the -[Active Directory secrets engine API](/api-docs/secret/ad) for more +[Active Directory secrets engine API](/vault/api-docs/secret/ad) for more details. diff --git a/website/content/docs/secrets/alicloud.mdx b/website/content/docs/secrets/alicloud.mdx index 899e1c7b92..a892725d34 100644 --- a/website/content/docs/secrets/alicloud.mdx +++ b/website/content/docs/secrets/alicloud.mdx @@ -207,5 +207,5 @@ the proper permission, it can generate credentials. ## API The AliCloud secrets engine has a full HTTP API. Please see the -[AliCloud secrets engine API](/api-docs/secret/alicloud) for more +[AliCloud secrets engine API](/vault/api-docs/secret/alicloud) for more details. diff --git a/website/content/docs/secrets/aws.mdx b/website/content/docs/secrets/aws.mdx index b4e791873b..299b4aa912 100644 --- a/website/content/docs/secrets/aws.mdx +++ b/website/content/docs/secrets/aws.mdx @@ -164,7 +164,7 @@ the proper permission, it can generate credentials. ~> **Note:** Due to AWS eventual consistency, after calling the `aws/config/rotate-root` endpoint, subsequent calls from Vault to AWS may fail for a few seconds until AWS becomes consistent again. - See the [AWS secrets engine API](/api-docs/secret/aws#rotate-root-iam-credentials) + See the [AWS secrets engine API](/vault/api-docs/secret/aws#rotate-root-iam-credentials) for further information on `config/rotate-root` functionality. ## Example IAM Policy for Vault @@ -479,5 +479,5 @@ errors for exceeding the AWS limit of 32 characters on STS token names. ## API The AWS secrets engine has a full HTTP API. Please see the -[AWS secrets engine API](/api-docs/secret/aws) for more +[AWS secrets engine API](/vault/api-docs/secret/aws) for more details. diff --git a/website/content/docs/secrets/azure.mdx b/website/content/docs/secrets/azure.mdx index f766d999c2..1bf9fe60a2 100644 --- a/website/content/docs/secrets/azure.mdx +++ b/website/content/docs/secrets/azure.mdx @@ -24,7 +24,7 @@ The password will be deleted when the lease is revoked. ~> Microsoft is shutting down their Azure Active Directory API and will be retiring it in 2022. If you are currently using this secret engine, you will need to update the credentials to include Microsoft Graph API permissions and specify the `use_microsoft_graph_api` configuration value as true. See the -[API Docs](/api-docs/secret/azure#use_microsoft_graph_api) for more details. +[API Docs](/vault/api-docs/secret/azure#use_microsoft_graph_api) for more details. ## Setup @@ -249,7 +249,7 @@ principal using the Azure portal: In this example we will migrate the Azure secret engine from using Azure Active Directory (AAD) to Microsoft Graph. -First, create a new service principal [with the proper permissions](/docs/secrets/azure#authentication) +First, create a new service principal [with the proper permissions](/vault/docs/secrets/azure#authentication) for managing Azure accounts. After granting the appropriate permissions, the following will be needed from the service principal to configure the secret engine: @@ -337,6 +337,6 @@ to learn how to use the Azure secrets engine to dynamically generate Azure crede The Azure secrets engine has a full HTTP API. Please see the [Azure secrets engine API docs][api] for more details. -[api]: /api-docs/secret/azure -[config]: /api-docs/secret/azure#configure-access +[api]: /vault/api-docs/secret/azure +[config]: /vault/api-docs/secret/azure#configure-access [repo]: https://github.com/hashicorp/vault-plugin-secrets-azure diff --git a/website/content/docs/secrets/consul.mdx b/website/content/docs/secrets/consul.mdx index 776e666c93..eb15ece6de 100644 --- a/website/content/docs/secrets/consul.mdx +++ b/website/content/docs/secrets/consul.mdx @@ -13,7 +13,7 @@ description: The Consul secrets engine for Vault generates tokens for Consul dyn The Consul secrets engine generates [Consul](https://www.consul.io/) API tokens dynamically based on Consul ACL policies. --> **Note:** See the Consul Agent [config documentation](https://developer.hashicorp.com/consul/docs/agent/config/config-files#acl-parameters) +-> **Note:** See the Consul Agent [config documentation](/consul/docs/agent/config/config-files#acl-parameters) for details on how to enable Consul's ACL system. ## Setup @@ -105,7 +105,7 @@ management tool. you will either provide a policy document and a token type, a list of policies or roles, or a set of service or node identities. When users generate credentials, they are generated against this role. - 1. For Consul versions 1.8 and above, attach [a Consul node identity](https://developer.hashicorp.com/consul/commands/acl/token/create#node-identity) to the role. + 1. For Consul versions 1.8 and above, attach [a Consul node identity](/consul/commands/acl/token/create#node-identity) to the role. ```shell-session $ vault write consul/roles/my-role \ @@ -114,7 +114,7 @@ management tool. Success! Data written to: consul/roles/my-role ``` - 1. For Consul versions 1.5 and above, attach either [a role in Consul](https://developer.hashicorp.com/consul/api-docs/acl/roles) or [a Consul service identity](https://developer.hashicorp.com/consul/commands/acl/token/create#service-identity) to the role: + 1. For Consul versions 1.5 and above, attach either [a role in Consul](/consul/api-docs/acl/roles) or [a Consul service identity](/consul/commands/acl/token/create#service-identity) to the role: ```shell-session $ vault write consul/roles/my-role consul_roles="api-server" @@ -128,7 +128,7 @@ management tool. Success! Data written to: consul/roles/my-role ``` - 1. For Consul versions 1.4 and above, generate [a policy in Consul](https://learn.hashicorp.com/tutorials/consul/access-control-setup-production), + 1. For Consul versions 1.4 and above, generate [a policy in Consul](/consul/tutorials/security/access-control-setup-production), and proceed to link it to the role: ```shell-session @@ -137,7 +137,7 @@ management tool. ``` 1. For Consul versions below 1.4, the policy must be base64-encoded. The policy language is - [documented by Consul](https://developer.hashicorp.com/consul/docs/security/acl/acl-legacy). Support for this method is + [documented by Consul](/consul/docs/security/acl/acl-legacy). Support for this method is deprecated as of Vault 1.11. Write a policy and proceed to link it to the role: @@ -149,11 +149,11 @@ management tool. -> **Token lease duration:** If you do not specify a value for `ttl` (or `lease` for Consul versions below 1.4) the tokens created using Vault's Consul secrets engine are created with a Time To Live (TTL) of 30 days. You can change - the lease duration by passing `-ttl=` to the command above where duration is a [duration format strings](/docs/concepts/duration-format). + the lease duration by passing `-ttl=` to the command above where duration is a [duration format strings](/vault/docs/concepts/duration-format). 1. You may further limit a role's access by adding the optional parameters `consul_namespace` and - `partition`. Please refer to Consul's [namespace documentation](https://developer.hashicorp.com/consul/docs/enterprise/namespaces) and - [admin partition documentation](https://developer.hashicorp.com/consul/docs/enterprise/admin-partitions) for further information about + `partition`. Please refer to Consul's [namespace documentation](/consul/docs/enterprise/namespaces) and + [admin partition documentation](/consul/docs/enterprise/admin-partitions) for further information about these features. 1. For Consul version 1.11 and above, link an admin partition to a role: @@ -200,13 +200,13 @@ the token is synchronized with Consul, apply the token to the agents using the C ## Tutorial Refer to [Administer Consul Access Control Tokens with -Vault](https://learn.hashicorp.com/tutorials/consul/vault-consul-secrets) for a +Vault](/consul/tutorials/vault-secure/vault-consul-secrets) for a step-by-step tutorial. ## API The Consul secrets engine has a full HTTP API. Please see the -[Consul secrets engine API](/api-docs/secret/consul) for more +[Consul secrets engine API](/vault/api-docs/secret/consul) for more details. -[consul-mgmt-token]: https://developer.hashicorp.com/consul/api-docs/acl#acl_create +[consul-mgmt-token]: /consul/api-docs/acl#acl_create diff --git a/website/content/docs/secrets/cubbyhole.mdx b/website/content/docs/secrets/cubbyhole.mdx index 632b539ea0..9d90ff5ba6 100644 --- a/website/content/docs/secrets/cubbyhole.mdx +++ b/website/content/docs/secrets/cubbyhole.mdx @@ -59,5 +59,5 @@ tutorial to learn how to securely distribute the initial token to the trusted en ## API The Cubbyhole secrets engine has a full HTTP API. Please see the -[Cubbyhole secrets engine API](/api-docs/secret/cubbyhole) for more +[Cubbyhole secrets engine API](/vault/api-docs/secret/cubbyhole) for more details. diff --git a/website/content/docs/secrets/databases/cassandra.mdx b/website/content/docs/secrets/databases/cassandra.mdx index 38014ec7e3..c8d6cc6d3c 100644 --- a/website/content/docs/secrets/databases/cassandra.mdx +++ b/website/content/docs/secrets/databases/cassandra.mdx @@ -15,7 +15,7 @@ Cassandra is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the Cassandra database. -See the [database secrets engine](/docs/secrets/databases) docs for +See the [database secrets engine](/vault/docs/secrets/databases) docs for more information about setting up the database secrets engine. ## Capabilities @@ -90,6 +90,6 @@ the proper permission, it can generate credentials. ## API -The full list of configurable options can be seen in the [Cassandra database plugin API](/api-docs/secret/databases/cassandra) page. +The full list of configurable options can be seen in the [Cassandra database plugin API](/vault/api-docs/secret/databases/cassandra) page. -For more information on the database secrets engine's HTTP API please see the [Database secret secrets engine API](/api-docs/secret/databases) page. +For more information on the database secrets engine's HTTP API please see the [Database secret secrets engine API](/vault/api-docs/secret/databases) page. diff --git a/website/content/docs/secrets/databases/couchbase.mdx b/website/content/docs/secrets/databases/couchbase.mdx index fd942f0988..ac9003c532 100644 --- a/website/content/docs/secrets/databases/couchbase.mdx +++ b/website/content/docs/secrets/databases/couchbase.mdx @@ -15,7 +15,7 @@ Couchbase is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the Couchbase database. -See the [database secrets engine](/docs/secrets/databases) docs for +See the [database secrets engine](/vault/docs/secrets/databases) docs for more information about setting up the database secrets engine. ## Capabilities @@ -138,6 +138,6 @@ to enable generating credentials. ## API -The full list of configurable options can be seen in the [Couchbase database plugin API](/api-docs/secret/databases/couchbase) page. +The full list of configurable options can be seen in the [Couchbase database plugin API](/vault/api-docs/secret/databases/couchbase) page. -For more information on the database secrets engine's HTTP API please see the [Database secret secrets engine API](/api-docs/secret/databases) page. +For more information on the database secrets engine's HTTP API please see the [Database secret secrets engine API](/vault/api-docs/secret/databases) page. diff --git a/website/content/docs/secrets/databases/custom.mdx b/website/content/docs/secrets/databases/custom.mdx index 5bf93984d1..cfe5fa6910 100644 --- a/website/content/docs/secrets/databases/custom.mdx +++ b/website/content/docs/secrets/databases/custom.mdx @@ -27,12 +27,12 @@ write your own code to generate credentials in any database you wish. It also allows databases that require dynamically linked libraries to be used as plugins while keeping Vault itself statically linked. -Please read the [Plugins internals](/docs/plugins) docs for more +Please read the [Plugins internals](/vault/docs/plugins) docs for more information about the plugin system before getting started building your Database plugin. Database plugins can be made to implement -[plugin multiplexing](/docs/plugins/plugin-architecture#plugin-multiplexing) +[plugin multiplexing](/vault/docs/plugins/plugin-architecture#plugin-multiplexing) which allows a single plugin process to be used for multiple database connections. To enable multiplexing, the plugin must be compiled with the `ServeMultiplex` function call from Vault's `dbplugin` package. @@ -207,7 +207,7 @@ plugin. We also recommend if you are planning on distributing your plugin to build with [gox](https://github.com/mitchellh/gox) for cross platform builds. To use your plugin with the database secrets engine you need to place the binary in the -plugin directory as specified in the [plugin internals](/docs/plugins) docs. +plugin directory as specified in the [plugin internals](/vault/docs/plugins) docs. You should now be able to register your plugin into the vault catalog. To do this your token will need sudo permissions. @@ -234,7 +234,7 @@ $ vault write database/config/mydatabase \ Scaling many external plugins can become resource intensive. To address performance problems with scaling external plugins, database plugins can be -made to implement [plugin multiplexing](/docs/plugins/plugin-architecture#plugin-multiplexing) +made to implement [plugin multiplexing](/vault/docs/plugins/plugin-architecture#plugin-multiplexing) which allows a single plugin process to be used for multiple database connections. To enable multiplexing, the plugin must be compiled with the `ServeMultiplex` function call from Vault's `dbplugin` package. @@ -247,7 +247,7 @@ multiplexed database plugin: Change the `Serve` function call to `ServeMultiplex This will run the RPC server for the plugin just as before. However, the `ServeMultiplex` function takes the factory function directly as its argument. This factory function is a function that returns an object that implements the -[`dbplugin.Database` interface](/docs/secrets/databases/custom#plugin-interface). +[`dbplugin.Database` interface](/vault/docs/secrets/databases/custom#plugin-interface). ### When should plugin multiplexing be avoided? @@ -267,7 +267,7 @@ that was not explicitly exposed. The new interface was introduced for several reasons: -1. [Password policies](/docs/concepts/password-policies) introduced in Vault 1.5 required +1. [Password policies](/vault/docs/concepts/password-policies) introduced in Vault 1.5 required that Vault be responsible for generating passwords. In the prior version, the database plugin was responsible for generating passwords. This prevented integration with password policies. diff --git a/website/content/docs/secrets/databases/db2.mdx b/website/content/docs/secrets/databases/db2.mdx index 1ada71a792..ff16dc2b0f 100644 --- a/website/content/docs/secrets/databases/db2.mdx +++ b/website/content/docs/secrets/databases/db2.mdx @@ -19,11 +19,11 @@ for Lightweight Directory Access Protocol (LDAP). This enables the Db2 database authenticate users and obtain group membership defined in an LDAP directory, removing the requirement that users and groups be defined to the operating system. -Vault's [LDAP secrets engine](/docs/secrets/ldap) can be used to manage the lifecycle +Vault's [LDAP secrets engine](/vault/docs/secrets/ldap) can be used to manage the lifecycle of credentials for Db2 environments that have been configured to delegate user authentication and group membership to an LDAP server. ## Tutorial -Refer to the [IBM Db2 Credential Management](https://learn.hashicorp.com/tutorials/vault/ibm-db2-openldap) +Refer to the [IBM Db2 Credential Management](/vault/tutorials/secrets-management/ibm-db2-openldap) tutorial to learn how to use Vault to manage both static and dynamic credentials for access to Db2. diff --git a/website/content/docs/secrets/databases/elasticdb.mdx b/website/content/docs/secrets/databases/elasticdb.mdx index 861e54f916..66c76e4831 100644 --- a/website/content/docs/secrets/databases/elasticdb.mdx +++ b/website/content/docs/secrets/databases/elasticdb.mdx @@ -18,7 +18,7 @@ Elasticsearch is one of the supported plugins for the database secrets engine. T plugin generates database credentials dynamically based on configured roles for Elasticsearch. -See the [database secrets engine](/docs/secrets/databases) docs for +See the [database secrets engine](/vault/docs/secrets/databases) docs for more information about setting up the database secrets engine. ## Capabilities @@ -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) page. +The full list of configurable options can be seen in the [Elasticsearch database plugin API](/vault/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. +[Database secrets engine API](/vault/api-docs/secret/databases) page. diff --git a/website/content/docs/secrets/databases/hanadb.mdx b/website/content/docs/secrets/databases/hanadb.mdx index c13d86816b..2361d08e99 100644 --- a/website/content/docs/secrets/databases/hanadb.mdx +++ b/website/content/docs/secrets/databases/hanadb.mdx @@ -13,7 +13,7 @@ HANA is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the HANA database. -See the [database secrets engine](/docs/secrets/databases) docs for +See the [database secrets engine](/vault/docs/secrets/databases) docs for more information about setting up the database secrets engine. ## Capabilities @@ -79,7 +79,7 @@ the proper permission, it can generate credentials. ## API -The full list of configurable options can be seen in the [HANA database plugin API](/api-docs/secret/databases/hanadb) page. +The full list of configurable options can be seen in the [HANA database plugin API](/vault/api-docs/secret/databases/hanadb) page. For more information on the database secrets engine's HTTP API please see the -[Database secrets engine API](/api-docs/secret/databases) page. +[Database secrets engine API](/vault/api-docs/secret/databases) page. diff --git a/website/content/docs/secrets/databases/index.mdx b/website/content/docs/secrets/databases/index.mdx index 5dd4eeac44..2c011c3928 100644 --- a/website/content/docs/secrets/databases/index.mdx +++ b/website/content/docs/secrets/databases/index.mdx @@ -15,7 +15,7 @@ configured roles. It works with a number of different databases through a plugin interface. There are a number of built-in database types, and an exposed framework for running custom database types for extendability. This means that services that need to access a database no longer need to hardcode credentials: they can -request them from Vault, and use Vault's [leasing mechanism](/docs/concepts/lease) +request them from Vault, and use Vault's [leasing mechanism](/vault/docs/concepts/lease) to more easily roll keys. These are referred to as "dynamic roles" or "dynamic secrets". @@ -136,41 +136,41 @@ and private key pair to authenticate. | Database | Root Credential Rotation | Dynamic Roles | Static Roles | Username Customization | Credential Types | | ---------------------------------------------------------------------- | ------------------------ | ------------- | ------------ | ---------------------- |---------------------------| -| [Cassandra](/docs/secrets/databases/cassandra) | Yes | Yes | Yes (1.6+) | Yes (1.7+) | password | -| [Couchbase](/docs/secrets/databases/couchbase) | Yes | Yes | Yes | Yes (1.7+) | password | -| [Elasticsearch](/docs/secrets/databases/elasticdb) | Yes | Yes | Yes (1.6+) | Yes (1.8+) | password | -| [HanaDB](/docs/secrets/databases/hanadb) | Yes (1.6+) | Yes | Yes (1.6+) | Yes (1.12+) | password | -| [InfluxDB](/docs/secrets/databases/influxdb) | Yes | Yes | Yes (1.6+) | Yes (1.8+) | password | -| [MongoDB](/docs/secrets/databases/mongodb) | Yes | Yes | Yes | Yes (1.7+) | password | -| [MongoDB Atlas](/docs/secrets/databases/mongodbatlas) | No | Yes | Yes | Yes (1.8+) | password | -| [MSSQL](/docs/secrets/databases/mssql) | Yes | Yes | Yes | Yes (1.7+) | password | -| [MySQL/MariaDB](/docs/secrets/databases/mysql-maria) | Yes | Yes | Yes | Yes (1.7+) | password | -| [Oracle](/docs/secrets/databases/oracle) | Yes | Yes | Yes | Yes (1.7+) | password | -| [PostgreSQL](/docs/secrets/databases/postgresql) | Yes | Yes | Yes | Yes (1.7+) | password | -| [Redis](/docs/secrets/databases/redis) | Yes | Yes | Yes | No | password | -| [Redis ElastiCache](/docs/secrets/databases/rediselasticache) | No | No | Yes | No | password | -| [Redshift](/docs/secrets/databases/redshift) | Yes | Yes | Yes | Yes (1.8+) | password | -| [Snowflake](/docs/secrets/databases/snowflake) | Yes | Yes | Yes | Yes (1.8+) | password, rsa_private_key | +| [Cassandra](/vault/docs/secrets/databases/cassandra) | Yes | Yes | Yes (1.6+) | Yes (1.7+) | password | +| [Couchbase](/vault/docs/secrets/databases/couchbase) | Yes | Yes | Yes | Yes (1.7+) | password | +| [Elasticsearch](/vault/docs/secrets/databases/elasticdb) | Yes | Yes | Yes (1.6+) | Yes (1.8+) | password | +| [HanaDB](/vault/docs/secrets/databases/hanadb) | Yes (1.6+) | Yes | Yes (1.6+) | Yes (1.12+) | password | +| [InfluxDB](/vault/docs/secrets/databases/influxdb) | Yes | Yes | Yes (1.6+) | Yes (1.8+) | password | +| [MongoDB](/vault/docs/secrets/databases/mongodb) | Yes | Yes | Yes | Yes (1.7+) | password | +| [MongoDB Atlas](/vault/docs/secrets/databases/mongodbatlas) | No | Yes | Yes | Yes (1.8+) | password | +| [MSSQL](/vault/docs/secrets/databases/mssql) | Yes | Yes | Yes | Yes (1.7+) | password | +| [MySQL/MariaDB](/vault/docs/secrets/databases/mysql-maria) | Yes | Yes | Yes | Yes (1.7+) | password | +| [Oracle](/vault/docs/secrets/databases/oracle) | Yes | Yes | Yes | Yes (1.7+) | password | +| [PostgreSQL](/vault/docs/secrets/databases/postgresql) | Yes | Yes | Yes | Yes (1.7+) | password | +| [Redis](/vault/docs/secrets/databases/redis) | Yes | Yes | Yes | No | password | +| [Redis ElastiCache](/vault/docs/secrets/databases/rediselasticache) | No | No | Yes | No | password | +| [Redshift](/vault/docs/secrets/databases/redshift) | Yes | Yes | Yes | Yes (1.8+) | password | +| [Snowflake](/vault/docs/secrets/databases/snowflake) | Yes | Yes | Yes | Yes (1.8+) | password, rsa_private_key | ## Custom Plugins This secrets engine allows custom database types to be run through the exposed -plugin interface. Please see the [custom database plugin](/docs/secrets/databases/custom) +plugin interface. Please see the [custom database plugin](/vault/docs/secrets/databases/custom) for more information. ## Credential Types Database systems support a variety of authentication methods and credential types. The database secrets engine supports management of credentials alternative to usernames -and passwords. The [credential_type](/api-docs/secret/databases#credential_type) -and [credential_config](/api-docs/secret/databases#credential_config) parameters +and passwords. The [credential_type](/vault/api-docs/secret/databases#credential_type) +and [credential_config](/vault/api-docs/secret/databases#credential_config) parameters of dynamic and static roles configure the credential that Vault will generate and make available to database plugins. See the documentation of individual database plugins for the credential types they support and usage examples. ## Password Generation -Passwords are generated via [Password Policies](/docs/concepts/password-policies). +Passwords are generated via [Password Policies](/vault/docs/concepts/password-policies). Databases can optionally set a password policy for use across all roles or at the individual role level for that database. For example, each time you call `vault write database/config/my-database` you can specify a password policy for all @@ -206,7 +206,7 @@ rule "charset" { As of Vault 1.10, you can now specify the option `disable_escaping` with a value of `true ` in some secrets engines to prevent Vault from escaping special characters in the username and password fields. This is necessary for some alternate connection string formats, such as ADO with MSSQL or Azure -SQL. See the [databases secrets engine API docs](/api-docs/secret/databases#common-fields) and reference +SQL. See the [databases secrets engine API docs](/vault/api-docs/secret/databases#common-fields) and reference individual plugin documentation to determine support for this parameter. For example, when the password contains URL-escaped characters like `#` or `%` they will @@ -224,11 +224,11 @@ 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/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) +- [Secrets as a Service: Dynamic Secrets](/vault/tutorials/db-credentials/database-secrets) +- [Database Root Credential Rotation](/vault/tutorials/db-credentials/database-root-rotation) +- [Database Static Roles and Credential Rotation](/vault/tutorials/db-credentials/database-creds-rotation) ## API The database secrets engine has a full HTTP API. Please see the [Database secret -secrets engine API](/api-docs/secret/databases) for more details. +secrets engine API](/vault/api-docs/secret/databases) for more details. diff --git a/website/content/docs/secrets/databases/influxdb.mdx b/website/content/docs/secrets/databases/influxdb.mdx index 7f1d1eb41d..d97e6692e9 100644 --- a/website/content/docs/secrets/databases/influxdb.mdx +++ b/website/content/docs/secrets/databases/influxdb.mdx @@ -15,7 +15,7 @@ InfluxDB is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the InfluxDB database. -See the [database secrets engine](/docs/secrets/databases) docs for +See the [database secrets engine](/vault/docs/secrets/databases) docs for more information about setting up the database secrets engine. ## Capabilities @@ -82,7 +82,7 @@ the proper permission, it can generate credentials. ## API The full list of configurable options can be seen in the [InfluxDB database -plugin API](/api-docs/secret/databases/influxdb) page. +plugin API](/vault/api-docs/secret/databases/influxdb) page. For more information on the database secrets engine's HTTP API please see the [Database secret -secrets engine API](/api-docs/secret/databases) page. +secrets engine API](/vault/api-docs/secret/databases) page. diff --git a/website/content/docs/secrets/databases/mongodb.mdx b/website/content/docs/secrets/databases/mongodb.mdx index 2e3b22ba0f..1ce48c92c7 100644 --- a/website/content/docs/secrets/databases/mongodb.mdx +++ b/website/content/docs/secrets/databases/mongodb.mdx @@ -14,9 +14,9 @@ description: |- MongoDB is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the MongoDB database and also supports -[Static Roles](/docs/secrets/databases#static-roles). +[Static Roles](/vault/docs/secrets/databases#static-roles). -See the [database secrets engine](/docs/secrets/databases) docs for +See the [database secrets engine](/vault/docs/secrets/databases) docs for more information about setting up the database secrets engine. ## Capabilities @@ -103,13 +103,13 @@ for more information. ## Tutorial Refer to [Database Secrets Engine with -MongoDB](https://learn.hashicorp.com/tutorials/vault/database-mongodb) for a +MongoDB](/vault/tutorials/db-credentials/database-mongodb) for a step-by-step tutorial. ## API The full list of configurable options can be seen in the [MongoDB database -plugin API](/api-docs/secret/databases/mongodb) page. +plugin API](/vault/api-docs/secret/databases/mongodb) page. For more information on the database secrets engine's HTTP API please see the -[Database secrets engine API](/api-docs/secret/databases) page. +[Database secrets engine API](/vault/api-docs/secret/databases) page. diff --git a/website/content/docs/secrets/databases/mongodbatlas.mdx b/website/content/docs/secrets/databases/mongodbatlas.mdx index 9ea78f5aab..99436e211d 100644 --- a/website/content/docs/secrets/databases/mongodbatlas.mdx +++ b/website/content/docs/secrets/databases/mongodbatlas.mdx @@ -14,7 +14,7 @@ plugin generates database credentials dynamically based on configured roles for MongoDB Atlas databases. It cannot support rotating the root user's credentials because it uses a public and private key pair to authenticate. -See the [database secrets engine](/docs/secrets/databases) docs for +See the [database secrets engine](/vault/docs/secrets/databases) docs for more information about setting up the database secrets engine. ## Capabilities @@ -78,7 +78,7 @@ the proper permissions, it can generate credentials. ## API The full list of configurable options can be seen in the [MongoDB Atlas Database -Plugin HTTP API](/api-docs/secret/databases/mongodbatlas) page. +Plugin HTTP API](/vault/api-docs/secret/databases/mongodbatlas) page. For more information on the database secrets engine's HTTP API please see the -[Database Secrets Engine API](/api-docs/secret/databases) page. +[Database Secrets Engine API](/vault/api-docs/secret/databases) page. diff --git a/website/content/docs/secrets/databases/mssql.mdx b/website/content/docs/secrets/databases/mssql.mdx index 7d72a643bc..91d61062e3 100644 --- a/website/content/docs/secrets/databases/mssql.mdx +++ b/website/content/docs/secrets/databases/mssql.mdx @@ -14,7 +14,7 @@ MSSQL is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the MSSQL database. -See the [database secrets engine](/docs/secrets/databases) docs for +See the [database secrets engine](/vault/docs/secrets/databases) docs for more information about setting up the database secrets engine. ## Capabilities @@ -165,7 +165,7 @@ vault write database/roles/my-role revocation_statements="\ ## API The full list of configurable options can be seen in the [MSSQL database -plugin API](/api-docs/secret/databases/mssql) page. +plugin API](/vault/api-docs/secret/databases/mssql) page. For more information on the database secrets engine's HTTP API please see the -[Database secrets engine API](/api-docs/secret/databases) page. +[Database secrets engine API](/vault/api-docs/secret/databases) page. diff --git a/website/content/docs/secrets/databases/mysql-maria.mdx b/website/content/docs/secrets/databases/mysql-maria.mdx index d867d3feb9..69723f246d 100644 --- a/website/content/docs/secrets/databases/mysql-maria.mdx +++ b/website/content/docs/secrets/databases/mysql-maria.mdx @@ -14,7 +14,7 @@ description: |- MySQL is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the MySQL database, and also supports [Static -Roles](/docs/secrets/databases#static-roles). +Roles](/vault/docs/secrets/databases#static-roles). This plugin has a few different instances built into vault, each instance is for a slightly different MySQL driver. The only difference between these plugins is @@ -26,7 +26,7 @@ accept different lengths. The available plugins are: - mysql-rds-database-plugin - mysql-legacy-database-plugin -See the [database secrets engine](/docs/secrets/databases) docs for +See the [database secrets engine](/vault/docs/secrets/databases) docs for more information about setting up the database secrets engine. ## Capabilities @@ -143,7 +143,7 @@ $ vault write database/roles/my-role \ The default root rotation setup for MySQL uses the `ALTER USER` syntax present in MySQL 5.7 and up. For MySQL 5.6, the [root rotation -statements](/api-docs/secret/databases#root_rotation_statements) +statements](/vault/api-docs/secret/databases#root_rotation_statements) must be configured to use the old `SET PASSWORD` syntax. For example: ```shell-session @@ -162,7 +162,7 @@ Rotation](https://learn.hashicorp.com/vault/secrets-management/db-root-rotation) ## API The full list of configurable options can be seen in the [MySQL database plugin -API](/api-docs/secret/databases/mysql-maria) page. +API](/vault/api-docs/secret/databases/mysql-maria) page. For more information on the database secrets engine's HTTP API please see the -[Database secrets engine API](/api-docs/secret/databases) page. +[Database secrets engine API](/vault/api-docs/secret/databases) page. diff --git a/website/content/docs/secrets/databases/oracle.mdx b/website/content/docs/secrets/databases/oracle.mdx index 7fe30d1938..1baf3f58f3 100644 --- a/website/content/docs/secrets/databases/oracle.mdx +++ b/website/content/docs/secrets/databases/oracle.mdx @@ -10,11 +10,11 @@ description: |- # Oracle Database Secrets Engine This secrets engine is a part of the Database Secrets Engine. If you have not read the -[Database Backend](/docs/secrets/databases) page, please do so now as it explains how to set up the database backend and +[Database Backend](/vault/docs/secrets/databases) page, please do so now as it explains how to set up the database backend and gives an overview of how the engine functions. Oracle is one of the supported plugins for the database secrets engine. It is capable of dynamically generating -credentials based on configured roles for Oracle databases. It also supports [Static Roles](/docs/secrets/databases#static-roles). +credentials based on configured roles for Oracle databases. It also supports [Static Roles](/vault/docs/secrets/databases#static-roles). ~> The Oracle database plugin is not bundled in the core Vault code tree and can be found at its own git repository here: @@ -26,7 +26,7 @@ found at its own git repository here: | Plugin Name | Root Credential Rotation | Dynamic Roles | Static Roles | Username Customization | | -------------------------------------------------------------------- | ------------------------ | ------------- | ------------ | ---------------------- | -| Customizable (see: [Custom Plugins](/docs/secrets/databases/custom)) | Yes | Yes | Yes | Yes (1.7+) | +| Customizable (see: [Custom Plugins](/vault/docs/secrets/databases/custom)) | Yes | Yes | Yes | Yes (1.7+) | ## Setup @@ -39,7 +39,7 @@ Before running the plugin you will need to have the Oracle Instant Client library installed. These can be downloaded from Oracle. The libraries will need to be placed in the default library search path or defined in the ld.so.conf configuration files. -If you are running Vault with [mlock enabled](/docs/configuration#disable_mlock), +If you are running Vault with [mlock enabled](/vault/docs/configuration#disable_mlock), you will need to enable ipc_lock capabilities for the plugin binary. 1. Enable the database secrets engine if it is not already enabled: @@ -71,13 +71,13 @@ you will need to enable ipc_lock capabilities for the plugin binary. password="myreallysecurepassword" ``` -If Oracle uses SSL, see the [connecting using SSL](/docs/secrets/databases/oracle#connect-using-ssl) example. +If Oracle uses SSL, see the [connecting using SSL](/vault/docs/secrets/databases/oracle#connect-using-ssl) example. If the version of Oracle you are using has a container database, you will need to connect to one of the pluggable databases rather than the container database in the `connection_url` field. 1. It is highly recommended that you immediately rotate the "root" user's password, see - [Rotate Root Credentials](/api-docs/secret/databases#rotate-root-credentials) for more details. + [Rotate Root Credentials](/vault/api-docs/secret/databases#rotate-root-credentials) for more details. This will ensure that only Vault is able to access the "root" user that Vault uses to manipulate dynamic & static credentials. @@ -104,7 +104,7 @@ pluggable databases rather than the container database in the `connection_url` f ... ``` - See the [Commands](/docs/commands#files) docs for more details. + See the [Commands](/vault/docs/commands#files) docs for more details. ### Connect Using SSL @@ -234,7 +234,7 @@ the proper permission, it can generate credentials. ## API The full list of configurable options can be seen in the [Oracle database plugin -API](/api-docs/secret/databases/oracle) page. +API](/vault/api-docs/secret/databases/oracle) page. For more information on the database secrets engine's HTTP API please see the -[Database secrets engine API](/api-docs/secret/databases) page. +[Database secrets engine API](/vault/api-docs/secret/databases) page. diff --git a/website/content/docs/secrets/databases/postgresql.mdx b/website/content/docs/secrets/databases/postgresql.mdx index 48861a2b69..8704ce188f 100644 --- a/website/content/docs/secrets/databases/postgresql.mdx +++ b/website/content/docs/secrets/databases/postgresql.mdx @@ -12,13 +12,13 @@ description: |- PostgreSQL is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the PostgreSQL database, and also supports [Static -Roles](/docs/secrets/databases#static-roles). +Roles](/vault/docs/secrets/databases#static-roles). -See the [database secrets engine](/docs/secrets/databases) docs for +See the [database secrets engine](/vault/docs/secrets/databases) docs for more information about setting up the database secrets engine. The PostgreSQL secrets engine uses [pgx][pgxlib], the same database library as the -[PostgreSQL storage backend](/docs/configuration/storage/postgresql). Connection string +[PostgreSQL storage backend](/vault/docs/configuration/storage/postgresql). Connection string options, including SSL options, can be found in the [pgx][pgxlib] and [PostgreSQL connection string][pg_conn_docs] documentation. @@ -86,10 +86,10 @@ the proper permission, it can generate credentials. ## API The full list of configurable options can be seen in the [PostgreSQL database -plugin API](/api-docs/secret/databases/postgresql) page. +plugin API](/vault/api-docs/secret/databases/postgresql) page. For more information on the database secrets engine's HTTP API please see the -[Database secrets engine API](/api-docs/secret/databases) page. +[Database secrets engine API](/vault/api-docs/secret/databases) page. [pgxlib]: https://pkg.go.dev/github.com/jackc/pgx/stdlib [pg_conn_docs]: https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING diff --git a/website/content/docs/secrets/databases/redis.mdx b/website/content/docs/secrets/databases/redis.mdx index ebf358c5fe..9d861cda15 100644 --- a/website/content/docs/secrets/databases/redis.mdx +++ b/website/content/docs/secrets/databases/redis.mdx @@ -4,7 +4,7 @@ page_title: Redis - Database - Secrets Engines description: |- Redis is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured - roles for the Redis database, and also supports [Static Roles](https://developer.hashicorp.com/vault/docs/secrets/databases#static-roles). + roles for the Redis database, and also supports [Static Roles](/vault/docs/secrets/databases#static-roles). --- # Redis Database Secrets Engine @@ -13,7 +13,7 @@ Redis is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the Redis database. -See the [database secrets engine](/docs/secrets/databases) docs for +See the [database secrets engine](/vault/docs/secrets/databases) docs for more information about setting up the database secrets engine. ## Capabilities @@ -121,6 +121,6 @@ to Vault to enable generating credentials. ## API -The full list of configurable options can be seen in the [Redis Database Plugin API](/api-docs/secret/databases/redis) page. +The full list of configurable options can be seen in the [Redis Database Plugin API](/vault/api-docs/secret/databases/redis) page. -For more information on the database secrets engine's HTTP API please see the [Database Secrets Engine API](/api-docs/secret/databases) page. +For more information on the database secrets engine's HTTP API please see the [Database Secrets Engine API](/vault/api-docs/secret/databases) page. diff --git a/website/content/docs/secrets/databases/rediselasticache.mdx b/website/content/docs/secrets/databases/rediselasticache.mdx index a6f160f457..e35aa23c00 100644 --- a/website/content/docs/secrets/databases/rediselasticache.mdx +++ b/website/content/docs/secrets/databases/rediselasticache.mdx @@ -11,7 +11,7 @@ description: |- Redis ElastiCache is one of the supported plugins for the database secrets engine. This plugin generates static credentials for existing managed roles. -See the [database secrets engine](/docs/secrets/databases) docs for +See the [database secrets engine](/vault/docs/secrets/databases) docs for more information about setting up the database secrets engine. ## Capabilities @@ -106,6 +106,6 @@ After the secrets engine is configured, write static roles to enable generating ## API -The full list of configurable options can be seen in the [Redis ElastiCache Database Plugin API](/api-docs/secret/databases/rediselasticache) page. +The full list of configurable options can be seen in the [Redis ElastiCache Database Plugin API](/vault/api-docs/secret/databases/rediselasticache) page. -For more information on the database secrets engine's HTTP API please see the [Database Secrets Engine API](/api-docs/secret/databases) page. +For more information on the database secrets engine's HTTP API please see the [Database Secrets Engine API](/vault/api-docs/secret/databases) page. diff --git a/website/content/docs/secrets/databases/redshift.mdx b/website/content/docs/secrets/databases/redshift.mdx index c764908e6a..3676925b62 100644 --- a/website/content/docs/secrets/databases/redshift.mdx +++ b/website/content/docs/secrets/databases/redshift.mdx @@ -12,9 +12,9 @@ description: |- Redshift is a supported plugin for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for the AWS Redshift database service, and also supports [Static -Roles](/docs/secrets/databases#static-roles). +Roles](/vault/docs/secrets/databases#static-roles). -See the [database secrets engine](/docs/secrets/databases) docs for +See the [database secrets engine](/vault/docs/secrets/databases) docs for more information about setting up the database secrets engine. ## Capabilities @@ -81,7 +81,7 @@ the proper permission, it can generate credentials. ## API The full list of configurable options can be seen in the [Redshift database -plugin API](/api-docs/secret/databases/redshift) page. +plugin API](/vault/api-docs/secret/databases/redshift) page. For more information on the database secrets engine's HTTP API please see the -[Database secrets engine API](/api-docs/secret/databases) page. +[Database secrets engine API](/vault/api-docs/secret/databases) page. diff --git a/website/content/docs/secrets/databases/snowflake.mdx b/website/content/docs/secrets/databases/snowflake.mdx index c9e500f584..93f1bc7c9f 100644 --- a/website/content/docs/secrets/databases/snowflake.mdx +++ b/website/content/docs/secrets/databases/snowflake.mdx @@ -11,9 +11,9 @@ description: |- Snowflake is one of the supported plugins for the database secrets engine. This plugin generates database credentials dynamically based on configured roles for Snowflake-hosted -databases and supports [Static Roles](/docs/secrets/databases#static-roles). +databases and supports [Static Roles](/vault/docs/secrets/databases#static-roles). -See the [database secrets engine](/docs/secrets/databases) docs for +See the [database secrets engine](/vault/docs/secrets/databases) docs for more information about setting up the database secrets engine. The Snowflake database secrets engine uses @@ -211,15 +211,15 @@ enable generating credentials. Snowflake supports using [key pair authentication](https://docs.snowflake.com/en/user-guide/key-pair-auth.html) for enhanced authentication security as an alternative to username and password authentication. The Snowflake database plugin can be used to manage key pair credentials for Snowflake users -by using the `rsa_private_key` [credential_type](/api-docs/secret/databases#credential_type). +by using the `rsa_private_key` [credential_type](/vault/api-docs/secret/databases#credential_type). -See the [usage](/docs/secrets/databases/snowflake#usage) section for examples using both +See the [usage](/vault/docs/secrets/databases/snowflake#usage) section for examples using both dynamic and static roles. ## API The full list of configurable options can be seen in the [Snowflake database -plugin API](/api-docs/secret/databases/snowflake) page. +plugin API](/vault/api-docs/secret/databases/snowflake) page. For more information on the database secrets engine's HTTP API please see the -[Database secrets engine API](/api-docs/secret/databases) page. +[Database secrets engine API](/vault/api-docs/secret/databases) page. diff --git a/website/content/docs/secrets/gcp.mdx b/website/content/docs/secrets/gcp.mdx index 7405edc45c..9d9940c0d5 100644 --- a/website/content/docs/secrets/gcp.mdx +++ b/website/content/docs/secrets/gcp.mdx @@ -101,7 +101,7 @@ path "/gcp/roleset/+" { ``` For more more information on policy syntax, see the -[policy documentation](/docs/concepts/policies#policy-syntax). +[policy documentation](/vault/docs/concepts/policies#policy-syntax). ### Examples @@ -213,7 +213,7 @@ For more information on creating and managing static accounts, see the ## Impersonated Accounts -Impersonated accounts are a way to generate an OAuth2 [access token](/docs/secrets/gcp#access-tokens) that is granted +Impersonated accounts are a way to generate an OAuth2 [access token](/vault/docs/secrets/gcp#access-tokens) that is granted the permissions and accesses of another given service account. These access tokens do not have the same 10-key limit as service account keys do, yet they retain their short-lived nature. By default, their TTL in GCP is 1 hour, but @@ -244,9 +244,9 @@ was configured, you can generate OAuth2 tokens or service account keys. ### Access Tokens To generate OAuth2 [access tokens](https://cloud.google.com/docs/authentication/token-types#access), -read from the [`gcp/.../token`](/api-docs/secret/gcp#generate-secret-iam-service-account-creds-oauth2-access-token) +read from the [`gcp/.../token`](/vault/api-docs/secret/gcp#generate-secret-iam-service-account-creds-oauth2-access-token) API. If using a roleset or static account, it must have been created with a -[`secret_type`](/api-docs/secret/gcp#secret_type) of `access_token`. Impersonated accounts will +[`secret_type`](/vault/api-docs/secret/gcp#secret_type) of `access_token`. Impersonated accounts will generate OAuth2 tokens by default. **Roleset:** @@ -547,7 +547,7 @@ You can either: If the mount is configured with credentials directly, the credential's key may be rotated to a Vault-generated value that is not accessible by the operator. For more details on this operation, please see the -[Root Credential Rotation](/api-docs/secret/gcp#rotate-root-credentials) API docs. +[Root Credential Rotation](/vault/api-docs/secret/gcp#rotate-root-credentials) API docs. ## Things to Note @@ -677,7 +677,7 @@ Please report issues, add feature requests, and submit contributions to the The GCP secrets engine has a full HTTP API. Please see the [GCP secrets engine API docs][api] for more details. -[api]: /api-docs/secret/gcp +[api]: /vault/api-docs/secret/gcp [cloud-creds]: https://cloud.google.com/docs/authentication/production#providing_credentials_to_your_application [custom-roles]: https://cloud.google.com/iam/docs/creating-custom-roles [gce]: https://cloud.google.com/compute/ diff --git a/website/content/docs/secrets/gcpkms.mdx b/website/content/docs/secrets/gcpkms.mdx index b5de0e473f..8c3c28bc43 100644 --- a/website/content/docs/secrets/gcpkms.mdx +++ b/website/content/docs/secrets/gcpkms.mdx @@ -435,7 +435,7 @@ Please report issues, add feature requests, and submit contributions to the The Google Cloud KMS secrets engine has a full HTTP API. Please see the [Google Cloud KMS secrets engine API docs][api] for more details. -[api]: /api-docs/secret/gcpkms +[api]: /vault/api-docs/secret/gcpkms [cloud-creds]: https://cloud.google.com/docs/authentication/production#providing_credentials_to_your_application [gce]: https://cloud.google.com/compute/ [gke]: https://cloud.google.com/kubernetes-engine/ @@ -444,4 +444,4 @@ The Google Cloud KMS secrets engine has a full HTTP API. Please see the [kms-pricing]: https://cloud.google.com/kms/pricing [repo]: https://github.com/hashicorp/vault-plugin-secrets-gcpkms [service-accounts]: https://cloud.google.com/compute/docs/access/service-accounts -[vault-transit]: /docs/secrets/transit +[vault-transit]: /vault/docs/secrets/transit diff --git a/website/content/docs/secrets/identity/identity-token.mdx b/website/content/docs/secrets/identity/identity-token.mdx index ecb8c7e04a..745f0822d8 100644 --- a/website/content/docs/secrets/identity/identity-token.mdx +++ b/website/content/docs/secrets/identity/identity-token.mdx @@ -64,7 +64,7 @@ Identity tokens will always contain, at a minimum, the claims required by OIDC: In addition, the operator may configure per-role templates that allow a variety of other entity information to be added to the token. The templates are structured as JSON with replaceable parameters. The parameter syntax is the same -as that used for [ACL Path Templating](/docs/concepts/policies). +as that used for [ACL Path Templating](/vault/docs/concepts/policies). For example: @@ -137,13 +137,13 @@ The full list of template parameters is shown below: | `identity.entity.aliases..custom_metadata` | Custom metadata associated with the alias for the given mount | | `identity.entity.aliases..custom_metadata.` | Custom metadata associated with the alias for the given mount and custom metadata key | | `time.now` | Current time as integral seconds since the Epoch | -| `time.now.plus.` | Current time plus a [duration format string](/docs/concepts/duration-format) | -| `time.now.minus.` | Current time minus a [duration format string](/docs/concepts/duration-format) | +| `time.now.plus.` | Current time plus a [duration format string](/vault/docs/concepts/duration-format) | +| `time.now.minus.` | Current time minus a [duration format string](/vault/docs/concepts/duration-format) | ### Token Generation An authenticated client may request a token using the [token generation -endpoint](/api-docs/secret/identity/tokens#generate-a-signed-id-token). The token +endpoint](/vault/api-docs/secret/identity/tokens#generate-a-signed-id-token). The token will be generated per the requested role's specifications, for the requester's entity. It is not possible to generate tokens for an arbitrary entity. @@ -161,7 +161,7 @@ only requiring _access_ to Vault, not _authorization_, as the .well-known endpoints are unauthenticated. Alternatively, the token may be sent to Vault for verification via an -[introspection endpoint](/api-docs/secret/identity/tokens#introspect-a-signed-id-token). +[introspection endpoint](/vault/api-docs/secret/identity/tokens#introspect-a-signed-id-token). The response will indicate whether the token is "active" or not, as well as any errors that occurred during validation. Beyond simply allowing the client to delegate verification to Vault, using this endpoint incorporates the additional @@ -175,15 +175,15 @@ authorization. The identity token system has one configurable parameter: issuer. The issuer `iss` claim is particularly important for proper validation of the token by clients, and special consideration should be given when using Identity Tokens -with [performance replication](/docs/enterprise/replication). +with [performance replication](/vault/docs/enterprise/replication). Consumers of the token will request public keys from Vault using the issuer URL, so it must be network reachable. Furthermore, the returned set of keys will include an issuer that must match the request. By default Vault will set the issuer to the Vault instance's -[`api_addr`](/docs/configuration#api_addr). This means that tokens +[`api_addr`](/vault/docs/configuration#api_addr). This means that tokens issued in a given cluster should be validated within that same cluster. -Alternatively, the [`issuer`](/api-docs/secret/identity/tokens#issuer) parameter +Alternatively, the [`issuer`](/vault/api-docs/secret/identity/tokens#issuer) parameter may be configured explicitly. This address must point to the identity/oidc path for the Vault instance (e.g. `https://vault-1.example.com:8200/v1/identity/oidc`) and should be @@ -192,5 +192,5 @@ reachable by any client trying to validate identity tokens. ## API The Identity secrets engine has a full HTTP API. Please see the -[Identity secrets engine API](/api-docs/secret/identity) for more +[Identity secrets engine API](/vault/api-docs/secret/identity) for more details. diff --git a/website/content/docs/secrets/identity/index.mdx b/website/content/docs/secrets/identity/index.mdx index 3170a8a0cc..3998135fa4 100644 --- a/website/content/docs/secrets/identity/index.mdx +++ b/website/content/docs/secrets/identity/index.mdx @@ -31,20 +31,20 @@ controlling the access of tokens that are already issued. ~> **NOTE:** This secrets engine will be mounted by default. This secrets engine cannot be disabled or moved. For more conceptual overview on identity, refer to -the [Identity](/docs/concepts/identity) documentation. +the [Identity](/vault/docs/concepts/identity) documentation. The Vault Identity secrets engine supports several different features. Each one is individually documented on its own page. -- [Identity tokens](/docs/secrets/identity/identity-token) -- [OIDC Identity Provider](/docs/secrets/identity/oidc-provider) +- [Identity tokens](/vault/docs/secrets/identity/identity-token) +- [OIDC Identity Provider](/vault/docs/secrets/identity/oidc-provider) ## API The Identity secrets engine has a full HTTP API. Please see the -[Identity secrets engine API](/api-docs/secret/identity) for more +[Identity secrets engine API](/vault/api-docs/secret/identity) for more details. Additionally, Vault can be configured as an OIDC identity provider. Please see -the [OIDC identity provider API](/api-docs/secret/identity/oidc-provider) for +the [OIDC identity provider API](/vault/api-docs/secret/identity/oidc-provider) for more details. diff --git a/website/content/docs/secrets/identity/oidc-provider.mdx b/website/content/docs/secrets/identity/oidc-provider.mdx index cef2ebf0db..a150df532d 100644 --- a/website/content/docs/secrets/identity/oidc-provider.mdx +++ b/website/content/docs/secrets/identity/oidc-provider.mdx @@ -9,24 +9,24 @@ description: >- Vault is an OpenID Connect ([OIDC](https://openid.net/specs/openid-connect-core-1_0.html)) identity provider. This enables client applications that speak the OIDC protocol to leverage -Vault's source of [identity](/docs/concepts/identity) and wide range of [authentication methods](/docs/auth) +Vault's source of [identity](/vault/docs/concepts/identity) and wide range of [authentication methods](/vault/docs/auth) when authenticating end-users. Client applications can configure their authentication logic to talk to Vault. Once enabled, Vault will act as the bridge to other identity providers via 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, -please visit the [OIDC provider](/docs/concepts/oidc-provider) concepts page. +please visit the [OIDC provider](/vault/docs/concepts/oidc-provider) concepts page. ## Setup The Vault OIDC provider system is built on top of the identity secrets engine. This secrets engine is mounted by default and cannot be disabled or moved. -Each Vault namespace has a default OIDC [provider](/docs/concepts/oidc-provider#providers) -and [key](/docs/concepts/oidc-provider#key). This built-in configuration enables client +Each Vault namespace has a default OIDC [provider](/vault/docs/concepts/oidc-provider#providers) +and [key](/vault/docs/concepts/oidc-provider#key). This built-in configuration enables client applications to begin using Vault as a source of identity with minimal configuration. For -details on the built-in configuration and advanced options, see the [OIDC provider](/docs/concepts/oidc-provider) +details on the built-in configuration and advanced options, see the [OIDC provider](/vault/docs/concepts/oidc-provider) concepts page. The following steps show a minimal configuration that allows a client application to use @@ -62,12 +62,12 @@ Any Vault auth method may be used within the OIDC flow. For simplicity, enable t ``` This operation creates a client application which can be used to configure an OIDC - relying party. See the [client applications](/docs/concepts/oidc-provider#client-applications) + relying party. See the [client applications](/vault/docs/concepts/oidc-provider#client-applications) section for details on different client types, including `confidential` and `public` clients. The `assignments` parameter limits the Vault entities and groups that are allowed to authenticate through the client application. By default, no Vault entities are allowed. - To allow all Vault entities to authenticate, the built-in [allow_all](/docs/concepts/oidc-provider#assignments) + To allow all Vault entities to authenticate, the built-in [allow_all](/vault/docs/concepts/oidc-provider#assignments) assignment is provided. 2. Read client credentials: @@ -147,9 +147,9 @@ A number of HashiCorp products provide OIDC authentication methods. This means t can leverage Vault as a source of identity using the OIDC protocol. See the following links for details on configuring OIDC authentication for other HashiCorp products: -- [Boundary](https://learn.hashicorp.com/tutorials/boundary/oidc-auth) -- [Consul](https://developer.hashicorp.com/consul/docs/security/acl/auth-methods/oidc) -- [Waypoint](https://developer.hashicorp.com/waypoint/docs/server/auth/oidc) +- [Boundary](/boundary/tutorials/access-management/oidc-auth) +- [Consul](/consul/docs/security/acl/auth-methods/oidc) +- [Waypoint](/waypoint/docs/server/auth/oidc) Otherwise, refer to the documentation of the specific OIDC relying party for usage details. @@ -161,12 +161,12 @@ The Vault OIDC provider feature currently supports the following authentication ## Tutorial -Refer to the [Vault as an OIDC Identity Provider](https://learn.hashicorp.com/tutorials/vault/oidc-identity-provider) +Refer to the [Vault as an OIDC Identity Provider](/vault/tutorials/auth-methods/oidc-identity-provider) tutorial to learn how to configure a HashiCorp [Boundary](https://www.boundaryproject.io/) to leverage Vault as a source of identity using the OIDC protocol. ## API The Vault OIDC provider feature has a full HTTP API. Please see the -[OIDC identity provider API](/api-docs/secret/identity/oidc-provider) for more +[OIDC identity provider API](/vault/api-docs/secret/identity/oidc-provider) for more details. diff --git a/website/content/docs/secrets/index.mdx b/website/content/docs/secrets/index.mdx index f4ce69497e..7e23aee24f 100644 --- a/website/content/docs/secrets/index.mdx +++ b/website/content/docs/secrets/index.mdx @@ -27,7 +27,7 @@ supporting operations like read, write, and delete. Most secrets engines can be enabled, disabled, tuned, and moved via the CLI or API. -- [Enable](/docs/commands/secrets/enable) - This enables a secrets engine at +- [Enable](/vault/docs/commands/secrets/enable) - This enables a secrets engine at a given path. With a few exceptions, secrets engines can be enabled at multiple paths. Each secrets engine is isolated to its path. By default, they are enabled at their "type" (e.g. "aws" enables at `aws/`). @@ -36,17 +36,17 @@ API. example, the KV secrets engine enabled at `kv/` and `KV/` are treated as two distinct instances of KV secrets engine. -- [Disable](/docs/commands/secrets/disable) - This disables an existing +- [Disable](/vault/docs/commands/secrets/disable) - This disables an existing secrets engine. When a secrets engine is disabled, all of its secrets are revoked (if they support it), and all the data stored for that engine in the physical storage layer is deleted. -- [Move](/docs/commands/secrets/move) - This moves the path for an existing +- [Move](/vault/docs/commands/secrets/move) - This moves the path for an existing secrets engine. This process revokes all secrets, since secret leases are tied to the path where they were created. The configuration data stored for the engine persists through the move. -- [Tune](/docs/commands/secrets/tune) - This tunes global configuration for +- [Tune](/vault/docs/commands/secrets/tune) - This tunes global configuration for the secrets engine such as the TTLs. Once a secrets engine is enabled, you can interact with it directly at its path diff --git a/website/content/docs/secrets/key-management/awskms.mdx b/website/content/docs/secrets/key-management/awskms.mdx index f8b1ae54f2..a841ee3eaf 100644 --- a/website/content/docs/secrets/key-management/awskms.mdx +++ b/website/content/docs/secrets/key-management/awskms.mdx @@ -20,11 +20,11 @@ the functionality. The Key Management secrets engine must be configured with credentials that have sufficient permissions to manage keys in an AWS KMS region. The authentication parameters are described -in the [credentials](/api-docs/secret/key-management/awskms#credentials) section of the API +in the [credentials](/vault/api-docs/secret/key-management/awskms#credentials) section of the API documentation. The authentication parameters will be set with the following order of precedence: -1. [KMS provider credentials](/api-docs/secret/key-management/awskms#credentials) +1. [KMS provider credentials](/vault/api-docs/secret/key-management/awskms#credentials) 2. Environment variables 3. Shared credentials file 4. IAM role for AWS EC2 or ECS task @@ -56,7 +56,7 @@ $ vault write keymgmt/kms/example-kms \ credentials=secret_key="bCiYmNroLxLmPNQ47VIvjlm8mQu5oktZcQdq195w" ``` -Refer to the AWS KMS [API documentation](/api-docs/secret/key-management/awskms) +Refer to the AWS KMS [API documentation](/vault/api-docs/secret/key-management/awskms) for a detailed description of individual configuration parameters. ## Key Transfer Specification @@ -76,7 +76,7 @@ associated with imported keys. Aliases will always have the form: `hashicorp/.vault.azure.net ``` The secrets engine doesn't require special configuration to communicate with a Key Vault instance -over an Azure Private Endpoint. For example, the given [KMS configuration](/docs/secrets/key-management/azurekeyvault#configuration) +over an Azure Private Endpoint. For example, the given [KMS configuration](/vault/docs/secrets/key-management/azurekeyvault#configuration) will result in the secrets engine resolving a Key Vault domain name of `keyvault-name.vault.azure.net` to the Private Endpoint IP address. Note that it's possible to change the Key Vault DNS suffix using the -[environment](/api-docs/secret/key-management/azurekeyvault#environment) +[environment](/vault/api-docs/secret/key-management/azurekeyvault#environment) configuration parameter or `AZURE_ENVIRONMENT` environment variable. diff --git a/website/content/docs/secrets/key-management/gcpkms.mdx b/website/content/docs/secrets/key-management/gcpkms.mdx index 61c40587a0..bd0f4072b3 100644 --- a/website/content/docs/secrets/key-management/gcpkms.mdx +++ b/website/content/docs/secrets/key-management/gcpkms.mdx @@ -18,12 +18,12 @@ the functionality. The Key Management secrets engine must be configured with credentials that have sufficient permissions to manage keys in an existing GCP Cloud KMS [key ring](https://cloud.google.com/kms/docs/resource-hierarchy#key_rings). -The authentication parameters are described in the [credentials](/api-docs/secret/key-management/gcpkms#credentials) +The authentication parameters are described in the [credentials](/vault/api-docs/secret/key-management/gcpkms#credentials) section of the API documentation. The authentication parameters will be set with the following order of precedence: 1. `GOOGLE_CREDENTIALS` environment variable -2. [KMS provider credentials](/api-docs/secret/key-management/gcpkms#credentials) parameter +2. [KMS provider credentials](/vault/api-docs/secret/key-management/gcpkms#credentials) parameter 3. [Application default credentials](https://cloud.google.com/docs/authentication/production) The service account must be authorized with the following minimum @@ -50,7 +50,7 @@ $ vault write keymgmt/kms/example-kms \ credentials=service_account_file="/path/to/service_account/credentials.json" ``` -Refer to the GCP Cloud KMS [API documentation](/api-docs/secret/key-management/gcpkms) +Refer to the GCP Cloud KMS [API documentation](/vault/api-docs/secret/key-management/gcpkms) for a detailed description of individual configuration parameters. ## Key Transfer Specification @@ -60,7 +60,7 @@ with the [key import](https://cloud.google.com/kms/docs/key-import) specificatio ## Key Purpose Compatability -The following table defines which key [purposes](/api-docs/secret/key-management#purpose) can be used +The following table defines which key [purposes](/vault/api-docs/secret/key-management#purpose) can be used for each key type supported by GCP Cloud KMS. | Key Type | Purpose | diff --git a/website/content/docs/secrets/key-management/index.mdx b/website/content/docs/secrets/key-management/index.mdx index f0961c57be..866aed868a 100644 --- a/website/content/docs/secrets/key-management/index.mdx +++ b/website/content/docs/secrets/key-management/index.mdx @@ -89,12 +89,12 @@ manage the lifecycle of cryptographic keys in [supported KMS providers](#kms-pro `purpose` and `protection`. The `purpose` defines the set of cryptographic capabilities that the key will have in the KMS provider. The `protection` defines where cryptographic operations are performed with the key in the KMS provider. See the API documentation for a list of - supported [purpose](/api-docs/secret/key-management#purpose) and [protection](/api-docs/secret/key-management#protection) + supported [purpose](/vault/api-docs/secret/key-management#purpose) and [protection](/vault/api-docs/secret/key-management#protection) values. ~> **Note:** The amount of time it takes to distribute a key to a KMS provider is proportional to the number of versions that the key has. If a timeout occurs when distributing a key to a KMS - provider, you may need to increase the [VAULT_CLIENT_TIMEOUT](https://www.vaultproject.io/docs/commands#vault_client_timeout). + provider, you may need to increase the [VAULT_CLIENT_TIMEOUT](/vault/docs/commands#vault_client_timeout). 1. Rotate a key: @@ -126,7 +126,7 @@ manage the lifecycle of cryptographic keys in [supported KMS providers](#kms-pro This operation results in the key being deleted from the KMS provider. The key will still exist in the secrets engine and can be redistributed to a KMS provider at a later time. - To permanently delete the key from the secrets engine, the [delete key](/api-docs/secret/key-management#delete-key) + To permanently delete the key from the secrets engine, the [delete key](/vault/api-docs/secret/key-management#delete-key) API may be invoked. ## Key Types @@ -146,9 +146,9 @@ The Key Management secrets engine supports generation of the following key types The Key Management secrets engine supports lifecycle management of keys in the following KMS providers: -- [Azure Key Vault](/docs/secrets/key-management/azurekeyvault) -- [AWS KMS](/docs/secrets/key-management/awskms) -- [GCP Cloud KMS](/docs/secrets/key-management/gcpkms) +- [Azure Key Vault](/vault/docs/secrets/key-management/azurekeyvault) +- [AWS KMS](/vault/docs/secrets/key-management/awskms) +- [GCP Cloud KMS](/vault/docs/secrets/key-management/gcpkms) Refer to the provider-specific documentation for details on how to properly configure each provider. @@ -168,10 +168,10 @@ The following table defines which key types are compatible with each KMS provide ## Tutorial -Refer to the [Key Management Secrets Engine](https://learn.hashicorp.com/collections/vault/key-management) tutorial series to learn how to use the key management secrets engine for Azure and GCP. +Refer to the [Key Management Secrets Engine](/vault/tutorials/key-management) tutorial series to learn how to use the key management secrets engine for Azure and GCP. ## API The Key Management secrets engine has a full HTTP API. Please see the -[Key Management Secrets Engine API](/api-docs/secret/key-management) for more +[Key Management Secrets Engine API](/vault/api-docs/secret/key-management) for more details. diff --git a/website/content/docs/secrets/kmip.mdx b/website/content/docs/secrets/kmip.mdx index 12de95a2f2..a9ab4017e8 100644 --- a/website/content/docs/secrets/kmip.mdx +++ b/website/content/docs/secrets/kmip.mdx @@ -48,7 +48,7 @@ Vault implements version 1.4 of the following Key Management Interoperability Pr * The supported hashing algorithms for Sign and Signature Verify operations are *SHA224*, *SHA256*, *SHA384*, *SHA512*, *RIPEMD160*, *SHA512_224*, *SHA512_256*, *SHA3_224*, *SHA3_256*, *SHA3_384*, and *SHA3_512* for *PSS* padding method, and algorithms *SHA224*, *SHA256*, *SHA384*, *SHA512*, and *RIPEMD160* for *PKCS1v15* padding method. * The supported hashing algorithms for MAC and MAC Verify operations are *SHA224*, *SHA256*, *SHA384*, *SHA512*, *RIPEMD160*, *SHA512_224*, *SHA512_256*, *SHA3_224*, *SHA3_256*, *SHA3_384*, and *SHA3_512* (*MD4*, *MD5*, and *SHA1* are not supoorted). -Refer to [KMIP - Profiles Support](/docs/secrets/kmip-profiles) page for more details. +Refer to [KMIP - Profiles Support](/vault/docs/secrets/kmip-profiles) page for more details. [baseline-server]: http://docs.oasis-open.org/kmip/profiles/v1.4/os/kmip-profiles-v1.4-os.html#_Toc491431430 [lifecycle-server]: http://docs.oasis-open.org/kmip/profiles/v1.4/os/kmip-profiles-v1.4-os.html#_Toc491431487 diff --git a/website/content/docs/secrets/kubernetes.mdx b/website/content/docs/secrets/kubernetes.mdx index 1285d5c4d0..049fd03221 100644 --- a/website/content/docs/secrets/kubernetes.mdx +++ b/website/content/docs/secrets/kubernetes.mdx @@ -23,7 +23,7 @@ and [Kubernetes RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rb documentation. ~> **Note:** We do not recommend using tokens created by the Kubernetes Secrets Engine to - authenticate with the [Vault Kubernetes Auth Method](/docs/auth/kubernetes). This will + authenticate with the [Vault Kubernetes Auth Method](/vault/docs/auth/kubernetes). This will generate many unique identities in Vault that will be hard to manage. ## Setup @@ -196,7 +196,7 @@ management tool. ``` Configuration options are available as specified in the - [API docs](/api-docs/secret/kubernetes). + [API docs](/vault/api-docs/secret/kubernetes). 1. You can now configure Kubernetes Secrets Engine to create a Vault role (**not** the same as a Kubernetes role) that can generate service account tokens for the given service account: @@ -365,4 +365,4 @@ service_account_token eyJHbGci0iJSUzI1Ni... ## API The Kubernetes Secrets Engine has a full HTTP API. Please see the -[Kubernetes Secrets Engine API docs](/api-docs/secret/kubernetes) for more details. +[Kubernetes Secrets Engine API docs](/vault/api-docs/secret/kubernetes) for more details. diff --git a/website/content/docs/secrets/kv/index.mdx b/website/content/docs/secrets/kv/index.mdx index 398d18910e..815f6cdce2 100644 --- a/website/content/docs/secrets/kv/index.mdx +++ b/website/content/docs/secrets/kv/index.mdx @@ -22,7 +22,7 @@ more performant because for any given request there will be fewer storage calls and no locking. More information about running in this mode can be found in the [K/V Version 1 -Docs](/docs/secrets/kv/kv-v1) +Docs](/vault/docs/secrets/kv/kv-v1) ## KV Version 2 @@ -39,4 +39,4 @@ command or API endpoint. Each of these operations can be ACL'ed differently, restricting who has permissions to soft delete, undelete, or fully remove data. More information about running in this mode can be found in the [K/V Version 2 -Docs](/docs/secrets/kv/kv-v2) +Docs](/vault/docs/secrets/kv/kv-v2) diff --git a/website/content/docs/secrets/kv/kv-v1.mdx b/website/content/docs/secrets/kv/kv-v1.mdx index f87222875a..fdb353fc89 100644 --- a/website/content/docs/secrets/kv/kv-v1.mdx +++ b/website/content/docs/secrets/kv/kv-v1.mdx @@ -107,5 +107,5 @@ tutorial to learn how to set up a uniform workflow to securely store sensitive i ## API The KV secrets engine has a full HTTP API. Please see the -[KV secrets engine API](/api-docs/secret/kv/kv-v1) for more +[KV secrets engine API](/vault/api-docs/secret/kv/kv-v1) for more details. diff --git a/website/content/docs/secrets/kv/kv-v2.mdx b/website/content/docs/secrets/kv/kv-v2.mdx index 4804df53ec..0eb586afb3 100644 --- a/website/content/docs/secrets/kv/kv-v2.mdx +++ b/website/content/docs/secrets/kv/kv-v2.mdx @@ -45,7 +45,7 @@ different paths. Each instance of the KV secrets engine is isolated and unique. An existing version 1 kv store can be upgraded to a version 2 kv store via the CLI or API, as shown below. This will start an upgrade process to upgrade the existing key/value data to a versioned format. The mount will be inaccessible during this process. This process could take a long time, so plan accordingly. -Once upgraded to version 2, the former paths at which the data was accessible will no longer suffice. You will need to adjust user policies to add access to the version 2 paths as detailed in the [ACL Rules section below](/docs/secrets/kv/kv-v2#acl-rules). Similarly, users/applications will need to update the paths at which they interact with the kv data once it has been upgraded to version 2. +Once upgraded to version 2, the former paths at which the data was accessible will no longer suffice. You will need to adjust user policies to add access to the version 2 paths as detailed in the [ACL Rules section below](/vault/docs/secrets/kv/kv-v2#acl-rules). Similarly, users/applications will need to update the paths at which they interact with the kv data once it has been upgraded to version 2. An existing version 1 kv can be upgraded to a version 2 KV store with the CLI command: @@ -153,10 +153,10 @@ path "secret/metadata/dev/team-1/*" { ``` The `allowed_parameters`, `denied_parameters`, and `required_parameters` fields are -not supported for policies used with the version 2 kv store. See the [Policies Concepts](/docs/concepts/policies) +not supported for policies used with the version 2 kv store. See the [Policies Concepts](/vault/docs/concepts/policies) for a description of these parameters. -See the [API Specification](/api-docs/secret/kv/kv-v2) for more +See the [API Specification](/vault/api-docs/secret/kv/kv-v2) for more information. ## Usage @@ -551,5 +551,5 @@ tutorial to learn how to use KV secrets engine v2 to version or roll back secret ## API The KV secrets engine has a full HTTP API. Please see the -[KV secrets engine API](/api-docs/secret/kv/kv-v2) for more +[KV secrets engine API](/vault/api-docs/secret/kv/kv-v2) for more details. diff --git a/website/content/docs/secrets/ldap.mdx b/website/content/docs/secrets/ldap.mdx index 2c15239316..86f5b07212 100644 --- a/website/content/docs/secrets/ldap.mdx +++ b/website/content/docs/secrets/ldap.mdx @@ -15,9 +15,9 @@ v3 protocol, including OpenLDAP, Active Directory, and IBM Resource Access Contr Facility (RACF). The secrets engine has three primary features: -- [Static Credentials](/docs/secrets/ldap#static-credentials) -- [Dynamic Credentials](/docs/secrets/ldap#dynamic-credentials) -- [Service Account Check-Out](/docs/secrets/ldap#service-account-check-out) +- [Static Credentials](/vault/docs/secrets/ldap#static-credentials) +- [Dynamic Credentials](/vault/docs/secrets/ldap#dynamic-credentials) +- [Service Account Check-Out](/vault/docs/secrets/ldap#service-account-check-out) ## Setup @@ -77,7 +77,7 @@ For managing IBM's Resource Access Control Facility (RACF) security system, the engine must be configured to use the schema `racf`. Generated passwords must be 8 characters or less to support RACF. The length of the -password can be configured using a [password policy](/docs/concepts/password-policies): +password can be configured using a [password policy](/vault/docs/concepts/password-policies): ```bash $ vault write ldap/config \ @@ -270,7 +270,7 @@ by a person or by machines. Vault will automatically rotate the password each ti service account is checked in. Service accounts can be voluntarily checked in, or Vault will check them in when their lending period (or, "ttl", in Vault's language) ends. -The service account check-out functionality works with various [schemas](/api-docs/secret/ldap#schema), +The service account check-out functionality works with various [schemas](/vault/api-docs/secret/ldap#schema), including OpenLDAP, Active Directory, and RACF. In the following usage example, the secrets engine is configured to manage a library of service accounts in an Active Directory instance. @@ -302,7 +302,7 @@ In this example, the service account names of `fizz@example.com` and `buzz@examp already been created on the remote AD server. They've been set aside solely for Vault to handle. The `ttl` is how long each check-out will last before Vault checks in a service account, rotating its password during check-in. The `max_ttl` is the maximum amount of time it can live -if it's renewed. These default to `24h`, and both use [duration format strings](/docs/concepts/duration-format). +if it's renewed. These default to `24h`, and both use [duration format strings](/vault/docs/concepts/duration-format). Also by default, a service account must be checked in by the same Vault entity or client token that checked it out. However, if this behavior causes problems, set `disable_check_in_enforcement=true`. @@ -395,7 +395,7 @@ check_ins [fizz@example.com] ``` To perform a check-in, Vault verifies that the caller _should_ be able to check in a given service account. -To do this, Vault looks for either the same [entity ID](https://learn.hashicorp.com/tutorials/vault/identity) +To do this, Vault looks for either the same [entity ID](/vault/tutorials/auth-methods/identity) used to check out the service account, or the same client token. If a caller is unable to check in a service account, or simply doesn't try, @@ -420,7 +420,7 @@ All revocation operations queued successfully! This engine previously allowed configuration of the length of the password that is generated when rotating credentials. This mechanism was deprecated in Vault 1.5 in favor of -[password policies](/docs/concepts/password-policies). This means the `length` field should +[password policies](/vault/docs/concepts/password-policies). This means the `length` field should no longer be used. The following password policy can be used to mirror the same behavior that the `length` field provides: @@ -462,5 +462,5 @@ olcPPolicyUseLockout: TRUE ## API -The LDAP secrets engine has a full HTTP API. Please see the [LDAP secrets engine API docs](/api-docs/secret/ldap) +The LDAP secrets engine has a full HTTP API. Please see the [LDAP secrets engine API docs](/vault/api-docs/secret/ldap) for more details. diff --git a/website/content/docs/secrets/mongodbatlas.mdx b/website/content/docs/secrets/mongodbatlas.mdx index d935b79b1c..5d2cd62d57 100644 --- a/website/content/docs/secrets/mongodbatlas.mdx +++ b/website/content/docs/secrets/mongodbatlas.mdx @@ -188,4 +188,4 @@ $ vault read mongodbatlas/creds/test ## API The MongoDB Atlas secrets engine has a full HTTP API. Please see the -[MongoDB Atlas secrets engine API docs](/api-docs/secret/mongodbatlas) for more details. +[MongoDB Atlas secrets engine API docs](/vault/api-docs/secret/mongodbatlas) for more details. diff --git a/website/content/docs/secrets/nomad.mdx b/website/content/docs/secrets/nomad.mdx index 33460bef3d..8edf56a4db 100644 --- a/website/content/docs/secrets/nomad.mdx +++ b/website/content/docs/secrets/nomad.mdx @@ -36,7 +36,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://learn.hashicorp.com/collections/nomad/access-control#generate-the-initial-token), although this +process](/nomad/tutorials/access-control#generate-the-initial-token), although this is discouraged for production deployments. ```shell-session @@ -53,7 +53,7 @@ Modify Index = 7 ``` The suggested pattern is to generate a token specifically for Vault, following the -[Nomad ACL guide](https://learn.hashicorp.com/collections/nomad/access-control) +[Nomad ACL guide](/nomad/tutorials/access-control) Next, we must configure Vault to know how to contact Nomad. This is done by writing the access information: @@ -113,11 +113,11 @@ Modify Index = 138 ## Tutorial Refer to [Generate Nomad Tokens with HashiCorp -Vault](https://learn.hashicorp.com/tutorials/nomad/vault-nomad-secrets) for a +Vault](/nomad/tutorials/integrate-vault/vault-nomad-secrets) for a step-by-step tutorial. ## API The Nomad secrets engine has a full HTTP API. Please see the -[Nomad Secrets Engine API](/api-docs/secret/nomad) for more +[Nomad Secrets Engine API](/vault/api-docs/secret/nomad) for more details. diff --git a/website/content/docs/secrets/pki/considerations.mdx b/website/content/docs/secrets/pki/considerations.mdx index ad03d6b989..9bdbed75bd 100644 --- a/website/content/docs/secrets/pki/considerations.mdx +++ b/website/content/docs/secrets/pki/considerations.mdx @@ -60,7 +60,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_](/docs/enterprise/managed-keys). In this case, Vault never sees the +[_managed key_](/vault/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. @@ -110,7 +110,7 @@ mount can decide which to use. ### Always Configure a Default Issuer -For backwards compatibility, [the default issuer](/api-docs/secret/pki#read-issuers-configuration) +For backwards compatibility, [the default issuer](/vault/api-docs/secret/pki#read-issuers-configuration) is used to service PKI endpoints without an explicit issuer (either via path selection or role-based selection). When certificates are revoked and their issuer is no longer part of this PKI mount, Vault places them on the default @@ -153,8 +153,8 @@ performance of easier-to-rotate intermediates and certificates (such as TLS intermediates). Vault supports the use of both the [`allowed_domains` parameter on -Roles](/api-docs/secret/pki#allowed_domains) and the [`permitted_dns_domains` -parameter to set the Name Constraints extension](/api-docs/secret/pki#permitted_dns_domains) +Roles](/vault/api-docs/secret/pki#allowed_domains) and the [`permitted_dns_domains` +parameter to set the Name Constraints extension](/vault/api-docs/secret/pki#permitted_dns_domains) on root and intermediate generation. This allows for several layers of separation of concerns between TLS-based services. @@ -223,7 +223,7 @@ is down. In Vault 1.11.0, the PKI Secrets Engine has introduced a new `leaf_not_after_behavior` [parameter on -issuers](/api-docs/secret/pki#leaf_not_after_behavior). +issuers](/vault/api-docs/secret/pki#leaf_not_after_behavior). This allows modification of the issuance behavior: should Vault `err`, preventing issuance of a longer-lived leaf cert than issuer, silently `truncate` to that of the issuer's `NotAfter` value, or `permit` longer @@ -237,7 +237,7 @@ In combination with a cascading expiration with longer lived roots (perhaps on the range of 2-10 years), shorter lived intermediates (perhaps on the range of 6 months to 2 years), and short-lived leaf certificates (on the range of 30 to 90 days), and the [rotation strategies discussed in other -sections](/docs/secrets/pki/rotation-primitives), this should keep the +sections](/vault/docs/secrets/pki/rotation-primitives), this should keep the CRLs adequately small. ### Cluster Performance and Quantity of Leaf Certificates @@ -248,7 +248,7 @@ this is a scale problem: 10-1000 long-lived, stored certificates are probably fine, but 50k-100k become a problem and 500k+ stored, unexpired certificates can negatively impact even large Vault clusters--even with short TTLs! -However, once these certificates are expired, a [tidy operation](/api-docs/secret/pki#tidy) +However, once these certificates are expired, a [tidy operation](/vault/api-docs/secret/pki#tidy) will clean up CRLs and Vault cluster storage. Note that organizational risk assessments for certificate compromise might @@ -264,7 +264,7 @@ Having a shorter TTL decreases the likelihood of needing to revoke a cert compromise. ~> Note: As of Vault 1.12, the PKI Secret Engine's [Bring-Your-Own-Cert - (BYOC)](/api-docs/secret/pki#revoke-certificate) + (BYOC)](/vault/api-docs/secret/pki#revoke-certificate) functionality allows revocation of certificates not previously stored (e.g., issued via a role with `no_store=true`). This means that setting `no_store=true` _is now_ safe to be used globally, regardless of importance @@ -304,7 +304,7 @@ HTTP. As much as possible, for managing certificates for services at scale, it is best to automate renewal of certificates. Vault agent [has support for -automatically renewing requested certificates](/docs/agent/template#certificates) +automatically renewing requested certificates](/vault/docs/agent/template#certificates) based on the `validTo` field. Other solutions might involve using [cert-manager](https://cert-manager.io/) in Kubernetes or OpenShift, backed by the Vault CA. @@ -338,7 +338,7 @@ endpoint. ## Safe Usage of Roles The Vault PKI Secrets Engine supports many options to limit issuance via -[Roles](/api-docs/secret/pki#create-update-role). +[Roles](/vault/api-docs/secret/pki#create-update-role). Careful consideration of construction is necessary to ensure that more permissions are not given than necessary. Additionally, roles should generally do _one_ thing; multiple roles should be preferable over having too permissive @@ -392,12 +392,12 @@ this mount. the `/pki/cert/crl` API endpoint. Additionally, the `http_raw_body` can be used to return CRL both in PEM and raw binary DER form, so it is suggested not to un-HMAC that field to not corrupt the log format.

- If this is done with only a [syslog](/docs/audit/syslog) audit device, + If this is done with only a [syslog](/vault/docs/audit/syslog) audit device, Vault can deny requests (with an opaque `500 Internal Error` message) after the action has been performed on the server, because it was unable to log the message.

The suggested workaround is to either leave the `certificate` and `crl` - response fields HMACed and/or to also enable the [`file`](/docs/audit/file) + response fields HMACed and/or to also enable the [`file`](/vault/docs/audit/file) audit log type. Some suggested keys to un-HMAC for requests are as follows: @@ -457,7 +457,7 @@ nature: ## Role-Based Access -Vault supports [path-based ACL Policies](https://learn.hashicorp.com/tutorials/vault/getting-started-policies) +Vault supports [path-based ACL Policies](/vault/tutorials/getting-started/getting-started-policies) for limiting access to various paths within Vault. The following is a condensed example reference of ACLing the PKI Secrets @@ -538,12 +538,12 @@ For these personas, we suggest the following ACLs, in condensed, tabular form: | `/root/replace` | Write | Yes | | | | | ~> Note: With managed keys, operators might need access to [read the mount - point's tunable data](/api-docs/system/mounts) (Read on `/sys/mounts`) and - may need access [to use or manage managed keys](/api-docs/system/managed-keys). + point's tunable data](/vault/api-docs/system/mounts) (Read on `/sys/mounts`) and + may need access [to use or manage managed keys](/vault/api-docs/system/managed-keys). ## Replicated DataSets -When operating with [Performance Secondary](/docs/enterprise/replication#architecture) +When operating with [Performance Secondary](/vault/docs/enterprise/replication#architecture) clusters, certain data-sets are maintained across all clusters, while others for performance and scalability reasons are kept within a given cluster. @@ -565,7 +565,7 @@ sent to the appropriate cluster that the data was generated on. The main effect is that within the PKI secrets engine leaf certificates issued with `no_store` set to `false` are stored local to the cluster that issued them. -This allows for both primary and [Performance Secondary](/docs/enterprise/replication#architecture) +This allows for both primary and [Performance Secondary](/vault/docs/enterprise/replication#architecture) clusters' active node to issue certificates for greater scalability. As a result, these certificates and any revocations are visible only on the issuing cluster. This additionally means each cluster has its own set of CRLs, distinct @@ -681,11 +681,11 @@ vault read pki/issuer/default Refer to the [Build Your Own Certificate Authority (CA)](https://learn.hashicorp.com/vault/secrets-management/sm-pki-engine) guide for a step-by-step tutorial. -Have a look at the [PKI Secrets Engine with Managed Keys](https://learn.hashicorp.com/tutorials/vault/managed-key-pki?in=vault/enterprise) +Have a look at the [PKI Secrets Engine with Managed Keys](/vault/tutorials/enterprise/managed-key-pki) for more about how to use externally managed keys with PKI. ## API The PKI secrets engine has a full HTTP API. Please see the -[PKI secrets engine API](/api-docs/secret/pki) for more +[PKI secrets engine API](/vault/api-docs/secret/pki) for more details. diff --git a/website/content/docs/secrets/pki/index.mdx b/website/content/docs/secrets/pki/index.mdx index 899b241a89..8d1084e504 100644 --- a/website/content/docs/secrets/pki/index.mdx +++ b/website/content/docs/secrets/pki/index.mdx @@ -31,17 +31,17 @@ written to disk. The PKI Secrets Engine documentation is split into the following pieces: - - [Overview](/docs/secrets/pki) - this document. - - [Setup and Usage](/docs/secrets/pki/setup) - a brief description of setting + - [Overview](/vault/docs/secrets/pki) - this document. + - [Setup and Usage](/vault/docs/secrets/pki/setup) - a brief description of setting up and using the PKI Secrets Engine to issue certificates. - - [Quick Start - Root CA Setup](/docs/secrets/pki/quick-start-root-ca) - A + - [Quick Start - Root CA Setup](/vault/docs/secrets/pki/quick-start-root-ca) - A quick start guide for setting up a root CA. - - [Quick Start - Intermediate CA Setup](/docs/secrets/pki/quick-start-intermediate-ca) - A + - [Quick Start - Intermediate CA Setup](/vault/docs/secrets/pki/quick-start-intermediate-ca) - A quick start guide for setting up an intermediate CA. - - [Considerations](/docs/secrets/pki/considerations) - A list of helpful + - [Considerations](/vault/docs/secrets/pki/considerations) - A list of helpful considerations to keep in mind when using and operating the PKI Secrets Engine. - - [Rotation Primitives](/docs/secrets/pki/rotation-primitives) - A document + - [Rotation Primitives](/vault/docs/secrets/pki/rotation-primitives) - A document which explains different types of certificates used to achieve rotation. ## Tutorial @@ -49,11 +49,11 @@ The PKI Secrets Engine documentation is split into the following pieces: Refer to the [Build Your Own Certificate Authority (CA)](https://learn.hashicorp.com/vault/secrets-management/sm-pki-engine) guide for a step-by-step tutorial. -Have a look at the [PKI Secrets Engine with Managed Keys](https://learn.hashicorp.com/tutorials/vault/managed-key-pki?in=vault/enterprise) +Have a look at the [PKI Secrets Engine with Managed Keys](/vault/tutorials/enterprise/managed-key-pki) for more about how to use externally managed keys with PKI. ## API The PKI secrets engine has a full HTTP API. Please see the -[PKI secrets engine API](/api-docs/secret/pki) for more +[PKI secrets engine API](/vault/api-docs/secret/pki) for more details. diff --git a/website/content/docs/secrets/pki/quick-start-intermediate-ca.mdx b/website/content/docs/secrets/pki/quick-start-intermediate-ca.mdx index e37127dd2c..258983f31c 100644 --- a/website/content/docs/secrets/pki/quick-start-intermediate-ca.mdx +++ b/website/content/docs/secrets/pki/quick-start-intermediate-ca.mdx @@ -6,7 +6,7 @@ description: The PKI secrets engine for Vault generates TLS certificates. # PKI Secrets Engine - Quick Start - Intermediate CA Setup -In the [first Quick Start guide](/docs/secrets/pki/quick-start-root-ca), +In the [first Quick Start guide](/vault/docs/secrets/pki/quick-start-root-ca), certificates were issued directly from the root certificate authority. As described in the example, this is not a recommended practice. This guide builds on the previous guide's root certificate authority and creates an @@ -262,11 +262,11 @@ OS. Refer to the [Build Your Own Certificate Authority (CA)](https://learn.hashicorp.com/vault/secrets-management/sm-pki-engine) guide for a step-by-step tutorial. -Have a look at the [PKI Secrets Engine with Managed Keys](https://learn.hashicorp.com/tutorials/vault/managed-key-pki?in=vault/enterprise) +Have a look at the [PKI Secrets Engine with Managed Keys](/vault/tutorials/enterprise/managed-key-pki) for more about how to use externally managed keys with PKI. ## API The PKI secrets engine has a full HTTP API. Please see the -[PKI secrets engine API](/api-docs/secret/pki) for more +[PKI secrets engine API](/vault/api-docs/secret/pki) for more details. diff --git a/website/content/docs/secrets/pki/quick-start-root-ca.mdx b/website/content/docs/secrets/pki/quick-start-root-ca.mdx index 8c5f365a10..bbd97068bf 100644 --- a/website/content/docs/secrets/pki/quick-start-root-ca.mdx +++ b/website/content/docs/secrets/pki/quick-start-root-ca.mdx @@ -219,11 +219,11 @@ subpath for interactive help output. Refer to the [Build Your Own Certificate Authority (CA)](https://learn.hashicorp.com/vault/secrets-management/sm-pki-engine) guide for a step-by-step tutorial. -Have a look at the [PKI Secrets Engine with Managed Keys](https://learn.hashicorp.com/tutorials/vault/managed-key-pki?in=vault/enterprise) +Have a look at the [PKI Secrets Engine with Managed Keys](/vault/tutorials/enterprise/managed-key-pki) for more about how to use externally managed keys with PKI. ## API The PKI secrets engine has a full HTTP API. Please see the -[PKI secrets engine API](/api-docs/secret/pki) for more +[PKI secrets engine API](/vault/api-docs/secret/pki) for more details. diff --git a/website/content/docs/secrets/pki/rotation-primitives.mdx b/website/content/docs/secrets/pki/rotation-primitives.mdx index 2b83796266..310b489be8 100644 --- a/website/content/docs/secrets/pki/rotation-primitives.mdx +++ b/website/content/docs/secrets/pki/rotation-primitives.mdx @@ -241,18 +241,18 @@ This construct is documented and used in several places: #### Execution in Vault To create a cross-signed certificate in Vault, use the [`/intermediate/cross-sign` -endpoint](/api-docs/secret/pki#generate-intermediate-csr). Here, when creating +endpoint](/vault/api-docs/secret/pki#generate-intermediate-csr). Here, when creating a cross-signature to all `cert B` to be validated by `cert A`, provide the values (`key_ref`, all Subject parts, &c) for `cert B` during intermediate generation. Then sign this CSR (using the [`/issuer/:issuer_ref/sign-intermediate` -endpoint](/api-docs/secret/pki#sign-intermediate)) with `cert A`'s reference +endpoint](/vault/api-docs/secret/pki#sign-intermediate)) with `cert A`'s reference and provide necessary values from `cert B` (e.g., Subject parts). `cert A` may live outside Vault. Finally, import the cross-signed certificate into Vault -[using the `/issuers/import/cert` endpoint](/api-docs/secret/pki#import-ca-certificates-and-keys). +[using the `/issuers/import/cert` endpoint](/vault/api-docs/secret/pki#import-ca-certificates-and-keys). If this process succeeded, and both `cert A` and `cert B` and their key material lives in Vault, the newly imported cross-signed certificate -will have a `ca_chain` response field [during read](/api-docs/secret/pki#read-issuer) +will have a `ca_chain` response field [during read](/vault/api-docs/secret/pki#read-issuer) containing `cert A`, and `cert B`'s `ca_chain` will contain the cross-signed cert and its `ca_chain` value. @@ -270,7 +270,7 @@ one of these pairs of chains. This is because the leaf issuance's `ca_chain` parameter copies the value from signing issuer directly, rather than computing its own copy of the chain. -To fix this, update the `manual_chain` field on the [issuers](/api-docs/secret/pki#update-issuer) +To fix this, update the `manual_chain` field on the [issuers](/vault/api-docs/secret/pki#update-issuer) to include the chains of both pairs. For instance, given `intA` signed by `rootA` and `intB` signed by `rootB` as its cross-signed version, one could do the following: @@ -355,9 +355,9 @@ same key material from the existing authority. #### Execution in Vault To create a reissued root certificate in Vault, use [`/issuers/generate/root/existing` -endpoint](/api-docs/secret/pki#generate-root). This allows the generation of a new +endpoint](/vault/api-docs/secret/pki#generate-root). This allows the generation of a new root certificate with the existing key material (via the `key_ref` request parameter). -If this process succeeded, when [reading the issuer](/api-docs/secret/pki#read-issuer) +If this process succeeded, when [reading the issuer](/vault/api-docs/secret/pki#read-issuer) (via `GET /issuer/:issuer_ref`), both issuers (old and reissued) will appear in each others' `ca_chain` response field (unless prevented so by a `manual_chain` value). @@ -366,16 +366,16 @@ To create a reissued intermediate certificate in Vault, this is a three step process: 1. Use the [`/issuers/generate/intermediate/existing` - endpoint](/api-docs/secret/pki#generate-intermediate-csr) + endpoint](/vault/api-docs/secret/pki#generate-intermediate-csr) to generate a new CSR with the existing key material with the `key_ref` request parameter. 2. Sign this CSR via the same signing process under the same issuer. This step is specific to the parent CA, which may or may not be Vault. - 3. Finally, use the [`/intermediate/set-signed` endpoint](/api-docs/secret/pki#import-ca-certificates-and-keys) + 3. Finally, use the [`/intermediate/set-signed` endpoint](/vault/api-docs/secret/pki#import-ca-certificates-and-keys) to import the signed certificate from step 2. If the process to reissue an intermediate certificate succeeded, when -[reading the issuer](/api-docs/secret/pki#read-issuer) (via +[reading the issuer](/vault/api-docs/secret/pki#read-issuer) (via `GET /issuer/:issuer_ref`), both issuers (old and reissued) will have the same `ca_chain` response field, except for the first entry (unless prevented so by a `manual_chain` value). @@ -436,11 +436,11 @@ certificates with unique serial numbers. Refer to the [Build Your Own Certificate Authority (CA)](https://learn.hashicorp.com/vault/secrets-management/sm-pki-engine) guide for a step-by-step tutorial. -Have a look at the [PKI Secrets Engine with Managed Keys](https://learn.hashicorp.com/tutorials/vault/managed-key-pki?in=vault/enterprise) +Have a look at the [PKI Secrets Engine with Managed Keys](/vault/tutorials/enterprise/managed-key-pki) for more about how to use externally managed keys with PKI. ## API The PKI secrets engine has a full HTTP API. Please see the -[PKI secrets engine API](/api-docs/secret/pki) for more +[PKI secrets engine API](/vault/api-docs/secret/pki) for more details. diff --git a/website/content/docs/secrets/pki/setup.mdx b/website/content/docs/secrets/pki/setup.mdx index 80e5f44873..52df3a3d26 100644 --- a/website/content/docs/secrets/pki/setup.mdx +++ b/website/content/docs/secrets/pki/setup.mdx @@ -110,11 +110,11 @@ the proper permission, it can generate credentials. Refer to the [Build Your Own Certificate Authority (CA)](https://learn.hashicorp.com/vault/secrets-management/sm-pki-engine) guide for a step-by-step tutorial. -Have a look at the [PKI Secrets Engine with Managed Keys](https://learn.hashicorp.com/tutorials/vault/managed-key-pki?in=vault/enterprise) +Have a look at the [PKI Secrets Engine with Managed Keys](/vault/tutorials/enterprise/managed-key-pki) for more about how to use externally managed keys with PKI. ## API The PKI secrets engine has a full HTTP API. Please see the -[PKI secrets engine API](/api-docs/secret/pki) for more +[PKI secrets engine API](/vault/api-docs/secret/pki) for more details. diff --git a/website/content/docs/secrets/rabbitmq.mdx b/website/content/docs/secrets/rabbitmq.mdx index d0b6984878..7671bc6578 100644 --- a/website/content/docs/secrets/rabbitmq.mdx +++ b/website/content/docs/secrets/rabbitmq.mdx @@ -94,7 +94,7 @@ the proper permission, it can generate credentials. ## API The RabbitMQ secrets engine has a full HTTP API. Please see the -[RabbitMQ secrets engine API](/api-docs/secret/rabbitmq) for more +[RabbitMQ secrets engine API](/vault/api-docs/secret/rabbitmq) for more details. [rmq-perms]: https://www.rabbitmq.com/management.html#permissions diff --git a/website/content/docs/secrets/ssh/dynamic-ssh-keys.mdx b/website/content/docs/secrets/ssh/dynamic-ssh-keys.mdx index 8dd217858f..5d2f435714 100644 --- a/website/content/docs/secrets/ssh/dynamic-ssh-keys.mdx +++ b/website/content/docs/secrets/ssh/dynamic-ssh-keys.mdx @@ -189,5 +189,5 @@ username@:~$ ## API The SSH secret secrets engine has a full HTTP API. Please see the -[SSH secret secrets engine API](/api-docs/secret/ssh) for more +[SSH secret secrets engine API](/vault/api-docs/secret/ssh) for more details. diff --git a/website/content/docs/secrets/ssh/index.mdx b/website/content/docs/secrets/ssh/index.mdx index bc2004ab6c..5ab529728e 100644 --- a/website/content/docs/secrets/ssh/index.mdx +++ b/website/content/docs/secrets/ssh/index.mdx @@ -20,14 +20,14 @@ credentials. The Vault SSH secrets engine supports the following modes. Each mode is individually documented on its own page. -- [Signed SSH Certificates](/docs/secrets/ssh/signed-ssh-certificates) -- [One-time SSH Passwords](/docs/secrets/ssh/one-time-ssh-passwords) -- [Dynamic SSH Keys](/docs/secrets/ssh/dynamic-ssh-keys) DEPRECATED +- [Signed SSH Certificates](/vault/docs/secrets/ssh/signed-ssh-certificates) +- [One-time SSH Passwords](/vault/docs/secrets/ssh/one-time-ssh-passwords) +- [Dynamic SSH Keys](/vault/docs/secrets/ssh/dynamic-ssh-keys) DEPRECATED All guides assume a basic familiarity with the SSH protocol. ## API The SSH secrets engine has a full HTTP API. Please see the -[SSH secrets engine API](/api-docs/secret/ssh) for more +[SSH secrets engine API](/vault/api-docs/secret/ssh) for more details. diff --git a/website/content/docs/secrets/ssh/one-time-ssh-passwords.mdx b/website/content/docs/secrets/ssh/one-time-ssh-passwords.mdx index e7a779b6f2..694820fd9c 100644 --- a/website/content/docs/secrets/ssh/one-time-ssh-passwords.mdx +++ b/website/content/docs/secrets/ssh/one-time-ssh-passwords.mdx @@ -116,5 +116,5 @@ to learn how to use the Vault SSH secrets engine to secure authentication and au ## API The SSH secrets engine has a full HTTP API. Please see the -[SSH secrets engine API](/api-docs/secret/ssh) for more +[SSH secrets engine API](/vault/api-docs/secret/ssh) for more details. diff --git a/website/content/docs/secrets/ssh/signed-ssh-certificates.mdx b/website/content/docs/secrets/ssh/signed-ssh-certificates.mdx index 8fedea1056..705180b99b 100644 --- a/website/content/docs/secrets/ssh/signed-ssh-certificates.mdx +++ b/website/content/docs/secrets/ssh/signed-ssh-certificates.mdx @@ -539,5 +539,5 @@ Destroy the keypair and `payload.json` from your hosts immediately after they ha ## API The SSH secrets engine has a full HTTP API. Please see the -[SSH secrets engine API](/api-docs/secret/ssh) for more +[SSH secrets engine API](/vault/api-docs/secret/ssh) for more details. diff --git a/website/content/docs/secrets/terraform.mdx b/website/content/docs/secrets/terraform.mdx index f2285fb3d9..d3de02b8b8 100644 --- a/website/content/docs/secrets/terraform.mdx +++ b/website/content/docs/secrets/terraform.mdx @@ -45,7 +45,7 @@ management tool. ``` See [Terraform Cloud's documentation on API - tokens](https://www.terraform.io/cloud-docs/users-teams-organizations/api-tokens) + tokens](/terraform/cloud-docs/users-teams-organizations/api-tokens) to determine the appropriate API token for use with the secret engine. In order to perform all operations, a User API token is recommended. @@ -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/cloud-docs/api-docs/account) to find the + API](/terraform/cloud-docs/api-docs/account) to find the desired User ID. ```shell-session @@ -156,16 +156,16 @@ token_id at-fqvtdTQ5kQWcjUfG Please see the [Terraform Cloud API Token documentation for more -information](https://www.terraform.io/cloud-docs/users-teams-organizations/api-tokens). +information](/terraform/cloud-docs/users-teams-organizations/api-tokens). ## Tutorial Refer to [Terraform Cloud Secrets -Engine](https://learn.hashicorp.com/tutorials/vault/terraform-secrets-engine) +Engine](/vault/tutorials/secrets-management/terraform-secrets-engine) for a step-by-step tutorial. ## API The Terraform Cloud secrets engine has a full HTTP API. Please see the -[Terraform Cloud secrets engine API](/api-docs/secret/terraform) for more +[Terraform Cloud secrets engine API](/vault/api-docs/secret/terraform) for more details. diff --git a/website/content/docs/secrets/totp.mdx b/website/content/docs/secrets/totp.mdx index 038292c3e2..cfe0559d75 100644 --- a/website/content/docs/secrets/totp.mdx +++ b/website/content/docs/secrets/totp.mdx @@ -120,5 +120,5 @@ management tool. ## API The TOTP secrets engine has a full HTTP API. Please see the -[TOTP secrets engine API](/api-docs/secret/totp) for more +[TOTP secrets engine API](/vault/api-docs/secret/totp) for more details. diff --git a/website/content/docs/secrets/transform/index.mdx b/website/content/docs/secrets/transform/index.mdx index 0ebd082440..677254bcae 100644 --- a/website/content/docs/secrets/transform/index.mdx +++ b/website/content/docs/secrets/transform/index.mdx @@ -188,7 +188,7 @@ In summary, there are three ways in which the tweak value may be sourced: Your team and organization should weigh the trade-offs when it comes to choosing the proper tweak source to use. For `supplied` and `internal` -sourcing, please see [FF3-1 Tweak Usage Details](transform/ff3-tweak-details) +sourcing, please see [FF3-1 Tweak Usage Details](/vault/docs/secrets/transform/ff3-tweak-details) #### Input Limits @@ -227,7 +227,7 @@ not support retrieving the original value back using the decode operation. ### Tokenization -[Tokenization](transform/tokenization) exchanges a +[Tokenization](/vault/docs/secrets/transform/tokenization) exchanges a sensitive value for an unrelated value called a _token_. The original sensitive value cannot be recovered from a token alone, they are irreversible. @@ -268,7 +268,7 @@ for external storage. #### Mapping Modes -[Tokenization](transform/tokenization) stores the results of an encode operation +[Tokenization](/vault/docs/secrets/transform/tokenization) stores the results of an encode operation in storage using a cryptographic construct that enhances the safety of its values. In the `default` mapping mode, the token itself is transformed via a one way function involving the transform key and elements of the token. As Vault does @@ -288,7 +288,7 @@ imported keys. In addition, tokenization transformations may be configured as *convergent*, meaning that tokenizing a plaintext and expiration more than once results in the same token value. Enabling convergence has performance and security -[considerations](transform/tokenization#convergence). +[considerations](/vault/docs/secrets/transform/tokenization#convergence). ## Deletion Behavior @@ -407,11 +407,11 @@ either SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512. 6. Base64 encode the result. -For more details on the key wrapping process, see the [key wrapping guide](/docs/secrets/transit/key-wrapping-guide) +For more details on the key wrapping process, see the [key wrapping guide](/vault/docs/secrets/transit/key-wrapping-guide) (be sure to use the transform wrapping key when wrapping a key for import into the transform secrets engine). ## API The Transform secrets engine has a full HTTP API. Please see the -[Transform secrets engine API](/api-docs/secret/transform) for more +[Transform secrets engine API](/vault/api-docs/secret/transform) for more details. diff --git a/website/content/docs/secrets/transform/tokenization.mdx b/website/content/docs/secrets/transform/tokenization.mdx index fbf0eb43b0..f43684caac 100644 --- a/website/content/docs/secrets/transform/tokenization.mdx +++ b/website/content/docs/secrets/transform/tokenization.mdx @@ -52,7 +52,7 @@ Some use cases may want to lookup the value of a token given its plaintext. Ord this is contrary to the nature of tokenization where we want to prevent the ability of an attacker to determine that a token corresponds to a plaintext value (a known plaintext attack). But for use cases that require it, the -[token lookup](../../../api-docs/secret/transform#token-lookup) +[token lookup](/vault/api-docs/secret/transform#token-lookup) operation is supported, but only in some configurations of the tokenization transformation. Token lookup is supported when convergence is enabled, or if the mapping mode is exportable *and* the storage backend is external. @@ -138,7 +138,7 @@ can immediately reject the operation when presented with an expired token. Currently the PostgreSQL, MySQL, and MSSQL relational databases are supported as external storage backends for tokenization. -The [Schema Endpoint](../../../api-docs/secret/transform#create-update-store-schema) +The [Schema Endpoint](/vault/api-docs/secret/transform#create-update-store-schema) may be used to initialize and upgrade the necessary database tables. Vault uses a schema versioning table to determine if it needs to create or modify the tables when using that endpoint. If you make changes to those tables yourself, @@ -192,10 +192,10 @@ Keys can be rotated to a new version, with backward compatibility for decoding. Encoding is always performed with the newest key version. Keys versions can be tidied as well. Keys may also be rotated automatically on a user-defined time interval, specified by the `auto_rotate_field` of the key config. For more -information, see the [transform api docs](../../../api-docs/secret/transform). +information, see the [transform api docs](/vault/api-docs/secret/transform). ## Tutorial Refer to [Tokenize Data with Transform Secrets -Engine](https://learn.hashicorp.com/tutorials/vault/tokenization) for a +Engine](/vault/tutorials/adp/tokenization) for a step-by-step tutorial. diff --git a/website/content/docs/secrets/transit/index.mdx b/website/content/docs/secrets/transit/index.mdx index d168b0191b..65cf13fed7 100644 --- a/website/content/docs/secrets/transit/index.mdx +++ b/website/content/docs/secrets/transit/index.mdx @@ -181,7 +181,7 @@ the proper permission, it can use this secrets engine. !> Vault HTTP API imposes a maximum request size of 32MB to prevent a denial of service attack. This can be tuned per [`listener` - block](/docs/configuration/listener/tcp) in the Vault server + block](/vault/docs/configuration/listener/tcp) in the Vault server configuration. 1. Decrypt a piece of data using the `/decrypt` endpoint with a named key: @@ -303,7 +303,7 @@ the ciphertext for the input of the `import` endpoint: - Base64 encode the result. For more details about wrapping the key for import into transit, see the -[key wrapping guide](/docs/secrets/transit/key-wrapping-guide). +[key wrapping guide](/vault/docs/secrets/transit/key-wrapping-guide). ## Tutorial @@ -314,5 +314,5 @@ tutorial to learn how to use the transit secrets engine to handle cryptographic ## API The Transit secrets engine has a full HTTP API. Please see the -[Transit secrets engine API](/api-docs/secret/transit) for more +[Transit secrets engine API](/vault/api-docs/secret/transit) for more details. diff --git a/website/content/docs/secrets/venafi.mdx b/website/content/docs/secrets/venafi.mdx index 0ed5763867..fda09fb086 100644 --- a/website/content/docs/secrets/venafi.mdx +++ b/website/content/docs/secrets/venafi.mdx @@ -24,7 +24,7 @@ workloads are the primary focus of the Venafi secrets engine. As such, revocation is not currently supported. The Venafi secrets engine makes use of HashiCorp Vault's -[plugin system](/docs/plugins) +[plugin system](/vault/docs/plugins) and Venafi's [VCert Client SDK](https://github.com/Venafi/vcert). If you have questions about the Venafi secrets engine, have an issue to report, or have developed improvements that you want to contribute, visit the @@ -104,7 +104,7 @@ and any other dependencies that appear in the Venafi Cloud documentation. Before certificates can be issued, you must complete these steps to configure the Venafi secrets engine: -1. Create the [directory](/docs/plugins/plugin-architecture#plugin-directory) +1. Create the [directory](/vault/docs/plugins/plugin-architecture#plugin-directory) where your Vault server will look for plugins (e.g. /etc/vault/vault_plugins). The directory must not be a symbolic link. On macOS, for example, /etc is a link to /private/etc. To avoid errors, choose an alternative directory such @@ -122,14 +122,14 @@ Venafi secrets engine: $ mv venafi-pki-backend /etc/vault/vault_plugins ``` -1. Update the Vault [server configuration](/docs/configuration/) +1. Update the Vault [server configuration](/vault/docs/configuration/) to specify the plugin directory: ```text plugin_directory = "/etc/vault/vault_plugins" ``` -1. Start your Vault using the [server command](/docs/commands/server). +1. Start your Vault using the [server command](/vault/docs/commands/server). 1. Get the SHA-256 checksum of the `venafi-pki-backend` plugin binary: @@ -138,7 +138,7 @@ Venafi secrets engine: ``` 1. Register the `venafi-pki-backend` plugin in the Vault - [system catalog](/docs/plugins/plugin-architecture#plugin-catalog): + [system catalog](/vault/docs/plugins/plugin-architecture#plugin-catalog): ```text $ vault write sys/plugins/catalog/secret/venafi-pki-backend \ @@ -186,7 +186,7 @@ Venafi secrets engine: Success! Data written to: venafi-pki/roles/cloud ``` -1. Lastly, configure a [role](/docs/secrets/pki) +1. Lastly, configure a [role](/vault/docs/secrets/pki) that maps a name in Vault to a Venafi secret for enrollment. To see all options available for roles, including `ttl`, `max_ttl` and `issuer_hint` (for validity), use `vault path-help venafi-pki/roles/:name` after @@ -300,6 +300,6 @@ To see all of the options available when requesting a certificate, including ## API Venafi Machine Identity Secrets Engine uses the same -[Vault API](/api-docs/secret/pki) +[Vault API](/vault/api-docs/secret/pki) as the built-in PKI secrets engine. Some methods, such as those for managing certificate authorities, do not apply. diff --git a/website/content/docs/upgrading/index.mdx b/website/content/docs/upgrading/index.mdx index dc52fdb91b..0af2ae2609 100644 --- a/website/content/docs/upgrading/index.mdx +++ b/website/content/docs/upgrading/index.mdx @@ -28,13 +28,13 @@ during, or after the upgrade. ## Integrated Storage Autopilot Vault 1.11 introduced [automated -upgrades](/docs/concepts/integrated-storage/autopilot#automated-upgrades) as +upgrades](/vault/docs/concepts/integrated-storage/autopilot#automated-upgrades) as part of the Integrated Storage Autopilot feature. If your Vault environment is configured to use Integrated Storage, consider leveraging this new feature to upgrade your Vault environment. -> **Tutorial:** Refer to the [Automate Upgrades with Vault - Enterprise](https://learn.hashicorp.com/tutorials/vault/raft-upgrade-automation) + Enterprise](/vault/tutorials/raft/raft-upgrade-automation) tutorial for more details. ## Agent @@ -58,7 +58,7 @@ along with the non-test cluster. ## OSS to Enterprise Installations -Upgrading to Vault Enterprise installations follow the same steps as OSS upgrades except that the Vault Enterprise binary is to be used and the license file [applied](/api-docs/system/license#install-license), when applicable. The Enterprise binary and license file can be obtained through your HashiCorp sales team. +Upgrading to Vault Enterprise installations follow the same steps as OSS upgrades except that the Vault Enterprise binary is to be used and the license file [applied](/vault/api-docs/system/license#install-license), when applicable. The Enterprise binary and license file can be obtained through your HashiCorp sales team. ## Non-HA Installations @@ -77,10 +77,10 @@ upgrade notes. version of Vault greater than or equal to 1.11 and you have Autopilot enabled. If so, you should let Autopilot do the upgrade for you, as that's easier and less prone to human error. Please refer to our [automated -upgrades](/docs/concepts/integrated-storage/autopilot#automated-upgrades) +upgrades](/vault/docs/concepts/integrated-storage/autopilot#automated-upgrades) documentation for information on this feature and our [Automate Upgrades with Vault -Enterprise](https://learn.hashicorp.com/tutorials/vault/raft-upgrade-automation) +Enterprise](/vault/tutorials/raft/raft-upgrade-automation) tutorial for more details. This is our recommended upgrade procedure if you're on a version of Vault before @@ -101,7 +101,7 @@ backend). Perform these steps on each standby: 1. Properly shut down Vault on the standby node via `SIGINT` or `SIGTERM` -2. Replace the Vault binary with the new version; ensure that `mlock()` capability is added to the new binary with [setcap](/docs/configuration#disable_mlock) +2. Replace the Vault binary with the new version; ensure that `mlock()` capability is added to the new binary with [setcap](/vault/docs/configuration#disable_mlock) 3. Start the standby node 4. Unseal the standby node 5. Verify `vault status` shows correct Version and HA Mode is `standby` @@ -120,7 +120,7 @@ active duty. To do this: not be able to take over until the lock's timeout period has expired. This is backend-specific but could be ten seconds or more. -2. Replace the Vault binary with the new version; ensure that `mlock()` capability is added to the new binary with [setcap](/docs/configuration#disable_mlock) +2. Replace the Vault binary with the new version; ensure that `mlock()` capability is added to the new binary with [setcap](/vault/docs/configuration#disable_mlock) 3. Start the node 4. Unseal the node 5. Verify `vault status` shows correct Version and HA Mode is `standby` @@ -137,7 +137,7 @@ upgrade notes. -> **Note:** Prior to any upgrade, be sure to also read and follow any instructions in the version-specific upgrade notes which are found in the navigation menu for this documentation. -Upgrading installations of Vault which participate in [Enterprise Replication](/docs/enterprise/replication) requires the following basic order of operations: +Upgrading installations of Vault which participate in [Enterprise Replication](/vault/docs/enterprise/replication) requires the following basic order of operations: - **Upgrade the replication secondary instances first** using appropriate guidance from the previous sections depending on whether each secondary diff --git a/website/content/docs/upgrading/plugins.mdx b/website/content/docs/upgrading/plugins.mdx index bc4f3e6ff0..6a54903322 100644 --- a/website/content/docs/upgrading/plugins.mdx +++ b/website/content/docs/upgrading/plugins.mdx @@ -13,7 +13,7 @@ at a path on a running server. The steps are the same whether the plugin being upgraded is built-in or external. ~> Plugin versioning was introduced with Vault 1.12.0, so if your Vault server is - on 1.11.x or earlier, see the [1.11.x version of this page](/docs/v1.11.x/upgrading/plugins) + on 1.11.x or earlier, see the [1.11.x version of this page](/vault/docs/v1.11.x/upgrading/plugins) for plugin upgrade instructions. ### Upgrading auth and secrets plugins @@ -64,7 +64,7 @@ an auth plugin, just replace all usages of `secrets` or `secret` with `auth`. $ vault secrets list -detailed ``` -1. Finally, trigger a [plugin reload](/docs/commands/plugin/reload) to reload all +1. Finally, trigger a [plugin reload](/vault/docs/commands/plugin/reload) to reload all mounted backends using that plugin or a subset of the mounts using that plugin with either the `plugin` or `mounts` flag respectively. @@ -178,11 +178,11 @@ transit v1.12.0+builtin.vault to manage schema upgrades and downgrades. Check the plugin release notes for any unsupported upgrade or downgrade transitions, especially before moving to a new major version or downgrading. -* Existing Vault [leases](/docs/concepts/lease) and [tokens](/docs/concepts/tokens) +* Existing Vault [leases](/vault/docs/concepts/lease) and [tokens](/vault/docs/concepts/tokens) are generally unaffected by plugin upgrades and reloads. This is because the lifecycle of leases and tokens is handled by core systems within Vault. The plugin itself only handles renewal and revocation of them when it’s requested by those core systems. -[plugin_reload_api]: /api-docs/system/plugins-reload-backend -[plugin_registration]: /docs/plugins/plugin-architecture#plugin-registration -[plugin_management]: /docs/plugins/plugin-management#enabling-disabling-external-plugins +[plugin_reload_api]: /vault/api-docs/system/plugins-reload-backend +[plugin_registration]: /vault/docs/plugins/plugin-architecture#plugin-registration +[plugin_management]: /vault/docs/plugins/plugin-management#enabling-disabling-external-plugins diff --git a/website/content/docs/upgrading/upgrade-to-0.10.2.mdx b/website/content/docs/upgrading/upgrade-to-0.10.2.mdx index 84b8688900..e90569baae 100644 --- a/website/content/docs/upgrading/upgrade-to-0.10.2.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.10.2.mdx @@ -15,9 +15,9 @@ for Vault 0.10.2 compared to 0.10.1. Please read it carefully. If you are using `transit`'s convergent encryption feature, which prior to this release was at version 2, we recommend -[rotating](/api-docs/secret/transit#rotate-key) +[rotating](/vault/api-docs/secret/transit#rotate-key) your encryption key (the new key will use version 3) and -[rewrapping](/api-docs/secret/transit#rewrap-data) +[rewrapping](/vault/api-docs/secret/transit#rewrap-data) your data to mitigate the chance of offline plaintext-confirmation attacks. ### PKI duration return types diff --git a/website/content/docs/upgrading/upgrade-to-0.11.0.mdx b/website/content/docs/upgrading/upgrade-to-0.11.0.mdx index 739b4f9895..1477c780e3 100644 --- a/website/content/docs/upgrading/upgrade-to-0.11.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.11.0.mdx @@ -136,9 +136,9 @@ allowing it to be set manually didn't make sense. If you are using `transit`'s convergent encryption feature, which prior to this release was at version 2, we recommend -[rotating](/api-docs/secret/transit#rotate-key) +[rotating](/vault/api-docs/secret/transit#rotate-key) your encryption key (the new key will use version 3) and -[rewrapping](/api-docs/secret/transit#rewrap-data) +[rewrapping](/vault/api-docs/secret/transit#rewrap-data) your data to mitigate the chance of offline plaintext-confirmation attacks. ### PKI duration return types diff --git a/website/content/docs/upgrading/upgrade-to-0.6.0.mdx b/website/content/docs/upgrading/upgrade-to-0.6.0.mdx index 5d9d4806fc..4d1098c377 100644 --- a/website/content/docs/upgrading/upgrade-to-0.6.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.6.0.mdx @@ -50,5 +50,5 @@ If using the Consul HA storage backend, Vault will now automatically register itself as the `vault` service and perform its own health checks/lifecycle status management. This behavior can be adjusted or turned off in Vault's configuration; see the -[documentation](/docs/configuration/storage/consul#check_timeout) +[documentation](/vault/docs/configuration/storage/consul#check_timeout) for details. diff --git a/website/content/docs/upgrading/upgrade-to-0.6.1.mdx b/website/content/docs/upgrading/upgrade-to-0.6.1.mdx index 9b13518f48..6ff4fd4f10 100644 --- a/website/content/docs/upgrading/upgrade-to-0.6.1.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.6.1.mdx @@ -15,7 +15,7 @@ carefully. Once an active node is running 0.6.1, only standby nodes running 0.6.1+ will be able to form an HA cluster. If following our [general upgrade -instructions](/docs/upgrading) this will +instructions](/vault/docs/upgrading) this will not be an issue. ## Health Endpoint Status Code Changes @@ -38,7 +38,7 @@ each status code (including `500`). Root tokens (tokens with the `root` policy) can no longer be created except by another root token or the -[`generate-root`](/api-docs/system/generate-root) +[`generate-root`](/vault/api-docs/system/generate-root) endpoint or CLI command. ## PKI Backend Certificates Will Contain Default Key Usages @@ -49,14 +49,14 @@ compatibility with some software that requires strict adherence to RFCs, such as OpenVPN. This behavior is fully adjustable; see the [PKI backend -documentation](/docs/secrets/pki) for +documentation](/vault/docs/secrets/pki) for details. ## DynamoDB Does Not Support HA By Default If using DynamoDB and want to use HA support, you will need to explicitly enable it in Vault's configuration; see the -[documentation](/docs/configuration#ha_storage) +[documentation](/vault/docs/configuration#ha_storage) for details. If you are already using DynamoDB in an HA fashion and wish to keep doing so, @@ -82,7 +82,7 @@ unfortunately has the side effect that `memberOf` is no longer searched for by default, which is a breaking change for many existing setups. `Scenario 2` in the [updated -documentation](/docs/auth/ldap) shows an +documentation](/vault/docs/auth/ldap) shows an example of configuring the backend to query `memberOf`. It is recommended that a test Vault server be set up and that successful authentication can be performed using the new configuration before upgrading a primary or production @@ -96,7 +96,7 @@ configuration can be specified successfully. ## App-ID is Deprecated With the addition of the new [AppRole -backend](/docs/auth/approle), App-ID is +backend](/vault/docs/auth/approle), App-ID is deprecated. There are no current plans to remove it, but we encourage using AppRole whenever possible, as it offers enhanced functionality and can accommodate many more types of authentication paradigms. App-ID will receive diff --git a/website/content/docs/upgrading/upgrade-to-0.6.2.mdx b/website/content/docs/upgrading/upgrade-to-0.6.2.mdx index 235a60c53a..077c68258c 100644 --- a/website/content/docs/upgrading/upgrade-to-0.6.2.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.6.2.mdx @@ -15,7 +15,7 @@ for Vault 0.6.2. Please read it carefully. In 0.6.1 this feature was in beta and required opting-in, but is now enabled by default. This can be disabled via the `"disable_clustering"` parameter in -Vault's [config](/docs/configuration), or +Vault's [config](/vault/docs/configuration), or per-request with the `X-Vault-No-Request-Forwarding` header. ## AppRole Role Constraints diff --git a/website/content/docs/upgrading/upgrade-to-0.8.0.mdx b/website/content/docs/upgrading/upgrade-to-0.8.0.mdx index 49bb0300d8..9d18421290 100644 --- a/website/content/docs/upgrading/upgrade-to-0.8.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.8.0.mdx @@ -49,4 +49,4 @@ is performing an explicit reindex. This path was meant to require `sudo` capability but was not implemented this way. It now requires `sudo` capability to run. -[reindex]: /api-docs/system/replication#reindex-replication +[reindex]: /vault/api-docs/system/replication#reindex-replication diff --git a/website/content/docs/upgrading/upgrade-to-0.9.0.mdx b/website/content/docs/upgrading/upgrade-to-0.9.0.mdx index 2db1197f4a..f977bcc91c 100644 --- a/website/content/docs/upgrading/upgrade-to-0.9.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.9.0.mdx @@ -117,5 +117,5 @@ corresponding object containing the `key_type`. Audit request and response entries are still in RFC3339 format but now have a granularity of nanoseconds. -[generate-root]: /api-docs/secret/pki#generate-root -[pkcs11-seal]: /docs/configuration/seal/pkcs11 +[generate-root]: /vault/api-docs/secret/pki#generate-root +[pkcs11-seal]: /vault/docs/configuration/seal/pkcs11 diff --git a/website/content/docs/upgrading/upgrade-to-0.9.3.mdx b/website/content/docs/upgrading/upgrade-to-0.9.3.mdx index 2f2ea7443b..b929e013f2 100644 --- a/website/content/docs/upgrading/upgrade-to-0.9.3.mdx +++ b/website/content/docs/upgrading/upgrade-to-0.9.3.mdx @@ -12,4 +12,4 @@ Due to a rapid release following 0.9.2, there are no version-specific upgrade instructions although any upgrade notices for 0.9.2 apply if you are coming from a previous version. -Please see the [0.9.2 upgrade guide](/docs/upgrading/upgrade-to-0.9.2) for notes on upgrading to 0.9.3. +Please see the [0.9.2 upgrade guide](/vault/docs/upgrading/upgrade-to-0.9.2) for notes on upgrading to 0.9.3. diff --git a/website/content/docs/upgrading/upgrade-to-1.10.x.mdx b/website/content/docs/upgrading/upgrade-to-1.10.x.mdx index 105b1b846d..e5b941f951 100644 --- a/website/content/docs/upgrading/upgrade-to-1.10.x.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.10.x.mdx @@ -26,10 +26,10 @@ was deprecated with the release of [Etcd v3.5](https://etcd.io/blog/2021/announc and will be decommissioned in a forthcoming Etcd release. Users of the `etcd` storage backend with the etcdv2 API that are -upgrading to Vault 1.10 should [migrate](/docs/commands/operator/migrate) +upgrading to Vault 1.10 should [migrate](/vault/docs/commands/operator/migrate) Vault storage to an Etcd v3 cluster prior to upgrading to Vault 1.10. All storage migrations should have -[backups](/docs/concepts/storage#backing-up-vault-s-persisted-data) +[backups](/vault/docs/concepts/storage#backing-up-vault-s-persisted-data) taken prior to migration. ## OTP Generation Process @@ -41,7 +41,7 @@ of the change in the prefix from hvs. to s. for service tokens. ## New error response for requests to perf standbys lagging behind active node -The introduction of [Server Side Consistent Tokens](/docs/faq/ssct) means that +The introduction of [Server Side Consistent Tokens](/vault/docs/faq/ssct) means that when issuing a request to a perf standby right after having obtained a token (e.g. via login), if the token and its lease haven't yet been replicated to the perf standby, an HTTP 412 error will be returned. Before 1.10.0 this typically would've @@ -59,11 +59,11 @@ Additionally, non-root service tokens are now longer than before. Previously, se were 26 characters; they now have a minimum of 95 characters. However, existing tokens will still work. -Refer to the [Server Side Consistent Token FAQ](/docs/faq/ssct) for details. +Refer to the [Server Side Consistent Token FAQ](/vault/docs/faq/ssct) for details. ## OIDC Provider Built-in Resources -In Vault 1.9, the [OIDC identity provider](/docs/secrets/identity/oidc-provider) feature +In Vault 1.9, the [OIDC identity provider](/vault/docs/secrets/identity/oidc-provider) feature was released as a tech preview. In Vault 1.10, built-in resources were introduced to the OIDC provider system to reduce configuration steps and enhance usability. @@ -75,14 +75,14 @@ The following built-in resources are included in each Vault namespace starting w - An `allow_all` assignment which authorizes all Vault entities to authenticate via a client application -If you created an [OIDC provider](/api-docs/secret/identity/oidc-provider#create-or-update-a-provider) -with the name `default`, [key](/api-docs/secret/identity/tokens#create-a-named-key) with the -name `default`, or [assignment](/api-docs/secret/identity/oidc-provider#create-or-update-an-assignment) +If you created an [OIDC provider](/vault/api-docs/secret/identity/oidc-provider#create-or-update-a-provider) +with the name `default`, [key](/vault/api-docs/secret/identity/tokens#create-a-named-key) with the +name `default`, or [assignment](/vault/api-docs/secret/identity/oidc-provider#create-or-update-an-assignment) with the name `allow_all` using the Vault 1.9 tech preview, the installation of these built-in resources will be skipped. We _strongly recommend_ that you delete any existing resources that have naming collisions before upgrading to Vault 1.10. Failing to delete resources with naming collisions could result unexpected default behavior. Additionally, we recommend reading -the corresponding details in the OIDC provider [concepts](/docs/concepts/oidc-provider) document +the corresponding details in the OIDC provider [concepts](/vault/docs/concepts/oidc-provider) document to understand how the built-in resources are used in the system. ## Known Issues @@ -93,7 +93,7 @@ to understand how the built-in resources are used in the system. ### Errors returned by perf standbys lagging behind active node with Consul storage -The introduction of [Server Side Consistent Tokens](/docs/faq/ssct) means that +The introduction of [Server Side Consistent Tokens](/vault/docs/faq/ssct) means that when issuing a request to a perf standby right after having obtained a token (e.g. via login), if the token and its lease haven't yet been replicated to the perf standby, an HTTP 412 error will be returned. Before 1.10.0 this wouldn't have @@ -101,9 +101,9 @@ resulted in the client seeing errors with Consul storage. ### Single Vault follower restart causes election even with established quorum -We now support Server Side Consistent Tokens (See [Replication](/docs/configuration/replication) and [Vault Eventual Consistency](/docs/enterprise/consistency)), which introduces a new token format that can only be used on nodes of 1.10 or higher version. This new format is enabled by default upon upgrading to the new version. Old format tokens can be read by Vault 1.10, but the new format Vault 1.10 tokens cannot be read by older Vault versions. +We now support Server Side Consistent Tokens (See [Replication](/vault/docs/configuration/replication) and [Vault Eventual Consistency](/vault/docs/enterprise/consistency)), which introduces a new token format that can only be used on nodes of 1.10 or higher version. This new format is enabled by default upon upgrading to the new version. Old format tokens can be read by Vault 1.10, but the new format Vault 1.10 tokens cannot be read by older Vault versions. -For more details, see the [Server Side Consistent Tokens FAQ](/docs/faq/ssct). +For more details, see the [Server Side Consistent Tokens FAQ](/vault/docs/faq/ssct). Since service tokens are always created on the leader, as long as the leader is not upgraded before performance standbys, service tokens will be of the old format and still be usable during the upgrade process. However, the usual upgrade process we recommend can't be relied upon to always upgrade the leader last. Due to this known [issue](https://github.com/hashicorp/vault/issues/14153), a Vault cluster using Integrated Storage may result in a leader not being upgraded last, and this can trigger a re-election. This re-election can cause the upgraded node to become the leader, resulting in the newly created tokens on the leader to be unusable on nodes that have not yet been upgraded. Note that this issue does not impact Vault OSS users. @@ -121,7 +121,7 @@ When adding or modifying a Duo MFA method for step-up Enterprise MFA using the ` Signing in to the Vault UI using an OIDC auth mount listed in the "tabs" of the form will result in the following error: "Authentication failed: role with oidc role_type is not allowed". -The auth mounts listed in the "tabs" of the form are those that have [listing_visibility](/api-docs/system/auth#listing_visibility-1) +The auth mounts listed in the "tabs" of the form are those that have [listing_visibility](/vault/api-docs/system/auth#listing_visibility-1) set to `unauth`. There is a workaround for this error that will allow you to sign in to Vault using the OIDC diff --git a/website/content/docs/upgrading/upgrade-to-1.11.x.mdx b/website/content/docs/upgrading/upgrade-to-1.11.x.mdx index fc160e5dcf..3f04003906 100644 --- a/website/content/docs/upgrading/upgrade-to-1.11.x.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.11.x.mdx @@ -16,7 +16,7 @@ for Vault 1.11.x compared to 1.10. Please read it carefully. The Elaticsearch Database Secrets Engine now uses the new `/_security` base API path instead of `/_xpack/security` when managing Elasticsearch. If users are on an Elasticsearch version prior to 6, they will need to switch back to the old -API path by setting the [bool config option](/api-docs/secret/databases/elasticdb#use_old_xpack) +API path by setting the [bool config option](/vault/api-docs/secret/databases/elasticdb#use_old_xpack) `use_old_xpack=true`. ## Changes diff --git a/website/content/docs/upgrading/upgrade-to-1.12.x.mdx b/website/content/docs/upgrading/upgrade-to-1.12.x.mdx index e0019b8684..639656edfd 100644 --- a/website/content/docs/upgrading/upgrade-to-1.12.x.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.12.x.mdx @@ -70,9 +70,9 @@ remediations if you have any affected mounts: * Upgrade Vault directly to 1.12.2 once released * Upgrade to an external version of the plugin before upgrading to 1.12.1; - * Using the [tune API](/api-docs/system/auth#tune-auth-method) for auth methods - * Using the [tune API](/api-docs/system/mounts#tune-mount-configuration) for secrets plugins - * Or using the [configure connection](/api-docs/secret/databases#configure-connection) + * Using the [tune API](/vault/api-docs/system/auth#tune-auth-method) for auth methods + * Using the [tune API](/vault/api-docs/system/mounts#tune-mount-configuration) for secrets plugins + * Or using the [configure connection](/vault/api-docs/secret/databases#configure-connection) API for database plugins * Unmount and remount the path without a version specified before upgrading to 1.12.1. **Note:** This will delete all data and leases associated with the mount. @@ -111,13 +111,13 @@ app-id auth v1.12.0+builtin.vault ``` The remediation for affected mounts is to set the -[VAULT_ALLOW_PENDING_REMOVAL_MOUNTS](/docs/commands/server#vault_allow_pending_removal_mounts) +[VAULT_ALLOW_PENDING_REMOVAL_MOUNTS](/vault/docs/commands/server#vault_allow_pending_removal_mounts) environment variable and replace any `Pending Removal` feature with the [preferred alternative -feature](/docs/deprecation/faq#q-what-should-i-do-if-i-use-mount-filters-appid-or-any-of-the-standalone-db-engines). +feature](/vault/docs/deprecation/faq#q-what-should-i-do-if-i-use-mount-filters-appid-or-any-of-the-standalone-db-engines). For more information on the phases of deprecation, see the [Deprecation Notices -FAQ](/docs/deprecation/faq#q-what-are-the-phases-of-deprecation). +FAQ](/vault/docs/deprecation/faq#q-what-are-the-phases-of-deprecation). #### Impacted Versions @@ -127,7 +127,7 @@ are unaffected. ### `vault plugin list` fails when audit logging is enabled If audit logging is enabled, Vault will fail to audit the response from any -calls to the [`GET /v1/sys/plugins/catalog`](/api-docs/system/plugins-catalog#list-plugins) +calls to the [`GET /v1/sys/plugins/catalog`](/vault/api-docs/system/plugins-catalog#list-plugins) endpoint, which causes the whole request to fail and return a 500 internal server error. From the CLI, this looks like the following: @@ -147,7 +147,7 @@ It will produce errors in Vault Server's logs such as: | ``` -As a workaround, [listing plugins by type](/api-docs/system/plugins-catalog#list-plugins-1) +As a workaround, [listing plugins by type](/vault/api-docs/system/plugins-catalog#list-plugins-1) will succeed: * `vault list sys/plugins/catalog/auth` diff --git a/website/content/docs/upgrading/upgrade-to-1.3.0.mdx b/website/content/docs/upgrading/upgrade-to-1.3.0.mdx index 2731b689b3..dac71b5095 100644 --- a/website/content/docs/upgrading/upgrade-to-1.3.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.3.0.mdx @@ -42,9 +42,9 @@ reauthenticate. ## Filtered Mount Replication Deprecation As of 1.3.0, paths that were once filtered with -[Filtered Mount Replication](/api-docs/system/replication/replication-performance#create-mounts-filter-deprecated) +[Filtered Mount Replication](/vault/api-docs/system/replication/replication-performance#create-mounts-filter-deprecated) are migrated to use -[Filtered Paths Replication](/api-docs/system/replication/replication-performance#create-paths-filter). +[Filtered Paths Replication](/vault/api-docs/system/replication/replication-performance#create-paths-filter). The APIs are very similar, but as of 1.3.0, we have marked the mount filter API as deprecated and recommend migrating to the path filter API, as the mount filter API will be removed in a future version of Vault. diff --git a/website/content/docs/upgrading/upgrade-to-1.5.0.mdx b/website/content/docs/upgrading/upgrade-to-1.5.0.mdx index e32f903f2c..676a06cf56 100644 --- a/website/content/docs/upgrading/upgrade-to-1.5.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.5.0.mdx @@ -15,7 +15,7 @@ for Vault 1.5.0 compared to 1.4.1. Please read it carefully. The deprecated `credentials_file` config option has been removed. The `GOOGLE_APPLICATION_CREDENTIALS` environment variable or default credentials may be used instead. See -[GCS Authentication](https://www.vaultproject.io/docs/configuration/storage/google-cloud-storage#gcs-authentication) +[GCS Authentication](/vault/docs/configuration/storage/google-cloud-storage#gcs-authentication) for details on supported options. ## Raft Configuration @@ -29,12 +29,12 @@ configuration is 1MiB. In addition, a new metric has been introduced, `vault.raft-storage.entry_size`, that allows for operators to sample the entry size, view the average, and adjust the configuration value as necessary. For additional details, please see -[Raft configuration](/docs/configuration/storage/raft). +[Raft configuration](/vault/docs/configuration/storage/raft). ## Enabling telemetry on 32-bit systems will cause Vault to crash. A workaround for this issue is to disable collection of usage gauges in -the [telemetry](/docs/configuration/telemetry) stanza of the configuration. +the [telemetry](/vault/docs/configuration/telemetry) stanza of the configuration. ``` telemetry { @@ -55,7 +55,7 @@ modified to make this operation impossible. The metrics collection process crash this while counting the number of KV secrets. A workaround for this issue is to disable collection of usage gauges in -the [telemetry](/docs/configuration/telemetry) stanza of the configuration. +the [telemetry](/vault/docs/configuration/telemetry) stanza of the configuration. ``` telemetry { @@ -69,7 +69,7 @@ This will disable all the metrics listed in the previous section. Or, set the en ## Non-string values in seal config prevent startup -Any values in the [Seal configuration stanza](/docs/configuration/seal) +Any values in the [Seal configuration stanza](/vault/docs/configuration/seal) that are not quoted strings yield a parse error of the form: ``` diff --git a/website/content/docs/upgrading/upgrade-to-1.6.0.mdx b/website/content/docs/upgrading/upgrade-to-1.6.0.mdx index aca95ad35f..6660b5089c 100644 --- a/website/content/docs/upgrading/upgrade-to-1.6.0.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.6.0.mdx @@ -33,13 +33,13 @@ modifications via replication. ## Database Engine Interface Upgrade The Database Engine has changed the underlying interface between Vault and each database -implementation. This change allows use of [password policies](/docs/concepts/password-policies) +implementation. This change allows use of [password policies](/vault/docs/concepts/password-policies) within the Database engine. The API for the Database Engine has not changed, only the underlying interface between Vault and the database plugins. All built-in database plugins (as well as the [Oracle](https://github.com/hashicorp/vault-plugin-database-oracle) plugin) have been upgraded to the new interface so no user actions are needed. Vault will continue to recognize existing custom database plugins but the old interface should be considered deprecated and may be removed in a -future release. See our [upgrade guide for custom databases](/docs/secrets/databases/custom) for +future release. See our [upgrade guide for custom databases](/vault/docs/secrets/databases/custom) for more information on upgrading custom database plugins. @include 'alpine-314.mdx' diff --git a/website/content/docs/upgrading/upgrade-to-1.7.x.mdx b/website/content/docs/upgrading/upgrade-to-1.7.x.mdx index 325ecac30f..90300d4719 100644 --- a/website/content/docs/upgrading/upgrade-to-1.7.x.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.7.x.mdx @@ -33,7 +33,7 @@ have been updated to more inclusive language (e.g. `/auth/aws/identity-whitelist updated to`/auth/aws/identity-accesslist`). The old and new endpoints are aliases, sharing the same underlying data. The legacy endpoint names are considered **deprecated** and will be removed in a future release (not before Vault 1.9). The complete list of -endpoint changes is available in the [AWS Auth API docs](/api-docs/auth/aws#deprecations-effective-in-vault-1-7). +endpoint changes is available in the [AWS Auth API docs](/vault/api-docs/auth/aws#deprecations-effective-in-vault-1-7). @include 'alpine-314.mdx' diff --git a/website/content/docs/upgrading/upgrade-to-1.8.x.mdx b/website/content/docs/upgrading/upgrade-to-1.8.x.mdx index e047c80e23..fad33d7ccd 100644 --- a/website/content/docs/upgrading/upgrade-to-1.8.x.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.8.x.mdx @@ -15,14 +15,14 @@ for Vault 1.8.x compared to 1.7. Please read it carefully. Licenses and EULA enhancements have been introduced in the Vault 1.8 release. These changes are important for Enterprise customers to review. They do not affect -OSS users. Please see the [License](/docs/enterprise/license) documentation for more details. +OSS users. Please see the [License](/vault/docs/enterprise/license) documentation for more details. ## Deprecations The following API endpoints have been deprecated and will be removed in a future release: * `sys/license` to manage licenses in storage; it is recommended to use - [License Autoloading](/docs/enterprise/license/autoloading) instead. + [License Autoloading](/vault/docs/enterprise/license/autoloading) instead. * `/gcp/token/:roleset` and `/gcp/key/:roleset` paths for generating secrets for rolesets in GCP Secrets. Use `/gcp/roleset/:roleset/token` and `/gcp/roleset/:roleset/key` instead. @@ -59,7 +59,7 @@ Vault Enterprise binaries for `arm64` architectures will crash immediately when ### AWS auth -AWS Auth using the [EC2 method](https://www.vaultproject.io/docs/auth/aws#ec2-auth-method) fails with the error `failed to verify the signature`. This effects 1.8.0 and 1.8.1 and there is not a workaround. The issue was fixed in Vault 1.8.2. +AWS Auth using the [EC2 method](/vault/docs/auth/aws#ec2-auth-method) fails with the error `failed to verify the signature`. This effects 1.8.0 and 1.8.1 and there is not a workaround. The issue was fixed in Vault 1.8.2. ### Configuration files in RedHat packages @@ -68,4 +68,4 @@ the defaults when a new package was installed. This [issue](https://github.com/h ### Introduction of rolesets -The introduction of `/gcp/roleset/:roleset/token` and `/gcp/roleset/:roleset/key` could inadvertently give users the ability to generate tokens and key if globs are used in policies. To avoid issues like this, globs should be avoided in policies to help adhere to the principle of least privilege. See the [roleset documentation](/docs/secrets/gcp#rolesets) for more information. +The introduction of `/gcp/roleset/:roleset/token` and `/gcp/roleset/:roleset/key` could inadvertently give users the ability to generate tokens and key if globs are used in policies. To avoid issues like this, globs should be avoided in policies to help adhere to the principle of least privilege. See the [roleset documentation](/vault/docs/secrets/gcp#rolesets) for more information. diff --git a/website/content/docs/upgrading/upgrade-to-1.9.x.mdx b/website/content/docs/upgrading/upgrade-to-1.9.x.mdx index 90ea40f6ec..1de7388f5d 100644 --- a/website/content/docs/upgrading/upgrade-to-1.9.x.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.9.x.mdx @@ -14,14 +14,14 @@ for Vault 1.9.x compared to 1.8. Please read it carefully. ## OIDC Provider Vault 1.9.0 introduced the ability for Vault to be an OpenID Connect (OIDC) identity -provider. To support the feature, Vault's [default policy](https://www.vaultproject.io/docs/concepts/policies#default-policy) +provider. To support the feature, Vault's [default policy](/vault/docs/concepts/policies#default-policy) was modified to include an ACL rule for its Authorization Endpoint. Due to the handling of Vault's default policy during upgrades, existing deployments of Vault that are upgraded to 1.9.0 will not have this required ACL rule. If you're upgrading to 1.9.0 and want to use the new OIDC provider feature, the following ACL rule must be added to the default policy **or** a policy associated with the Vault -[Auth Method](https://www.vaultproject.io/docs/auth) used to authenticate end-users during +[Auth Method](/vault/docs/auth) used to authenticate end-users during the OIDC flow. ```hcl @@ -38,14 +38,14 @@ token roles. When creating a role, the key parameter is required and the key must exist. Previously, it was possible to create a role and assign it a named key that did not yet exist despite the documentation stating otherwise. -All calls to [create or update a role](https://www.vaultproject.io/api-docs/secret/identity/tokens#create-or-update-a-role) +All calls to [create or update a role](/vault/api-docs/secret/identity/tokens#create-or-update-a-role) must be checked to ensure that roles are not being created or updated with non-existent keys. ## SSH Role Parameter `allowed_extensions` Behavior Change Prior versions of Vault allowed clients to specify any extension when requesting -SSH certificate [signing requests](https://www.vaultproject.io/api-docs/secret/ssh#sign-ssh-key) +SSH certificate [signing requests](/vault/api-docs/secret/ssh#sign-ssh-key) if their role had an `allowed_extensions` set to `""` or was missing. Now, Vault will reject a client request that specifies extensions if the role @@ -63,7 +63,7 @@ specified by clients. ### HTTP Request Counter Deprecation In Vault 1.9, the internal HTTP Request count -[API](https://www.vaultproject.io/api-docs/v1.8.x/system/internal-counters#http-requests) +[API](/vault/api-docs/v1.8.x/system/internal-counters#http-requests) will be 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`. @@ -80,9 +80,9 @@ v3.5](https://etcd.io/blog/2021/announcing-etcd-3.5/), and will be decommissioned in the Etcd v3.6 release. Users upgrading to Vault 1.9 and planning to eventually upgrade to Vault 1.10 -should prepare to [migrate](/docs/commands/operator/migrate) Vault storage to +should prepare to [migrate](/vault/docs/commands/operator/migrate) Vault storage to an Etcd v3 cluster prior to upgrading to Vault 1.10. All storage migrations -should have [backups](/docs/concepts/storage#backing-up-vault-s-persisted-data) +should have [backups](/vault/docs/concepts/storage#backing-up-vault-s-persisted-data) taken prior to migration. ## TLS Cipher Suites Changes @@ -105,8 +105,8 @@ See [this blog post](https://go.dev/blog/tls-cipher-suites) for more information ### Identity Token Backend Key Rotations Existing Vault installations that use the [Identity Token -backend](/api-docs/secret/identity/tokens) and have [named -keys](/api-docs/secret/identity/tokens#create-a-named-key) generated will +backend](/vault/api-docs/secret/identity/tokens) and have [named +keys](/vault/api-docs/secret/identity/tokens#create-a-named-key) generated will encounter a panic when any of those existing keys pass their `rotation_period`. This issue affects Vault 1.9.0, and is fixed in Vault 1.9.1. Users should upgrade directly to 1.9.1 or above in order to avoid this panic. diff --git a/website/content/docs/use-cases.mdx b/website/content/docs/use-cases.mdx index 54fc0971c8..4cc350c11d 100644 --- a/website/content/docs/use-cases.mdx +++ b/website/content/docs/use-cases.mdx @@ -8,7 +8,7 @@ description: >- # Use Cases -[HashiCorp Vault](/docs/what-is-vault) is an identity-based secrets and encryption management system. Vault validates and authorizes clients (users, machines, apps) before providing them access to secrets or stored sensitive data. +[HashiCorp Vault](/vault/docs/what-is-vault) is an identity-based secrets and encryption management system. Vault validates and authorizes clients (users, machines, apps) before providing them access to secrets or stored sensitive data. This page describes common Vault use cases and provides related resources that can be used to create Vault configurations and workflows. Please note that not all use cases may be listed. @@ -21,43 +21,43 @@ With Vault, you can generate short-lived, just-in-time credentials that are auto Credentials can be long-lived and static, where they don't change or are changed infrequently. Vault can store these secrets bedhind its cryptographic barrier, and clients can request them to use in their applications. -- Refer to the [Versioned Key/Vault Secrets Engine](https://learn.hashicorp.com/tutorials/vault/versioned-kv?in=vault/secrets-management) tutorial and learn how a versioned key-value secrets engine protects your static secrets. +- Refer to the [Versioned Key/Vault Secrets Engine](/vault/tutorials/secrets-management/versioned-kv) tutorial and learn how a versioned key-value secrets engine protects your static secrets. ### Dynamic Secrets The key value with secrets storage is the ability to dynamically generate credentials. These credentials are created when clients need them. Vault can also manage the lifecycle of these credentials, including but not limited to, deleting them after a defined period of time. -- Refer to the [Dynamic Secrets: Database Secrets Engine](https://learn.hashicorp.com/tutorials/vault/database-secrets) tutorial and learn how Vault can dynamically manage your database credentials. +- Refer to the [Dynamic Secrets: Database Secrets Engine](/vault/tutorials/db-credentials/database-secrets) tutorial and learn how Vault can dynamically manage your database credentials. -In addition to database credential management, Vault can manage your Active Directory accounts, SSH keys, PKI certificates and more. Visit the [Secrets Management](https://learn.hashicorp.com/collections/vault/secrets-management) tutorial series to learn more about secrets management using Vault. +In addition to database credential management, Vault can manage your Active Directory accounts, SSH keys, PKI certificates and more. Visit the [Secrets Management](/vault/tutorials/secrets-management) tutorial series to learn more about secrets management using Vault. ## Data Encryption -Many organizations seek solutions to encrypt/decrypt application data within a cloud or multi-datacenter environment; deploying cryptography and maintaining a complex key management infrastructure can be expensive and challenging to develop. Vault provides [encryption as a service](/docs/secrets/transit) with centralized key management to simplify encrypting data in transit and stored across clouds and datacenters. Vault can encrypt/decrypt data stored elsewhere, essentially allowing applications to encrypt their data while storing it in the primary data store. Vault's security team manages and maintains the responsibility of the data encryption within the Vault environment, allowing developers to focus solely on encrypting/decrypting data as needed. +Many organizations seek solutions to encrypt/decrypt application data within a cloud or multi-datacenter environment; deploying cryptography and maintaining a complex key management infrastructure can be expensive and challenging to develop. Vault provides [encryption as a service](/vault/docs/secrets/transit) with centralized key management to simplify encrypting data in transit and stored across clouds and datacenters. Vault can encrypt/decrypt data stored elsewhere, essentially allowing applications to encrypt their data while storing it in the primary data store. Vault's security team manages and maintains the responsibility of the data encryption within the Vault environment, allowing developers to focus solely on encrypting/decrypting data as needed. ### Resources -- Try our [Encryption as a Service: Transit Secrets Engine](https://learn.hashicorp.com/collections/vault/encryption-as-a-service) to learn the essential workings of the Transit secrets engine handles cryptographic functions on data in-transit. +- Try our [Encryption as a Service: Transit Secrets Engine](/vault/tutorials/encryption-as-a-service) to learn the essential workings of the Transit secrets engine handles cryptographic functions on data in-transit. -- For more advanced data protection, refer to the [Advanced Data Protection](https://learn.hashicorp.com/collections/vault/adp) tutorial series. Vault's Transform secrets engine handles secure data transformation and tokenization against provided input value. +- For more advanced data protection, refer to the [Advanced Data Protection](/vault/tutorials/adp) tutorial series. Vault's Transform secrets engine handles secure data transformation and tokenization against provided input value. ## Identity-Based Access -Organizations need a way to manage identity sprawl with the proliferation of different clouds, services, and systems- all with their identity providers. The risk of compromising an organization's security infrastructure increases as organizations are forced to manage multiple identity management systems as they try to implement solutions to unify a single logical identity across numerous cloud platforms. Different platforms support different methods and constructs for identity, making it difficult to recognize a user or identity across multiple forms of credentials. Vault solves this challenge by using a unified ACL system to broker access to systems and secrets and merges identities across providers. With [identity-based access](/docs/secrets/identity), organizations can leverage any trusted resource identity to regulate and manage system and application access, and authentication across various clouds, systems, and endpoints. +Organizations need a way to manage identity sprawl with the proliferation of different clouds, services, and systems- all with their identity providers. The risk of compromising an organization's security infrastructure increases as organizations are forced to manage multiple identity management systems as they try to implement solutions to unify a single logical identity across numerous cloud platforms. Different platforms support different methods and constructs for identity, making it difficult to recognize a user or identity across multiple forms of credentials. Vault solves this challenge by using a unified ACL system to broker access to systems and secrets and merges identities across providers. With [identity-based access](/vault/docs/secrets/identity), organizations can leverage any trusted resource identity to regulate and manage system and application access, and authentication across various clouds, systems, and endpoints. ### Resources -- Try our [Identity: Entities and Groups](https://learn.hashicorp.com/tutorials/vault/identity) tutorial to learn how Vault's unified identity system works. +- Try our [Identity: Entities and Groups](/vault/tutorials/auth-methods/identity) tutorial to learn how Vault's unified identity system works. -- Follow the [Policies](https://learn.hashicorp.com/collections/vault/policies) tutorial series to learn how Vault enforces role-based access control (RBAC) across multiple cloud environments. +- Follow the [Policies](/vault/tutorials/policies) tutorial series to learn how Vault enforces role-based access control (RBAC) across multiple cloud environments. ## Key Management -Working with cloud providers requires that you use their security features, which involve encryption keys issued and stored by the provider in its own key management system (KMS). You may also have a requirement to maintain root of trust and control of the encryption key lifecycle, both within and outside of the cloud. The [Vault Key Management Secrets Engine](/docs/secrets/key-management) provides a consistent workflow for distribution and lifecycle management of cloud provider keys, allowing organizations to maintain centralized control of their keys in Vault while leveraging the cryptographic capabilities native to the KMS providers. +Working with cloud providers requires that you use their security features, which involve encryption keys issued and stored by the provider in its own key management system (KMS). You may also have a requirement to maintain root of trust and control of the encryption key lifecycle, both within and outside of the cloud. The [Vault Key Management Secrets Engine](/vault/docs/secrets/key-management) provides a consistent workflow for distribution and lifecycle management of cloud provider keys, allowing organizations to maintain centralized control of their keys in Vault while leveraging the cryptographic capabilities native to the KMS providers. ### Resources -- Try our [Key Management Secrets Engine with Azure Key Vault](https://learn.hashicorp.com/tutorials/vault/key-management-secrets-engine-azure-key-vault?in=vault/adp) to enable management of the Key Vault key with the Key Management secrets engine. +- Try our [Key Management Secrets Engine with Azure Key Vault](/vault/tutorials/adp/key-management-secrets-engine-azure-key-vault) to enable management of the Key Vault key with the Key Management secrets engine. -- Try our [Key Management Secrets Engine with GCP Cloud KMS](https://learn.hashicorp.com/tutorials/vault/key-management-secrets-engine-azure-key-vault?in=vault/adp) to enable management of the Key Value key with the Key Management secrets engine. +- Try our [Key Management Secrets Engine with GCP Cloud KMS](/vault/tutorials/adp/key-management-secrets-engine-azure-key-vault) to enable management of the Key Value key with the Key Management secrets engine. diff --git a/website/content/docs/what-is-vault.mdx b/website/content/docs/what-is-vault.mdx index d4154325d0..69c7dd55a9 100644 --- a/website/content/docs/what-is-vault.mdx +++ b/website/content/docs/what-is-vault.mdx @@ -70,13 +70,13 @@ The key features of Vault are: Revocation assists in key rolling as well as locking down systems in the case of an intrusion. --> **Tip**: Learn more about Vault [use cases](/docs/use-cases). +-> **Tip**: Learn more about Vault [use cases](/vault/docs/use-cases). ### What is HCP Vault? -HashiCorp Cloud Platform (HCP) Vault is a hosted version of Vault, which is operated by HashiCorp to allow organizations to get up and running quickly. HCP Vault uses the same binary as self-hosted Vault, which means you will have a consistent user experience. You can use the same Vault clients to communicate with HCP Vault as you use to communicate with a self-hosted Vault. Refer to the [HCP Vault](https://cloud.hashicorp.com/docs/vault) documentation to learn more. +HashiCorp Cloud Platform (HCP) Vault is a hosted version of Vault, which is operated by HashiCorp to allow organizations to get up and running quickly. HCP Vault uses the same binary as self-hosted Vault, which means you will have a consistent user experience. You can use the same Vault clients to communicate with HCP Vault as you use to communicate with a self-hosted Vault. Refer to the [HCP Vault](/hcp/docs/vault) documentation to learn more. --> **Hands On:** Try the [Get started](https://learn.hashicorp.com/collections/vault/cloud) tutorials to set up a managed Vault cluster. +-> **Hands On:** Try the [Get started](/vault/tutorials/cloud) tutorials to set up a managed Vault cluster. ### Community diff --git a/website/content/partials/aws-sha1-deprecation.mdx b/website/content/partials/aws-sha1-deprecation.mdx index 28b762cbad..fb05450db6 100644 --- a/website/content/partials/aws-sha1-deprecation.mdx +++ b/website/content/partials/aws-sha1-deprecation.mdx @@ -1,5 +1,5 @@ ~> **Note**: Starting in Vault 1.12, only the `pkcs7` login flow with the AWS [`/rsa2048` signature endpoint](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/verify-rsa2048.html) credentials will work by default due to the deprecation of SHA-1-based signatures. - Please see [the deprecation FAQ](/docs/deprecation/faq#q-what-is-the-impact-of-removing-support-for-x-509-certificates-with-signatures-that-use-sha-1) + Please see [the deprecation FAQ](/vault/docs/deprecation/faq#q-what-is-the-impact-of-removing-support-for-x-509-certificates-with-signatures-that-use-sha-1) for more details and a workaround. diff --git a/website/content/partials/consul-dataplane-compat.mdx b/website/content/partials/consul-dataplane-compat.mdx index 8b039a1953..e9a71997e8 100644 --- a/website/content/partials/consul-dataplane-compat.mdx +++ b/website/content/partials/consul-dataplane-compat.mdx @@ -1 +1 @@ -~> **Compatibility information:** As of Consul 1.14.0, Consul on Kubernetes uses [Consul Dataplane](https://developer.hashicorp.com/consul/docs/connect/dataplane) by default instead of client agents. Vault does not currently support Consul Dataplane. Please follow the Consul 1.14.0 [upgrade guide](https://developer.hashicorp.com/consul/docs/k8s/upgrade#upgrading-to-consul-dataplane) to ensure that your Consul on Kubernetes deployment continues to use client agents. +~> **Compatibility information:** As of Consul 1.14.0, Consul on Kubernetes uses [Consul Dataplane](/consul/docs/connect/dataplane) by default instead of client agents. Vault does not currently support Consul Dataplane. Please follow the Consul 1.14.0 [upgrade guide](/consul/docs/k8s/upgrade#upgrading-to-consul-dataplane) to ensure that your Consul on Kubernetes deployment continues to use client agents. diff --git a/website/content/partials/consul-dataplane-upgrade-note.mdx b/website/content/partials/consul-dataplane-upgrade-note.mdx index d4a6d31f6e..060e23222f 100644 --- a/website/content/partials/consul-dataplane-upgrade-note.mdx +++ b/website/content/partials/consul-dataplane-upgrade-note.mdx @@ -1,2 +1,2 @@ ### Consul Dataplane Compatibility -If you are using Consul on Kubernetes, please be aware that upgrading to Consul 1.14.0 will impact Consul [secrets](/docs/secrets/consul), [storage](/docs/configuration/storage/consul), and [service registration](/docs/configuration/service-registration/consul). As of Consul 1.14.0, Consul on Kubernetes uses [Consul Dataplane](https://developer.hashicorp.com/consul/docs/connect/dataplane) by default instead of client agents. Vault does not currently support Consul Dataplane. Please follow the Consul 1.14.0 [upgrade guide](https://developer.hashicorp.com/consul/docs/k8s/upgrade#upgrading-to-consul-dataplane) to ensure that your Consul on Kubernetes deployment continues to use client agents. +If you are using Consul on Kubernetes, please be aware that upgrading to Consul 1.14.0 will impact Consul [secrets](/vault/docs/secrets/consul), [storage](/vault/docs/configuration/storage/consul), and [service registration](/vault/docs/configuration/service-registration/consul). As of Consul 1.14.0, Consul on Kubernetes uses [Consul Dataplane](/consul/docs/connect/dataplane) by default instead of client agents. Vault does not currently support Consul Dataplane. Please follow the Consul 1.14.0 [upgrade guide](/consul/docs/k8s/upgrade#upgrading-to-consul-dataplane) to ensure that your Consul on Kubernetes deployment continues to use client agents. diff --git a/website/content/partials/db-secrets-credential-types.mdx b/website/content/partials/db-secrets-credential-types.mdx index 3da4eb93d7..aaa21c9ba1 100644 --- a/website/content/partials/db-secrets-credential-types.mdx +++ b/website/content/partials/db-secrets-credential-types.mdx @@ -8,9 +8,9 @@ The following options are available for each `credential_type` value: - `password` - - `password_policy` `(string: )` - The [policy](/docs/concepts/password-policies) + - `password_policy` `(string: )` - The [policy](/vault/docs/concepts/password-policies) used for password generation. If not provided, defaults to the password policy of the - database [configuration](/api-docs/secret/databases#password_policy). + database [configuration](/vault/api-docs/secret/databases#password_policy). - `rsa_private_key` - `key_bits` `(int: 2048)` - The bit size of the RSA key to generate. Options include: diff --git a/website/content/partials/raft-large-snapshots.mdx b/website/content/partials/raft-large-snapshots.mdx index aeafacee6c..d06cf7ea0f 100644 --- a/website/content/partials/raft-large-snapshots.mdx +++ b/website/content/partials/raft-large-snapshots.mdx @@ -2,5 +2,5 @@ Taking and restoring Raft snapshots can exceed Vault's default and recommended timeout settings. The -[`VAULT_CLIENT_TIMEOUT`](/docs/commands#vault_client_timeout) environment variable can +[`VAULT_CLIENT_TIMEOUT`](/vault/docs/commands#vault_client_timeout) environment variable can be used to allow for more time to take or restore a snapshot. diff --git a/website/content/partials/raft-retry-join-failure.mdx b/website/content/partials/raft-retry-join-failure.mdx index 2b5a95783f..47b66912c6 100644 --- a/website/content/partials/raft-retry-join-failure.mdx +++ b/website/content/partials/raft-retry-join-failure.mdx @@ -1,12 +1,12 @@ ### Cluster initialization hangs with `retry_join` The -[`retry_join`](/docs/concepts/integrated-storage/index#retry_join-configuration) +[`retry_join`](/vault/docs/concepts/integrated-storage/index#retry_join-configuration) feature no longer successfully attempts to rejoin the raft cluster every 2 seconds following a join failure. The error occurs when attempting to initialize non-leader nodes with a -[`retry_join` stanza](/docs/configuration/storage/raft/#retry_join-stanza). This +[`retry_join` stanza](/vault/docs/configuration/storage/raft/#retry_join-stanza). This affects multi-node raft clusters on [impacted versions](#impacted-versions). The bug was introduced by commit diff --git a/website/content/partials/tokenstorefields.mdx b/website/content/partials/tokenstorefields.mdx index 6d6ab365ea..a74b936715 100644 --- a/website/content/partials/tokenstorefields.mdx +++ b/website/content/partials/tokenstorefields.mdx @@ -3,7 +3,7 @@ successfully, and ties the resulting token to these blocks as well. - `token_explicit_max_ttl` `(integer: 0 or string: "")` - If set, will encode an [explicit max - TTL](/docs/concepts/tokens#token-time-to-live-periodic-tokens-and-explicit-max-ttls) + TTL](/vault/docs/concepts/tokens#token-time-to-live-periodic-tokens-and-explicit-max-ttls) onto the token. This is a hard cap even if `token_ttl` and `token_max_ttl` would otherwise allow a renewal. - `token_no_default_policy` `(bool: false)` - If set, the `default` policy will @@ -14,7 +14,7 @@ If you require the token to have the ability to create child tokens, you will need to set this value to 0. - `token_period` `(integer: 0 or string: "")` - The - [period](/docs/concepts/tokens#token-time-to-live-periodic-tokens-and-explicit-max-ttls), + [period](/vault/docs/concepts/tokens#token-time-to-live-periodic-tokens-and-explicit-max-ttls), if any, to set on the token. - `token_type` `(string: "")` - The type of token that should be generated. Can be `service`, `batch`, or `default` to use the mount's tuned default (which diff --git a/website/content/partials/user-lockout.mdx b/website/content/partials/user-lockout.mdx index 6b899a2005..b66fffbfac 100644 --- a/website/content/partials/user-lockout.mdx +++ b/website/content/partials/user-lockout.mdx @@ -15,9 +15,9 @@ The user lockout feature can disabled as follows: - It can be disabled globally using environment variable VAULT_DISABLE_USER_LOCKOUT. - It can be disabled for all supported auth methods (ldap, userpass and approle) or a specific supported auth method using "disable_lockout" parameter within user_lockout stanza in configuration file. - Please see [user lockout configuration](/docs/configuration/user-lockout#user_lockout-stanza) for more details. -- It can be disabled for a specific auth mount using "auth tune". Please see [auth tune command](/docs/commands/auth/tune) -or [auth tune api](/api-docs/system/auth#tune-auth-method) for more details. + Please see [user lockout configuration](/vault/docs/configuration/user-lockout#user_lockout-stanza) for more details. +- It can be disabled for a specific auth mount using "auth tune". Please see [auth tune command](/vault/docs/commands/auth/tune) +or [auth tune api](/vault/api-docs/system/auth#tune-auth-method) for more details. ~> **NOTE**: This feature is available from Vault version 1.13 and is only supported by userpass, ldap and approle auth methods. \ No newline at end of file diff --git a/website/content/partials/x509-sha1-deprecation.mdx b/website/content/partials/x509-sha1-deprecation.mdx index 39a5d75375..ff030daa41 100644 --- a/website/content/partials/x509-sha1-deprecation.mdx +++ b/website/content/partials/x509-sha1-deprecation.mdx @@ -1,5 +1,5 @@ ~> **Note**: This engine can use external X.509 certificates as part of TLS or signature validation. Verifying signatures against X.509 certificates that use SHA-1 is deprecated and is no longer usable without a workaround starting in Vault 1.12. See the - [deprecation FAQ](/docs/deprecation/faq#q-what-is-the-impact-of-removing-support-for-x-509-certificates-with-signatures-that-use-sha-1) + [deprecation FAQ](/vault/docs/deprecation/faq#q-what-is-the-impact-of-removing-support-for-x-509-certificates-with-signatures-that-use-sha-1) for more information. \ No newline at end of file