remove old Vault version docs

Signed-off-by: Jan Martens <jan@martens.eu.org>

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

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.

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

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.

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

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)

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
@@ -248,12 +246,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

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 | 
 
 

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

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

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.
 

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`
 

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

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

website/content/docs/concepts/client-count/faq.mdx

@@ -14,9 +14,7 @@ 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) |
@@ -60,7 +58,3 @@ description: |-
 ## Usage ((#usage))
 
 @include 'faq/client-count/usage.mdx'
-
-## OpenBao auditor tool ((#auditor))
-
-@include 'faq/client-count/tools.mdx'

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.
 
-<Note title="Behavior change in Vault 1.9+">
-  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.
+<Note title="Behavior of non-enter tokens">
+  All non-entity tokens with the same namespace and policy assignments are
+  treated as the same client entity. 
 </Note>
 
 @include "content-footer-title.mdx"