diff --git a/website/content/api-docs/auth/jwt.mdx b/website/content/api-docs/auth/jwt.mdx index 11e6cc38ce..82445b4b25 100644 --- a/website/content/api-docs/auth/jwt.mdx +++ b/website/content/api-docs/auth/jwt.mdx @@ -34,7 +34,7 @@ set. - `oidc_discovery_ca_pem` `(string: )` - The contents of a CA certificate or chain of certificates, in PEM format, to use to validate connections to the OIDC Discovery URL. If not set, system certificates are used. - `oidc_client_id` `(string: )` - The OAuth Client ID from the provider for OIDC roles. - `oidc_client_secret` `(string: )` - The OAuth Client Secret from the provider for OIDC roles. -- `oidc_response_mode` `(string: )` - The response mode to be used in the OAuth2 request. Allowed values are "query" and "form_post". Defaults to "query". If using Vault namespaces, and oidc_response_mode is "form_post", then "namespace_in_state" should be set to false. +- `oidc_response_mode` `(string: )` - The response mode to be used in the OAuth2 request. Allowed values are "query" and "form_post". Defaults to "query". - `oidc_response_types` `(comma-separated string, or array of strings: )` - The response types to request. Allowed values are "code" and "id_token". Defaults to "code". Note: "id_token" may only be used if "oidc_response_mode" is set to "form_post". - `jwks_url` `(string: )` - JWKS URL to use to authenticate signatures. Cannot be used with "oidc_discovery_url" or "jwt_validation_pubkeys". diff --git a/website/content/api-docs/secret/databases/cassandra.mdx b/website/content/api-docs/secret/databases/cassandra.mdx index 7e169de018..77f90204ca 100644 --- a/website/content/api-docs/secret/databases/cassandra.mdx +++ b/website/content/api-docs/secret/databases/cassandra.mdx @@ -207,12 +207,3 @@ list the plugin does not support that statement type. serialized JSON string array, or a base64-encoded serialized JSON string array. The `{{username}}` value will be substituted. If not provided, defaults to a reasonable default alter user statement. - -~> Prior to Vault 1.7.1 and 1.6.4 the default `root_rotation_statements` does not - allow for usernames with special characters in them due to missing quotes - around the username. To fix this issue in versions prior to Vault 1.7.1/1.6.4, - specify the following `root_rotation_statements`: - - ```sql - ALTER USER '{{username}}' WITH PASSWORD '{{password}}'; - ``` diff --git a/website/content/api-docs/secret/identity/mfa/duo.mdx b/website/content/api-docs/secret/identity/mfa/duo.mdx index 0b1e636551..eb8cfd2912 100644 --- a/website/content/api-docs/secret/identity/mfa/duo.mdx +++ b/website/content/api-docs/secret/identity/mfa/duo.mdx @@ -17,7 +17,7 @@ This endpoint defines an MFA method of type Duo. - `method_id` `(string: "")` - Optional UUID to specify if updating an existing method. -- `method_name` `(string)` - The unique name identifier for this MFA method. Supported from Vault 1.13.0. +- `method_name` `(string)` - The unique name identifier for this MFA method. - `username_format` `(string)` - A template string for mapping Identity names to MFA methods. Values to substitute should be placed in `{{}}`. For example, `"{{identity.entity.name}}"`. If blank, the Entity's Name field is used as-is. diff --git a/website/content/api-docs/secret/identity/mfa/okta.mdx b/website/content/api-docs/secret/identity/mfa/okta.mdx index e28c2ab996..d93ec0a63c 100644 --- a/website/content/api-docs/secret/identity/mfa/okta.mdx +++ b/website/content/api-docs/secret/identity/mfa/okta.mdx @@ -17,7 +17,7 @@ This endpoint defines an MFA method of type Okta. - `method_id` `(string: "")` - Optional UUID to specify if updating an existing method. -- `method_name` `(string)` - The unique name identifier for this MFA method. Supported from Vault 1.13.0. +- `method_name` `(string)` - The unique name identifier for this MFA method. - `username_format` `(string)` - A format string for mapping Identity names to MFA method names. Values to substitute should be placed in `{{}}`. For example, `"{{identity.entity.name}}@example.com"`. If blank, the Entity's Name field is used as-is. diff --git a/website/content/api-docs/secret/identity/mfa/pingid.mdx b/website/content/api-docs/secret/identity/mfa/pingid.mdx index 9942e0ce0a..379f6acc39 100644 --- a/website/content/api-docs/secret/identity/mfa/pingid.mdx +++ b/website/content/api-docs/secret/identity/mfa/pingid.mdx @@ -17,7 +17,7 @@ This endpoint defines an MFA method of type PingID. - `method_id` `(string: "")` - Optional UUID to specify if updating an existing method. -- `method_name` `(string)` - The unique name identifier for this MFA method. Supported from Vault 1.13.0. +- `method_name` `(string)` - The unique name identifier for this MFA method. - `username_format` `(string)` - A template string for mapping Identity names to MFA method names. Values to substitute should be placed in `{{}}`. For example, `"{{identity.entity.name}}@example.com"`. If blank, the Entity's Name field is used as-is. diff --git a/website/content/api-docs/secret/identity/mfa/totp.mdx b/website/content/api-docs/secret/identity/mfa/totp.mdx index e8c272d95c..23e90d861d 100644 --- a/website/content/api-docs/secret/identity/mfa/totp.mdx +++ b/website/content/api-docs/secret/identity/mfa/totp.mdx @@ -17,7 +17,7 @@ This endpoint defines an MFA method of type TOTP. - `method_id` `(string: "")` - Optional UUID to specify if updating an existing method. -- `method_name` `(string)` - The unique name identifier for this MFA method. Supported from Vault 1.13.0. +- `method_name` `(string)` - The unique name identifier for this MFA method. - `issuer` `(string: )` - The name of the key's issuing organization. diff --git a/website/content/api-docs/secret/pki.mdx b/website/content/api-docs/secret/pki.mdx index f3130ab7c3..4a96b35adb 100644 --- a/website/content/api-docs/secret/pki.mdx +++ b/website/content/api-docs/secret/pki.mdx @@ -92,7 +92,7 @@ update your API calls accordingly. ## Notice about new Multi-Issuer functionality -Vault since 1.11.0 allows a single PKI mount to have multiple Certificate +OpenBao allows a single PKI mount to have multiple Certificate Authority (CA) certificates ("issuers") in a single mount, for the purpose of facilitating rotation. All issuers within a single mount are treated as a single Authority, meaning that: @@ -109,14 +109,13 @@ to mix different types of CAs (roots and intermediates). ~> **Note**: Some functionality will not work if a default issuer is not configured. OpenBao automatically selects the default issuer from the - current issuing certificate on migration from an older OpenBao version - (Vault < 1.11.0). + current issuing certificate on migration from an older OpenBao version. ## ACME certificate issuance -Starting with Vault 1.14, OpenBao supports the [ACME certificate lifecycle -management protocol](https://datatracker.ietf.org/doc/html/rfc8555) for issuing -and renewing leaf server certificates. +OpenBao supports the [ACME certificate lifecycle management +protocol](https://datatracker.ietf.org/doc/html/rfc8555) for issuing and +renewing leaf server certificates. In order to use ACME, a [cluster path](#set-cluster-configuration) must be set and ACME must be [enabled in its configuration](#set-acme-configuration) @@ -1519,9 +1518,9 @@ These are unauthenticated endpoints. | `GET` | `/pki/ca_chain` | `default` | PEM [\[1\]](#openbao-cli-with-der-pem-responses "OpenBao CLI With DER/PEM Responses") | | `GET` | `/pki/cert/ca_chain` | `default` | JSON | -~> **Note**: As of Vault 1.11.0, these endpoints now return the full chain - (including the default issuer's certificate and all parent issuers known - to OpenBao) in these responses. +~> **Note**: These endpoints return the full chain (including the default + issuer's certificate and all parent issuers known to OpenBao) in these + responses. #### Sample request @@ -1562,7 +1561,7 @@ Endpoints with source `local` only include cluster-local revocations. These are unauthenticated endpoints. -~> **Note**: As of Vault 1.11.0, these endpoints now serve a [version 2](https://datatracker.ietf.org/doc/html/rfc5280#section-5.1.2.1) CRL response. +~> **Note**: These endpoints now serve a [version 2](https://datatracker.ietf.org/doc/html/rfc5280#section-5.1.2.1) CRL response. ~> Note: this endpoint accepts the `If-Modified-Since` header, to respond with 304 Not Modified when the requested resource has not changed. This header @@ -1718,10 +1717,10 @@ These are unauthenticated endpoints. - `crl` for the _default_ issuer's CRL - `ca_chain` for the _default_ issuer's CA trust chain. -~> **Note**: As of Vault 1.11.0, these endpoints return the full chain +~> **Note**: These endpoints return the full chain (including this certificate and all parent issuers known to OpenBao) in the `ca_chain` response, for both the `certificate` and newer `ca_chain` - fields. The root certificate is no longer elided. + fields. #### Sample request @@ -1879,12 +1878,12 @@ be reused for this root. This generated root will sign its own CRL. Authority Access distribution points use the values set via `config/urls`. -~> **Note**: As of Vault 1.11.0, the PKI Secrets Engine now supports multiple - issuers under a single mount. Use the management operations in this section - to [list](#list-issuers) and [modify issuers](#update-issuer) within this - mount. No issuers will be overridden by calling this operation. Deleting - individual keys and issuers should be preferred to calling `DELETE /pki/root`, - [which deletes everything](#delete-all-issuers-and-keys). +~> **Note**: The PKI Secrets Engine supports multiple issuers under a single + mount. Use the management operations in this section to [list](#list-issuers) + and [modify issuers](#update-issuer) within this mount. No issuers will be + overridden by calling this operation. Deleting individual keys and issuers + should be preferred to calling `DELETE /pki/root`, [which deletes + everything](#delete-all-issuers-and-keys). | Method | Path | | :----- | :--------------------------------- | @@ -2266,10 +2265,9 @@ issuer or key entry; duplicates (including with existing keys) will be ignored. The response will indicate what issuers and keys were created as part of this request (in the `imported_issuers` and `imported_keys`), along with a `mapping` field, indicating which keys belong to which issuers (including from already -imported entries present in the same bundle). In Vault 1.14.0, the response -also contains an `existing_issuers` and `existing_keys` fields, which specifies -the issuer and key IDs of any entries in the bundle that already -existed within this mount. +imported entries present in the same bundle). The response also contains an +`existing_issuers` and `existing_keys` fields, which specifies the issuer and +key IDs of any entries in the bundle that already existed within this mount. | Method | Path | Allows private keys | Request Parameter | | :----- | :----------------------------- | :------------------ | :---------------- | @@ -2409,10 +2407,9 @@ do so, import a new issuer and a new `issuer_id` will be assigned. ~> **Note** `POST`ing to this endpoint causes OpenBao to overwrite the previous contents of the issuer, using the provided request data (and any defaults for elided parameters). It does not update only the provided fields.

- Since Vault 1.11.0, OpenBao supports the PATCH operation to this endpoint, - using the [JSON patch format](https://datatracker.ietf.org/doc/html/rfc6902) - supported by KVv2, allowing update of specific fields. Note that - `openbao write` uses `POST`. + OpenBao supports the PATCH operation to this endpoint, using the [JSON patch + format](https://datatracker.ietf.org/doc/html/rfc6902) supported by KVv2, + allowing update of specific fields. Note that `bao write` uses `POST`. #### Parameters @@ -2872,10 +2869,9 @@ request is denied. OpenBao to overwrite the contents of the role, using the provided request data (and any defaults for elided parameters). It does not update only the provided fields.

- Since Vault 1.11.0, OpenBao supports the PATCH operation to this endpoint, - using the [JSON patch format](https://datatracker.ietf.org/doc/html/rfc6902) - supported by KVv2, allowing update of specific fields. Note that - `openbao write` uses `POST`. + OpenBao supports the PATCH operation to this endpoint, using the [JSON patch + format](https://datatracker.ietf.org/doc/html/rfc6902) supported by KVv2, + allowing update of specific fields. Note that `bao write` uses `POST`. #### Parameters @@ -3735,13 +3731,13 @@ and **must** be called on every cluster. to delete their issuer and is instead necessary to **remove** the mount completely. -~> **Note**: As of Vault 1.12, it is suggested to switch to enabling the CRL's - `auto_rebuild` functionality to avoid having to manually hit the Rotate - endpoint when the CRL expires. This ensures a valid CRL is always - maintained, at the expense of potentially not being up-to-date. If a - revocation occurs that must be immediately propagated, this endpoint can - be used to regenerate the CRL, though distribution must still occur outside - of OpenBao (either manually or via AIA where supported). +~> **Note**: It is suggested to switch to enabling the CRL's `auto_rebuild` + functionality to avoid having to manually hit the Rotate endpoint when the + CRL expires. This ensures a valid CRL is always maintained, at the expense of + potentially not being up-to-date. If a revocation occurs that must be + immediately propagated, this endpoint can be used to regenerate the CRL, + though distribution must still occur outside of OpenBao (either manually or + via AIA where supported). | Method | Path | | :----- | :---------------- | @@ -3981,9 +3977,8 @@ expiration time. discarded, potentially causing a performance penalty on each request. During regular CA operations, it is not necessary to run this operation.

- It is suggested to run this tidy when removing or importing new issuers and - on the first upgrade to a post-1.11 Vault version, but otherwise not to run - it during automatic tidy operations. + It is suggested to run this tidy when removing or importing new issuers but + otherwise not to run it during automatic tidy operations. - `tidy_expired_issuers` `(bool: false)` - Set to true to automatically remove expired issuers after the `issuer_safety_buffer` duration has elapsed. We @@ -3994,12 +3989,11 @@ expiration time. past the `issuer_safety_buffer` specified. - `tidy_move_legacy_ca_bundle` `(bool: false)` - Set to true to backup any - legacy CA/issuers bundle (from Vault versions earlier than 1.11) to - `config/ca_bundle.bak`. This can be restored with `sys/raw` back to - `config/ca_bundle` if necessary, but won't impact mount startup (as - mounts will attempt to read the latter and do a migration of CA issuers - if present). Migration will only occur after `issuer_safety_buffer` has - passed since the last successful migration. + legacy CA/issuers bundle to `config/ca_bundle.bak`. This can be restored with + `sys/raw` back to `config/ca_bundle` if necessary, but won't impact mount + startup (as mounts will attempt to read the latter and do a migration of CA + issuers 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](/vault/docs/concepts/duration-format) used as a safety buffer to ensure certificates are not expunged prematurely; as an example, this can keep @@ -4287,5 +4281,5 @@ See [PKI Cluster Scalability](/vault/docs/secrets/pki/considerations#cluster-sca ## OpenBao CLI with DER/PEM responses The OpenBao CLI can only display JSON responses. For APIs that return non-JSON formatted -data such as DER and PEM formats, `openbao read` will fail without the `-format=raw` -option added in Vault 1.13 or another client such as `curl` must be used. +data such as DER and PEM formats, `bao read` will fail without the `-format=raw` +option or another client such as `curl` must be used. diff --git a/website/content/api-docs/secret/ssh.mdx b/website/content/api-docs/secret/ssh.mdx index 38048f41f1..f035a0dca6 100644 --- a/website/content/api-docs/secret/ssh.mdx +++ b/website/content/api-docs/secret/ssh.mdx @@ -801,7 +801,7 @@ parameters of the issued certificate can be further customized in this API call. ~> **Note**: The issued credentials are returned but _not_ stored by OpenBao. If you do not save them from the response, issue new credentials by using - this request again. This endpoint is available with Vault version 1.12+. + this request again. | Method | Path | | :----- | :---------------- | @@ -890,10 +890,7 @@ from this engine. remove these keys from systems with authorized hosts entries created by OpenBao. That must be done manually by an operator, potentially before the removal of these host keys if they are necessary to access these - systems.

- For a more effective cleanup process, it is suggest to stay on Vault 1.12, - manually revoke all dynamic key leases, wait for this to finish, and then - upgrade to Vault 1.13+. + systems. | Method | Path | | :------- | :----------------------- | diff --git a/website/content/api-docs/secret/transit.mdx b/website/content/api-docs/secret/transit.mdx index 4bed29b496..e69d291040 100644 --- a/website/content/api-docs/secret/transit.mdx +++ b/website/content/api-docs/secret/transit.mdx @@ -712,6 +712,11 @@ will be returned. encryption. If not set, uses the latest version. Must be greater than or equal to the key's `min_encryption_version`, if set. +- `nonce` `(string: "")` – Specifies the **base64 encoded** nonce value. The + value must be exactly 96 bits (12 bytes) long and the user must ensure that + for any given context (and thus, any given encryption key) this nonce value is + **never reused**. + - `reference` `(string: "")` - A user-supplied string that will be present in the `reference` field on the corresponding `batch_results` item in the response, to assist in understanding @@ -827,6 +832,8 @@ This endpoint decrypts the provided ciphertext using the named key. - `context` `(string: "")` – Specifies the **base64 encoded** context for key derivation. This is required if key derivation is enabled. +- `nonce` `(string: "")` – Specifies a base64 encoded nonce value used during + encryption. - `reference` `(string: "")` - A user-supplied string that will be present in the `reference` field on the corresponding `batch_results` item in the response, to assist in understanding @@ -912,6 +919,9 @@ functionality to untrusted users or scripts. operation. If not set, uses the latest version. Must be greater than or equal to the key's `min_encryption_version`, if set. +- `nonce` `(string: "")` – Specifies a base64 encoded nonce value used during + encryption. + - `reference` `(string: "")` - A user-supplied string that will be present in the `reference` field on the corresponding `batch_results` item in the response, to assist in understanding @@ -991,6 +1001,11 @@ then made available to trusted users. - `context` `(string: "")` – Specifies the key derivation context, provided as a base64-encoded string. This must be provided if derivation is enabled. +- `nonce` `(string: "")` – Specifies a nonce value, provided as base64 encoded. + The value must be exactly 96 bits (12 bytes) long and the user must ensure + that for any given context (and thus, any given encryption key) this nonce + value is **never reused**. + - `bits` `(int: 256)` – Specifies the number of bits in the desired key. Can be 128, 256, or 512. diff --git a/website/content/api-docs/system/auth.mdx b/website/content/api-docs/system/auth.mdx index 2177776dde..30ef4df704 100644 --- a/website/content/api-docs/system/auth.mdx +++ b/website/content/api-docs/system/auth.mdx @@ -329,7 +329,7 @@ can be achieved without `sudo` via `sys/mounts/auth/[auth-path]/tune`._ to use, e.g. "v1.0.0". Changes will not take effect until the mount is reloaded. - `user_lockout_config` `(map: nil)` – Specifies the user lockout configuration - for the mount. User lockout feature was added in Vault 1.13. These are the possible values: + for the mount. These are the possible values: - `lockout_threshold` `(string: "")` - Specifies the number of failed login attempts after which the user is locked out, specified as a string like "15". diff --git a/website/content/api-docs/system/inspect/index.mdx b/website/content/api-docs/system/inspect/index.mdx index 4cd1137b2b..d16e697e6b 100644 --- a/website/content/api-docs/system/inspect/index.mdx +++ b/website/content/api-docs/system/inspect/index.mdx @@ -13,7 +13,7 @@ This endpoint is off by default. See the [OpenBao 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. +~> **NOTE**: These endpoints are subject to change or may disappear without notice. ## Supported inspection paths diff --git a/website/content/api-docs/system/internal-counters.mdx b/website/content/api-docs/system/internal-counters.mdx index 589933296d..87735602a0 100644 --- a/website/content/api-docs/system/internal-counters.mdx +++ b/website/content/api-docs/system/internal-counters.mdx @@ -92,20 +92,6 @@ period, which is represented by the `start_time` and `end_time` parameters. There are a few things to keep in mind while using this API. -- For Vault versions before 1.11, the activity information only accounts for -the activity of the latest contiguous months in the billing period. -For example, if the billing period is from Jan 2022 to June 2022, and the -activity subsystem in OpenBao was not capturing data for the months Jan to March, -the response will only include information for May and June. Note that if no -`start_time` and `end_time` parameters are specified, the billing period defaults -to 12 months, so the endpoint will return activity information from the end of the -previous month to the start of 12 months prior to that date. - -- As of 1.11, this behavior has been modified to return all available data within -the specified billing period. - -- As of 1.12, the `end_time` can be the current month. - - The response contains the total activity for the billing period and the attributions of the total activity against specific components in OpenBao. This helps in understanding the total activity better by knowing which components in @@ -239,13 +225,15 @@ OpenBao lead to the new clients for each month. } ``` -- The `distinct_entities` field name has been deprecated since Vault 1.10. Refer to +- The `distinct_entities` field name has been deprecated. Refer to `entity_clients` field instead. The `distinct_entities` field is currently -returned by the API for backward compatibility and it may be removed in the future. +returned by the API for backward compatibility and it may be removed in the +future. -- The `non_entity_tokens` field name has been deprecated since Vault 1.10. Refer to +- The `non_entity_tokens` field name has been deprecated. Refer to `non_entity_clients` field instead. The `non_entity_tokens` field is currently -returned by the API for backward compatibility, and it may be removed in the future. +returned by the API for backward compatibility, and it may be removed in the +future. - If the `end_date` supplied to the API is for the current month, the activity information returned by this API will only be till the previous month. The @@ -327,8 +315,6 @@ be listed as "deleted namespace :ID:." Deleted namespaces are reported only for queries in the root namespace because the information about the namespace path is unknown. -This endpoint was added in Vault 1.6. - | Method | Path | | :----- | :-------------------------------- | | `GET` | `/sys/internal/counters/activity` | @@ -729,8 +715,6 @@ Note: the client count may be inaccurate in the moments following an OpenBao reboot, or leadership change. The estimate will stabilize when background loading of client data has completed. -This endpoint was added in Vault 1.7. - | Method | Path | | :----- | :---------------------------------------- | | `GET` | `/sys/internal/counters/activity/monthly` | @@ -957,8 +941,6 @@ months in the requested time range. information returned by this API will include activity for this month, however it may be up to 20 minutes delayed. -This endpoint was added in Vault 1.11. - | Method | Path | | :----- | :---------------------------------------- | | `GET` | `/sys/internal/counters/activity/export` | diff --git a/website/content/api-docs/system/leases.mdx b/website/content/api-docs/system/leases.mdx index be1a9cceac..b5d9be4599 100644 --- a/website/content/api-docs/system/leases.mdx +++ b/website/content/api-docs/system/leases.mdx @@ -261,8 +261,6 @@ per mount point. Note that it currently only supports type "irrevocable". This can help determine if particular endpoints are disproportionately resulting in irrevocable leases. -This endpoint was added in Vault 1.8. - ### Parameters - `type` `(string: )` - Specifies the type of lease. @@ -292,8 +290,6 @@ of leases per mount point. Note that it currently only supports type This can help determine if particular endpoints or causes are disproportionately resulting in irrevocable leases. -This endpoint was added in Vault 1.8. - ### Parameters - `type` `(string: )` - Specifies the type of lease. diff --git a/website/content/api-docs/system/mfa-validate.mdx b/website/content/api-docs/system/mfa-validate.mdx index 52e3c3c19f..cb46fb6a30 100644 --- a/website/content/api-docs/system/mfa-validate.mdx +++ b/website/content/api-docs/system/mfa-validate.mdx @@ -35,8 +35,7 @@ string slices. In cases where an MFA method is configured not to use passcodes, } ``` -As of Vault 1.13.0, it is also possible to use an MFA method name as the key to the `mfa_payload`. -In versions 1.12.x and below,`passcode=` was used for Duo MFA only. Starting in version 1.13.x, `passcode=` is optional for all supported MFA methods. +It is also possible to use an MFA method name as the key to the `mfa_payload`. ```json { diff --git a/website/content/api-docs/system/policies-password.mdx b/website/content/api-docs/system/policies-password.mdx index 0f4db50d77..ad775319a3 100644 --- a/website/content/api-docs/system/policies-password.mdx +++ b/website/content/api-docs/system/policies-password.mdx @@ -11,8 +11,6 @@ The `/sys/policies/password/` endpoints are used to manage password generation p Not all secret engines utilize password policies, so check the documentation for the engine you are using for compatibility. -~> Password policies are only available in Vault version 1.5+. - See [Password Policies](/vault/docs/concepts/password-policies) for details of how password policies work as well as the syntax of the policies themselves. diff --git a/website/content/api-docs/system/user-lockout.mdx b/website/content/api-docs/system/user-lockout.mdx index c554707f4d..3bc97591e9 100644 --- a/website/content/api-docs/system/user-lockout.mdx +++ b/website/content/api-docs/system/user-lockout.mdx @@ -21,8 +21,6 @@ queries in the root namespace because the information about the namespace path is unknown. The response will be returned in the decreasing order of locked user counts. -This endpoint was added in Vault 1.13. - | Method | Path | | :----- | :--------------- | | `GET` | `/sys/locked-users` | @@ -197,9 +195,6 @@ $ curl \ The unlock user endpoint frees a locked user with the provided `mount_accessor` and `alias_identifier` in the given namespace. The unlock command is idempotent. Calls to the endpoint succeed even if the user matching the provided `mount_accessor` and `alias_identifier` is not currently locked. - -This endpoint was added in Vault 1.13. - | Method | Path | | :----- | :--------------- | | `POST` | `/sys/locked-users/:mount_accessor/unlock/:alias-identifier` | diff --git a/website/content/api-docs/system/version-history.mdx b/website/content/api-docs/system/version-history.mdx index 062d976f12..e48eb9cedb 100644 --- a/website/content/api-docs/system/version-history.mdx +++ b/website/content/api-docs/system/version-history.mdx @@ -6,9 +6,6 @@ description: The `/sys/version-history` endpoint is used to retrieve the version # `/sys/version-history` -~> **NOTE**: Tracking version history was added in Vault version 1.9.0. Entries for versions installed prior to version 1.9.0 will not be available via this API. -This API was added in 1.10.0. - The `/sys/version-history` endpoint is used to retrieve the version history of an OpenBao instance. ## Read version history @@ -17,7 +14,7 @@ This endpoint returns the version history of the OpenBao. The response will cont - `keys`: a list of installed versions in chronological order based on the time installed - `key_info`: a map indexed by the versions found in the `keys` list containing the following subkeys: - - `build_date`: the time (in UTC) at which the OpenBao binary used to run the OpenBao server was built. **Note: Only tracked from Vault version 1.11.0 or greater** + - `build_date`: the time (in UTC) at which the OpenBao binary used to run the OpenBao server was built. - `previous_version`: the version installed prior to this version or `null` if no prior version exists - `timestamp_installed`: the time (in UTC) at which the version was installed diff --git a/website/content/docs/agent-and-proxy/agent/caching/index.mdx b/website/content/docs/agent-and-proxy/agent/caching/index.mdx index 3844b5b472..33e25a5da9 100644 --- a/website/content/docs/agent-and-proxy/agent/caching/index.mdx +++ b/website/content/docs/agent-and-proxy/agent/caching/index.mdx @@ -14,11 +14,6 @@ created tokens and responses containing leased secrets generated off of these newly created tokens. The renewals of the cached tokens and leases are also managed by the agent. --> **Note:** OpenBao Agent Caching works best with servers/clusters that are -running on Vault 1.1 and above due to changes that were introduced -alongside this feature, such as the exposure of the `orphan` field in token -creation responses. - ## Caching and renewals Response caching and renewals are managed by the agent only under these diff --git a/website/content/docs/agent-and-proxy/agent/template.mdx b/website/content/docs/agent-and-proxy/agent/template.mdx index 8b6c17026c..895923a462 100644 --- a/website/content/docs/agent-and-proxy/agent/template.mdx +++ b/website/content/docs/agent-and-proxy/agent/template.mdx @@ -251,7 +251,7 @@ of the secret's lease duration has elapsed. ### Non-Renewable secrets If a secret or token isn't renewable or leased, OpenBao Agent will fetch the secret every 5 minutes. -This can be configured using Template config [static_secret_render_interval](/vault/docs/agent-and-proxy/agent/template#static_secret_render_interval) (requires Vault 1.8+). +This can be configured using Template config [static_secret_render_interval](/vault/docs/agent-and-proxy/agent/template#static_secret_render_interval). Non-renewable secrets include (but not limited to) [KV Version 2](/vault/docs/secrets/kv/kv-v2). ### Non-Renewable leased secrets @@ -268,7 +268,7 @@ this by inspecting the secret's time-to-live (TTL). ### Certificates -As of Vault 1.11, certificates can be rendered using either `pkiCert` or +Certificates can be rendered using either `pkiCert` or `secret` template functions, although it is recommended to use `pkiCert` to avoid unnecessarily generating certificates whenever Agent restarts or re-authenticates. diff --git a/website/content/docs/agent-and-proxy/agent/versions.mdx b/website/content/docs/agent-and-proxy/agent/versions.mdx index 2575072e68..463a06a883 100644 --- a/website/content/docs/agent-and-proxy/agent/versions.mdx +++ b/website/content/docs/agent-and-proxy/agent/versions.mdx @@ -10,7 +10,7 @@ description: |- There is no requirement to run identical versions of OpenBao Agent and OpenBao Server. It is safe to run different versions, however you may not be able to take advantage of all the newest features in OpenBao if you do not upgrade to the most recent versions of Agent and Server. We recognize that this isn’t always possible, so we do support version mismatch as best as possible. -As of Vault Agent 1.13.0, Agent will write a note to its logs when it detects a mismatch between Agent and Server. This is purely informative, intended to assist with debugging in case the mismatch is given rise to problems, e.g. because a newer Agent version is trying to make use of functionality that doesn't exist in the Server version it's talking to. If Agent is behaving acceptably, the message may be ignored. +Agent will write a note to its logs when it detects a mismatch between Agent and Server. This is purely informative, intended to assist with debugging in case the mismatch is given rise to problems, e.g. because a newer Agent version is trying to make use of functionality that doesn't exist in the Server version it's talking to. If Agent is behaving acceptably, the message may be ignored. This document describes the common cases. There may be occasional exceptions, which if intentional will be called out in the CHANGELOG in a `CHANGES` section. If unintentional/undocumented these should be treated as bugs and reported. diff --git a/website/content/docs/agent-and-proxy/autoauth/sinks/file.mdx b/website/content/docs/agent-and-proxy/autoauth/sinks/file.mdx index c377f92940..ff5c7113e9 100644 --- a/website/content/docs/agent-and-proxy/autoauth/sinks/file.mdx +++ b/website/content/docs/agent-and-proxy/autoauth/sinks/file.mdx @@ -21,7 +21,7 @@ written with `0640` permissions as default, but can be overridden with the optio ## Configuration - `path` `(string: required)` - The path to use to write the token file -- `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 OpenBao from modifying the file mode. Note: This configuration option is only available in Vault 1.3.0 and above. +- `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 OpenBao from modifying the file mode. ~> Note: Configuration options for response-wrapping and encryption for the sink file are located within the [options common to all sinks](/vault/docs/agent-and-proxy/autoauth#configuration-sinks) documentation. diff --git a/website/content/docs/agent-and-proxy/proxy/caching/index.mdx b/website/content/docs/agent-and-proxy/proxy/caching/index.mdx index a5c32fc99d..ec6316d1ae 100644 --- a/website/content/docs/agent-and-proxy/proxy/caching/index.mdx +++ b/website/content/docs/agent-and-proxy/proxy/caching/index.mdx @@ -14,11 +14,6 @@ created tokens and responses containing leased secrets generated off of these newly created tokens. The renewals of the cached tokens and leases are also managed by the proxy. --> **Note:** OpenBao Proxy Caching works best with servers/clusters that are -running on Vault 1.1 and above due to changes that were introduced -alongside this feature, such as the exposure of the `orphan` field in token -creation responses. - ## Caching and renewals Response caching and renewals are managed by the proxy only under these diff --git a/website/content/docs/auth/cert.mdx b/website/content/docs/auth/cert.mdx index 790c6a1bcb..ccc1f335a5 100644 --- a/website/content/docs/auth/cert.mdx +++ b/website/content/docs/auth/cert.mdx @@ -27,8 +27,6 @@ configuration. This is because the certificates are sent through TLS communicati ## Revocation checking -Since Vault 0.4, the method supports revocation checking. - An authorized user can submit PEM-formatted CRLs identified by a given name; these can be updated or deleted at will. They may also set the URL of a trusted CRL distribution point, and have OpenBao fetch the CRL as needed. diff --git a/website/content/docs/auth/jwt/index.mdx b/website/content/docs/auth/jwt/index.mdx index 79faff5e3b..a8bbbd144f 100644 --- a/website/content/docs/auth/jwt/index.mdx +++ b/website/content/docs/auth/jwt/index.mdx @@ -151,7 +151,7 @@ EOF `cat jwt.json | jq -r .access_token | cut -d. -f2 | base64 -D` -- As of Vault 1.2, the [`verbose_oidc_logging`](/vault/api-docs/auth/jwt#verbose_oidc_logging) role +- 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 diff --git a/website/content/docs/auth/kerberos.mdx b/website/content/docs/auth/kerberos.mdx index ca69c37235..4776241837 100644 --- a/website/content/docs/auth/kerberos.mdx +++ b/website/content/docs/auth/kerberos.mdx @@ -202,12 +202,6 @@ Then make sure you're ready to share the error output of that command, the contents of the `krb5.conf` file, and [the entries listed](https://docs.oracle.com/cd/E19683-01/806-4078/6jd6cjs1q/index.html) in the `keytab` file. -After you've stripped the issue down to its simplest form, if you still -encounter difficulty resolving it, it will be much easier to gain assistance -by posting your reproduction to the [Vault Forum](https://discuss.hashicorp.com/c/vault) -or by providing it to [HashiCorp Support](https://www.hashicorp.com/support) -(if applicable.) - ### Additional troubleshooting resources - [Troubleshooting OpenBao](/vault/tutorials/monitoring/troubleshooting-vault) diff --git a/website/content/docs/auth/kubernetes.mdx b/website/content/docs/auth/kubernetes.mdx index 4202bd7a04..9b171fd68c 100644 --- a/website/content/docs/auth/kubernetes.mdx +++ b/website/content/docs/auth/kubernetes.mdx @@ -134,16 +134,14 @@ if the expiry time passes, and OpenBao will no longer be able to use the `TokenReview` API. See [How to work with short-lived Kubernetes tokens][short-lived-tokens] below for details on handling this change. -In response to the issuer changes, Kubernetes auth has been updated in Vault -1.9.0 to not validate the issuer by default. The Kubernetes API does the same -validation when reviewing tokens, so enabling issuer validation on the OpenBao -side is duplicated work. Without disabling OpenBao's issuer validation, it is not +In response to the issuer changes, Kubernetes auth has been updated to not +validate the issuer by default. The Kubernetes API does the same validation when +reviewing tokens, so enabling issuer validation on the OpenBao side is +duplicated work. Without disabling OpenBao's issuer validation, it is not possible for a single Kubernetes auth configuration to work for default mounted -pod tokens with both Kubernetes 1.20 and 1.21. Note that auth mounts created -before Vault 1.9 will maintain the old default, and you will need to explicitly -set `disable_iss_validation=true` before upgrading Kubernetes to 1.21. See -[Discovering the service account `issuer`](#discovering-the-service-account-issuer) -below for guidance if you wish to enable issuer validation in OpenBao. +pod tokens with both Kubernetes 1.20 and 1.21.. See [Discovering the service +account `issuer`](#discovering-the-service-account-issuer) below for guidance if +you wish to enable issuer validation in OpenBao. [k8s-1.21-changelog]: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md#api-change-2 [short-lived-tokens]: #how-to-work-with-short-lived-kubernetes-tokens @@ -154,12 +152,12 @@ There are a few different ways to configure auth for Kubernetes pods when default mounted pod tokens are short-lived, each with their own tradeoffs. This table summarizes the options, each of which is explained in more detail below. -| Option | All tokens are short-lived | Can revoke tokens early | Other considerations | -| ------------------------------------ | -------------------------- | ----------------------- | -------------------- | -| Use local token as reviewer JWT | Yes | Yes | Requires Vault (1.9.3+) to be deployed on the Kubernetes cluster | -| Use client JWT as reviewer JWT | Yes | Yes | Operational overhead | -| Use long-lived token as reviewer JWT | No | Yes | | -| Use JWT auth instead | Yes | No | | +| Option | All tokens are short-lived | Can revoke tokens early | Other considerations | +|--------------------------------------|----------------------------|-------------------------|-----------------------------------------------------------| +| Use local token as reviewer JWT | Yes | Yes | Requires OpenBao to be deployed on the Kubernetes cluster | +| Use client JWT as reviewer JWT | Yes | Yes | Operational overhead | +| Use long-lived token as reviewer JWT | No | Yes | | +| Use JWT auth instead | Yes | No | | -> **Note:** By default, Kubernetes currently extends the lifetime of admission injected service account tokens to a year to help smooth the transition to @@ -184,11 +182,6 @@ bao write auth/kubernetes/config \ kubernetes_host=https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT ``` -!> **Note:** Requires Vault 1.9.3+. In earlier versions the service account -token and CA certificate is read once and stored in Vault storage. -When the service account token expires or is revoked, Vault will no longer be -able to use the `TokenReview` API and client authentication will fail. - #### Use the OpenBao client's JWT as the reviewer JWT When configuring Kubernetes auth, you can omit the `token_reviewer_jwt`, and OpenBao @@ -248,12 +241,11 @@ limitation in mind. ### Discovering the service account `issuer` --> **Note:** From Vault 1.9.0, `disable_iss_validation` and `issuer` are deprecated -and the default for `disable_iss_validation` has changed to `true` for new -Kubernetes auth mounts. The following section only applies if you have set -`disable_iss_validation=false` or created your mount before 1.9 with the default -value, but `disable_iss_validation=true` is the new recommended value for all -versions of Vault. +-> **Note:** `disable_iss_validation` and `issuer` are deprecated and the +default for `disable_iss_validation` has changed to `true` for new Kubernetes +auth mounts. The following section only applies if you have set +`disable_iss_validation=false` , but `disable_iss_validation=true` is the new +recommended value for all versions of OpenBao. Kubernetes 1.21+ clusters may require setting the service account [`issuer`](/vault/api-docs/auth/kubernetes#issuer) to the same value as diff --git a/website/content/docs/auth/login-mfa/faq.mdx b/website/content/docs/auth/login-mfa/faq.mdx index de4aeb264a..3110b3feed 100644 --- a/website/content/docs/auth/login-mfa/faq.mdx +++ b/website/content/docs/auth/login-mfa/faq.mdx @@ -18,7 +18,7 @@ This FAQ section contains frequently asked questions about the Login MFA feature | MFA workflow | What does it do? | Who manages the MFA? | | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | -| [Login MFA](/vault/docs/auth/login-mfa) | MFA in OpenBao provides MFA on login. CLI, API, and UI-based login are supported. | MFA is managed by Vault | +| [Login MFA](/vault/docs/auth/login-mfa) | MFA in OpenBao provides MFA on login. CLI, API, and UI-based login are supported. | MFA is managed by OpenBao | | [Okta Auth MFA](/vault/docs/auth/okta#mfa) | This is MFA as part of [Okta Auth method](/vault/docs/auth/okta) in OpenBao, 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. CLI/API login are supported. | MFA is managed externally by Okta | diff --git a/website/content/docs/auth/login-mfa/index.mdx b/website/content/docs/auth/login-mfa/index.mdx index dbf59ef403..709332a205 100644 --- a/website/content/docs/auth/login-mfa/index.mdx +++ b/website/content/docs/auth/login-mfa/index.mdx @@ -42,7 +42,7 @@ MFA in OpenBao includes the following login types: 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 paths are enforced by default. 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](/vault/api-docs/secret/identity/mfa) for details @@ -61,10 +61,12 @@ In the Single-phase login, the required MFA information is embedded in a login r the `X-Vault-MFA` header. In this case, the MFA validation is done as a part of the login request. -MFA credentials are retrieved from the `X-Vault-MFA` HTTP header. Before Vault 1.13.0, the format of -the header is `mfa_method_id[:passcode]` for TOTP, Okta, and PingID. However, for Duo, it is `mfa_method_id[:passcode=]`. -The item in the `[]` is optional. From Vault 1.13.0, the format is consistent for all supported MFA methods, and one can use either of the above two formats. -If there are multiple MFA methods that need to be validated, a user can pass in multiple `X-Vault-MFA` HTTP headers. +MFA credentials are retrieved from the `X-Vault-MFA` HTTP header. The format of +the header is either `mfa_method_id[:passcode]` or +`mfa_method_id[:passcode=]`, and one can use either of the above two +formats. The item in the `[]` is optional. If there are multiple MFA methods +that need to be validated, a user can pass in multiple `X-Vault-MFA` HTTP +headers. #### Sample request @@ -84,7 +86,7 @@ If an MFA method does not require a passcode, the login request MFA header only http://127.0.0.1:8200/v1/auth/userpass/login/alice ``` -Starting in Vault 1.13.0, an operator can configure a name for an MFA method. +An operator can configure a name for an MFA method. This name should be unique in the namespace in which the MFA method is configured. The MFA method name can be used in the MFA header. @@ -228,8 +230,8 @@ To get started with Login MFA, refer to the [Login MFA](/vault/tutorials/auth-me ### TOTP passcode validation rate limit -Rate limiting of Login MFA paths are enforced by default in Vault 1.10.1 and above. -By default, OpenBao allows for 5 consecutive failed TOTP passcode validation. -This value can also be configured by adding `max_validation_attempts` to the TOTP configuration. -If the number of consecutive failed TOTP passcode validation exceeds the configured value, the user -needs to wait until a fresh TOTP passcode is available. +Rate limiting of Login MFA paths are enforced by default. OpenBao allows for 5 +consecutive failed TOTP passcode validations. This value can also be configured +by adding `max_validation_attempts` to the TOTP configuration. If the number of +consecutive failed TOTP passcode validation exceeds the configured value, the +user needs to wait until a fresh TOTP passcode is available. diff --git a/website/content/docs/commands/auth/help.mdx b/website/content/docs/commands/auth/help.mdx index 2b585c55ad..96264218db 100644 --- a/website/content/docs/commands/auth/help.mdx +++ b/website/content/docs/commands/auth/help.mdx @@ -24,7 +24,7 @@ Get usage instructions for the userpass auth method: $ bao auth help userpass Usage: bao login -method=userpass [CONFIG K=V...] - The userpass auth method allows users to authenticate using Vault's + The userpass auth method allows users to authenticate using OpenBao's internal user database. # ... diff --git a/website/content/docs/commands/auth/tune.mdx b/website/content/docs/commands/auth/tune.mdx index 82cbd3fd06..e8671c3b08 100644 --- a/website/content/docs/commands/auth/tune.mdx +++ b/website/content/docs/commands/auth/tune.mdx @@ -173,13 +173,12 @@ flags](/vault/docs/commands) included on all commands. [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. + after which the user is locked out. - `-user-lockout-duration` `(duration: "")` - Specifies the duration for which a user will be locked out. - User lockout feature was added in Vault 1.13. - `-user-lockout-counter-reset-duration` `(duration: "")` - Specifies the duration after which the lockout - counter is reset with no failed login attempts. User lockout feature was added in Vault 1.13. + counter is reset with no failed login attempts. -- `-user-lockout-disable` `(bool: false)` - Disables the user lockout feature if set to true. User lockout feature was added in Vault 1.13. +- `-user-lockout-disable` `(bool: false)` - Disables the user lockout feature if set to true. diff --git a/website/content/docs/commands/index.mdx b/website/content/docs/commands/index.mdx index f4a52061b4..f692cb5c1d 100644 --- a/website/content/docs/commands/index.mdx +++ b/website/content/docs/commands/index.mdx @@ -10,12 +10,6 @@ description: |- # OpenBao commands (CLI) -~> **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](/vault/docs/upgrading/upgrade-to-0.9.2#backwards-compatible-cli-changes) for -more information. - In addition to a verbose [HTTP API](/vault/api-docs), OpenBao features a command-line interface (CLI) that wraps common functionality and formats output. The OpenBao CLI is a single static binary. It is a thin wrapper around the HTTP API. Every @@ -273,8 +267,8 @@ this file at any time to "logout" of OpenBao. The CLI reads the following environment variables to set behavioral defaults. This can alleviate the need to repetitively type a flag. Flags always take precedence over the environment variables. Each of the following environment -variables must be set on the OpenBao process. In Vault 1.13+, all environment -variables available to the OpenBao process will be logged during startup. +variables must be set on the OpenBao process. All environment variables +available to the OpenBao process will be logged during startup. ### `VAULT_TOKEN` diff --git a/website/content/docs/commands/kv/index.mdx b/website/content/docs/commands/kv/index.mdx index cf4f9c0409..095c70cd23 100644 --- a/website/content/docs/commands/kv/index.mdx +++ b/website/content/docs/commands/kv/index.mdx @@ -22,10 +22,6 @@ The deprecated path-like syntax can also be used (e.g. `bao kv get secret/creds` for KV v2, because it is not actually the full API path to the secret (secret/data/foo) and may cause confusion. -~> A `flag provided but not defined: -mount` error means you are using an older version of OpenBao before the -mount flag syntax was introduced. Upgrade to at least Vault 1.11, or refer to previous versions of the docs -which only use the old syntax to refer to the mount path. - ## Examples Create or update the key named "creds" in the K/V Version 2 enabled at "secret" @@ -130,7 +126,7 @@ Subcommands: enable-versioning Turns on versioning for a KV store get Retrieves data from the KV store list List data or secrets - metadata Interact with Vault's Key-Value storage + metadata Interact with OpenBao's Key-Value storage patch Sets or updates data in the KV store without overwriting put Sets or updates data in the KV store rollback Rolls back to a previous version of data diff --git a/website/content/docs/commands/pki/health-check.mdx b/website/content/docs/commands/pki/health-check.mdx index 2f834243c6..f86a57d834 100644 --- a/website/content/docs/commands/pki/health-check.mdx +++ b/website/content/docs/commands/pki/health-check.mdx @@ -88,10 +88,7 @@ This command returns the following exit codes: one or more health checks. Note that an exit code of `5` (due to a version mismatch) is not necessarily -fatal to the health check. For example, the `crl_validity_period` health -check will return an invalid version warning when run against Vault 1.11 as -no Delta CRL exists for this version of Vault, but this will not impact its -ability to check the complete CRL. +fatal to the health check. Each health check outputs one or results in a list. This list contains a mapping of keys (`status`, `status_code`, `endpoint`, and `message`) to diff --git a/website/content/docs/concepts/client-count/faq.mdx b/website/content/docs/concepts/client-count/faq.mdx index 1714902774..9b8c509091 100644 --- a/website/content/docs/concepts/client-count/faq.mdx +++ b/website/content/docs/concepts/client-count/faq.mdx @@ -14,10 +14,6 @@ description: |- | Computing client count | | ----------------------- | -| [Can I compute clients for Vault versions before v1.6?](#before-1-6) | -| [Can I compute KMIP clients for OpenBao?](#kmip) | -| [Can I compute changes in clients month to month from the UI for Vault v1.8   v1.10?](#month-to-month) | -| [Do child namespaces create duplication in the client count?](#namespace-dupes) | | [Does the Nomad-OpenBao integration affect client counts?](#nomad) | | [Are batch tokens counted differently than service tokens?](#batch-tokens) | | [Do custom user filters affect client counts?](#custom-filters) | @@ -25,26 +21,18 @@ description: |- | Upgrading and migration | | ----------------------- | -| [How has client count changed across different OpenBao versions?](#logic-improvements) | -| [How has the usage metric UI changed across different OpenBao versions?](#ui-improvements) | -| [Are there any known client count issues in the UI/API?](#uiapi-ki) | | [What happens to client count when I upgrade?](#what-happens-at-upgrade) | | Usage | | ----------------------- | | [Can I view the list of unique client IDs that contributed to my client count aggregate?](#view-data) | | [Is clientID viewable in the audit logs for non-entity tokens?](#clientid-in-logs) | -| [Can I skip client computation for a period of time during the billing period?](#skip-computation) | +| [Can I skip client computation for a period of time during the period?](#skip-computation) | | [Are there conditions that will cause me to lose client data?](#lost-data) | -| [What happens if a portion of the data is missing for my billing period?](#missing-data) | +| [What happens if a portion of the data is missing for my period?](#missing-data) | | [Can I disable client counting?](#disable-client-count) | | [Can I configure OpenBao to log the client count data?](#log-client-count) | -| OpenBao auditor tool | -| ----------------------- | -| [What is the OpenBao auditor?](##openbao-auditor) | -| [Are there any known client count issues in the auditor tool?](#auditor-ki) | - ## Definitions ((#definitions)) @include 'faq/client-count/definitions.mdx' @@ -60,7 +48,3 @@ description: |- ## Usage ((#usage)) @include 'faq/client-count/usage.mdx' - -## OpenBao auditor tool ((#auditor)) - -@include 'faq/client-count/tools.mdx' diff --git a/website/content/docs/concepts/client-count/index.mdx b/website/content/docs/concepts/client-count/index.mdx index 3f174712bb..f9aff97bef 100644 --- a/website/content/docs/concepts/client-count/index.mdx +++ b/website/content/docs/concepts/client-count/index.mdx @@ -130,18 +130,9 @@ token as a unique client for production usage. We strongly discourage the use of unaffiliated tokens and recommend that you always associate a token with an entity alias and token role. - - As of Vault 1.9, all non-entity tokens with the same namespace and policy - assignments are treated as the same client entity. Prior to Vault 1.9, every - non-entity token was treated as a unique client entity, which drastically - inflated telemetry around client count. - - If you are using Vault 1.8 or earlier, and need to address client count - inflation without upgrading, we recommend creating a - [token role](/vault/api-docs/auth/token#create-update-token-role) with - allowable entity aliases and assigning all tokens to an appropriate - [role and entity alias name](/vault/api-docs/auth/token#create-token) before - using them. + + All non-entity tokens with the same namespace and policy assignments are + treated as the same client entity. @include "content-footer-title.mdx" diff --git a/website/content/docs/concepts/events.mdx b/website/content/docs/concepts/events.mdx index 8f81c8a6ff..16b31d1ed8 100644 --- a/website/content/docs/concepts/events.mdx +++ b/website/content/docs/concepts/events.mdx @@ -14,7 +14,7 @@ Events are arbitrary, **non-secret** data that can be exchanged between producer and subscribers (OpenBao components and external users via the API). Events are delivered on a *best-effort* basis, so do not have delivery guarantees at this time. -As of Vault 1.13, events are not considered production-ready, and so are disabled by default when starting an OpenBao server. +Events are not considered production-ready, and so are disabled by default when starting a OpenBao server. Events can be enabled via the `events.alpha1` [experiment option](/vault/docs/configuration#experiments) in the OpenBao configuration or on the command-line: @@ -35,20 +35,20 @@ additional `metadata` field. The following events are currently generated by OpenBao and its builtin plugins automatically: -| Plugin | Event Type | Vault version | -| ------ | ----------------------- | ------------- | -| kv | `kv-v1/delete` | 1.13 | -| kv | `kv-v1/write` | 1.13 | -| kv | `kv-v2/config-write` | 1.13 | -| kv | `kv-v2/data-delete` | 1.13 | -| kv | `kv-v2/data-patch` | 1.13 | -| kv | `kv-v2/data-write` | 1.13 | -| kv | `kv-v2/delete` | 1.13 | -| kv | `kv-v2/destroy` | 1.13 | -| kv | `kv-v2/metadata-delete` | 1.13 | -| kv | `kv-v2/metadata-patch` | 1.13 | -| kv | `kv-v2/metadata-write` | 1.13 | -| kv | `kv-v2/undelete` | 1.13 | +| Plugin | Event Type | +| ------ | ----------------------- | +| kv | `kv-v1/delete` | +| kv | `kv-v1/write` | +| kv | `kv-v2/config-write` | +| kv | `kv-v2/data-delete` | +| kv | `kv-v2/data-patch` | +| kv | `kv-v2/data-write` | +| kv | `kv-v2/delete` | +| kv | `kv-v2/destroy` | +| kv | `kv-v2/metadata-delete` | +| kv | `kv-v2/metadata-patch` | +| kv | `kv-v2/metadata-write` | +| kv | `kv-v2/undelete` | ## Event format @@ -158,11 +158,3 @@ path "sys/events/subscribe/*" { capabilities = ["read"] } ``` - - -## Supported versions - -| Vault Version | Support | -| ------------- | ------------------------------------------- | -| <= 1.12 | Not supported | -| 1.13 | Supported (with `events.alpha1` experiment) | diff --git a/website/content/docs/concepts/integrated-storage/autopilot.mdx b/website/content/docs/concepts/integrated-storage/autopilot.mdx index f606cc0a91..c3578d9e3e 100644 --- a/website/content/docs/concepts/integrated-storage/autopilot.mdx +++ b/website/content/docs/concepts/integrated-storage/autopilot.mdx @@ -8,7 +8,7 @@ description: Learn about the autopilot subsystem of integrated raft storage in O Autopilot enables automated workflows for managing Raft clusters. The current feature set includes 3 main features: Server Stabilization, Dead Server Cleanup -and State API. These three features were introduced in Vault 1.7. +and State API. ## Server stabilization @@ -43,14 +43,14 @@ Follower node health is determined by 2 factors. ### Default configuration -By default, Autopilot will be enabled with clusters using Vault 1.7+, -although dead server cleanup is not enabled by default. Upgrade of -Raft clusters deployed with older versions of OpenBao will also transition to use -Autopilot automatically. +By default, Autopilot is enabled in OpenBao, although dead server cleanup is not +enabled by default. Autopilot exposes a [configuration API](/vault/api-docs/system/storage/raftautopilot#set-configuration) to manage its -behavior. Autopilot gets initialized with the following default values. If these default values do not meet your expected autopilot behavior, don't forget to set them to your desired values. +behavior. Autopilot gets initialized with the following default values. If these +default values do not meet your expected autopilot behavior, don't forget to set +them to your desired values. - `cleanup_dead_servers` - `false` - This controls whether to remove dead servers from diff --git a/website/content/docs/concepts/integrated-storage/index.mdx b/website/content/docs/concepts/integrated-storage/index.mdx index 5afcd9b420..a0f69dd283 100644 --- a/website/content/docs/concepts/integrated-storage/index.mdx +++ b/website/content/docs/concepts/integrated-storage/index.mdx @@ -7,9 +7,9 @@ description: Learn about the integrated raft storage in OpenBao. # Integrated storage OpenBao supports a number of storage options for the durable storage of OpenBao's -information. As of Vault 1.4 an Integrated Storage option is offered. This -storage backend does not rely on any third party systems, implements high -availability semantics and provides backup/restore workflows. +information. This Integrated Storage backend does not rely on any third party +systems, implements high availability semantics and provides backup/restore +workflows. The option stores OpenBao's data on the server's filesystem and uses a consensus protocol to replicate data to each server in the cluster. More @@ -230,10 +230,10 @@ 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 +The simplest option might be to specify a [`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 +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. Note that names in a certificate's DNS SAN don't actually have to be registered diff --git a/website/content/docs/concepts/password-policies.mdx b/website/content/docs/concepts/password-policies.mdx index 96d43d3c41..201c675de8 100644 --- a/website/content/docs/concepts/password-policies.mdx +++ b/website/content/docs/concepts/password-policies.mdx @@ -15,7 +15,7 @@ the documentation for the engine you are using for compatibility. **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](/vault/api-docs/system/policies-password). +The Password policies [API docs can be found here](/vault/api-docs/system/policies-password). !> Password policies are an advanced usage of OpenBao. This generates credentials for external systems (databases, LDAP, etc.) and should be used with caution. diff --git a/website/content/docs/concepts/pgp-gpg-keybase.mdx b/website/content/docs/concepts/pgp-gpg-keybase.mdx index 531377bd28..1db87a98f2 100644 --- a/website/content/docs/concepts/pgp-gpg-keybase.mdx +++ b/website/content/docs/concepts/pgp-gpg-keybase.mdx @@ -28,7 +28,7 @@ the shards and unseal normally. One of the early fundamental problems when bootstrapping and initializing OpenBao was that the first user (the initializer) received a plain-text copy of all of the unseal keys. This defeats the promises of OpenBao's security model, and it -also makes the distribution of those keys more difficult. Since Vault 0.3, +also makes the distribution of those keys more difficult. OpenBao can optionally be initialized using PGP keys. In this mode, OpenBao will generate the unseal keys and then immediately encrypt them using the given users' public PGP keys. Only the owner of the corresponding private key is then diff --git a/website/content/docs/concepts/policies.mdx b/website/content/docs/concepts/policies.mdx index bb2c167be0..ead9825dea 100644 --- a/website/content/docs/concepts/policies.mdx +++ b/website/content/docs/concepts/policies.mdx @@ -150,7 +150,7 @@ path "secret/zip-*" { ``` In addition, a `+` can be used to denote any number of characters bounded -within a single path segment (this appeared in Vault 1.1): +within a single path segment: ```ruby # Permit reading the "teamb" path under any top-level path under secret/ diff --git a/website/content/docs/concepts/response-wrapping.mdx b/website/content/docs/concepts/response-wrapping.mdx index dabd408901..4912c741f5 100644 --- a/website/content/docs/concepts/response-wrapping.mdx +++ b/website/content/docs/concepts/response-wrapping.mdx @@ -6,9 +6,6 @@ description: Wrapping responses in cubbyholes for secure distribution. # Response wrapping -_Note_: Some of this information relies on features of response-wrapping tokens -introduced in Vault 0.8 and may not be available in earlier releases. - ## Overview In many OpenBao deployments, clients can access OpenBao directly and consume diff --git a/website/content/docs/concepts/seal.mdx b/website/content/docs/concepts/seal.mdx index 60f795289c..c677823588 100644 --- a/website/content/docs/concepts/seal.mdx +++ b/website/content/docs/concepts/seal.mdx @@ -194,13 +194,13 @@ seal will require that the service backing the Auto Unseal is accessible during the migration. ~> **NOTE**: Seal migration from Auto Unseal to Auto Unseal of the same type is -supported since Vault 1.6.0. However, there is a current limitation that +supported in OpenBao. However, there is a current limitation that prevents migrating from AWSKMS to AWSKMS; all other seal migrations of the same type are supported. Seal migration from One Auto Unseal type (AWS KMS) to different Auto Unseal type (HSM, Azure KMS, etc.) is also supported on older versions as well. -### Migration post Vault 1.5.1 +### Migration steps These steps are common for seal migrations between any supported kinds and for any storage backend. @@ -277,10 +277,6 @@ will be migrated to be used as unseal keys. #### Migration from auto unseal to auto unseal -~> **NOTE**: Migration between same Auto Unseal types is supported in Vault -1.6.0 and higher. For these pre-1.5.1 steps, it is only possible to migrate from -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](/vault/docs/configuration/seal) and add `disabled = "true"` to the seal diff --git a/website/content/docs/concepts/tokens.mdx b/website/content/docs/concepts/tokens.mdx index 891cf5a4e3..1dbe3d3f9b 100644 --- a/website/content/docs/concepts/tokens.mdx +++ b/website/content/docs/concepts/tokens.mdx @@ -38,11 +38,11 @@ for details on how these concepts play out in practice. ## Token types -As of Vault 1.0, there are two types of tokens: `service` tokens and `batch` -tokens. A section near the bottom of this page contains detailed information -about their differences, but it is useful to understand other token concepts -first. The features in the following sections all apply to service tokens, and -their applicability to batch tokens is discussed later. +There are two types of tokens: `service` tokens and `batch` tokens. A section +near the bottom of this page contains detailed information about their +differences, but it is useful to understand other token concepts first. The +features in the following sections all apply to service tokens, and their +applicability to batch tokens is discussed later. ## The token store diff --git a/website/content/docs/configuration/listener/tcp.mdx b/website/content/docs/configuration/listener/tcp.mdx index ba470f2046..0307e1574a 100644 --- a/website/content/docs/configuration/listener/tcp.mdx +++ b/website/content/docs/configuration/listener/tcp.mdx @@ -23,7 +23,7 @@ advertise the correct address to other nodes. ## Listener's custom response headers -As of version 1.9, Vault supports defining custom HTTP response headers for the root path (`/`) and also on API endpoints (`/v1/*`). +OpenBao 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](/vault/api-docs/system/config-ui) which allows users @@ -285,7 +285,7 @@ listener "tcp" { ### Configuring custom http response headers -Note: Requires Vault version 1.9 or newer. This example shows configuring custom http response headers. +This example shows configuring custom http response headers. Operators can configure `"custom_response_headers"` sub-stanza in the listener stanza to set custom http headers appropriate to their applications. Examples of such headers are `"Strict-Transport-Security"` and `"Content-Security-Policy"` which are known HTTP headers, and could be configured to harden diff --git a/website/content/docs/configuration/service-registration/consul.mdx b/website/content/docs/configuration/service-registration/consul.mdx index 5e4d9de4c2..cc555ff943 100644 --- a/website/content/docs/configuration/service-registration/consul.mdx +++ b/website/content/docs/configuration/service-registration/consul.mdx @@ -14,8 +14,6 @@ Consul Service Registration registers OpenBao as a service in [Consul][consul] w a default health check. When Consul is configured as the storage backend, the stanza `service_registration` is not needed as it will automatically register OpenBao as a service. -~> **Version information:** The `service_registration` configuration option was introduced in Vault 1.4.0. - @include 'consul-dataplane-compat.mdx' - **HashiCorp Supported** – Consul Service Registration is officially supported diff --git a/website/content/docs/deprecation/faq.mdx b/website/content/docs/deprecation/faq.mdx index 3cc5b85711..338ff52bc0 100644 --- a/website/content/docs/deprecation/faq.mdx +++ b/website/content/docs/deprecation/faq.mdx @@ -5,38 +5,20 @@ sidebar_title: FAQ description: |- An FAQ page to communicate frequently asked questions concerning feature deprecations. --- - # Feature deprecation FAQ -This page provides frequently asked questions concerning decisions made about Vault feature deprecations. Please refer to the [Feature Deprecation Notice and Plans](/vault/docs/deprecation) document for up-to-date information on Vault feature deprecations and notice. +This page provides frequently asked questions concerning decisions made about OpenBao feature deprecations. Please refer to the [Feature Deprecation Notice and Plans](/vault/docs/deprecation) document for up-to-date information on OpenBao feature deprecations and notice. -- [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) -- [Q: What should I do if I use Mount Filters, AppID, or any of the standalone DB engines?](#q-what-should-i-do-if-i-use-mount-filters-appid-or-any-of-the-standalone-db-engines) - [Q: What is the impact of removing support for X.509 certificates with signatures that use SHA-1?](#q-what-is-the-impact-of-removing-support-for-x-509-certificates-with-signatures-that-use-sha-1) - [Q: What are the phases of deprecation?](#q-what-are-the-phases-of-deprecation) -### Q: i'm currently using the etcd storage backend feature. how does the deprecation impact me? - -The Etcd v2 has been deprecated with the release of Etcd v3.5 and will be decommissioned by Etcd v3.6. Etcd v2 API will be removed in Vault 1.10. The Etcd storage backend users should migrate Vault storage to an Etcd V3 cluster before upgrading to Vault 1.10. We recommend that you back up all storage migrations before upgrading. - -### Q: what should i do if i use mount filters, AppID, or any of the standalone DB engines? - -These features were deprecated in prior releases of Vault. We are targeting the removal of these features from the product in the Vault 1.12 release. Please plan to upgrade to these features before the release of Vault 1.12. Refer to the table below for a list of alternative features. - -| Deprecated Feature | Alternative Feature | -| --------------------- | ------------------------------------------------------------------------------------------------------------------- | -| 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. - ### Q: what is the impact of removing support for x.509 certificates with signatures that use SHA-1? -Starting with Vault 1.12.0, Vault will be built with Go 1.18 or later. -The standard library in Go 1.18 and later [rejects X.509 signatures](https://go.dev/doc/go1.18#sha1) that use a SHA-1 hash. +OpenBao is built with Go 1.21 or later. The standard library in Go 1.18 and +later [rejects X.509 signatures](https://go.dev/doc/go1.18#sha1) that use a +SHA-1 hash. -If this issue impacts your usage of Vault, you can temporarily work around it by deploying Vault with the environment variable `GODEBUG=x509sha1=1` set. +If this issue impacts your usage of OpenBao, you can temporarily work around it by deploying OpenBao with the environment variable `GODEBUG=x509sha1=1` set. This workaround will fail in a future version of Go, however, the Go team has not said when they will remove this workaround. If you want to check whether a certificate or CA contains a problematic signature, you can use the OpenSSL CLI: @@ -74,9 +56,9 @@ Here are the use cases that may still use certificates with SHA-1: ### Q: what are the phases of deprecation? -As of version 1.12, Vault implements a multi-phased approach to deprecation. The intent of this approach is to provide sufficient warning that a feature will be removed and safe handling of stored data when the associated feature has been removed. +OpenBao implements a multi-phased approach to deprecation. The intent of this approach is to provide sufficient warning that a feature will be removed and safe handling of stored data when the associated feature has been removed. -The phases of deprecation are also known as "Deprecation Status". These statuses are currently reflected in builtin plugins and are exposed via the Vault `auth`, `secrets`, and `plugins` CLI/API endpoints. For more information, refer to the corresponding documentation. +The phases of deprecation are also known as "Deprecation Status". These statuses are currently reflected in builtin plugins and are exposed via the OpenBao `auth`, `secrets`, and `plugins` CLI/API endpoints. For more information, refer to the corresponding documentation. The four phases of deprecation are: `Supported`, `Deprecated`, `Pending Removal`, and `Removed`. @@ -88,7 +70,7 @@ This is the default status and reflects a feature which is still supported. Ther #### Deprecated -This status reflects a feature which has been marked for deprecation in a later release of Vault. This is the first phase of the deprecation process. A status of `Deprecated` has two effects: +This status reflects a feature which has been marked for deprecation in a later release of OpenBao. This is the first phase of the deprecation process. A status of `Deprecated` has two effects: 1. After an upgrade, any existing `Deprecated` feature (builtin auth/secrets plugins enabled via CLI or API prior to upgrade) will log `Warn`-level messages on unseal. @@ -98,11 +80,11 @@ This status reflects a feature which has been marked for deprecation in a later #### Pending removal -This status reflects a feature which has been officially deprecated in this release of Vault. This is the first phase in the process that fundamentally alters the behavior of Vault. The effects are two-fold: +This status reflects a feature which has been officially deprecated in this release of OpenBao. This is the first phase in the process that fundamentally alters the behavior of OpenBao. The effects are two-fold: -1. After an upgrade, any existing `Pending Removal` feature (builtin auth/secrets plugins enabled via CLI or API prior to upgrade) will log `Error`-level messages to the Vault log and cause an immediate shutdown of the Vault core. +1. After an upgrade, any existing `Pending Removal` feature (builtin auth/secrets plugins enabled via CLI or API prior to upgrade) will log `Error`-level messages to the OpenBao log and cause an immediate shutdown of the OpenBao core. -2. Any new `Pending Removal` will fail and log `Error`-level messages to the Vault log and CLI/API. +2. Any new `Pending Removal` will fail and log `Error`-level messages to the OpenBao log and CLI/API. ##### VAULT_ALLOW_PENDING_REMOVAL_MOUNTS @@ -110,17 +92,17 @@ The `Pending Removal` behavior may be overriden using a new environment variable #### Removed -This status reflects a feature which has been officially removed from Vault. `Removed` is the last phase of the deprecation process. During this phase, code for this feature no longer exists within Vault. +This status reflects a feature which has been officially removed from OpenBao. `Removed` is the last phase of the deprecation process. During this phase, code for this feature no longer exists within OpenBao. -1. After an upgrade, any existing `Removed` feature will log `Error`-level messages to the Vault log and cause an immediate shutdown of the Vault core. +1. After an upgrade, any existing `Removed` feature will log `Error`-level messages to the OpenBao log and cause an immediate shutdown of the OpenBao core. -2. Any new `Removed` features will fail and log `Error`-level messages to the Vault log and CLI/API. +2. Any new `Removed` features will fail and log `Error`-level messages to the OpenBao log and CLI/API. #### Migration path In order to successfully upgrade, use of the `Removed` feature must be discontinued. To accomplish this: -1. Downgrade Vault to a previous version. +1. Downgrade OpenBao to a previous version. 2. Replace any `Removed` or `Pending Removal` feature with the [preferred alternative feature](#q-what-should-i-do-if-i-use-mount-filters-appid-or-any-of-the-standalone-db-engines). diff --git a/website/content/docs/deprecation/index.mdx b/website/content/docs/deprecation/index.mdx index 6d4cc5f5a9..24fa3c08a1 100644 --- a/website/content/docs/deprecation/index.mdx +++ b/website/content/docs/deprecation/index.mdx @@ -5,33 +5,18 @@ sidebar_title: Feature Deprecation Notice and Plans description: |- An announcement page to communicate feature deprecations and plans. --- - # 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](/vault/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 OpenBao features as well as features we have removed or disabled from the project. 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://github.com/orgs/openbao/discussions). Please refer to the [FAQ](/vault/docs/deprecation/faq) page for frequently asked questions concerning OpenBao feature deprecations. **Deprecation Announcement**: This indicates the release version during which the announcement was made to deprecate a feature. **End of Support**: This indicates when a deprecated feature becomes unsupported. Consult the table below and consider the timeline provided to upgrade. -**Feature Removal**: This indicates that the feature is completely removed/disabled from the product. +**Feature Removal**: This indicates that the feature is completely removed/disabled from the project. ~> **Note**: All specified targeted version announcements for End of Support and Feature Removal may be subject to change. -| Feature | Deprecation announcement | End of Support | Feature Removal | Migration Path/Impact | Resources | -| ------------------------------------------------- | ------------------------ | -------------- | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Active Directory Secrets Engine | 1.13 | v1.18 | v1.19 | Use the [LDAP Secrets Engine](/vault/docs/secrets/ldap) with the `ad` [schema](/vault/api-docs/secret/ldap#schema) | [Migration Guide](/vault/docs/secrets/ad/migration-guide) | -| 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 (Community) | 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) | -| *****Standalone DB Engines (Community) | v0.8 | N/A | v1.13 | Use the alternative DB secrets engine feature. | [DB secrets engine](/vault/docs/secrets/databases) | -| *****AppID (Community) | 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](/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) | -| Vault Agent API proxy support | v1.14 | v1.16 | v1.17 | Migrate to [Vault Proxy](/vault/docs/proxy/index) by v1.17| +| Feature | Deprecation announcement | End of Support | Feature Removal | Migration Path/Impact | Resources | +|---------|--------------------------|----------------|-----------------|-----------------------|-----------| -*If you use **Standalone DB Engines** or **AppID (Community)**, 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. -This behavior may temporarily be overridden when starting the Vault server by using the `VAULT_ALLOW_PENDING_REMOVAL_MOUNTS` environment variable until they are officially removed in Vault version 1.13. -If you are still using these deprecated features and attempt to upgrade to 1.13 (the target feature removal timeframe), you will not be able to start up Vault without downgrading and migrating away from these features. diff --git a/website/content/docs/get-started/developer-qs.mdx b/website/content/docs/get-started/developer-qs.mdx index 81344e72da..26adc84cea 100644 --- a/website/content/docs/get-started/developer-qs.mdx +++ b/website/content/docs/get-started/developer-qs.mdx @@ -3,60 +3,34 @@ layout: docs page_title: Developer Quick Start description: Learn how to store and retrieve your first secret. --- - # Developer quick start -This quick start will explore how to use Vault client libraries inside your application code to store and retrieve your first secret value. Vault takes the security burden away from developers by providing a secure, centralized secret store for an application’s sensitive data: credentials, certificates, encryption keys, and more. - -The complete code samples for the steps below are available here: - -- [Go](https://github.com/hashicorp/vault-examples/blob/main/examples/_quick-start/go/example.go) -- [Ruby](https://github.com/hashicorp/vault-examples/blob/main/examples/_quick-start/ruby/example.rb) -- [C#](https://github.com/hashicorp/vault-examples/blob/main/examples/_quick-start/dotnet/Example.cs) -- [Python](https://github.com/hashicorp/vault-examples/blob/main/examples/_quick-start/python/example.py) -- [Java (Spring)](https://github.com/hashicorp/vault-examples/blob/main/examples/_quick-start/java/Example.java) -- [OpenAPI-based Go](https://github.com/hashicorp/vault-client-go/#getting-started) -- [OpenAPI-based .NET](https://github.com/hashicorp/vault-client-dotnet/#getting-started) - -For an out-of-the-box runnable demo application showcasing these concepts and more, see the hello-vault repositories ([Go](https://github.com/hashicorp/hello-vault-go), [C#](https://github.com/hashicorp/hello-vault-dotnet) and [Java/Spring Boot](https://github.com/hashicorp/hello-vault-spring)). +This quick start will explore how to use OpenBao client libraries inside your application code to store and retrieve your first secret value. OpenBao takes the security burden away from developers by providing a secure, centralized secret store for an application’s sensitive data: credentials, certificates, encryption keys, and more. ## Prerequisites -- [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. +- A development environment applicable to one of the languages in this quick start (currently **Go** and **Bash (curl)**) -## Step 1: start Vault +## Step 1: start OpenBao -!> **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. +!> **Warning**: This in-memory “dev” server is useful for practicing with OpenBao locally for the first time, but is insecure and **should never be used in production**. For developers who need to manage their own production OpenBao 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: - -**For Docker users, run this command**: +Run the OpenBao server in a non-production "dev" mode: ```shell-session -$ docker run -p 8200:8200 -e 'VAULT_DEV_ROOT_TOKEN_ID=dev-only-token' vault +$ bao server -dev -dev-root-token-id="dev-only-token" ``` -**For non-Docker users, run this command**: - -```shell-session -$ vault server -dev -dev-root-token-id="dev-only-token" -``` +The `-dev-root-token-id` flag for dev servers tells the OpenBao server to allow full root access to anyone who presents a token with the specified value (in this case "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](/vault/docs/concepts/tokens#root-tokens) is useful for development, but allows full access to all data and functionality of OpenBao, so it must be carefully guarded in production. Ideally, even an administrator of OpenBao 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! +OpenBao is now listening over HTTP on port **8200**. With all the setup out of the way, it's time to get coding! ## Step 2: install a client library -To read and write secrets in your application, you need to first configure a client to connect to Vault. -Let's install the Vault client library for your language of choice. - --> **Note**: Some of these libraries are currently community-maintained. +To read and write secrets in your application, you need to first configure a client to connect to OpenBao. +Let's install the OpenBao client library for your language of choice. @@ -72,153 +46,7 @@ Now, let's add the import statements for the client library to the top of the fi ```go -import vault "github.com/openbao/openbao/api" -``` - - - - - - - -[Ruby](https://github.com/hashicorp/vault-ruby) (official) client library: - -```shell-session -$ gem install vault -``` - -Now, let's add the import statements for the client library to the top of the file. - - - -```ruby -require "vault" -``` - - - - - - - -[C#](https://github.com/rajanadar/VaultSharp) client library: - -```shell-session -$ dotnet add package VaultSharp -``` - -Now, let's add the import statements for the client library to the top of the file. - - - -```cs -using VaultSharp; -using VaultSharp.V1.AuthMethods; -using VaultSharp.V1.AuthMethods.Token; -using VaultSharp.V1.Commons; -``` - - - - - - - -[Python](https://github.com/hvac/hvac) client library: - -```shell-session -$ pip install hvac -``` - -Now, let's add the import statements for the client library to the top of the file. - - - -```Python -import hvac -``` - - - - - - - -[Java (Spring)](https://spring.io/projects/spring-vault) client library: - -Add the following to pom.xml: - -```xml - - org.springframework.vault - spring-vault-core - 2.3.1 - -``` - -Now, let's add the import statements for the client library to the top of the file. - - - -```Java -import org.springframework.vault.authentication.TokenAuthentication; -import org.springframework.vault.client.VaultEndpoint; -import org.springframework.vault.support.Versioned; -import org.springframework.vault.core.VaultTemplate; -``` - - - - - - - -[OpenAPI Go](https://github.com/hashicorp/vault-client-go) (Beta) client library: - -```shell-session -$ go get github.com/hashicorp/vault-client-go -``` - -Now, let's add the import statements for the client library to the top of the file. - - - -```go -import ( - "github.com/hashicorp/vault-client-go" - "github.com/hashicorp/vault-client-go/schema" -) -``` - - - - - - - - -[OpenAPI .NET](https://github.com/hashicorp/vault-client-dotnet) (Beta) client library: - -Vault is a package available at [Hashicorp Nuget](https://www.nuget.org/profiles/hashicorp). - - -```shell-session -$ nuget install HashiCorp.Vault -Version "0.1.0-beta" -``` - -**Or:** - -```shell-session -$ dotnet add package Hashicorp.Vault -version "0.1.0-beta" -``` - -Now, let's add the import statements for the client library to the top of the file. - - - -```cs -using Vault; -using Vault.Client; +import openbao "github.com/openbao/openbao/api" ``` @@ -227,76 +55,30 @@ using Vault.Client; -## Step 3: authenticate to Vault - -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. +## Step 3: authenticate to OpenBao -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: +A variety of [authentication methods](/vault/docs/auth) can be used to prove +your application's identity to the OpenBao server. 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 OpenBao client that will use token-based +authentication for all its requests: ```go -config := vault.DefaultConfig() +config := openbao.DefaultConfig() config.Address = "http://127.0.0.1:8200" -client, err := vault.NewClient(config) +client, err := openbao.NewClient(config) if err != nil { - log.Fatalf("unable to initialize Vault client: %v", err) + log.Fatalf("unable to initialize OpenBao client: %v", err) } client.SetToken("dev-only-token") ``` - - - -```ruby -Vault.configure do |config| - config.address = "http://127.0.0.1:8200" - config.token = "dev-only-token" -end -``` - - - - -```cs -IAuthMethodInfo authMethod = new TokenAuthMethodInfo(vaultToken: "dev-only-token"); - -VaultClientSettings vaultClientSettings = new -VaultClientSettings("http://127.0.0.1:8200", authMethod); -IVaultClient vaultClient = new VaultClient(vaultClientSettings); -``` - - - - -```Python -client = hvac.Client( - url='http://127.0.0.1:8200', - token='dev-only-token', -) -``` - - - - -```Java -VaultEndpoint vaultEndpoint = new VaultEndpoint(); - -vaultEndpoint.setHost("127.0.0.1"); -vaultEndpoint.setPort(8200); -vaultEndpoint.setScheme("http"); - -VaultTemplate vaultTemplate = new VaultTemplate( - vaultEndpoint, - new TokenAuthentication("dev-only-token") -); -``` - @@ -304,49 +86,21 @@ VaultTemplate vaultTemplate = new VaultTemplate( $ export VAULT_TOKEN="dev-only-token" ``` - - - -```go -client, err := vault.New( - vault.WithAddress("http://127.0.0.1:8200"), - vault.WithRequestTimeout(30*time.Second), -) -if err != nil { - log.Fatal(err) -} - -if err := client.SetToken("dev-only-token"); err != nil { - log.Fatal(err) -} -``` - - - - -```cs -string address = "http://127.0.0.1:8200"; -VaultConfiguration config = new VaultConfiguration(address); - -VaultClient vaultClient = new VaultClient(config); -vaultClient.SetToken("dev-only-token"); -``` - ## Step 4: store a secret -Secrets are sensitive data like API keys and passwords that we shouldn’t be storing in our code or configuration files. Instead, we want to store values like this in Vault. +Secrets are sensitive data like API keys and passwords that we shouldn’t be storing in our code or configuration files. Instead, we want to store values like this in OpenBao. -We'll use the Vault client we just initialized to write a secret to Vault, like so: +We'll use the OpenBao client we just initialized to write a secret to OpenBao, like so: ```go secretData := map[string]interface{}{ - "password": "Hashi123", + "password": "OpenBao123", } @@ -358,56 +112,6 @@ if err != nil { fmt.Println("Secret written successfully.") ``` - - - -```ruby -secret_data = {data: {password: "Hashi123"}} -Vault.logical.write("secret/data/my-secret-password", secret_data) - -puts "Secret written successfully." -``` - - - - -```cs -var secretData = new Dictionary { { "password", "Hashi123" } }; -vaultClient.V1.Secrets.KeyValue.V2.WriteSecretAsync( - path: "/my-secret-password", - data: secretData, - mountPoint: "secret" -).Wait(); - -Console.WriteLine("Secret written successfully."); -``` - - - - -```Python -create_response = client.secrets.kv.v2.create_or_update_secret( - path='my-secret-password', - secret=dict(password='Hashi123'), -) - -print('Secret written successfully.') -``` - - - - -```Java -Map data = new HashMap<>(); -data.put("password", "Hashi123"); - -Versioned.Metadata createResponse = vaultTemplate - .opsForVersionedKeyValue("secret") - .put("my-secret-password", data); - -System.out.println("Secret written successfully."); -``` - @@ -416,52 +120,24 @@ $ curl \ --header "X-Vault-Token: $VAULT_TOKEN" \ --header "Content-Type: application/json" \ --request POST \ - --data '{"data": {"password": "Hashi123"}}' \ + --data '{"data": {"password": "OpenBao123"}}' \ http://127.0.0.1:8200/v1/secret/data/my-secret-password ``` - - - -```go -_, err = client.Secrets.KVv2Write(context.Background(), "my-secret-password", schema.KVv2WriteRequest{ - Data: map[string]any{ - "password": "Hashi123", - }, -}) -if err != nil { - log.Fatal(err) -} - -log.Println("Secret written successfully.") -``` - - - - -```cs -var secretData = new Dictionary { { "password", "Hashi123" } }; - -// Write a secret -var kvRequestData = new KVv2WriteRequest(secretData); - -vaultClient.Secrets.KVv2Write("my-secret-password", kvRequestData); -``` - -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. +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 `OpenBao123` 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. +We also provided the path to our secret in OpenBao. We will reference this path in a moment when we learn how to retrieve our secret. -Run the code now, and you should see `Secret written successfully`. If not, check that you've used the correct value for the root token and Vault server address. +Run the code now, and you should see `Secret written successfully`. If not, check that you've used the correct value for the root token and OpenBao server address. ## Step 5: retrieve a secret Now that we know how to write a secret, let's practice reading one. -Underneath the line where you wrote a secret to Vault, let's add a few more lines, where we will be retrieving the secret and unpacking the value: +Underneath the line where you wrote a secret to OpenBao, let's add a few more lines, where we will be retrieving the secret and unpacking the value: @@ -478,49 +154,6 @@ log.Fatalf("value type assertion failed: %T %#v", secret.Data["password"], secre } ``` - - - -```ruby -secret = Vault.logical.read("secret/data/my-secret-password") -password = secret.data[:data][:password] -``` - - - - -```cs -Secret secret = vaultClient.V1.Secrets.KeyValue.V2.ReadSecretAsync( - path: "/my-secret-password", - mountPoint: "secret" -).Result; - -var password = secret.Data.Data["password"]; -``` - - - - -```Python -read_response = client.secrets.kv.read_secret_version(path='my-secret-password') - -password = read_response['data']['data']['password'] -``` - - - - -```Java -Versioned> readResponse = vaultTemplate - .opsForVersionedKeyValue("secret") - .get("my-secret-password"); - -String password = ""; -if (readResponse != null && readResponse.hasData()) { - password = (String) readResponse.getData().get("password"); -} -``` - @@ -530,26 +163,6 @@ $ curl \ http://127.0.0.1:8200/v1/secret/data/my-secret-password > secrets.json ``` - - - -```go -s, err := client.Secrets.KVv2Read(context.Background(), "my-secret-password") -if err != nil { - log.Fatal(err) -} - -log.Println("Secret retrieved:", s.Data) -``` - - - - -```cs -VaultResponse resp = vaultClient.Secrets.KVv2Read("my-secret-password"); -Console.WriteLine(resp.Data); -``` - @@ -559,55 +172,13 @@ Last, confirm that the value we unpacked from the read response is correct: ```go -if value != "Hashi123" { - log.Fatalf("unexpected password value %q retrieved from vault", value) +if value != "OpenBao123" { + log.Fatalf("unexpected password value %q retrieved from openbao", value) } fmt.Println("Access granted!") ``` - - - -```ruby -abort "Unexpected password" if password != "Hashi123" - -puts "Access granted!" -``` - - - - -```cs -if (password.ToString() != "Hashi123") -{ - throw new System.Exception("Unexpected password"); -} - -Console.WriteLine("Access granted!"); -``` - - - - -```Python -if password != 'Hashi123': - sys.exit('unexpected password') - -print('Access granted!') -``` - - - - -```Java -if (!password.equals("Hashi123")) { - throw new Exception("Unexpected password"); -} - -System.out.println("Access granted!"); -``` - @@ -620,12 +191,8 @@ $ cat secrets.json | jq '.data.data' If the secret was fetched successfully, you should see the `Access granted!` message after you run the code. If not, check to see if you provided the correct path to your secret. -**That's it! You've just written and retrieved your first Vault secret!** +**That's it! You've just written and retrieved your first OpenBao secret!** # Additional examples -For more secure examples of client authentication, see the auth snippets in the [vault-examples](https://github.com/hashicorp/vault-examples) repo. - -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](/vault/docs/agent-and-proxy/agent) documentation. +To learn how to integrate applications with OpenBao without needing to always change your application code, see the [OpenBao Agent](/vault/docs/agent-and-proxy/agent) documentation. diff --git a/website/content/docs/internals/integrated-storage.mdx b/website/content/docs/internals/integrated-storage.mdx index bf50d11894..f72b8523f9 100644 --- a/website/content/docs/internals/integrated-storage.mdx +++ b/website/content/docs/internals/integrated-storage.mdx @@ -11,7 +11,7 @@ information. Each backend offers pros, cons, advantages, and trade-offs. For example, some backends support high availability while others provide a more robust backup and restoration process. -As of Vault 1.4, an Integrated Storage option is offered. This storage backend +An Integrated Storage option is offered. This storage backend does not rely on any third party systems; it implements high availability and provides backup/restore workflows. @@ -148,7 +148,7 @@ for when a node is treated as healthy before it's considered an eligible voter i quorum list. Other features which may be enabled include the ability to remove nodes considered as dead from the quorum list after a certain period. -Autopilot is enabled by default in Vault 1.7+. The default configuration values +Autopilot is enabled by default and the default configuration values should work well for most OpenBao deployments, but they can be changed if needed. Autopilot includes stabilization logic for nodes joining the cluster. @@ -158,7 +158,7 @@ and only after a stability thresholds are they then full voting members. Setting the stability threshold too low can result in cluster instability as nodes will be counted as voters before they are capable of voting. -As of Vault 1.7, a dead server cleanup capability is available. With this feature +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](/vault/api-docs/system/storage/raftautopilot). If you wish to decommission a node manually, this can be done with the @@ -166,9 +166,6 @@ If you wish to decommission a node manually, this can be done with the #### Without autopilot -Older versions of Vault, 1.6.x & lower, as well as cases where Autopilot may be -disabled or misconfigured, behave differently. - In scenarios involving those when a node joins a Raft cluster, it attempts to catch up with the rest of the nodes through the data that it's replicating from the leader. While in this initial synchronisation state, the node cannot diff --git a/website/content/docs/internals/limits.mdx b/website/content/docs/internals/limits.mdx index fcd2c22993..d25e3467e7 100644 --- a/website/content/docs/internals/limits.mdx +++ b/website/content/docs/internals/limits.mdx @@ -22,9 +22,9 @@ the absolute limits being reached. The maximum size of an object written to a storage backend is determined by that backend. -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](/vault/docs/configuration/storage/raft#max_entry_size). +For the integrated storage backend, the default limit is 1 MiB. This may be +configured via `max_entry_size` in the [storage +stanza](/vault/docs/configuration/storage/raft#max_entry_size). Many of the other limits within OpenBao derive from the maximum size of a storage entry, as described in the next sections. It is possible to diff --git a/website/content/docs/internals/rotation.mdx b/website/content/docs/internals/rotation.mdx index aa7bb8fc61..32be8c555f 100644 --- a/website/content/docs/internals/rotation.mdx +++ b/website/content/docs/internals/rotation.mdx @@ -64,7 +64,7 @@ compromise. Due to the nature of the AES-256-GCM encryption used, keys should be rotated before approximately 232 encryptions have been performed, following the guidelines of NIST publication 800-38D. -As of Vault 1.7, OpenBao will automatically rotate the backend encryption key +OpenBao will automatically rotate the backend encryption key prior to reaching 232 encryption operations by default. Operators can estimate the number of encryptions by summing the following: diff --git a/website/content/docs/internals/telemetry/enable-telemetry.mdx b/website/content/docs/internals/telemetry/enable-telemetry.mdx index 31fabe3e2b..a6c9605def 100644 --- a/website/content/docs/internals/telemetry/enable-telemetry.mdx +++ b/website/content/docs/internals/telemetry/enable-telemetry.mdx @@ -11,7 +11,6 @@ Collect telemetry data from your OpenBao installation. ## Before you start -- **You must have Vault 1.14 or later installed and running**. - **You must have access to your [OpenBao configuration](/vault/docs/configuration) file**. diff --git a/website/content/docs/plugins/plugin-architecture.mdx b/website/content/docs/plugins/plugin-architecture.mdx index dbb85d0516..aa96a169a3 100644 --- a/website/content/docs/plugins/plugin-architecture.mdx +++ b/website/content/docs/plugins/plugin-architecture.mdx @@ -59,9 +59,6 @@ time. If the storage backend has HA enabled and supports automatic host address detection, OpenBao will automatically attempt to determine the `api_addr` as well. -~> Note: Prior to Vault version 1.9.2, reading the original connection's TLS -connection state is not supported in plugins. - ## Plugin registration An important consideration of OpenBao's plugin system is to ensure the plugin @@ -103,17 +100,6 @@ $ bao plugin register -sha256= \ Success! Registered plugin: myplugin-database-plugin ``` -Vault versions prior to v0.10.4 lacked the `vault plugin` operator and the -registration step for them is: - -```shell-session -$ bao write sys/plugins/catalog/database/myplugin-database-plugin \ - sha256= \ - command="myplugin" - -Success! Data written to: sys/plugins/catalog/database/myplugin-database-plugin -``` - ### Plugin execution When a backend wants to run a plugin, it first looks up the plugin, by name, in diff --git a/website/content/docs/release-notes/index.mdx b/website/content/docs/release-notes/index.mdx index 0cdfc63caf..b5939683f4 100644 --- a/website/content/docs/release-notes/index.mdx +++ b/website/content/docs/release-notes/index.mdx @@ -1,15 +1,14 @@ --- layout: docs page_title: Release Notes -description: Release notes for new Vault versions. +description: Release notes for new OpenBao versions. --- - # Release notes -Release notes describe major updates in new versions of Vault. +Release notes describe major updates in new versions of OpenBao. Choose a version from the navigation sidebar to view the release notes for each -of the major software packages in the Vault product line. +of the major software packages in the OpenBao product line. Please refer to the [Changelog](https://github.com/openbao/openbao/blob/main/CHANGELOG.md) for diff --git a/website/content/docs/secrets/databases/custom.mdx b/website/content/docs/secrets/databases/custom.mdx index 1f34a15c3c..ad1a8e6925 100644 --- a/website/content/docs/secrets/databases/custom.mdx +++ b/website/content/docs/secrets/databases/custom.mdx @@ -11,11 +11,11 @@ description: |- # Custom database secrets engines -~> The interface for custom database plugins has changed in Vault 1.6. Vault will -continue to recognize the now deprecated version of this interface for some time. -If you are using a plugin with the deprecated interface, you should upgrade to the -newest version. See [Upgrading database plugins](#upgrading-database-plugins) -for more details. +~> Version 5 of the interface for custom database plugins has been released. +OpenBao will continue to recognize the now deprecated version 4 of this +interface for some time. If you are using a plugin with the deprecated +interface, you should upgrade to the newest version. See [Upgrading database +plugins](#upgrading-database-plugins) for more details. ~> **Advanced topic!** Plugin development is a highly advanced topic in OpenBao, and is not required knowledge for day-to-day usage. If you don't plan on writing @@ -279,23 +279,18 @@ Some use cases that should avoid plugin multiplexing might include: crashes or plugin reload calls ## Upgrading database plugins to the v5 interface - ### Background -In Vault 1.6, the database interface changed. The new version is referred to as version 5 -and the previous version as version 4. This is due to prior versioning of the interface -that was not explicitly exposed. - The new interface was introduced for several reasons: -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. +1. [Password policies](/vault/docs/concepts/password-policies) required that + OpenBao be responsible for generating passwords. In the prior version, the + database plugin was responsible for generating passwords. This prevented + integration with password policies. 2. Passwords needed to be generated by database plugins. This meant that plugin authors were responsible for generating secure passwords. This should be done with a helper - function available within the Vault SDK, however there was nothing preventing an + function available within the OpenBao SDK, however there was nothing preventing an author from generating insecure passwords. 3. There were a number of inconsistencies within the version 4 interface that made it confusing for authors. For instance: passwords were handled in 3 different ways. @@ -317,12 +312,11 @@ function call. ### Upgrading your custom database -Vault 1.6 supports both version 4 and version 5 database plugins. The support for version 4 -plugins will be removed in a future release. Version 5 database plugins will not function with -Vault prior to version 1.6. If you upgrade your database plugins, ensure that you are only using -Vault 1.6 or later. To determine if a plugin is using version 4 or version 5, the following is a -list of changes in no particular order that you can check against your plugin to determine -the version: +OpenBao supports both version 4 and version 5 database plugins. The support for +version 4 plugins will be removed in a future release. To determine if a plugin +is using version 4 or version 5, the following is a list of changes in no +particular order that you can check against your plugin to determine the +version: 1. The import path for version 4 is `github.com/openbao/openbao/sdk/database/dbplugin` whereas the import path for version 5 is `github.com/openbao/openbao/sdk/database/dbplugin/v5` @@ -337,7 +331,7 @@ If you are using a version 4 custom database plugin, the following are basic ins for upgrading to version 5. -> In version 4, password generation was the responsibility of the plugin. This is no longer -the case with version 5. Vault is responsible for generating passwords and passing them to +the case with version 5. OpenBao is responsible for generating passwords and passing them to the plugin via `NewUserRequest.Password` and `UpdateUserRequest.Password.NewPassword`. 1. Change the import path from `github.com/openbao/openbao/sdk/database/dbplugin` to @@ -355,7 +349,7 @@ the plugin via `NewUserRequest.Password` and `UpdateUserRequest.Password.NewPass password of the user to be created. It also includes a list of statements for creating the user as well as several other fields that may or may not be applicable. Your custom plugin should use the password provided in the request, not generate one. If you generate a password - instead, Vault will not know about it and will give the caller the wrong password. + instead, OpenBao will not know about it and will give the caller the wrong password. 5. `SetCredentials`, `RotateRootCredentials`, and `RenewUser` are combined into `UpdateUser`. The request object, `UpdateUserRequest` contains three parts: the username to change, a `ChangePassword` and a `ChangeExpiration` object. When one of the objects is not nil, this diff --git a/website/content/docs/secrets/databases/index.mdx b/website/content/docs/secrets/databases/index.mdx index 35564d319f..b5cbf8176c 100644 --- a/website/content/docs/secrets/databases/index.mdx +++ b/website/content/docs/secrets/databases/index.mdx @@ -147,7 +147,7 @@ the proper permission, it can generate credentials. ## Database capabilities -As of Vault 1.6, all databases support dynamic roles and static roles. All plugins support rotating +All databases support dynamic roles and static roles. All plugins support rotating the root user's credentials. @@ -155,10 +155,10 @@ the root user's credentials. | Database | Root Credential Rotation | Dynamic Roles | Static Roles | Username Customization | Credential Types | |------------------------------------------------------------|--------------------------|---------------|--------------|------------------------|------------------| -| [Cassandra](/vault/docs/secrets/databases/cassandra) | Yes | Yes | Yes (1.6+) | Yes (1.7+) | password | -| [InfluxDB](/vault/docs/secrets/databases/influxdb) | Yes | Yes | Yes (1.6+) | Yes (1.8+) | password | -| [MySQL/MariaDB](/vault/docs/secrets/databases/mysql-maria) | Yes | Yes | Yes | Yes (1.7+) | password | -| [PostgreSQL](/vault/docs/secrets/databases/postgresql) | Yes | Yes | Yes | Yes (1.7+) | password | +| [Cassandra](/vault/docs/secrets/databases/cassandra) | Yes | Yes | Yes | Yes | password | +| [InfluxDB](/vault/docs/secrets/databases/influxdb) | Yes | Yes | Yes | Yes | password | +| [MySQL/MariaDB](/vault/docs/secrets/databases/mysql-maria) | Yes | Yes | Yes | Yes | password | +| [PostgreSQL](/vault/docs/secrets/databases/postgresql) | Yes | Yes | Yes | Yes | password | | [Redis](/vault/docs/secrets/databases/redis) | Yes | Yes | Yes | No | password | ## Custom plugins @@ -212,10 +212,10 @@ rule "charset" { ## Disable character escaping -As of Vault 1.10, you can now specify the option `disable_escaping` with a value of `true ` in -some secrets engines to prevent OpenBao from escaping special characters in the username and password -fields. This is necessary for some alternate connection string formats. See the -[databases secrets engine API +You can specify the option `disable_escaping` with a value of `true ` in some +secrets engines to prevent OpenBao from escaping special characters in the +username and password fields. This is necessary for some alternate connection +string formats. 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. diff --git a/website/content/docs/secrets/ldap.mdx b/website/content/docs/secrets/ldap.mdx index 76b6118139..ab95d2cef0 100644 --- a/website/content/docs/secrets/ldap.mdx +++ b/website/content/docs/secrets/ldap.mdx @@ -418,21 +418,6 @@ $ bao lease revoke ldap/library/accounting-team/check-out/PvBVG0m7pEg2940Cb3Jw3K All revocation operations queued successfully! ``` -## Password generation - -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](/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: - -```hcl -length= -rule "charset" { - charset = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789" -} -``` - ## LDAP password policy The LDAP secret engine does not hash or encrypt passwords prior to modifying diff --git a/website/content/docs/secrets/pki/considerations.mdx b/website/content/docs/secrets/pki/considerations.mdx index 8cfed54bdb..9f3c144809 100644 --- a/website/content/docs/secrets/pki/considerations.mdx +++ b/website/content/docs/secrets/pki/considerations.mdx @@ -69,11 +69,11 @@ root CA (which may be a second mount of the `pki` secrets engine). ## One CA certificate, one secrets engine -Since Vault 1.11.0, the PKI Secrets Engine supports multiple issuers in a single -mount. However, in order to simplify the configuration, it is _strongly_ -recommended that operators limit a mount to a single issuer. If you want to issue -certificates from multiple disparate CAs, mount the PKI secrets engine at multiple -mount points with separate CA certificates in each. +The PKI Secrets Engine supports multiple issuers in a single mount. However, in +order to simplify the configuration, it is _strongly_ recommended that operators +limit a mount to a single issuer. If you want to issue certificates from +multiple disparate CAs, mount the PKI secrets engine at multiple mount points +with separate CA certificates in each. The rationale for separating mounts is to simplify permissions management: very few individuals need access to perform operations with the root, but @@ -232,10 +232,9 @@ chain. ## Cluster URLs are important -In Vault 1.13, support for [templated AIA -URLs](/vault/api-docs/secret/pki#enable_aia_url_templating-1) -was added. In Vault 1.14, with ACME support, the same configuration is used for allowing -ACME clients to discover the URL of this cluster. +ACME support uses the same configuration as [templated AIA +URLs](/vault/api-docs/secret/pki#enable_aia_url_templating-1)to allow ACME +clients to discover the URL of this cluster. ~> **Warning**: It is important to ensure that this configuration is up to date and maintained correctly, always pointing to the node's cluster @@ -245,10 +244,10 @@ ACME clients to discover the URL of this cluster. ## Automate rotation with ACME -In Vault 1.14, support for the [Automatic Certificate Management Environment -(ACME)](https://datatracker.ietf.org/doc/html/rfc8555) protocol has been -added to the PKI Engine. This is a standardized way to handle validation, -issuance, rotation, and revocation of server certificates. +The PKI Engine supports the [Automatic Certificate Management Environment +(ACME)](https://datatracker.ietf.org/doc/html/rfc8555) protocol. This is a +standardized way to handle validation, issuance, rotation, and revocation of +server certificates. Many ecosystems, from web servers like Caddy, Nginx, and Apache, to orchestration environments like Kubernetes (via cert-manager) natively @@ -372,16 +371,15 @@ reach out to a server on a network it could otherwise not access. ### ACME and client counting -In Vault 1.14, ACME contributes differently to usage metrics than other -interactions with the PKI Secrets Engine. Due to its use of unauthenticated -requests (which do not generate OpenBao tokens), it would not be counted in -the traditional [activity log APIs](/vault/api-docs/system/internal-counters#activity-export). -Instead, certificates issued via ACME will be counted via their unique -certificate identifiers (the combination of CN, DNS SANs, and IP SANs). -These will create a stable identifier that will be consistent across -renewals, other ACME clients, mounts, and namespaces, contributing to -the activity log presently as a non-entity token attributed to the first -mount which created that request. +ACME contributes differently to usage metrics than other interactions with the +PKI Secrets Engine. Due to its use of unauthenticated requests (which do not +generate OpenBao tokens), it would not be counted in the traditional [activity +log APIs](/vault/api-docs/system/internal-counters#activity-export). Instead, +certificates issued via ACME will be counted via their unique certificate +identifiers (the combination of CN, DNS SANs, and IP SANs). These will create a +stable identifier that will be consistent across renewals, other ACME clients, +mounts, and namespaces, contributing to the activity log presently as a +non-entity token attributed to the first mount which created that request. ## Keep certificate lifetimes short, for CRL's sake @@ -412,31 +410,28 @@ clients don't have to figure out what to do with a lack of response. Run OpenBao in HA mode, and the CRL endpoint should be available even if a particular node is down. -~> Note: Since Vault 1.11.0, with multiple issuers in the same mount point, +~> Note: When using multiple issuers in the same mount point, different issuers may have different CRLs (depending on subject and key material). This means that OpenBao may need to regenerate multiple CRLs. This is again a rationale for keeping TTLs short and avoiding revocation if possible. -~> Note: Since Vault 1.12.0, we support two complementary revocation - mechanisms: Delta CRLs, which allow for rebuilds of smaller, incremental - additions to the last complete CRL, and OCSP, which allows responding to - revocation status requests for individual certificates. When coupled with - the new CRL auto-rebuild functionality, this means that the revoking step - isn't as costly (as the CRL isn't always rebuilt on each revocation), - outside of storage considerations. However, while the rebuild operation - still can be expensive with lots of certificates, it will be done on a - schedule rather than on demand. +~> Note: OpenBao supports two complementary revocation mechanisms: Delta CRLs, + which allow for rebuilds of smaller, incremental additions to the last + complete CRL, and OCSP, which allows responding to revocation status requests + for individual certificates. When coupled with the new CRL auto-rebuild + functionality, this means that the revoking step isn't as costly (as the CRL + isn't always rebuilt on each revocation), outside of storage considerations. + However, while the rebuild operation still can be expensive with lots of + certificates, it will be done on a schedule rather than on demand. ### NotAfter behavior on leaf certificates -In Vault 1.11.0, the PKI Secrets Engine has introduced a new -`leaf_not_after_behavior` [parameter on -issuers](/vault/api-docs/secret/pki#leaf_not_after_behavior). -This allows modification of the issuance behavior: should OpenBao `err`, -preventing issuance of a longer-lived leaf cert than issuer, silently -`truncate` to that of the issuer's `NotAfter` value, or `permit` longer -expirations. +The PKI Secrets Engine supports a `leaf_not_after_behavior` [parameter on +issuers](/vault/api-docs/secret/pki#leaf_not_after_behavior). This allows +modification of the issuance behavior: should OpenBao `err`, preventing issuance +of a longer-lived leaf cert than issuer, silently `truncate` to that of the +issuer's `NotAfter` value, or `permit` longer expirations. It is strongly suggested to use `err` or `truncate` for intermediates; `permit` is only useful for root certificates, as intermediate's NotAfter @@ -472,12 +467,12 @@ Having a shorter TTL decreases the likelihood of needing to revoke a cert (but cannot prevent it entirely) and decrease the impact of any such compromise. -~> Note: As of Vault 1.12, the PKI Secret Engine's [Bring-Your-Own-Cert - (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 - of issued certificates (and their likelihood for revocation). +~> Note: The PKI Secret Engine's [Bring-Your-Own-Cert + (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_ safe to + be used globally, regardless of importance of issued certificates (and their + likelihood for revocation). ## You must configure issuing/CRL/OCSP information _in advance_ @@ -504,17 +499,17 @@ HTTP. ## Automate CRL building and tidying -Since Vault 1.12, the PKI Secrets Engine supports automated CRL rebuilding -(including optional Delta CRLs which can be built more frequently than -complete CRLs) via the `/config/crl` endpoint. Additionally, tidying of -revoked and expired certificates can be configured automatically via the -`/config/auto-tidy` endpoint. Both of these should be enabled to ensure -compatibility with the wider PKIX ecosystem and performance of the cluster. +The PKI Secrets Engine supports automated CRL rebuilding (including optional +Delta CRLs which can be built more frequently than complete CRLs) via the +`/config/crl` endpoint. Additionally, tidying of revoked and expired +certificates can be configured automatically via the `/config/auto-tidy` +endpoint. Both of these should be enabled to ensure compatibility with the wider +PKIX ecosystem and performance of the cluster. ## Spectrum of revocation support -Starting with Vault 1.13, the PKI secrets engine has the ability to support a -spectrum of cluster sizes and certificate revocation quantities. +The PKI secrets engine has the ability to support a spectrum of cluster sizes +and certificate revocation quantities. For users with few revocations or who want a unified view and have the inter-cluster bandwidth to support it, we recommend turning on auto @@ -554,20 +549,6 @@ unreasonably large, each cluster's certificates could have AIA info point to an externally stored and maintained, sharded CRL. However, OpenBao has no mechanism to sign OCSP requests at this time. -## Issuer subjects and CRLs - -As noted on several [GitHub issues](https://github.com/hashicorp/vault/issues/10176), -Go's x509 library has an opinionated parsing and structuring mechanism for -certificate's Subjects. Issuers created within OpenBao are fine, but when using -externally created CA certificates, these may not be parsed -correctly throughout all parts of the PKI. In particular, CRLs embed a -(modified) copy of the issuer name. This can be avoided by using OCSP to -track revocation, but note that performance characteristics are different -between OCSP and CRLs. - -~> Note: As of Go 1.20 and Vault 1.13, Go correctly formats the CRL's issuer - name and this notice [does not apply](https://github.com/golang/go/commit/a367981b4c8e3ae955eca9cc597d9622201155f3). - ## Automate leaf certificate renewal To manage certificates for services at scale, it is best to automate the @@ -580,19 +561,18 @@ by the OpenBao CA. ## Safe minimums Since its inception, this secrets engine has enforced SHA256 for signature -hashes rather than SHA1. As of 0.5.1, a minimum of 2048 bits for RSA keys is -also enforced. Software that can handle SHA256 signatures should also be able to -handle 2048-bit keys, and 1024-bit keys are considered unsafe and are disallowed -in the Internet PKI. +hashes rather than SHA1. A minimum of 2048 bits for RSA keys is also enforced. +Software that can handle SHA256 signatures should also be able to handle +2048-bit keys, and 1024-bit keys are considered unsafe and are disallowed in the +Internet PKI. ## Token lifetimes and revocation When a token expires, it revokes all leases associated with it. This means that long-lived CA certs need correspondingly long-lived tokens, something that is -easy to forget. Starting with 0.6, root and intermediate CA certs no longer have -associated leases, to prevent unintended revocation when not using a token with -a long enough lifetime. To revoke these certificates, use the `pki/revoke` -endpoint. +easy to forget. Root and intermediate CA certs don't have associated leases, to +prevent unintended revocation when not using a token with a long enough +lifetime. To revoke these certificates, use the `pki/revoke` endpoint. ## Safe usage of roles @@ -850,33 +830,6 @@ certain KMS devices (like HSMs and GCP) may not support this with the same key. As a result, the OCSP responder may fail to sign responses, returning an internal error. -## Issuer storage migration issues - -When Vault migrates to the new multi-issuer storage layout on releases prior -to 1.11.6, 1.12.2, and 1.13, and storage write errors occur during the mount -initialization and storage migration process, the default issuer _may_ not -have the correct `ca_chain` value and may only have the self-reference. These -write errors most commonly manifest in logs as a message like -`failed to persist issuer ... chain to disk: ` and indicate that Vault -was not stable at the time of migration. Note that this only occurs when more -than one issuer exists within the mount (such as an intermediate with root). - -To fix this manually (until a new version of Vault automatically rebuilds the -issuer chain), a rebuild of the chains can be performed: - -``` -curl -X PATCH -H "Content-Type: application/merge-patch+json" -H "X-Vault-Request: true" -H "X-Vault-Token: $(vault print token)" -d '{"manual_chain":"self"}' https://.../issuer/default -curl -X PATCH -H "Content-Type: application/merge-patch+json" -H "X-Vault-Request: true" -H "X-Vault-Token: $(vault print token)" -d '{"manual_chain":""}' https://.../issuer/default -``` - -This temporarily sets the manual chain on the default issuer to a self-chain -only, before reverting it back to automatic chain building. This triggers a -refresh of the `ca_chain` field on the issuer, and can be verified with: - -``` -vault read pki/issuer/default -``` - ## Tutorial Refer to the [Build Your Own Certificate Authority (CA)](/vault/tutorials/secrets-management/pki-engine) diff --git a/website/content/docs/secrets/pki/index.mdx b/website/content/docs/secrets/pki/index.mdx index 1c85a0ea22..1a0ecb292c 100644 --- a/website/content/docs/secrets/pki/index.mdx +++ b/website/content/docs/secrets/pki/index.mdx @@ -8,7 +8,8 @@ description: The PKI secrets engine for OpenBao generates TLS certificates. @include 'x509-sha1-deprecation.mdx' --> **Vault as Consul CA provider:** If you are using Vault 1.11.0+ as a Connect CA, run a Consul version which includes the fix for [GH-15525](https://github.com/hashicorp/consul/pull/15525). Refer to this [Knowledge Base article](https://support.hashicorp.com/hc/en-us/articles/11308460105491) for more details. +-> **OpenBao as Consul CA provider:** If you are using OpenBao as a Connect CA, +run a Consul version greater than 1.12.8. The PKI secrets engine generates dynamic X.509 certificates. With this secrets engine, services can get certificates without going through the usual manual diff --git a/website/content/docs/secrets/pki/rotation-primitives.mdx b/website/content/docs/secrets/pki/rotation-primitives.mdx index 1bb2850080..6d987699d5 100644 --- a/website/content/docs/secrets/pki/rotation-primitives.mdx +++ b/website/content/docs/secrets/pki/rotation-primitives.mdx @@ -6,10 +6,9 @@ description: The PKI secrets engine for OpenBao generates TLS certificates. # PKI secrets engine - rotation primitives -Since Vault 1.11.0, Vault's PKI Secrets Engine supports multiple issuers in a -single mount point. By using the certificate types below, rotation can be -accomplished in various situations involving both root and intermediate CAs -managed by OpenBao. +OpenBao's PKI Secrets Engine supports multiple issuers in a single mount point. +By using the certificate types below, rotation can be accomplished in various +situations involving both root and intermediate CAs managed by OpenBao. ## X.509 certificate fields @@ -62,7 +61,7 @@ The following fields on the final certificate are relevant to rotation: certificate's validity period relative to the validity period of the issuing certificate. However, it [does state](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5) that certificates ought to be revoked if their status cannot be maintained - up to their notAfter date. This is why Vault 1.11's `/pki/issuer/:issuer_ref` + up to their notAfter date. This is why OpenBao's `/pki/issuer/:issuer_ref` configuration endpoint maintains the `leaf_not_after_behavior` per-issuer rather than per-role. - Additionally, some browsers will place ultimate trust in the certificates diff --git a/website/content/docs/secrets/ssh/index.mdx b/website/content/docs/secrets/ssh/index.mdx index 30d5cdd99b..be86214960 100644 --- a/website/content/docs/secrets/ssh/index.mdx +++ b/website/content/docs/secrets/ssh/index.mdx @@ -24,11 +24,6 @@ individually documented on its own page. All guides assume a basic familiarity with the SSH protocol. -## Removal of dynamic keys feature - -Per [Vault 1.12's deprecation notice page](/vault/docs/v1.12.x/deprecation), -the dynamic keys functionality of this engine has been removed in Vault 1.13. - ## API The SSH secrets engine has a full HTTP API. Please see the diff --git a/website/content/docs/secrets/ssh/signed-ssh-certificates.mdx b/website/content/docs/secrets/ssh/signed-ssh-certificates.mdx index e328f599a0..ed71a10ca1 100644 --- a/website/content/docs/secrets/ssh/signed-ssh-certificates.mdx +++ b/website/content/docs/secrets/ssh/signed-ssh-certificates.mdx @@ -99,13 +99,6 @@ team, or configuration management tooling. 1. Create a named OpenBao role for signing client keys. - ~> **IMPORTANT NOTE:** Prior to Vault-1.9, if `"allowed_extensions"` is either empty or not specified in the role, - Vault will assume permissive defaults: any user assigned to the role may specify any arbitrary - extension values as part of the certificate request to the Vault server. - This may have significant impact on third-party systems that rely on an `extensions` field for security-critical information. - In those cases, consider using a template to specify default extensions, and explicitly setting - `"allowed_extensions"` to an arbitrary, non-empty string if the field is empty or not set. - Because of the way some SSH certificate features are implemented, options are passed as a map. The following example adds the `permit-pty` extension to the certificate, and allows the user to specify their own values for `permit-pty` and `permit-port-forwarding` diff --git a/website/content/docs/secrets/transit/index.mdx b/website/content/docs/secrets/transit/index.mdx index 945d6a14e4..a3a54948bb 100644 --- a/website/content/docs/secrets/transit/index.mdx +++ b/website/content/docs/secrets/transit/index.mdx @@ -115,8 +115,8 @@ To accommodate for any needed upgrades to the algorithm, different versions of convergent encryption have historically been supported: - Version 1 required the client to provide their own nonce, which is highly - flexible but if done incorrectly can be dangerous. This was only in Vault - 0.6.1, and keys using this version cannot be upgraded. + flexible but if done incorrectly can be dangerous. Keys using this version + cannot be upgraded. - Version 2 used an algorithmic approach to deriving the parameters. However, the algorithm used was susceptible to offline plaintext-confirmation attacks, which could allow attackers to brute force decryption if the plaintext size diff --git a/website/content/docs/upgrading/index.mdx b/website/content/docs/upgrading/index.mdx index 503d0dbaad..6c56a1a62c 100644 --- a/website/content/docs/upgrading/index.mdx +++ b/website/content/docs/upgrading/index.mdx @@ -25,14 +25,6 @@ supported. The upgrade notes for each intervening version must be reviewed. The upgrade notes may describe additional steps or configuration to update before, during, or after the upgrade. -## Integrated storage autopilot - -Vault 1.11 introduced [automated -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. - ## Agent The OpenBao Agent is an API client of the OpenBao Server. OpenBao APIs are almost @@ -65,8 +57,4 @@ upgrade notes. ## HA installations -The recommended upgrade procedure depends on the version of OpenBao you're currently on and the storage backend of OpenBao. If you're currently running on Vault 1.11 or later with Integrated Storage and you have Autopilot enabled, 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](/vault/docs/concepts/integrated-storage/autopilot#automated-upgrades) documentation for information on this feature. - -If you're currently on a version of Vault before 1.11, or you've chosen to opt-out the Autopilot automated upgrade features when running Vault after 1.11 with Integrated Storage, or if you are running Vault with other storage backend such as Consul. Please refer to our [Vault HA upgrades Pre 1.11/Without Autopilot Upgrade Automation](/vault/docs/upgrading/vault-ha-upgrade) documentation for more details. Please note that this upgrade procedure also applies if you are upgrading Vault from pre 1.11 to post 1.11. +Please refer to our [OpenBao HA upgrades](/vault/docs/upgrading/vault-ha-upgrade) documentation for more details. diff --git a/website/content/docs/upgrading/plugins.mdx b/website/content/docs/upgrading/plugins.mdx index 602a215b7a..3dfa085526 100644 --- a/website/content/docs/upgrading/plugins.mdx +++ b/website/content/docs/upgrading/plugins.mdx @@ -12,11 +12,6 @@ The following procedures detail steps for upgrading a plugin that has been mount at a path on a running server. The steps are the same whether the plugin being upgraded is built-in or external. -~> [Plugin versioning](/vault/docs/plugins#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](/vault/docs/v1.11.x/upgrading/plugins) - for plugin upgrade instructions. - ### Upgrading auth and secrets plugins The process is nearly identical for auth and secret plugins. If you are upgrading diff --git a/website/content/docs/upgrading/vault-ha-upgrade.mdx b/website/content/docs/upgrading/vault-ha-upgrade.mdx index 464cc17957..170016519a 100644 --- a/website/content/docs/upgrading/vault-ha-upgrade.mdx +++ b/website/content/docs/upgrading/vault-ha-upgrade.mdx @@ -1,60 +1,36 @@ --- layout: docs -page_title: Vault HA upgrades without Autopilot Upgrade Automation (Pre 1.11) +page_title: OpenBao HA upgrades description: |- - Upgrade instructions for Vault HA Pre 1.11 or Vault without autopilot upgrade automation being enabled. Be sure to read the Upgrading-Vault Guides as well. + Upgrade instructions for OpenBao HA. Be sure to read the Upgrading-OpenBao Guides as well. --- -# Vault HA upgrades without autopilot upgrade automation (Pre 1.11) - -This is our recommended upgrade procedure if **one** of the following applies: - -- Running Vault version earlier than 1.11 -- Opt-out the [Autopilot automated upgrade](/vault/docs/concepts/integrated-storage/autopilot#automated-upgrade) features with Vault 1.11 or later -- Running Vault with external storage backend such as Consul +# OpenBao HA upgrades You should consider how to apply the steps described in this document to your particular setup since HA setups can differ on whether a load balancer is in -use, what addresses clients are being given to connect to Vault (standby + +use, what addresses clients are being given to connect to OpenBao (standby + leader, leader-only, or discovered via service discovery), etc. -If you are running on Vault 1.11+ with Integrated Storage and wish to enable the -Autopilot upgrade automation features, read to the [automated -upgrades](/vault/docs/concepts/integrated-storage/autopilot#automated-upgrades) -documentation for details. - - ## HA installations -Regardless of the method you use, do not fail over from a newer version of Vault +Regardless of the method you use, do not fail over from a newer version of OpenBao to an older version. Our suggested procedure is designed to prevent this. -Please note that Vault does not support true zero-downtime upgrades, but with +Please note that OpenBao does not support true zero-downtime upgrades, but with proper upgrade procedure the downtime should be very short (a few hundred milliseconds to a second depending on how the speed of access to the storage backend). - - -If you are currently running on Vault 1.11+ with Integrated Storage and have -chosen to opt-out the Autopilot automated upgrade features, please disable the -default automated upgrade migrations feature of the Vault. Without disabling -this feature, you may run into Lost Quorum issue as described in the [Quorum -lost while upgrading the vault from 1.11.0 to later version of -it](https://support.hashicorp.com/hc/en-us/articles/7122445204755-Quorum-lost-while-upgrading-the-vault-from-1-11-0-to-later-version-of-it) -article. - - - 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()` +1. Properly shut down OpenBao on the standby node via `SIGINT` or `SIGTERM` +2. Replace the OpenBao 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` +5. Verify `bao status` shows correct Version and HA Mode is `standby` 6. Review the node's logs to ensure successful startup and unseal At this point all standby nodes are upgraded and ready to take over. The @@ -70,18 +46,18 @@ To complete the cluster upgrade: It is important that you shut the node down properly. This will perform a step-down and release the HA lock, allowing a standby node to take over with a very short delay. - If you kill Vault without letting it release the lock, a standby node will + If you kill OpenBao without letting it release the lock, a standby node will 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()` +2. Replace the OpenBao 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` +5. Verify `bao status` shows correct Version and HA Mode is `standby` 6. Review the node's logs to ensure successful startup and unseal Internal upgrade tasks will happen after one of the upgraded standby nodes diff --git a/website/content/docs/use-cases.mdx b/website/content/docs/use-cases.mdx index e921f753d9..52b2baadab 100644 --- a/website/content/docs/use-cases.mdx +++ b/website/content/docs/use-cases.mdx @@ -21,7 +21,7 @@ With OpenBao, you can generate short-lived, just-in-time credentials that are au Credentials can be long-lived and static, where they don't change or are changed infrequently. OpenBao 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](/vault/tutorials/secrets-management/versioned-kv) tutorial and learn how a versioned key-value secrets engine protects your static secrets. +- Refer to the [Versioned Key/Value Secrets Engine](/vault/tutorials/secrets-management/versioned-kv) tutorial and learn how a versioned key-value secrets engine protects your static secrets. ### Dynamic secrets diff --git a/website/content/partials/alerts/auditor-deprecated.mdx b/website/content/partials/alerts/auditor-deprecated.mdx deleted file mode 100644 index 17efb708a4..0000000000 --- a/website/content/partials/alerts/auditor-deprecated.mdx +++ /dev/null @@ -1,5 +0,0 @@ - - You can still download the Vault auditor, but we no longer actively support - the tool. We strongly encourage upgrading to - an actively supported version of Vault. - \ No newline at end of file diff --git a/website/content/partials/alerts/rc-alert.mdx b/website/content/partials/alerts/rc-alert.mdx deleted file mode 100644 index cac2771c43..0000000000 --- a/website/content/partials/alerts/rc-alert.mdx +++ /dev/null @@ -1,7 +0,0 @@ - - -The information you are reading is subject to change and should not be -referenced as official guidance until the associated release is generally -available. - - \ No newline at end of file diff --git a/website/content/partials/alpine-314.mdx b/website/content/partials/alpine-314.mdx deleted file mode 100644 index e2c1f87ad9..0000000000 --- a/website/content/partials/alpine-314.mdx +++ /dev/null @@ -1,9 +0,0 @@ -## Alpine 3.14 - -Docker images for Vault 1.6.6+, 1.7.4+, and 1.8.2+ are built with Alpine 3.14, -due to a security issue in Alpine 3.13 (CVE-2021-36159). -Some users on older versions of Docker may run into issues with these images. -See the following for more details: - -- https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.14.0#faccessat2 -- https://about.gitlab.com/blog/2021/08/26/its-time-to-upgrade-docker-engine/ diff --git a/website/content/partials/api/restricted-endpoints.mdx b/website/content/partials/api/restricted-endpoints.mdx deleted file mode 100644 index 3c8508b60e..0000000000 --- a/website/content/partials/api/restricted-endpoints.mdx +++ /dev/null @@ -1,48 +0,0 @@ - - - - The CLI commands associated with restricted API paths are also restricted. - - -API path | Root | Admin -------------------------------------------- | ---- | ----- -`sys/audit` | YES | NO -`sys/audit-hash` | YES | YES -`sys/config/auditing/*` | YES | NO -`sys/config/cors` | YES | NO -`sys/config/group-policy-application` | YES | NO -`sys/config/reload` | YES | NO -`sys/config/state` | YES | NO -`sys/config/ui` | YES | NO -`sys/decode-token` | YES | NO -`sys/experiments` | YES | NO -`sys/generate-recovery-token` | YES | NO -`sys/generate-root` | YES | NO -`sys/health` | YES | NO -`sys/host-info` | YES | NO -`sys/in-flight-req` | YES | NO -`sys/init` | YES | NO -`sys/internal/counters/activity` | YES | NO -`sys/internal/counters/activity/export` | YES | NO -`sys/internal/counters/activity/monthly` | YES | NO -`sys/internal/counters/config` | YES | NO -`sys/internal/inspect/router/*` | YES | NO -`sys/key-status` | YES | NO -`sys/loggers` | YES | NO -`sys/metrics` | YES | NO -`sys/mfa/method/*` | YES | NO -`sys/monitor` | YES | YES -`sys/pprof/*` | YES | NO -`sys/quotas/config` | YES | NO -`sys/quotas/lease-count` | YES | NO -`sys/quotas/rate-limit` | YES | NO -`sys/raw` | YES | NO -`sys/rekey/*` | YES | NO -`sys/rekey-recovery-key` | YES | NO -`sys/rotate/config` | YES | NO -`sys/rotate` | YES | NO -`sys/seal` | YES | NO -`sys/sealwrap/rewrap` | YES | NO -`sys/step-down` | YES | NO -`sys/storage` | YES | NO -`sys/unseal` | YES | NO diff --git a/website/content/partials/application-of-sentinel-rgps-via-identity-groups.mdx b/website/content/partials/application-of-sentinel-rgps-via-identity-groups.mdx deleted file mode 100644 index 881c03d52f..0000000000 --- a/website/content/partials/application-of-sentinel-rgps-via-identity-groups.mdx +++ /dev/null @@ -1,5 +0,0 @@ -As of versions `1.15.0`, `1.14.4`, and `1.13.8`, [the Sentinel RGPSs derived from membership in identity groups apply -only to entities in the same and child namespaces, relative to the identity group](/vault/docs/enterprise/sentinel#rgps-and-namespaces). - -Also, the [`group_policy_application_mode`](/vault/api-docs/system/config-group-policy-application) only applies to -to ACL policies. Vault Sentinel Role Governing Policies (RGPs) are not affected by group policy application mode. diff --git a/website/content/partials/authn-names.mdx b/website/content/partials/authn-names.mdx index 0715610319..9702a66b4c 100644 --- a/website/content/partials/authn-names.mdx +++ b/website/content/partials/authn-names.mdx @@ -1,5 +1,5 @@ In addition to custom authentication methods configured with secure plugins, -Vault supports many standardized authentication methods by default. +OpenBao supports many standardized authentication methods by default. | AuthN method | Unique ID | Configured with | ----------------------------------------------------------------------- | -------------------------------------------- | ---------------- diff --git a/website/content/partials/builds-without-ui.mdx b/website/content/partials/builds-without-ui.mdx deleted file mode 100644 index 3b5c0434d2..0000000000 --- a/website/content/partials/builds-without-ui.mdx +++ /dev/null @@ -1,4 +0,0 @@ -### Core binaries lacking Vault UI - -Core binaries of Vault 1.5.1, 1.4.4, 1.3.8, and 1.2.5 were built without the -Vault UI. Enterprise binaries are not affected. diff --git a/website/content/partials/enterprise-licenses.mdx b/website/content/partials/enterprise-licenses.mdx deleted file mode 100644 index b4ab6a9b18..0000000000 --- a/website/content/partials/enterprise-licenses.mdx +++ /dev/null @@ -1,6 +0,0 @@ -### Enterprise licenses - -In versions 1.2.6, 1.3.9, 1.4.5, and 1.5.2, the enterprise licenses were not incorporated correctly -into the build and we have issued patch releases (x.y.z.1) for enterprise customers containing the -proper license. As the previous builds were both not working and causing confusion, we have removed -the binaries. diff --git a/website/content/partials/entity-alias-mapping.mdx b/website/content/partials/entity-alias-mapping.mdx deleted file mode 100644 index 650a8fe234..0000000000 --- a/website/content/partials/entity-alias-mapping.mdx +++ /dev/null @@ -1,7 +0,0 @@ -## Entity alias mapping - -Previously, an entity in Vault could be mapped to multiple entity aliases on the same authentication backend. This -led to a potential security vulnerability (CVE-2021-43998), as ACL policies templated with alias information would match the first -alias created. Thus, tokens created from all aliases of the entity, will have access to the paths containing alias -metadata of the first alias due to templated policies being incorrectly applied. As a result, the mapping behavior was updated -such that an entity can only have one alias per authentication backend. This change exists in Vault 1.9.0+, 1.8.5+ and 1.7.6+. \ No newline at end of file diff --git a/website/content/partials/faq/client-count/computing-clients.mdx b/website/content/partials/faq/client-count/computing-clients.mdx index 533bba82df..4a4ac146d9 100644 --- a/website/content/partials/faq/client-count/computing-clients.mdx +++ b/website/content/partials/faq/client-count/computing-clients.mdx @@ -1,61 +1,11 @@ -### Can i compute clients for Vault versions before v1.6? ((#before-1-6)) - -@include 'alerts/auditor-deprecated.mdx' - -**Yes**. - -Use the [Vault auditor tool](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool) -to compute and display client count data for Vault v1.3 – v1.5 using the -client compute logic available in Vault 1.7. Auditor use with Vault versions -older than 1.3 is untested. - -### Can i compute KMIP clients for Vault? ((#kmip)) - -**No**. - -Currently, KMIP clients are not available via the usage metrics UI or client -count API. - -### Can i get monthly changes for Vault versions older than v1.10? ((#month-to-month)) - -**Yes, for Vault v1.8 – v1.10.** - -To calculate client counts for a given month, you must perform a series of -billing period updates in the UI and manual calculations: - -Month | Billing period in UI | Result | Computation ---------- | ------------------------ | ------------ | ----------- -January | January | `JAN` | None -February | January   February | `JAN_FEB` | `FEB = JAN_FEB - JAN` -March | January   February | `JAN_MAR` | `MAR = JAN_MAR - JAN_FEB` -April | January   February | `JAN_APR` | `APR = JAN_APR - JAN_MAR` -May | January   February | `JAN_MAY` | `MAY = JAN_MAY - JAN_APR` -June | January   February | `JAN_JUN` | `JUN = JAN_JUN - JAN_MAY` -July | January   February | `JAN_JUL` | `JUL = JAN_JUL - JAN_JUN` -August | January   February | `JAN_AUG` | `AUG = JAN_AUG - JAN_JUL` -September | January   September | `JAN_SEP` | `SEP = JAN_SEP - JAN_AUG` -October | January   February | `JAN_OCT` | `OCT = JAN_OCT - JAN_SEP` -November | January   February | `JAN_NOV` | `NOV = JAN_NOV - JAN_OCT` -December | January   February | `JAN_DEV` | `DEC = JAN_DEC - JAN_NOV` - -### Do child namespaces create duplication in the client count? ((#namespace-dupes)) - -**Maybe**. - -Tokens created in a parent namespace are recognized as the same client when used -in a child namespace. But, tokens created **across** a parent/child namespace -boundary may be counted as multiple clients. See the -[clients and entities](/vault/docs/concepts/client-count) overview for more -details. - -### Does the Nomad-Vault integration affect client counts? ((#nomad)) +### Does the Nomad-Openbao integration affect client counts? ((#nomad)) **Maybe**. -[Nomad Vault integration](/nomad/docs/integrations/vault-integration#token-role-based-integration) +[Nomad Openbao integration](/nomad/docs/integrations/vault-integration#token-role-based-integration) uses token roles where a single token role creates tokens for many Nomad jobs. Unless you have configured explicit identity aliases for your Nomad tokens, -Vault will record every running instance of a Nomad job as a unique client. +Openbao will record every running instance of a Nomad job as a unique client. ### Are batch tokens counted differently than service tokens? ((#batch-tokens)) @@ -63,7 +13,7 @@ Vault will record every running instance of a Nomad job as a unique client. Batch token clients are counted like service token clients. The batch token is mapped to either to the associated active entity or an artificial entity that -Vault creates by combining the assigned namespace and policy. See the +Openbao creates by combining the assigned namespace and policy. See the [clients and entities](/vault/docs/concepts/client-count) overview for more details. @@ -75,16 +25,11 @@ Custom [user filters](/vault/api-docs/auth/ldap#userfilter) can change the way that entity aliases are mapped, which can affect the client count computation. Consult the [clients and entities](/vault/docs/concepts/client-count) overview -for more information about how Vault determines entity assignments. +for more information about how Openbao determines entity assignments. ### Does mount migration affect client counts? ((#mount-migration)) **Maybe**. -If you are using Vault 1.10+: - - Migrating mounts **across** namespace will create duplication in the client count. - Migrating mounts **within** a namespace will not affect client count. - -If you are using an older version of Vault, migrating mounts will always create -duplication in the client count. diff --git a/website/content/partials/faq/client-count/definitions.mdx b/website/content/partials/faq/client-count/definitions.mdx index bd575aa179..63c1c89251 100644 --- a/website/content/partials/faq/client-count/definitions.mdx +++ b/website/content/partials/faq/client-count/definitions.mdx @@ -1,20 +1,9 @@ ### What is a client? ((#what-is-a-client)) -Any unique application, service, or user that authenticates to a HashiCorp -Vault cluster. The client count metric is a combination of entity clients and +Any unique application, service, or user that authenticates to an +OpenBao cluster. The client count metric is a combination of entity clients and non-entity clients. -For billing and consumption, only clients that are active during the billing -period count toward total usage. Clients are only counted once within a billing -period, regardless of how many times that client is active and when that client -authenticates to a cluster, it has unlimited access to that cluster for the -remainder of the billing period. - -| Installation type | Billing period -| ----------------- | --------------- -| HCP | monthly -| Self-managed | annually - Consult the [clients and entities](/vault/docs/concepts/client-count) overview for more information on client definitions. @@ -25,4 +14,4 @@ for more information on client definitions. - **Certificate clients** map to an active ACME PKI certificate. Consult the [clients and entities](/vault/docs/concepts/client-count) overview -for more information about how Vault determines entity assignments. \ No newline at end of file +for more information about how OpenBao determines entity assignments. diff --git a/website/content/partials/faq/client-count/tools.mdx b/website/content/partials/faq/client-count/tools.mdx deleted file mode 100644 index 789e41e228..0000000000 --- a/website/content/partials/faq/client-count/tools.mdx +++ /dev/null @@ -1,21 +0,0 @@ -### What is the Vault auditor? ((##vault-auditor)) - -@include 'alerts/auditor-deprecated.mdx' - -The [Vault auditor tool](/vault/tutorials/monitoring/usage-metrics#vault-auditor-tool) -lets customers running Vault v1.3 – v1.5 compute and display client -count data using the client compute logic available in Vault 1.7. Auditor use -with Vault versions older than 1.3 is untested. - -The auditor may report that your audit logs are unreadable of the logs are too -large or you are running an older version than Vault 1.6. - - -### Are there any known client count issues in the auditor tool? ((#auditor-ki)) - -**Yes**. - -The Vault auditor only includes the computation logic improvements from Vault -v1.6 – v1.7. Running the auditor on Vault v1.8+ will result in -discrepancies when comparing the result to data available through the -Vault UI or API. diff --git a/website/content/partials/faq/client-count/upgrading.mdx b/website/content/partials/faq/client-count/upgrading.mdx index 1a26d921d6..595d3bf2ae 100644 --- a/website/content/partials/faq/client-count/upgrading.mdx +++ b/website/content/partials/faq/client-count/upgrading.mdx @@ -1,79 +1,3 @@ -### How has client count changed across different Vault versions? ((#logic-improvements)) +### What happens to client count when I upgrade? ((#what-happens-at-upgrade)) -Client counts have been available via the usage metrics UI since Vault 1.6. We -have made continual improvements to the Vault client count computation logic -provided in the Vault UI and API. - -| Version | Interface | Accuracy improvement -| :-----: | --------- | -------------------- -| 1.6 | N/A | Introduced client counts as a metric -| 1.8 | All | Eliminated wrapped tokens and control groups and counts active identity entities at usage instead of create time -| 1.9 | All | Improved non-entity token tracking and local auth mount computation logic -| 1.10 | API | Supported data export for unique clients contributing to the client count aggregate for a selected billing period -| 1.10 | UI | Displayed clients per auth mount within a namespace -| 1.11 | API | Supported unique client export for selected billing periods -| 1.11 | UI | Displayed month over month calculations for client count - -The latest GA version of the Vault binary always contains the most updated -version of the client count computation logic. - -### How has the usage metric UI changed across different Vault versions? ((#ui-improvements)) - -| Version | UI improvement -| :-----: | ----------------------------- -| 1.9 | The dashboard added the ability to export client count data for all namespaces and tabs for **Current month** and **Monthly history** that list the top ten namespaces by client count -| 1.10 | Added attribution of clients per authN mount to the **Current month** and **Monthly history** tabs -| 1.11 | Added the ability to view changes in client counts month over month, the running client total, and new monthly clients. - -### Are there any known client count issues in the UI/API? ((#uiapi-ki)) - -**Yes**. - -| Version | Client count issue -| :-----: | ----------------------------- -| 1.9 | Billing period cannot be computed for start and end dates that fall in the middle of a month -| 1.10 | KMIP clients are not provided. -| 1.10 | Data on the **Current month** tab does not take the billing period into account. - -### What happens to client count when i upgrade? ((#what-happens-at-upgrade)) - -**Vault will only reflect the number of active unique clients since the upgrade**. - -We recommend upgrading **before** your next billing period begins so that the -usage metrics UI correctly reflects all clients for the current billing period. - - - If your billing period falls on either side of a Vault upgrade, the compute - logic may be different across the billing period, which will change client - count results and create noisy data. - - - - - Vault 1.9 introduced changes to non-entity token and local auth mount logic - for client counting that affects anyone upgrading from v1.8 to a newer - version: -
    -
  • - Any non-entity tokens created before the upgrade will receive an - artificial client ID the next time the token authenticates to Vault. As - result, the token will be counted as a new client, but will not be - recounted on subsequent connections. -
    • -
  • - Any local auth mounts created before the upgrade will continue to - count as a unique client, but new mounts created after the upgrade will - receive an artificial client ID to avoid duplication in the client count. -
    • -
- - - - As of v1.7, Vault forbids users from creating two aliases from the same authN - mount under a single entity. Additionally, Vault 1.9 forbids mapping multiple - service accounts under different namespaces to a single entity. - - Each unique combination of authN mount, namespace, and alias, will be counted - as a distinct client. - - \ No newline at end of file +**OpenBao will only reflect the number of active unique clients since the upgrade**. diff --git a/website/content/partials/faq/client-count/usage.mdx b/website/content/partials/faq/client-count/usage.mdx index 60201928fd..246a23622b 100644 --- a/website/content/partials/faq/client-count/usage.mdx +++ b/website/content/partials/faq/client-count/usage.mdx @@ -1,40 +1,40 @@ ### Can I view the list of unique client IDs that contributed to my client count aggregate? ((#view-data)) -**Yes, if you are using Vault 1.11 or later**. +**Yes**. -As of Vault 1.11, you can export the list of unique -clients that contributed to your client count for a given billing period with +You can export the list of unique +clients that contributed to your client count for a given period with the [activity export API endpoint](/vault/api-docs/system/internal-counters#activity-export). ### Is clientID viewable in the audit logs for non-entity tokens? ((#clientid-in-logs)) -**Yes, for Vault v1.9+**. +**Yes**. -As of Vault v1.9, audit logs include a field called `clientID` that records the +Audit logs include a field called `clientID` that records the active or computed entity ID of the associated token. -### Can I skip client computation for a period of time during the billing period? ((#skip-computation)) +### Can I skip client computation for a period of time during the period? ((#skip-computation)) **Yes, but the data may be inaccurate**. Breaking up the data will likely result in client duplication. For example, -assume your billing period runs from January 1st to December 31st, and you break +assume your period runs from January 1st to December 31st, and you break the computation into two periods to exclude the month of April: - Period1 runs from January 1st to March 31st - Period2 runs from June 1st to December 31st -Vault treats the two requests independently so January 1st and June 1st are both +OpenBao treats the two requests independently so January 1st and June 1st are both used as a fresh start to re-count unique clients. Any client that was active -during both periods will appear in both result sets, even though Vault will only -counted that client **once** for the actual billing period. +during both periods will appear in both result sets, even though OpenBao will only +counted that client **once** for the actual period. ### Are there conditions that will cause me to lose client data? ((#lost-data)) **Yes**. -The Vault activity log handles client computation. The standby nodes track and +The OpenBao activity log handles client computation. The standby nodes track and accumulate activity log data then transmit updates to the active node over gRPC whenever the log grows by 8KB or 10 minutes has elapsed, whichever happens first. @@ -43,12 +43,12 @@ If a node goes down during the accumulation phase you will lose the untransmitted data in addition to any client count data that would have been collected during the outage. -### What happens if a portion of the data is missing for my billing period? ((#missing-data)) +### What happens if a portion of the data is missing for my period? ((#missing-data)) -**Vault only returns the most recent contiguous set of data**. +**OpenBao only returns the most recent contiguous set of data**. -For example, assume your billing period runs from January 1st to December 31st -but you disabled tracking for the month of April. Vault will look for the +For example, assume your period runs from January 1st to December 31st +but you disabled tracking for the month of April. OpenBao will look for the largest, contiguous window of time where data is available, May through December, and compute results for that period of time. May 2021 through December 2021. @@ -56,16 +56,16 @@ and compute results for that period of time. May 2021 through December 2021. **Yes**. -You can use the Vault API to +You can use the OpenBao API to [update the client count configuration](/vault/api-docs/system/internal-counters#update-the-client-count-configuration) and disable the tracking parameter. If you disable client counting in the middle -of a month, Vault will discard any data currently recorded for the month. Data +of a month, OpenBao will discard any data currently recorded for the month. Data for previous months is preserved. -### Can I configure Vault to log the client count data? ((#log-client-count)) +### Can I configure OpenBao to log the client count data? ((#log-client-count)) **Yes**. -You can use the Vault API to +You can use the OpenBao API to [update the client count configuration](/vault/api-docs/system/internal-counters#update-the-client-count-configuration) and specify your preferred retention period. diff --git a/website/content/partials/known-issues/aws-static-roles.mdx b/website/content/partials/known-issues/aws-static-roles.mdx deleted file mode 100644 index 75122d43c5..0000000000 --- a/website/content/partials/known-issues/aws-static-roles.mdx +++ /dev/null @@ -1,16 +0,0 @@ -### AWS static roles ignore changes to rotation period ((#aws-static-role-rotation)) - -#### Affected versions - -- 1.14.0+ - -#### Issue - -AWS static roles currently ignore configuration changes made to the key rotation -period. As a result, Vault will continue to use whatever rotation period was set -when the roles were originally created. - -#### Workaround - -Delete and recreate any static role objects that should use the new rotation -period. diff --git a/website/content/partials/known-issues/ephemeral-loggers-memory-leak.mdx b/website/content/partials/known-issues/ephemeral-loggers-memory-leak.mdx deleted file mode 100644 index c45281560b..0000000000 --- a/website/content/partials/known-issues/ephemeral-loggers-memory-leak.mdx +++ /dev/null @@ -1,20 +0,0 @@ -### Vault is storing references to ephemeral sub-loggers leading to unbounded memory consumption - -#### Affected versions - -This memory consumption bug affects Vault Community and Enterprise versions: - -- 1.13.7 - 1.13.9 -- 1.14.3 - 1.14.5 -- 1.15.0 - 1.15.1 - -This change that introduced this bug has been reverted as of 1.13.10, 1.14.6, and 1.15.2 - -#### Issue -Vault is unexpectedly storing references to ephemeral sub-loggers which prevents them from being cleaned up, leading to -unbound memory consumption for loggers. This came about from a change to address a previously known issue around -[sub-logger levels not being adjusted on reload](#sublogger-levels-unchanged-on-reload). -This impacts many areas of Vault, but primarily logins in Enterprise. - -#### Workaround -There is no workaround. diff --git a/website/content/partials/known-issues/expiration-metrics-fatal-error.mdx b/website/content/partials/known-issues/expiration-metrics-fatal-error.mdx deleted file mode 100644 index 2a539756f2..0000000000 --- a/website/content/partials/known-issues/expiration-metrics-fatal-error.mdx +++ /dev/null @@ -1,22 +0,0 @@ -### Fatal error during expiration metrics gathering causing Vault crash - -#### Affected versions - -This issue affects Vault Community and Enterprise versions: -- 1.13.9 -- 1.14.5 -- 1.15.1 - -A fix has been issued in Vault 1.13.10, 1.14.6, and 1.15.2. - -#### Issue - -A recent change to Vault to improve state change speed (e.g. becoming active or standby) introduced a concurrency issue -which can lead to a concurrent iteration and write on a map, causing a fatal error and crashing Vault. This error occurs -when gathering lease and token metrics from the expiration manager. These metrics originate from the active node in a HA -cluster, as such a standby node will take over active duties and the cluster will remain functional should the original -active node encounter this bug. The new active node will be vulnerable to the same bug, but may not encounter it immediately. - -There is no workaround. - - diff --git a/website/content/partials/known-issues/internal-error-namespace-missing-policy.mdx b/website/content/partials/known-issues/internal-error-namespace-missing-policy.mdx deleted file mode 100644 index 13d2eb4f5e..0000000000 --- a/website/content/partials/known-issues/internal-error-namespace-missing-policy.mdx +++ /dev/null @@ -1,143 +0,0 @@ -### Internal error when vault policy in namespace does not exist -If a user is a member of a group that gets a policy from a -namespace other than the one they’re trying to log into, -and that policy doesn’t exist, Vault returns an internal error. -This impacts all auth methods. - -#### Affected versions -- 1.13.8 and 1.13.9 -- 1.14.4 and 1.14.5 -- 1.15.0 and 1.15.1 - -A fix will be released in Vault 1.15.2, 1.14.6, and 1.13.10. - -### Workaround - -During authentication, Vault derives inherited policies based on the groups an -entity belongs to. Vault returns an internal error when attaching the derived -policy to a token when: - -1. the token belongs to a different namespace than the one handling - authentication, and -2. the derived policy does not exist under the namespace. - - -You can resolve the error by adding the policy to the relevant namespace or -deleting the group policy mapping that uses the derived policy. - -As an example, consider the following userpass auth method failure. The error is -due to the fact that Vault expects a group policy under the namespace that does -not exist. - - - -```shell-session -# Failed login -$ vault login -method=userpass username=user1 password=123 -Error authenticating: Error making API request. - -URL: PUT http://127.0.0.1:8200/v1/auth/userpass/login/user1 -Code: 500. Errors: - -* internal error -``` - - - -To confirm the problem is a missing policy, start by identifying the relevant -entity and group IDs: - - - -```shell-session -$ vault read -format=json identity/entity/name/user1 | \ - jq '{"entity_id": .data.id, "group_ids": .data.group_ids} ' -{ - "entity_id": "420c82de-57c3-df2e-2ef6-0690073b1636", - "group_ids": [ - "6cb152b7-955d-272b-4dcf-a2ed668ca1ea" - ] -} -``` - - - -Use the group ID to fetch the relevant policies for the group under the `ns1` -namespace: - - - -```shell-session -$ vault read -format=json -namespace=ns1 \ - identity/group/id/6cb152b7-955d-272b-4dcf-a2ed668ca1ea | \ - jq '.data.policies' -[ - "group_policy" -] -``` - - - -Now that we know Vault is looking for a policy called `group_policy`, we can -check whether that policy exists under the `ns1` namespace: - - - -```shell-session -$ vault policy list -namespace=ns1 -default -``` - - - -The only policy in the `ns1` namespace is `default`, which confirms that the -missing policy (`group_policy`) is causing the error. - - -To fix the problem, we can either remove the missing policy from the -`6cb152b7-955d-272b-4dcf-a2ed668ca1ea` group or create the missing policy under -the `ns1` namespace. - - - - - -To remove `group_policy` from group ID `6cb152b7-955d-272b-4dcf-a2ed668ca1ea`, -use the `vault write` command to set the applicable policies to just include -`default`: - -```shell-session -$ vault write \ - -namespace=ns1 \ - identity/group/id/6cb152b7-955d-272b-4dcf-a2ed668ca1ea \ - name="test" \ - policies="default" -``` - - - - - -To create the missing policy, use `vault policy write` and define the -appropriate capabilities: - -```shell-session -$ vault policy write -namespace=ns1 group_policy - << EOF - path "secret/data/*" { - capabilities = ["create", "update"] - } -EOF -``` - - - - -Verify the fix by re-running the login command: - - - -```shell-session -$ vault login -method=userpass username=user1 password=123 -``` - - \ No newline at end of file diff --git a/website/content/partials/known-issues/sublogger-levels-unchanged-on-reload.mdx b/website/content/partials/known-issues/sublogger-levels-unchanged-on-reload.mdx deleted file mode 100644 index 33c72e2b7e..0000000000 --- a/website/content/partials/known-issues/sublogger-levels-unchanged-on-reload.mdx +++ /dev/null @@ -1,32 +0,0 @@ -### Sublogger levels not adjusted on reload ((#sublogger-levels-unchanged-on-reload)) - -#### Affected versions - -This issue affects all Vault Community and Vault Enterprise versions. - -#### Issue - -Vault does not honor a modified `log_level` configuration for certain subsystem -loggers on SIGHUP. - -The issue is known to specifically affect `resolver.watcher` and -`replication.index.*` subloggers. - -After modifying the `log_level` and issuing a reload (SIGHUP), some loggers are -updated to reflect the new configuration, while some subsystem logger levels -remain unchanged. - -For example, after starting a server with `log_level: "trace"` and modifying it -to `log_level: "info"` the following lines appear after reload: - -``` -[TRACE] resolver.watcher: dr mode doesn't have failover support, returning -... -[DEBUG] replication.index.perf: saved checkpoint: num_dirty=5 -[DEBUG] replication.index.local: saved checkpoint: num_dirty=0 -[DEBUG] replication.index.periodic: starting WAL GC: from=2531280 to=2531280 last=2531536 -``` - -#### Workaround - -The workaround is to restart the Vault server. diff --git a/website/content/partials/known-issues/transit-managed-keys-panics.mdx b/website/content/partials/known-issues/transit-managed-keys-panics.mdx deleted file mode 100644 index 7cea98da8b..0000000000 --- a/website/content/partials/known-issues/transit-managed-keys-panics.mdx +++ /dev/null @@ -1,23 +0,0 @@ -### Transit Encryption with Cloud KMS managed keys causes a panic - -#### Affected versions - -- 1.13.1+ up to 1.13.8 inclusively -- 1.14.0+ up to 1.14.4 inclusively -- 1.15.0 - -#### Issue - -Vault panics when it receives a Transit encryption API call that is backed by a Cloud KMS managed key (Azure, GCP, AWS). - - -The issue does not affect encryption and decryption with the following key types: - -- PKCS#11 managed keys -- Transit native keys - - - -#### Workaround - -None at this time diff --git a/website/content/partials/known-issues/transit-managed-keys-sign-fails.mdx b/website/content/partials/known-issues/transit-managed-keys-sign-fails.mdx deleted file mode 100644 index 69e0bf2711..0000000000 --- a/website/content/partials/known-issues/transit-managed-keys-sign-fails.mdx +++ /dev/null @@ -1,23 +0,0 @@ -### Transit Sign API calls with managed keys fail - -#### Affected versions - -- 1.14.0+ up to 1.14.4 inclusively -- 1.15.0 - -#### Issue - -Vault responds to Transit sign API calls with the following error when the request uses a managed key: - -`requested version for signing does not contain a private part` - - -The issue does not affect signing with the following key types: - -- Transit native keys - - - -#### Workaround - -None at this time diff --git a/website/content/partials/known-issues/ui-collapsed-navbar.mdx b/website/content/partials/known-issues/ui-collapsed-navbar.mdx deleted file mode 100644 index 08d28f137d..0000000000 --- a/website/content/partials/known-issues/ui-collapsed-navbar.mdx +++ /dev/null @@ -1,16 +0,0 @@ -### Collapsed navbar does not allow you to click inside the console or namespace picker - -#### Affected versions - -The UI issue affects Vault versions 1.14.0+ and 1.15.0+. -A fix is expected for Vault 1.16.0. - -#### Issue - -The Vauil UI currently uses a version of HDS that does not allow users to click -within collapsed elements. In particular, the dev console or namespace picker -become inaccessible when viewing the components in smaller viewports. - -#### Workaround - -Expand the width of the screen until you deactivate the collapsed view. Once the full navbar is displayed, click the desired components. \ No newline at end of file diff --git a/website/content/partials/known-issues/ui-pki-control-groups.mdx b/website/content/partials/known-issues/ui-pki-control-groups.mdx deleted file mode 100644 index fbdbf6358c..0000000000 --- a/website/content/partials/known-issues/ui-pki-control-groups.mdx +++ /dev/null @@ -1,17 +0,0 @@ -### Users limited by control groups can only access issuer detail from PKI overview page ((#ui-pki-control-groups)) - -#### Affected versions - -- Vault 1.14.x - -#### Issue - -Vault UI users who require control group approval to read issuer details are -directed to the Control Group Access page when they try to view issuer details -from links on the Issuer list page. - -#### Workaround - -Vault UI users constrained by control groups should select issuers from the -**PKI overview** page to view detailed information instead of the -**Issuers list** page. \ No newline at end of file diff --git a/website/content/partials/known-issues/ui-safari-login-screen.mdx b/website/content/partials/known-issues/ui-safari-login-screen.mdx deleted file mode 100644 index 37373b6204..0000000000 --- a/website/content/partials/known-issues/ui-safari-login-screen.mdx +++ /dev/null @@ -1,13 +0,0 @@ -### Safari login screen appears broken on the UI - -#### Affected versions - -- 1.14.0 - -#### Issue - -The login screen on Safari appears to be broken, presenting as a blank white screen. - -#### Workaround - -Scroll down to find the login section. \ No newline at end of file diff --git a/website/content/partials/known-issues/update-primary-addrs-panic.mdx b/website/content/partials/known-issues/update-primary-addrs-panic.mdx deleted file mode 100644 index d7e63828e8..0000000000 --- a/website/content/partials/known-issues/update-primary-addrs-panic.mdx +++ /dev/null @@ -1,16 +0,0 @@ -### Using 'update_primary_addrs' on a demoted cluster causes Vault to panic ((#update-primary-addrs-panic)) - -#### Affected versions - -- 1.13.3, 1.13.4 & 1.14.0 - -#### Issue - -If the [`update_primary_addrs`](/vault/api-docs/system/replication/replication-performance#update_primary_addrs) -parameter is used on a recently demoted cluster, Vault will panic due to no longer -having information about the primary cluster. - -#### Workaround - -Instead of using `update_primary_addrs` on the recently demoted cluster, instead provide an -[activation token](/vault/api-docs/system/replication/replication-performance#token-1). \ No newline at end of file diff --git a/website/content/partials/known-issues/update-primary-data-loss.mdx b/website/content/partials/known-issues/update-primary-data-loss.mdx deleted file mode 100644 index 955b798ccd..0000000000 --- a/website/content/partials/known-issues/update-primary-data-loss.mdx +++ /dev/null @@ -1,57 +0,0 @@ -### API calls to update-primary may lead to data loss ((#update-primary-data-loss)) - -#### Affected versions - -All versions of Vault before 1.14.1, 1.13.5, 1.12.9, and 1.11.12. - -#### Issue - -The [update-primary](/vault/api-docs/system/replication/replication-performance#update-performance-secondary-s-primary) -endpoint temporarily removes all mount entries except for those that are managed -automatically by vault (e.g. identity mounts). In certain situations, a race -condition between mount table truncation replication repairs may lead to data -loss when updating secondary replication clusters. - -Situations where the race condition may occur: - -- **When the cluster has local data (e.g., PKI certificates, app role secret IDs) - in shared mounts**. - Calling `update-primary` on a performance secondary with local data in shared - mounts may corrupt the merkle tree on the secondary. The secondary still - contains all the previously stored data, but the corruption means that - downstream secondaries will not receive the shared data and will interpret the - update as a request to delete the information. If the downstream secondary is - promoted before the merkle tree is repaired, the newly promoted secondary will - not contain the expected local data. The missing data may be unrecoverable if - the original secondary is is lost or destroyed. -- **When the cluster has an `Allow` paths defined.** - As of Vault 1.0.3.1, startup, unseal, and calling `update-primary` all trigger a - background job that looks at the current mount data and removes invalid entries - based on path filters. When a secondary has `Allow` path filters, the cleanup - code may misfire in the windown of time after update-primary truncats the mount - tables but before the mount tables are rewritten by replication. The cleanup - code deletes data associated with the missing mount entries but does not modify - the merkle tree. Because the merkle tree remains unchanged, replication will not - know that the data is missing and needs to be repaired. - -#### Workaround 1: PR secondary with local data in shared mounts - -Watch for `cleaning key in merkle tree` in the TRACE log immediately after an -update-primary call on a PR secondary to indicate the merkle tree may be -corrupt. Repair the merkle tree by issuing a -[replication reindex request](/vault/api-docs/system/replication#reindex-replication) -to the PR secondary. - -If TRACE logs are no longer available, we recommend pre-emptively reindexing the -PR secondary as a precaution. - -#### Workaround 2: PR secondary with "Allow" path filters - -Watch for `deleted mistakenly stored mount entry from backend` in the INFO log. -Reindex the performance secondary to update the merkle tree with the missing -data and allow replication to disseminate the changes. **You will not be able to -recover local data on shared mounts (e.g., PKI certificates)**. - -If INFO logs are no longer available, query the shared mount in question to -confirm whether your role and configuration data are present on the primary but -missing from the secondary. diff --git a/website/content/partials/ldap-upndomain-issue.mdx b/website/content/partials/ldap-upndomain-issue.mdx deleted file mode 100644 index df32e08410..0000000000 --- a/website/content/partials/ldap-upndomain-issue.mdx +++ /dev/null @@ -1,6 +0,0 @@ -## LDAP auth engine and upndomain - -Users of the LDAP auth engine with the `upndomain` configuration setting populated -should hold off on upgrading to 1.4.x for now. We are investigating a regression -introduced by [#8333](https://github.com/hashicorp/vault/pull/8333). There is -no Github issue for this bug yet. diff --git a/website/content/partials/lease-count-quota-upgrade.mdx b/website/content/partials/lease-count-quota-upgrade.mdx deleted file mode 100644 index 81a529efec..0000000000 --- a/website/content/partials/lease-count-quota-upgrade.mdx +++ /dev/null @@ -1,5 +0,0 @@ -### Lease count quota invalidations on DR secondaries fixed - -Lease count quota invalidation causes DR Secondaries to panic and experience -a hard shutdown. This issue exists prior to Vault 1.6.6 and 1.7.4. It is -fixed in Vault 1.6.6, 1.7.4, and 1.8.0. diff --git a/website/content/partials/ocsp-redirect.mdx b/website/content/partials/ocsp-redirect.mdx deleted file mode 100644 index a41c3562ed..0000000000 --- a/website/content/partials/ocsp-redirect.mdx +++ /dev/null @@ -1,11 +0,0 @@ -### PKI OCSP GET requests can return HTTP redirect responses - -If a base64 encoded OCSP request contains consecutive '/' characters, the GET request -will return a 301 permanent redirect response. If the redirection is followed, the -request will not decode as it will not be a properly base64 encoded request. - -As a workaround, OCSP POST requests can be used which are unaffected. - -#### Impacted versions - -Affects all current versions of 1.12.x and 1.13.x diff --git a/website/content/partials/okta-group-pagination.mdx b/website/content/partials/okta-group-pagination.mdx deleted file mode 100644 index 4a74af24d2..0000000000 --- a/website/content/partials/okta-group-pagination.mdx +++ /dev/null @@ -1,8 +0,0 @@ -## Okta auth with > 200 groups - -In 1.4.0 Vault started using the official Okta Go client library. Unlike -the previous Okta library it used, the official library doesn't automatically -handle pagination when there are more than 200 groups listed. If a user -associated with more than 200 Okta groups logs in, only 200 of them will be -seen by Vault. The fix is [#9580](https://github.com/hashicorp/vault/pull/9580) -and will eventually appear in 1.4.x and 1.5.x point releases. diff --git a/website/content/partials/perf-standby-token-create-forwarding-failure.mdx b/website/content/partials/perf-standby-token-create-forwarding-failure.mdx deleted file mode 100644 index b36f861f33..0000000000 --- a/website/content/partials/perf-standby-token-create-forwarding-failure.mdx +++ /dev/null @@ -1,19 +0,0 @@ -### Token creation with a new entity alias could silently fail - -A regression caused token creation requests under specific circumstances to be -forwarded from perf standbys (Enterprise only) to the active node incorrectly. -They would appear to succeed, however no lease was created. The token would then -be revoked on first use causing a 403 error. - -This only happened when all of the following conditions were met: - - the token is being created against a role - - the request specifies an entity alias which has never been used before with - the same role (for example for a brand new role or a unique alias) - - the request happens to be made to a perf standby rather than the active node - -Retrying token creation after the affected token is rejected would work since -the entity alias has already been created. - -#### Affected versions - -Affects Vault 1.13.0 to 1.13.3. Fixed in 1.13.4. diff --git a/website/content/partials/pgx-params.mdx b/website/content/partials/pgx-params.mdx deleted file mode 100644 index 544820a52d..0000000000 --- a/website/content/partials/pgx-params.mdx +++ /dev/null @@ -1,5 +0,0 @@ -### Postgres library change - -Vault 1.11+ uses pgx instead of lib/pq for Postgres connections. If you are -using parameters like `fallback_application_name` that pgx does not support, you -may need to update your `connection_url` before upgrading to Vault 1.11+. diff --git a/website/content/partials/pki-double-migration-bug.mdx b/website/content/partials/pki-double-migration-bug.mdx deleted file mode 100644 index e1ff94c637..0000000000 --- a/website/content/partials/pki-double-migration-bug.mdx +++ /dev/null @@ -1,30 +0,0 @@ -### PKI storage migration revives deleted issuers - -Vault 1.11 introduced Storage v1, a new storage layout that supported -multiple issuers within a single mount. Bug fixes in Vault 1.11.6, 1.12.2, -and 1.13.0 corrected a write-ordering issue that lead to invalid CA chains. -Specifically, incorrectly ordered writes could fail due to load, resulting -in the mount being re-migrated next time it was loaded or silently -truncating CA chains. This collection of bug fixes introduced Storage v2. - -#### Affected versions - -Vault may incorrectly re-migrated legacy issuers created before Vault 1.11 that -were migrated to Storage v1 and deleted before upgrading to a Vault version with -Storage v2. - -The migration fails when Vault finds managed keys associated with the legacy -issuers that were removed from the managed key repository prior to the upgrade. - -The migration error appears in Vault logs as: - -> Error during migration of PKI mount: -> failed to lookup public key from managed key: -> no managed key found with uuid - - -Issuers created in Vault 1.11+ and direct upgrades to a Storage v2 layout are -not affected. - - -The Storage v1 upgrade bug was fixed in Vault 1.14.1, 1.13.5, and 1.12.9. diff --git a/website/content/partials/pki-forwarding-bug.mdx b/website/content/partials/pki-forwarding-bug.mdx deleted file mode 100644 index c48a6d8e92..0000000000 --- a/website/content/partials/pki-forwarding-bug.mdx +++ /dev/null @@ -1,10 +0,0 @@ -## PKI certificate generation forwarding regression - -A bug introduced in Vault 1.8 causes certificate generation requests to the PKI secrets engine made on a performance -secondary node to be forwarded to the cluster's primary node. The resulting certificates are stored on the primary node, -and thus visible to list and read certificate requests only on the primary node rather than the secondary node as -intended. Furthermore, if a certificate is subsequently revoked on a performance secondary node, the secondary's -certificate revocation list is updated, rather than the primary's where the certificate is stored. This bug is fixed -in Vault 1.8.8 and 1.9.3. -Certificates issued after the fix are correctly stored locally to the performance secondary. - diff --git a/website/content/partials/plugin-file-permissions-check.mdx b/website/content/partials/plugin-file-permissions-check.mdx index 92dcdbe3db..fcf439f5b9 100644 --- a/website/content/partials/plugin-file-permissions-check.mdx +++ b/website/content/partials/plugin-file-permissions-check.mdx @@ -1,5 +1,5 @@ Enabling the file permissions check via the environment variable `VAULT_ENABLE_FILE_PERMISSIONS_CHECK` -allows Vault to check if the config directory and files are owned by the user running Vault. +allows OpenBao to check if the config directory and files are owned by the user running OpenBao. It also checks if there are no write or execute permissions for group or others. -Vault allows operators to specify the user and permissions of the plugin directory and binaries -using parameters `plugin_file_uid` and `plugin_file_permissions` in config if an operator needs those to be different. This check is disabled by default. \ No newline at end of file +OpenBao allows operators to specify the user and permissions of the plugin directory and binaries +using parameters `plugin_file_uid` and `plugin_file_permissions` in config if an operator needs those to be different. This check is disabled by default. diff --git a/website/content/partials/plugin-versioning.mdx b/website/content/partials/plugin-versioning.mdx index 5859fcf5f5..8455d8ece8 100644 --- a/website/content/partials/plugin-versioning.mdx +++ b/website/content/partials/plugin-versioning.mdx @@ -1,7 +1,7 @@ Plugins can optionally self-report their own semantic version. For plugins that -do so, Vault will automatically populate the plugin's version in the catalog +do so, OpenBao will automatically populate the plugin's version in the catalog without requiring the user to provide it. If users do provide a version during -registration, Vault will error if the version provided does not match what the +registration, OpenBao will error if the version provided does not match what the plugin reports. Plugins that report a non-empty version _must_ report a valid [Semantic Version](https://semver.org/) with a leading 'v' added or registration will fail, e.g. `v1.0.0` or `v2.3.2-beta`. @@ -9,6 +9,3 @@ will fail, e.g. `v1.0.0` or `v2.3.2-beta`. Plugins that want to opt into this behavior can implement the version interface. However, it is not a prerequisite; users can still provide a version during registration if the plugin does not implement the version interface. - -To implement the version interface, plugins should first upgrade the Vault SDK -package to at least v0.6.0. \ No newline at end of file diff --git a/website/content/partials/primary-cluster-addr-change.mdx b/website/content/partials/primary-cluster-addr-change.mdx deleted file mode 100644 index ef9c34e80b..0000000000 --- a/website/content/partials/primary-cluster-addr-change.mdx +++ /dev/null @@ -1,16 +0,0 @@ -### Primary cluster address change - -In Vault 1.4.0-1.4.3, a secondary cluster with a single `primary_cluster_addr` -configured will obtain the address of the active node in the primary cluster -via replication heartbeats from the primary cluster. - -If the `api_addr` and `cluster_addr` in the heartbeats from the primary -cluster are not reachable from the secondary cluster, replication will not -work. This situation can arise if, for example, `primary_cluster_addr` -corresponds to a load balancer accessible from the secondary cluster, but the -`api_addr` and `cluster_addr` on the primary cluster are only accessible -from the primary cluster. - -In Vault 1.4.4, we will use the `primary_cluster_addr` if it has been set, -instead of relying on the heartbeat information, but it's possible to -encounter this issue in Vault 1.4.0-1.4.3. diff --git a/website/content/partials/raft-large-snapshots.mdx b/website/content/partials/raft-large-snapshots.mdx index ccacecf5d6..541ccef451 100644 --- a/website/content/partials/raft-large-snapshots.mdx +++ b/website/content/partials/raft-large-snapshots.mdx @@ -1,6 +1,6 @@ ### Large raft snapshots -Taking and restoring Raft snapshots can exceed Vault's default and recommended +Taking and restoring Raft snapshots can exceed OpenBao's default and recommended timeout settings. The [`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-panic-old-tls-key.mdx b/website/content/partials/raft-panic-old-tls-key.mdx deleted file mode 100644 index 43f8160978..0000000000 --- a/website/content/partials/raft-panic-old-tls-key.mdx +++ /dev/null @@ -1,17 +0,0 @@ -### Integrated storage panic related to old TLS key - -Raft in Vault uses its own set of TLS certificates, independent of those that the user -controls to protect the API port and those used for replication and clustering. These -certs get rotated daily, but to ensure that nodes which were down or behind on Raft log -replication don't lose the ability to speak with other nodes, the newly generated daily -TLS cert only starts being used once we see that all nodes have received it. - -A recent security audit related change results in this rotation code [getting a -panic](https://github.com/hashicorp/vault/issues/15147) when the current cert is -more than 24h old. This can happen if the cluster as a whole is down for a day -or more. It can also happen if a single node is unreachable 24h, or sufficiently -backlogged in applying raft logs that it's more than a day behind. - -Impacted versions: 1.10.1, 1.9.5, 1.8.10. Versions prior to these are unaffected. - -New releases addressing this panic are coming soon. diff --git a/website/content/partials/raft-retry-join-failure.mdx b/website/content/partials/raft-retry-join-failure.mdx deleted file mode 100644 index cb87e79c63..0000000000 --- a/website/content/partials/raft-retry-join-failure.mdx +++ /dev/null @@ -1,24 +0,0 @@ -### Cluster initialization hangs with `retry_join` - -The -[`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](/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 -https://github.com/hashicorp/vault/commit/cc6409222ce246ed72d067debe6ffeb8f62f9dad -and first reported in https://github.com/hashicorp/vault/issues/16486. - -#### Impacted versions - -Affects versions 1.11.1, 1.11.2, 1.10.5, and 1.10.6. Versions prior to these -are unaffected. - -NOTE: This error does not extend to version 1.9.8+, which is slightly different -in this portion of the code and does not exhibit the same behavior. - -New releases addressing this bug are coming soon. diff --git a/website/content/partials/release-notes/deprecation-note.mdx b/website/content/partials/release-notes/deprecation-note.mdx deleted file mode 100644 index 1c222d194b..0000000000 --- a/website/content/partials/release-notes/deprecation-note.mdx +++ /dev/null @@ -1,4 +0,0 @@ -Please refer to the [Deprecation Plans and Notice](/vault/docs/deprecation) page -for up-to-date information on feature deprecations and plans or the [Feature -Deprecation FAQ](/vault/docs/deprecation/faq) for general questions about -our deprecation process. \ No newline at end of file diff --git a/website/content/partials/release-notes/intro.mdx b/website/content/partials/release-notes/intro.mdx deleted file mode 100644 index 5ec87fdd76..0000000000 --- a/website/content/partials/release-notes/intro.mdx +++ /dev/null @@ -1,8 +0,0 @@ -Release notes provide an at-a-glance summary of key updates to new versions of -Vault. For a comprehensive list of product updates, improvements, and bug fixes -refer to the [changelog](https://github.com/openbao/openbao/blob/main/CHANGELOG.md) -included with the Vault code on GitHub. - -We encourage you to -[upgrade to the latest release of Vault](/vault/docs/upgrading) -to take advantage of continuing improvements, critical fixes, and new features. \ No newline at end of file diff --git a/website/content/partials/telemetry-metrics/runtime-note.mdx b/website/content/partials/telemetry-metrics/runtime-note.mdx index f0e424e415..5ead77fc2c 100644 --- a/website/content/partials/telemetry-metrics/runtime-note.mdx +++ b/website/content/partials/telemetry-metrics/runtime-note.mdx @@ -1,2 +1,2 @@ -Runtime metrics relate specifically to the **Go runtime** for your Vault -instance. \ No newline at end of file +Runtime metrics relate specifically to the **Go runtime** for your OpenBao +instance. diff --git a/website/content/partials/telemetry-metrics/vault/audit/log_request_failure.mdx b/website/content/partials/telemetry-metrics/vault/audit/log_request_failure.mdx index 1bad614551..d8c56b09f1 100644 --- a/website/content/partials/telemetry-metrics/vault/audit/log_request_failure.mdx +++ b/website/content/partials/telemetry-metrics/vault/audit/log_request_failure.mdx @@ -7,9 +7,9 @@ counter | number | Number of audit log request failures across all devices The number of request failures is a **crucial metric**. A non-zero value for `vault.audit.log_request_failure` indicates that all your -configured audit devices failed to log a request (or response). If Vault cannot +configured audit devices failed to log a request (or response). If OpenBao cannot properly audit a request, or the response to a request, the original request will fail. -Refer to the Vault logs and any device-specific metrics to troubleshoot the -failing audit log device. \ No newline at end of file +Refer to the OpenBao logs and any device-specific metrics to troubleshoot the +failing audit log device. diff --git a/website/content/partials/telemetry-metrics/vault/audit/log_response_failure.mdx b/website/content/partials/telemetry-metrics/vault/audit/log_response_failure.mdx index 4abbabf005..7d860f92c8 100644 --- a/website/content/partials/telemetry-metrics/vault/audit/log_response_failure.mdx +++ b/website/content/partials/telemetry-metrics/vault/audit/log_response_failure.mdx @@ -7,9 +7,9 @@ counter | number | Number of audit log request failures across all devices The number of request failures is a **crucial metric**. A non-zero value for `vault.audit.log_response_failure` indicates that one of -the configured audit log devices failed to respond to Vault. If Vault cannot +the configured audit log devices failed to respond to OpenBao. If OpenBao cannot properly audit a request, or the response to a request, the original request will fail. Refer to the device-specific metrics and logs to troubleshoot the failing audit -log device. \ No newline at end of file +log device. diff --git a/website/content/partials/telemetry-metrics/vault/core/active.mdx b/website/content/partials/telemetry-metrics/vault/core/active.mdx index 982a3866d2..5e4d0b617d 100644 --- a/website/content/partials/telemetry-metrics/vault/core/active.mdx +++ b/website/content/partials/telemetry-metrics/vault/core/active.mdx @@ -2,7 +2,7 @@ Metric type | Value | Description ----------- | ------- | ----------- -gauge | boolean | Indicates whether the Vault node is active +gauge | boolean | Indicates whether the OpenBao node is active - A value of `1` indicates that the node is active. -- A value of `0` indicates that the node is in standby. \ No newline at end of file +- A value of `0` indicates that the node is in standby. diff --git a/website/content/partials/telemetry-metrics/vault/core/leadership_setup_failed.mdx b/website/content/partials/telemetry-metrics/vault/core/leadership_setup_failed.mdx index 7ceefd09f0..d6d5222de1 100644 --- a/website/content/partials/telemetry-metrics/vault/core/leadership_setup_failed.mdx +++ b/website/content/partials/telemetry-metrics/vault/core/leadership_setup_failed.mdx @@ -5,6 +5,6 @@ Metric type | Value | Description summary | ms | Time taken by the most recent leadership setup failure Setup failure time is an important health metric for your high-availability -Vault installation. We strongly recommend that you closely monitor +OpenBao installation. We strongly recommend that you closely monitor `vault.core.leadership_setup_failed` and set alerts that keep you informed of -the overall cluster leadership status. \ No newline at end of file +the overall cluster leadership status. diff --git a/website/content/partials/telemetry-metrics/vault/core/locked_users.mdx b/website/content/partials/telemetry-metrics/vault/core/locked_users.mdx index 5d267d8322..77fbbd9a4d 100644 --- a/website/content/partials/telemetry-metrics/vault/core/locked_users.mdx +++ b/website/content/partials/telemetry-metrics/vault/core/locked_users.mdx @@ -2,6 +2,6 @@ Metric type | Value | Description ----------- | ----- | ----------- -gauge | users | The number of users currently locked out of Vault +gauge | users | The number of users currently locked out of OpenBao -The number of locked users refreshes every 15 minutes. \ No newline at end of file +The number of locked users refreshes every 15 minutes. diff --git a/website/content/partials/telemetry-metrics/vault/core/seal.mdx b/website/content/partials/telemetry-metrics/vault/core/seal.mdx deleted file mode 100644 index 625d91c7de..0000000000 --- a/website/content/partials/telemetry-metrics/vault/core/seal.mdx +++ /dev/null @@ -1,5 +0,0 @@ -### vault.core.seal ((#vault-core-seal)) - -Metric type | Value | Description ------------ | ----- | ----------- -summary | ms | Time required to complete seal operations \ No newline at end of file diff --git a/website/content/partials/telemetry-metrics/vault/core/seal_internal.mdx b/website/content/partials/telemetry-metrics/vault/core/seal_internal.mdx index b56e47b801..a348464ae8 100644 --- a/website/content/partials/telemetry-metrics/vault/core/seal_internal.mdx +++ b/website/content/partials/telemetry-metrics/vault/core/seal_internal.mdx @@ -2,4 +2,4 @@ Metric type | Value | Description ----------- | ----- | ----------- -summary | ms | Time required to complete internal Vault seal operations \ No newline at end of file +summary | ms | Time required to complete internal OpenBao seal operations diff --git a/website/content/partials/telemetry-metrics/vault/core/unsealed.mdx b/website/content/partials/telemetry-metrics/vault/core/unsealed.mdx index b89881b766..22952ab7ce 100644 --- a/website/content/partials/telemetry-metrics/vault/core/unsealed.mdx +++ b/website/content/partials/telemetry-metrics/vault/core/unsealed.mdx @@ -2,9 +2,9 @@ Metric type | Value | Description ----------- | ------- | ----------- -gauge | boolean | Indicates whether Vault is currently unsealed +gauge | boolean | Indicates whether OpenBao is currently unsealed -- A value of `1` indicates Vault is currently **unsealed** and clients **can** +- A value of `1` indicates OpenBao is currently **unsealed** and clients **can** + read secrets. +- A value of `0` indicates OpenBao is currently **sealed** and clients **cannot** read secrets. -- A value of `0` indicates Vault is currently **sealed** and clients **cannot** - read secrets. \ No newline at end of file diff --git a/website/content/partials/telemetry-metrics/vault/expire/leases/by_expiration.mdx b/website/content/partials/telemetry-metrics/vault/expire/leases/by_expiration.mdx index 5370662091..1778756872 100644 --- a/website/content/partials/telemetry-metrics/vault/expire/leases/by_expiration.mdx +++ b/website/content/partials/telemetry-metrics/vault/expire/leases/by_expiration.mdx @@ -5,11 +5,11 @@ Metric type | Value | Description gauge | leases | The number of leases set to expire, grouped by the configured interval The relevant time intervals are defined in the telemetry stanza for your -Vault server configuration with the following parameters: +OpenBao server configuration with the following parameters: - `lease_metrics_epsilon`: 1 hour (default) - `num_lease_metrics_buckets`: 168 hours (default) - `add_lease_metrics_namespace_labels`: false (default) -Vault reports the number of leases due to expire every `lease_metrics_epsilon` -interval in the time period `current_time + num_lease_metrics_buckets`. \ No newline at end of file +OpenBao reports the number of leases due to expire every `lease_metrics_epsilon` +interval in the time period `current_time + num_lease_metrics_buckets`. diff --git a/website/content/partials/telemetry-metrics/vault/identity/entity/active/monthly.mdx b/website/content/partials/telemetry-metrics/vault/identity/entity/active/monthly.mdx index f635152be1..61c9d8f509 100644 --- a/website/content/partials/telemetry-metrics/vault/identity/entity/active/monthly.mdx +++ b/website/content/partials/telemetry-metrics/vault/identity/entity/active/monthly.mdx @@ -4,5 +4,5 @@ Metric type | Value | Description ----------- | -------- | ----------- gauge | entities | The number of distinct entities (per namespace) that created a token during the past month -Vault reports `vault.identity.entity.active.monthly` at the start of each month -when client counting is enabled. \ No newline at end of file +OpenBao reports `vault.identity.entity.active.monthly` at the start of each month +when client counting is enabled. diff --git a/website/content/partials/telemetry-metrics/vault/identity/entity/active/partial_month.mdx b/website/content/partials/telemetry-metrics/vault/identity/entity/active/partial_month.mdx index 38ef1261ca..e946265fc8 100644 --- a/website/content/partials/telemetry-metrics/vault/identity/entity/active/partial_month.mdx +++ b/website/content/partials/telemetry-metrics/vault/identity/entity/active/partial_month.mdx @@ -4,5 +4,5 @@ Metric type | Value | Description ----------- | -------- | ----------- gauge | entities | The number of distinct entities (per namespace) that created a token during the current month -Vault reports `vault.identity.entity.active.partial_month` periodically during -the month when client counting is enabled. \ No newline at end of file +OpenBao reports `vault.identity.entity.active.partial_month` periodically during +the month when client counting is enabled. diff --git a/website/content/partials/telemetry-metrics/vault/identity/entity/active/reporting_period.mdx b/website/content/partials/telemetry-metrics/vault/identity/entity/active/reporting_period.mdx index 7ba234c3f5..59b09935a0 100644 --- a/website/content/partials/telemetry-metrics/vault/identity/entity/active/reporting_period.mdx +++ b/website/content/partials/telemetry-metrics/vault/identity/entity/active/reporting_period.mdx @@ -4,5 +4,5 @@ Metric type | Value | Description ----------- | -------- | ----------- gauge | entities | The number of distinct entities (per namespace) that created a token during the configured reporting period -Vault reports `vault.identity.entity.active.reporting_period` at the start of -each month when client counting is enabled. \ No newline at end of file +OpenBao reports `vault.identity.entity.active.reporting_period` at the start of +each month when client counting is enabled. diff --git a/website/content/partials/telemetry-metrics/vault/identity/entity/alias/count.mdx b/website/content/partials/telemetry-metrics/vault/identity/entity/alias/count.mdx index 6a0395d466..13b93aa17b 100644 --- a/website/content/partials/telemetry-metrics/vault/identity/entity/alias/count.mdx +++ b/website/content/partials/telemetry-metrics/vault/identity/entity/alias/count.mdx @@ -2,6 +2,6 @@ Metric type | Value | Description ----------- | ------- | ----------- -gauge | aliases | The number of identity entities aliases (per authN mount) currently stored in Vault +gauge | aliases | The number of identity entities aliases (per authN mount) currently stored in OpenBao -Vault updates the alias count every `usage_guage_period` interval. \ No newline at end of file +OpenBao updates the alias count every `usage_guage_period` interval. diff --git a/website/content/partials/telemetry-metrics/vault/identity/entity/count.mdx b/website/content/partials/telemetry-metrics/vault/identity/entity/count.mdx index 439ef4ad1e..4d26e3e9ce 100644 --- a/website/content/partials/telemetry-metrics/vault/identity/entity/count.mdx +++ b/website/content/partials/telemetry-metrics/vault/identity/entity/count.mdx @@ -2,4 +2,4 @@ Metric type | Value | Description ----------- | -------- | ----------- -gauge | entities | The number of identity entity aliases (per namespace) currently stored in Vault \ No newline at end of file +gauge | entities | The number of identity entity aliases (per namespace) currently stored in OpenBao diff --git a/website/content/partials/telemetry-metrics/vault/identity/num_entities.mdx b/website/content/partials/telemetry-metrics/vault/identity/num_entities.mdx index 0e04a862dc..0cdcfa697e 100644 --- a/website/content/partials/telemetry-metrics/vault/identity/num_entities.mdx +++ b/website/content/partials/telemetry-metrics/vault/identity/num_entities.mdx @@ -2,4 +2,4 @@ Metric type | Value | Description ----------- | -------- | ----------- -gauge | entities | The total number of identity entities currently stored in Vault +gauge | entities | The total number of identity entities currently stored in OpenBao diff --git a/website/content/partials/telemetry-metrics/vault/logshipper/streamwals/guard_found.mdx b/website/content/partials/telemetry-metrics/vault/logshipper/streamwals/guard_found.mdx index d4a92efc12..cc724e232a 100644 --- a/website/content/partials/telemetry-metrics/vault/logshipper/streamwals/guard_found.mdx +++ b/website/content/partials/telemetry-metrics/vault/logshipper/streamwals/guard_found.mdx @@ -2,4 +2,4 @@ Metric type | Value | Description ----------- | ------- | ----------- -counter | number | Number of times Vault began streaming WAL entires and found a starting index in the merkle tree \ No newline at end of file +counter | number | Number of times OpenBao began streaming WAL entires and found a starting index in the merkle tree diff --git a/website/content/partials/telemetry-metrics/vault/logshipper/streamwals/missing_guard.mdx b/website/content/partials/telemetry-metrics/vault/logshipper/streamwals/missing_guard.mdx index e07ee008fa..b0c29d4e90 100644 --- a/website/content/partials/telemetry-metrics/vault/logshipper/streamwals/missing_guard.mdx +++ b/website/content/partials/telemetry-metrics/vault/logshipper/streamwals/missing_guard.mdx @@ -2,4 +2,4 @@ Metric type | Value | Description ----------- | ------- | ----------- -counter | number | Number of times Vault began streaming WAL entires without finding a starting index in the Merkle tree \ No newline at end of file +counter | number | Number of times OpenBao began streaming WAL entires without finding a starting index in the Merkle tree diff --git a/website/content/partials/telemetry-metrics/vault/logshipper/streamwals/scanned_entries.mdx b/website/content/partials/telemetry-metrics/vault/logshipper/streamwals/scanned_entries.mdx index 701aed9850..4eb25edeab 100644 --- a/website/content/partials/telemetry-metrics/vault/logshipper/streamwals/scanned_entries.mdx +++ b/website/content/partials/telemetry-metrics/vault/logshipper/streamwals/scanned_entries.mdx @@ -2,4 +2,4 @@ Metric type | Value | Description ----------- | ------- | ----------- -summary | entries | Number of entries scanned in the buffer before Vault found the correct entry \ No newline at end of file +summary | entries | Number of entries scanned in the buffer before OpenBao found the correct entry diff --git a/website/content/partials/telemetry-metrics/vault/metrics/collection/error.mdx b/website/content/partials/telemetry-metrics/vault/metrics/collection/error.mdx index 2529ee94bb..f191d37c99 100644 --- a/website/content/partials/telemetry-metrics/vault/metrics/collection/error.mdx +++ b/website/content/partials/telemetry-metrics/vault/metrics/collection/error.mdx @@ -2,4 +2,4 @@ Metric type | Value | Description ----------- | ------- | ----------- -counter | number | The total number of errors (per gauge type) that Vault encountered while collecting usage data \ No newline at end of file +counter | number | The total number of errors (per gauge type) that OpenBao encountered while collecting usage data diff --git a/website/content/partials/telemetry-metrics/vault/route/rollback/mountpoint.mdx b/website/content/partials/telemetry-metrics/vault/route/rollback/mountpoint.mdx index 5101e16948..3174f45603 100644 --- a/website/content/partials/telemetry-metrics/vault/route/rollback/mountpoint.mdx +++ b/website/content/partials/telemetry-metrics/vault/route/rollback/mountpoint.mdx @@ -4,5 +4,5 @@ Metric type | Value | Description ----------- | ----- | ----------- summary | ms | Time required to send a rollback request to the backend and for the backend to complete the operation for the given mount point -Vault automatically schedules and performs mount point rollback operations to -clean up partial errors. \ No newline at end of file +OpenBao automatically schedules and performs mount point rollback operations to +clean up partial errors. diff --git a/website/content/partials/telemetry-metrics/vault/runtime/alloc_bytes.mdx b/website/content/partials/telemetry-metrics/vault/runtime/alloc_bytes.mdx index 021ca1bb47..b21717fbb0 100644 --- a/website/content/partials/telemetry-metrics/vault/runtime/alloc_bytes.mdx +++ b/website/content/partials/telemetry-metrics/vault/runtime/alloc_bytes.mdx @@ -2,7 +2,7 @@ Metric type | Value | Description ----------- | ----- | ----------- -gauge | bytes | Space currently allocated to Vault processes +gauge | bytes | Space currently allocated to OpenBao processes The number of allocated bytes may peak from time to time, but should -always return to a steady state value in a health Vault installation. \ No newline at end of file +always return to a steady state value in a health OpenBao installation. diff --git a/website/content/partials/telemetry-metrics/vault/runtime/heap_objects.mdx b/website/content/partials/telemetry-metrics/vault/runtime/heap_objects.mdx index 74d40f1eb7..8fe6f76e8d 100644 --- a/website/content/partials/telemetry-metrics/vault/runtime/heap_objects.mdx +++ b/website/content/partials/telemetry-metrics/vault/runtime/heap_objects.mdx @@ -6,4 +6,4 @@ gauge | number | Total number of objects on the heap in memory The `vault.runtime.heap_objects` metric is a good memory pressure indicator. We recommend monitoring `vault.runtime.heap_objects` to establish an accurate -baseline and thresholds for alerting on the health of your Vault installation. \ No newline at end of file +baseline and thresholds for alerting on the health of your OpenBao installation. diff --git a/website/content/partials/telemetry-metrics/vault/runtime/num_goroutines.mdx b/website/content/partials/telemetry-metrics/vault/runtime/num_goroutines.mdx index 6386fe7453..8272c289b2 100644 --- a/website/content/partials/telemetry-metrics/vault/runtime/num_goroutines.mdx +++ b/website/content/partials/telemetry-metrics/vault/runtime/num_goroutines.mdx @@ -6,4 +6,4 @@ gauge | number | Total number of Go routines running in memory The `vault.runtime.num_goroutines` metric is a good system load indicator. We recommend monitoring `vault.runtime.num_goroutines` to establish an accurate -baseline and thresholds for alerting on the health of your Vault installation. \ No newline at end of file +baseline and thresholds for alerting on the health of your OpenBao installation. diff --git a/website/content/partials/telemetry-metrics/vault/runtime/sys_bytes.mdx b/website/content/partials/telemetry-metrics/vault/runtime/sys_bytes.mdx index 3919c23e49..d9806e0cb5 100644 --- a/website/content/partials/telemetry-metrics/vault/runtime/sys_bytes.mdx +++ b/website/content/partials/telemetry-metrics/vault/runtime/sys_bytes.mdx @@ -2,8 +2,8 @@ Metric type | Value | Description ----------- | ------- | ----------- -gauge | number | Total number of bytes allocated to Vault +gauge | number | Total number of bytes allocated to OpenBao The total number of allocated system bytes includes space currently used by the heap plus space that has been reclaimed by, but not returned to, the operating -system. \ No newline at end of file +system. diff --git a/website/content/partials/telemetry-metrics/vault/runtime/total_gc_pause_ns.mdx b/website/content/partials/telemetry-metrics/vault/runtime/total_gc_pause_ns.mdx index 1811ab7a29..a2cb40cd7a 100644 --- a/website/content/partials/telemetry-metrics/vault/runtime/total_gc_pause_ns.mdx +++ b/website/content/partials/telemetry-metrics/vault/runtime/total_gc_pause_ns.mdx @@ -2,4 +2,4 @@ Metric type | Value | Description ----------- | ----- | ----------- -gauge | ns | The total garbage collector pause time since Vault was last started \ No newline at end of file +gauge | ns | The total garbage collector pause time since OpenBao was last started diff --git a/website/content/partials/telemetry-metrics/vault/runtime/total_gc_runs.mdx b/website/content/partials/telemetry-metrics/vault/runtime/total_gc_runs.mdx index f2c9666ebb..7a9f9c8c38 100644 --- a/website/content/partials/telemetry-metrics/vault/runtime/total_gc_runs.mdx +++ b/website/content/partials/telemetry-metrics/vault/runtime/total_gc_runs.mdx @@ -2,4 +2,4 @@ Metric type | Value | Description ----------- | ------- | ----------- -gauge | number | The total number of garbage collection runs since Vault was last started \ No newline at end of file +gauge | number | The total number of garbage collection runs since OpenBao was last started diff --git a/website/content/partials/telemetry-metrics/vault/secret/kv/count.mdx b/website/content/partials/telemetry-metrics/vault/secret/kv/count.mdx index 226f964ff9..49d406428b 100644 --- a/website/content/partials/telemetry-metrics/vault/secret/kv/count.mdx +++ b/website/content/partials/telemetry-metrics/vault/secret/kv/count.mdx @@ -4,4 +4,4 @@ Metric type | Value | Description ----------- | ------- | ----------- gauge | number | Number of entries in each key-value secrets engines -Vault organizes the key-value pair count by cluster, namespace, and mount point. \ No newline at end of file +OpenBao organizes the key-value pair count by cluster, namespace, and mount point. diff --git a/website/content/partials/telemetry-metrics/vault/secret/lease/creation.mdx b/website/content/partials/telemetry-metrics/vault/secret/lease/creation.mdx index 3649d0c0b0..6aae2f53a2 100644 --- a/website/content/partials/telemetry-metrics/vault/secret/lease/creation.mdx +++ b/website/content/partials/telemetry-metrics/vault/secret/lease/creation.mdx @@ -4,5 +4,5 @@ Metric type | Value | Description ----------- | ------- | ----------- counter | number | Number of leases created by secrets engines -Vault organizes the lease count by cluster, namespace, secret engine, mount -point, and time to live (TTL). \ No newline at end of file +OpenBao organizes the lease count by cluster, namespace, secret engine, mount +point, and time to live (TTL). diff --git a/website/content/partials/telemetry-metrics/vault/token/count.mdx b/website/content/partials/telemetry-metrics/vault/token/count.mdx index a5a0e6c104..144254c48b 100644 --- a/website/content/partials/telemetry-metrics/vault/token/count.mdx +++ b/website/content/partials/telemetry-metrics/vault/token/count.mdx @@ -4,5 +4,5 @@ Metric type | Value | Description ----------- | ------- | ----------- gauge | number | Number of un-expired and un-revoked tokens available for use in the token store -Vault updates the token count every 10 minutes organizes the result by cluster -and namespace. \ No newline at end of file +OpenBao updates the token count every 10 minutes organizes the result by cluster +and namespace. diff --git a/website/content/partials/telemetry-metrics/vault/token/count/by_auth.mdx b/website/content/partials/telemetry-metrics/vault/token/count/by_auth.mdx index 5e418cf5f7..b382f000fd 100644 --- a/website/content/partials/telemetry-metrics/vault/token/count/by_auth.mdx +++ b/website/content/partials/telemetry-metrics/vault/token/count/by_auth.mdx @@ -4,5 +4,5 @@ Metric type | Value | Description ----------- | ------- | ----------- gauge | number | Total number of service tokens created by a particular auth method -Vault organizes the token count by cluster, namespace, and authentication -method. \ No newline at end of file +OpenBao organizes the token count by cluster, namespace, and authentication +method. diff --git a/website/content/partials/telemetry-metrics/vault/token/count/by_policy.mdx b/website/content/partials/telemetry-metrics/vault/token/count/by_policy.mdx index 0d8abce212..0808fec024 100644 --- a/website/content/partials/telemetry-metrics/vault/token/count/by_policy.mdx +++ b/website/content/partials/telemetry-metrics/vault/token/count/by_policy.mdx @@ -4,5 +4,5 @@ Metric type | Value | Description ----------- | ------- | ----------- gauge | number | Total number of service tokens with a particular policy attached -Vault organizes the token count by cluster, namespace, and policy. Tokens with -more than one policy attached appear in the gauge for each associated policy. \ No newline at end of file +OpenBao organizes the token count by cluster, namespace, and policy. Tokens with +more than one policy attached appear in the gauge for each associated policy. diff --git a/website/content/partials/telemetry-metrics/vault/token/count/by_ttl.mdx b/website/content/partials/telemetry-metrics/vault/token/count/by_ttl.mdx index c42426efd0..464f27edcf 100644 --- a/website/content/partials/telemetry-metrics/vault/token/count/by_ttl.mdx +++ b/website/content/partials/telemetry-metrics/vault/token/count/by_ttl.mdx @@ -4,5 +4,5 @@ Metric type | Value | Description ----------- | ------- | ----------- gauge | number | Total number of service tokens assigned a particular time to live (TTL) -Vault organizes the token count by cluster, namespace, and the TTL -range assigned at creation. \ No newline at end of file +OpenBao organizes the token count by cluster, namespace, and the TTL +range assigned at creation. diff --git a/website/content/partials/telemetry-metrics/vault/token/create.mdx b/website/content/partials/telemetry-metrics/vault/token/create.mdx index e76ef22228..5c6e6b405d 100644 --- a/website/content/partials/telemetry-metrics/vault/token/create.mdx +++ b/website/content/partials/telemetry-metrics/vault/token/create.mdx @@ -2,4 +2,4 @@ Metric type | Value | Description ----------- | ----- | ----------- -summary | ms | Time required to create a token in Vault \ No newline at end of file +summary | ms | Time required to create a token in OpenBao diff --git a/website/content/partials/telemetry-metrics/vault/token/createaccessor.mdx b/website/content/partials/telemetry-metrics/vault/token/createaccessor.mdx index ceef939e86..ba43e29a19 100644 --- a/website/content/partials/telemetry-metrics/vault/token/createaccessor.mdx +++ b/website/content/partials/telemetry-metrics/vault/token/createaccessor.mdx @@ -2,4 +2,4 @@ Metric type | Value | Description ----------- | ----- | ----------- -summary | ms | Time required to create a token accessor in Vault \ No newline at end of file +summary | ms | Time required to create a token accessor in OpenBao diff --git a/website/content/partials/telemetry-metrics/vault/token/creation.mdx b/website/content/partials/telemetry-metrics/vault/token/creation.mdx index 4abeaa8736..2737f403ac 100644 --- a/website/content/partials/telemetry-metrics/vault/token/creation.mdx +++ b/website/content/partials/telemetry-metrics/vault/token/creation.mdx @@ -4,5 +4,5 @@ Metric type | Value | Description ----------- | ------- | ----------- counter | number | Number of service or batch tokens created -Vault organizes the creation count by cluster, namespace, authentication method, -mount point, time to live (TTL), and token type. \ No newline at end of file +OpenBao organizes the creation count by cluster, namespace, authentication method, +mount point, time to live (TTL), and token type. diff --git a/website/content/partials/telemetry-metrics/vault/token/lookup.mdx b/website/content/partials/telemetry-metrics/vault/token/lookup.mdx index 6376d42e1f..66da87d3fe 100644 --- a/website/content/partials/telemetry-metrics/vault/token/lookup.mdx +++ b/website/content/partials/telemetry-metrics/vault/token/lookup.mdx @@ -2,4 +2,4 @@ Metric type | Value | Description ----------- | ----- | ----------- -summary | ms | Time required to look up a token in Vault \ No newline at end of file +summary | ms | Time required to look up a token in OpenBao diff --git a/website/content/partials/telemetry-metrics/vault/token/revoke.mdx b/website/content/partials/telemetry-metrics/vault/token/revoke.mdx index 1560291b8d..cfc559b22a 100644 --- a/website/content/partials/telemetry-metrics/vault/token/revoke.mdx +++ b/website/content/partials/telemetry-metrics/vault/token/revoke.mdx @@ -2,4 +2,4 @@ Metric type | Value | Description ----------- | ----- | ----------- -summary | ms | Time required to revoke a token in Vault \ No newline at end of file +summary | ms | Time required to revoke a token in OpenBao diff --git a/website/content/partials/telemetry-metrics/vault/token/revoke_tree.mdx b/website/content/partials/telemetry-metrics/vault/token/revoke_tree.mdx index 56e4004b9d..a1ab52258d 100644 --- a/website/content/partials/telemetry-metrics/vault/token/revoke_tree.mdx +++ b/website/content/partials/telemetry-metrics/vault/token/revoke_tree.mdx @@ -2,4 +2,4 @@ Metric type | Value | Description ----------- | ----- | ----------- -summary | ms | Time required to fully revoke a token tree in Vault \ No newline at end of file +summary | ms | Time required to fully revoke a token tree in OpenBao diff --git a/website/content/partials/telemetry/supported-aggregation-agents.mdx b/website/content/partials/telemetry/supported-aggregation-agents.mdx index 47e1e04a87..22c44e47f5 100644 --- a/website/content/partials/telemetry/supported-aggregation-agents.mdx +++ b/website/content/partials/telemetry/supported-aggregation-agents.mdx @@ -1,4 +1,4 @@ -Vault uses the `go-metrics` package to export telemetry and supports the +OpenBao uses the `go-metrics` package to export telemetry and supports the following aggregation agents for time-series monitoring: Config prefix | Name | Company diff --git a/website/content/partials/tokenization-rotation-persistence.mdx b/website/content/partials/tokenization-rotation-persistence.mdx deleted file mode 100644 index 7cd971a2ee..0000000000 --- a/website/content/partials/tokenization-rotation-persistence.mdx +++ /dev/null @@ -1,14 +0,0 @@ -### Rotation configuration persistence issue could lose transform tokenization key versions - -A rotation performed manually or via automatic time based rotation after -restarting or leader change of Vault, where configuration of rotation was -changed since the initial configuration of the tokenization transform can -result in the loss of intermediate key versions. Tokenized values from -these versions would not be decodeable. It is recommended that customers -who have enabled automatic rotation disable it, and other customers avoid -key rotation until the upcoming fix. - -#### Affected versions - -This issue affects Vault Enterprise with ADP versions 1.10.x and higher. A -fix will be released in Vault 1.11.9, 1.12.5, and 1.13.1. diff --git a/website/content/partials/transform-upgrade.mdx b/website/content/partials/transform-upgrade.mdx deleted file mode 100644 index fc08e551b2..0000000000 --- a/website/content/partials/transform-upgrade.mdx +++ /dev/null @@ -1,8 +0,0 @@ -### Transform storage upgrades fixed - -The Transform Secrets Engine storage upgrade introduced in 1.6.0 introduced -malformed configuration for transformations configured earlier than 1.6.0, -resulting in an error using these transformations if Vault is restarted -after the upgrade. This issue exists on Vault 1.6.0 through 1.6.3, and is fixed -in Vault 1.6.4 and 1.7.0. Transformations configured on 1.6.0 or higher are -unaffected. diff --git a/website/content/partials/ui-pki-control-groups-known-issue.mdx b/website/content/partials/ui-pki-control-groups-known-issue.mdx deleted file mode 100644 index ed7b03ab1a..0000000000 --- a/website/content/partials/ui-pki-control-groups-known-issue.mdx +++ /dev/null @@ -1,17 +0,0 @@ -### Users limited by control groups can only access issuer detail from PKI overview page ((#ui-pki-control-groups)) - -#### Affected versions - -- Vault 1.14.x - -#### Issue - -Vault UI users who require control group approval to read issuer details are -directed to the Control Group Access page when they try to view issuer details -from links on the Issuer list page. - -#### Workaround - -Vault UI users constrained by control groups should select issuers from the -**PKI overview** page to view detailed information instead of the -**Issuers list** page. diff --git a/website/content/partials/ui-safari-login-screen.mdx b/website/content/partials/ui-safari-login-screen.mdx deleted file mode 100644 index 37373b6204..0000000000 --- a/website/content/partials/ui-safari-login-screen.mdx +++ /dev/null @@ -1,13 +0,0 @@ -### Safari login screen appears broken on the UI - -#### Affected versions - -- 1.14.0 - -#### Issue - -The login screen on Safari appears to be broken, presenting as a blank white screen. - -#### Workaround - -Scroll down to find the login section. \ No newline at end of file diff --git a/website/content/partials/user-lockout.mdx b/website/content/partials/user-lockout.mdx index 288cb7e1ec..38f53f958f 100644 --- a/website/content/partials/user-lockout.mdx +++ b/website/content/partials/user-lockout.mdx @@ -1,5 +1,5 @@ If a user provides bad credentials several times in quick succession, -Vault will stop trying to validate their credentials for a while, instead returning immediately +OpenBao will stop trying to validate their credentials for a while, instead returning immediately with a permission denied error. We call this behavior "user lockout". The time for which a user will be locked out is called “lockout duration”. The user will be able to login after the lockout duration has passed. The number of failed login attempts after which the user is locked out is called @@ -19,4 +19,4 @@ The user lockout feature can be disabled as follows: - 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 the userpass, ldap, and approle auth methods. \ No newline at end of file +~> **NOTE**: This feature is only supported by the userpass, ldap, and approle auth methods. diff --git a/website/content/partials/x509-sha1-deprecation.mdx b/website/content/partials/x509-sha1-deprecation.mdx index ff030daa41..e9d4db252b 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 + usable without a workaround. 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 information. \ No newline at end of file + for more information.