From 91face4effdfd1cec53f24d13d0c73ddd7e2418b Mon Sep 17 00:00:00 2001 From: Sarah Chavis <62406755+schavis@users.noreply.github.com> Date: Tue, 15 Aug 2023 10:31:52 -0700 Subject: [PATCH] convert OSS language to "community" (#22343) --- website/content/api-docs/relatedtools.mdx | 2 +- .../content/api-docs/secret/identity/mfa/index.mdx | 4 ++-- website/content/api-docs/secret/pki.mdx | 2 +- .../content/api-docs/system/internal-counters.mdx | 2 +- website/content/api-docs/system/mfa/index.mdx | 2 +- website/content/docs/auth/login-mfa/faq.mdx | 14 +++++++------- .../docs/concepts/integrated-storage/index.mdx | 2 +- website/content/docs/concepts/mount-migration.mdx | 4 ++-- website/content/docs/concepts/storage.mdx | 6 +++--- website/content/docs/deprecation/faq.mdx | 2 +- website/content/docs/deprecation/index.mdx | 10 +++++----- website/content/docs/enterprise/license/faq.mdx | 4 ++-- website/content/docs/faq/ssct.mdx | 6 +++--- website/content/docs/platform/aws/index.mdx | 2 +- website/content/docs/platform/k8s/vso/index.mdx | 3 +-- .../content/docs/platform/k8s/vso/installation.mdx | 2 +- website/content/docs/release-notes/1.10.0.mdx | 10 +++++----- website/content/docs/release-notes/1.11.0.mdx | 2 +- website/content/docs/release-notes/1.14.0.mdx | 2 +- website/content/docs/upgrading/index.mdx | 4 ++-- .../content/docs/upgrading/upgrade-to-1.10.x.mdx | 2 +- .../content/docs/upgrading/upgrade-to-1.12.x.mdx | 2 +- .../content/docs/upgrading/upgrade-to-1.8.x.mdx | 2 +- website/content/partials/builds-without-ui.mdx | 4 ++-- 24 files changed, 47 insertions(+), 48 deletions(-) diff --git a/website/content/api-docs/relatedtools.mdx b/website/content/api-docs/relatedtools.mdx index 78db6fd9f2..12b0732b11 100644 --- a/website/content/api-docs/relatedtools.mdx +++ b/website/content/api-docs/relatedtools.mdx @@ -34,7 +34,7 @@ The following list of tools is maintained by the community of Vault users; Hashi - [vsh](https://github.com/fishi0x01/vsh) - Interactive shell with tab-completion. Allows recursive operations on paths. Allows migration of secrets between both KV versions. - [vault-cli](https://github.com/IBM/vault-cli) - A yaml based automation tool that bootstraps Vault cluster(s) with the desired configuration (namespaces, endpoints, policies, roles, endpoint) - [vault-go](https://github.com/IBM/vault-go) - Helper Golang Vault types as Kubernetes Custom Resource Definitions (CRD) -- [HashiBox](https://github.com/nunchistudio/hashibox) - Vagrant environment to simulate highly-available cloud with Consul, Nomad, Vault, and optional support for Waypoint. OSS & Enterprise supported. +- [HashiBox](https://github.com/nunchistudio/hashibox) - Vagrant environment to simulate highly-available cloud with Consul, Nomad, Vault, and optional support for Waypoint. Community & Enterprise supported. - [vkv](https://github.com/FalcoSuessgott/vkv) - Recursively list key-values entries from Vaults KV2 engine in various formats. Want to add your own project, or one that you use? Additions are welcome via [pull requests](https://github.com/hashicorp/vault/blob/main/website/content/api-docs/relatedtools.mdx). diff --git a/website/content/api-docs/secret/identity/mfa/index.mdx b/website/content/api-docs/secret/identity/mfa/index.mdx index 5f441af358..39923c3e19 100644 --- a/website/content/api-docs/secret/identity/mfa/index.mdx +++ b/website/content/api-docs/secret/identity/mfa/index.mdx @@ -22,6 +22,6 @@ description: >- - [Login Enforcement](/vault/api-docs/secret/identity/mfa/login-enforcement) - [MFA Validate](/vault/api-docs/system/mfa/validate) -While the above endpoints are available in both the open source and Enterprise versions of Vault, +While the above endpoints are available in all editions of Vault, they are namespace aware. MFA methods and login enforcements created in one namespace are separate from other -namespaces. In the open source version of Vault, everything operates in the root namespace. +namespaces. In the community version of Vault, everything operates in the root namespace. diff --git a/website/content/api-docs/secret/pki.mdx b/website/content/api-docs/secret/pki.mdx index d8bf059183..67165ebbe1 100644 --- a/website/content/api-docs/secret/pki.mdx +++ b/website/content/api-docs/secret/pki.mdx @@ -4099,7 +4099,7 @@ the CRL. ~> Note: The `unified_crl`, `unified_crl_on_existing_paths`, and `cross_cluster_revocation` parameters are all Vault Enterprise only - functionality. While they appear in the responses on Vault OSS, they cannot + functionality. While they appear in the responses on Vault Community Edition, they cannot be enabled. | Method | Path | diff --git a/website/content/api-docs/system/internal-counters.mdx b/website/content/api-docs/system/internal-counters.mdx index 42d46b550e..9d841e13ac 100644 --- a/website/content/api-docs/system/internal-counters.mdx +++ b/website/content/api-docs/system/internal-counters.mdx @@ -873,7 +873,7 @@ The `/sys/internal/counters/config` endpoint is used to configure logging of act - `default_report_months` `(integer: 12)` - The number of months to report if no `start_time` is specified in a query. - `enabled` `(string: enable, disable, default)` - Enable or disable counting of client activity. When set to `default`, the client - counts are enabled on Enterprise builds and disabled on OSS builds. Disabling the feature during the middle of a month will + counts are enabled on Enterprise builds and disabled on community builds. Disabling the feature during the middle of a month will discard any data recorded for that month, but does not delete previous months. - `retention_months` `(integer: 24)` - The number of months of history to retain. diff --git a/website/content/api-docs/system/mfa/index.mdx b/website/content/api-docs/system/mfa/index.mdx index cd07b63e0d..0a114c1a6a 100644 --- a/website/content/api-docs/system/mfa/index.mdx +++ b/website/content/api-docs/system/mfa/index.mdx @@ -31,7 +31,7 @@ returns an ID when a method is created. Although MFA methods supported with Step - Step-up Enterprise MFA: `sys/mfa/method/:type/:/name` - Login MFA: `identity/mfa/method/:type` -~> **Note:** While the `sys/mfa` endpoint is supported for both OSS and Vault Enterprise, `sys/mfa/method/:type/:/name` is only supported for Vault Enterprise. +~> **Note:** While the `sys/mfa` endpoint is supported for both Vault Community and Enterprise editions, `sys/mfa/method/:type/:/name` is only supported for Vault Enterprise. Refer to the [Login MFA FAQ](/vault/docs/auth/login-mfa/faq#q-are-there-new-mfa-api-endpoints-introduced-as-part-of-the-new-vault-version-1-10-mfa-for-login-functionality) document diff --git a/website/content/docs/auth/login-mfa/faq.mdx b/website/content/docs/auth/login-mfa/faq.mdx index 62a3bd25a2..8c8e46698c 100644 --- a/website/content/docs/auth/login-mfa/faq.mdx +++ b/website/content/docs/auth/login-mfa/faq.mdx @@ -26,23 +26,23 @@ This FAQ section contains frequently asked questions about the Login MFA feature Vault supports Step-up Enterprise MFA as part of our Enterprise edition. The Step-up Enterprise MFA provides MFA on login, or for step-up access to sensitive resources in Vault using ACL and Sentinel policies, and is configurable through the CLI/API. -Starting with Vault version 1.10, Vault OSS provides [MFA on login](/vault/docs/auth/login-mfa) only. This is also available with Vault Enterprise and configurable through the CLI/API. +Starting with Vault version 1.10, Vault Community Edition provides [MFA on login](/vault/docs/auth/login-mfa) only. This is also available with Vault Enterprise and configurable through the CLI/API. The Step-up Enterprise MFA will co-exist with the newly introduced Login MFA starting with Vault version 1.10. ### Q: what are the various MFA workflows that are available to me as a Vault user as of Vault version 1.10, and how are they different? -| MFA workflow | What does it do? | Who manages the MFA? | OSS vs. Enterprise Support | +| MFA workflow | What does it do? | Who manages the MFA? | Community vs. Enterprise Support | | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | ----------------------------- | -| [Login MFA](/vault/docs/auth/login-mfa) | MFA in Vault OSS provides MFA on login. CLI, API, and UI-based login are supported. | MFA is managed by Vault | Supported in Vault OSS | -| [Okta Auth MFA](/vault/docs/auth/okta#mfa) | This is MFA as part of [Okta Auth method](/vault/docs/auth/okta) in Vault OSS, where MFA is enforced by Okta on login. MFA must be satisfied for authentication to be successful. This is different from the Okta MFA method used with Login MFA and Step-up Enterprise MFA. CLI/API login are supported. | MFA is managed externally by Okta | Supported in Vault OSS | +| [Login MFA](/vault/docs/auth/login-mfa) | MFA in Vault Community Edition provides MFA on login. CLI, API, and UI-based login are supported. | MFA is managed by Vault | Supported in Vault Community Edition | +| [Okta Auth MFA](/vault/docs/auth/okta#mfa) | This is MFA as part of [Okta Auth method](/vault/docs/auth/okta) in Vault Community Edition, where MFA is enforced by Okta on login. MFA must be satisfied for authentication to be successful. This is different from the Okta MFA method used with Login MFA and Step-up Enterprise MFA. CLI/API login are supported. | MFA is managed externally by Okta | Supported in Vault Community Edition | | [Step-up Enterprise MFA](/vault/docs/enterprise/mfa) | MFA in Vault Enterprise provides MFA for login and for step-up access to sensitive resources in Vault. Supports CLI/API based login, and ACL/Sentinel policies. | MFA is managed by Vault | Supported in Vault Enterprise | -~> **Note**: [The Legacy MFA](/vault/docs/v1.10.x/auth/mfa) is a **deprecated** MFA workflow in Vault OSS. Refer [here](#q-what-is-the-legacy-mfa-feature) for more details. +~> **Note**: [The Legacy MFA](/vault/docs/v1.10.x/auth/mfa) is a **deprecated** MFA workflow in Vault Community Edition. Refer [here](#q-what-is-the-legacy-mfa-feature) for more details. ### Q: what is the legacy MFA feature? -[Legacy MFA](/vault/docs/v1.10.x/auth/mfa) is functionality that was available in Vault OSS, prior to introducing MFA in the Enterprise version. This is now a deprecated feature. Please see the [Vault Feature Deprecation Notice and Plans](/vault/docs/deprecation) for detailed product plans around deprecated features. We plan to remove Legacy MFA in 1.11. +[Legacy MFA](/vault/docs/v1.10.x/auth/mfa) is functionality that was available in Vault Community Edition, prior to introducing MFA in the Enterprise version. This is now a deprecated feature. Please see the [Vault Feature Deprecation Notice and Plans](/vault/docs/deprecation) for detailed product plans around deprecated features. We plan to remove Legacy MFA in 1.11. ### Q: will HCP Vault support MFA? @@ -93,7 +93,7 @@ The Step-up Enterprise MFA uses the combination of mount accessors plus a `usern ### Q: are namespaces supported with the MFA workflows that Vault has as of Vault version 1.10? The Step-up Enterprise MFA configurations can only be configured in the root [namespace](/vault/docs/enterprise/mfa#namespaces), although they can be referenced in other namespaces via the policies. -The Login MFA supports namespaces awareness. Users will need a Vault Enterprise license to user or configure Login MFA with namespaces. MFA method configurations can be defined per namespace with Login MFA, and used in enforcements defined in that namespace and its children. Everything operates in the root namespace in Vault OSS. MFA login enforcements can also be defined per namespace, and applied to that namespace and its children. +The Login MFA supports namespaces awareness. Users will need a Vault Enterprise license to user or configure Login MFA with namespaces. MFA method configurations can be defined per namespace with Login MFA, and used in enforcements defined in that namespace and its children. Everything operates in the root namespace in Vault Community Edition. MFA login enforcements can also be defined per namespace, and applied to that namespace and its children. ### Q: i use the Vault agent. does MFA pose any challenges for me? diff --git a/website/content/docs/concepts/integrated-storage/index.mdx b/website/content/docs/concepts/integrated-storage/index.mdx index 93575008e7..6e1d8c79ca 100644 --- a/website/content/docs/concepts/integrated-storage/index.mdx +++ b/website/content/docs/concepts/integrated-storage/index.mdx @@ -221,7 +221,7 @@ and egg problem. Nodes don't have a shared view of storage until the raft cluster has been formed, but we're trying to form the raft cluster! To solve this problem, a Vault node must speak to another Vault node using the API port instead of the cluster port. This is currently the only situation in which -OSS Vault does this (Vault Enterprise also does something similar when setting +Vault Community Edition does this (Vault Enterprise also does something similar when setting up replication.) - `node2` wants to join the cluster, so issues challenge API request to existing member `node1` diff --git a/website/content/docs/concepts/mount-migration.mdx b/website/content/docs/concepts/mount-migration.mdx index 8ae1e91b58..17060f1076 100644 --- a/website/content/docs/concepts/mount-migration.mdx +++ b/website/content/docs/concepts/mount-migration.mdx @@ -11,10 +11,10 @@ is supported by API endpoints and a CLI helper around them. ## Why -There can be several reasons for wanting to migrate mounts. On OSS, the use cases could be for +There can be several reasons for wanting to migrate mounts. In Vault Community Edition, the use cases could be for renaming mounts to align with org standards. There may be more potential for use cases on Enterprise as namespaces come into the picture. -When migrating from an OSS binary to an Enterprise binary, organizations may want to divide their +When migrating from a Community binary to an Enterprise binary, organizations may want to divide their mounts across several namespaces. Mounts may also be moved across namespaces when there is a reorganization of roles and responsibilities. diff --git a/website/content/docs/concepts/storage.mdx b/website/content/docs/concepts/storage.mdx index 77ddb5e15d..408e8b4708 100644 --- a/website/content/docs/concepts/storage.mdx +++ b/website/content/docs/concepts/storage.mdx @@ -15,7 +15,7 @@ storage backend is untrusted storage used purely to keep encrypted information. @include 'ent-supported-storage.mdx' -Many other options for storage are available with community support for open-source Vault - see our +Many other options for storage are available with community support for Vault - see our [Storage Configuration](/vault/docs/configuration/storage) section for more information. @@ -62,11 +62,11 @@ study](https://www.hashicorp.com/resources/oh-no-i-deleted-my-vault-secret). We do not recommend backups as protection against the failure of an individual machine. Vault servers can run in clusters, so to protect against server failure, we recommend running Vault in [HA -mode](/vault/docs/internals/high-availability). With open source features, a +mode](/vault/docs/internals/high-availability). With community features, a Vault cluster can extend across multiple availability zones within a region. Vault Enterprise supports replicated clusters and disaster recovery for data -center failure. When using OSS Vault in [HA +center failure. When using Vault Community Edition in [HA Mode](/vault/docs/internals/high-availability), a backup can help guard against the failure of a data center. diff --git a/website/content/docs/deprecation/faq.mdx b/website/content/docs/deprecation/faq.mdx index 9b6afb48d6..e96f91c57b 100644 --- a/website/content/docs/deprecation/faq.mdx +++ b/website/content/docs/deprecation/faq.mdx @@ -20,7 +20,7 @@ This page provides frequently asked questions concerning decisions made about Va If you are an Enterprise Vault user, there is no impact. There are no changes to the Enterprise MFA offering. -If you are an OSS user and use the legacy MFA, this will impact you since we plan to deprecate the legacy MFA feature. However, while we will continue to provide support for MFA in Vault OSS in the upcoming Vault 1.10 release, our target is to remove the legacy MFA feature from the product in the following Vault 1.11 release. Therefore, you should plan to migrate to the new MFA feature when Vault OSS supports it. +If you use Vault Community Edition and use the legacy MFA, this will impact you since we plan to deprecate the legacy MFA feature. However, while we will continue to provide support for MFA in Vault Community Edition in the upcoming Vault 1.10 release, our target is to remove the legacy MFA feature from the product in the following Vault 1.11 release. Therefore, you should plan to migrate to the new MFA feature when Vault Community Edition supports it. ### Q: i'm currently using the etcd storage backend feature. how does the deprecation impact me? diff --git a/website/content/docs/deprecation/index.mdx b/website/content/docs/deprecation/index.mdx index e61b75388f..a6c5c8a515 100644 --- a/website/content/docs/deprecation/index.mdx +++ b/website/content/docs/deprecation/index.mdx @@ -24,18 +24,18 @@ This announcement page is maintained and updated periodically to communicate imp | Vault Enterprise storage backend | N/A | v1.12 | N/A | Use [Integrated Storage](/vault/docs/configuration/storage/raft) or [Consul](/vault/docs/configuration/storage/consul) as your Vault's storage backend. Vault Enterprise will no longer start up if configured to use a storage backend other than Integrated Storage or Consul. | [Upgrade Guide](/vault/docs/upgrading/upgrade-to-1.12.x) | | Vault generation of Dynamic SSH Keys | v0.7.1 | N/A | v1.13 | Use the alternative [signed SSH certificates](/vault/docs/secrets/ssh/signed-ssh-certificates) feature which supports key pair generation as of Vault 1.12. SSH certificates do not require an external connection from Vault to provision the key/certificate and more secure than having Vault provision dynamic SSH keys. | [SSH Certificates](/vault/docs/secrets/ssh/signed-ssh-certificates) | | [Duplicative Docker Images](https://hub.docker.com/_/vault) | v1.12 | 1.13 | v1.14 | Upon feature removal, the `vault` Docker image will no longer be updated. Only the [Verified Publisher](https://hub.docker.com/r/hashicorp/vault) `hashicorp/vault` image will be updated on DockerHub. Users of [Official Images](https://hub.docker.com/_/vault) will need to use `docker pull hashicorp/vault:` instead of `docker pull vault:version` to get newer versions of Vault in Docker images. Currently, HashiCorp publishes and updates identical Docker images of Vault as Verified Publisher and Official images separately. | [The Verified Publisher Program](https://docs.docker.com/docker-hub/publish/) | -| Etcd V2 API (OSS) | v1.9 | N/A | v1.10 | The Etcd v2 has been deprecated with the release of Etcd v3.5, and will be decomissioned by Etcd v3.6. Etcd v2 API has been removed in Vaut 1.10. Users of Etcd storage backend must migrate Vault storage to an Etcd V3 cluster prior to upgrading to Vault 1.10. All storage migrations should be backed up prior to migration. | [Etcd Storage Backend](/vault/docs/configuration/storage/etcd) | +| 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) | | Licenses in storage (ENT) | v1.8 | v1.10 | v1.11 | Migrate to [Autoloading](/vault/docs/enterprise/license/autoloading) by v1.11. | [Vault License](/vault/docs/enterprise/license) [System Backend](/vault/api-docs/system/license) [FAQ](/vault/docs/enterprise/license/faq) | | Mount Filters (ENT) | v1.3 | v1.10 | v1.11 | Use the alternative feature: [Path Filters](/vault/api-docs/system/replication/replication-performance#create-paths-filter). | [API Deprecation Notice](/vault/api-docs/system/replication/replication-performance#create-mounts-filter-deprecated) [Filter Mount Replication Deprecation Notice](/vault/docs/upgrading/upgrade-to-1.3.0#filtered-mount-replication-deprecation) | -| Legacy MFA (OSS) | v1.0 | N/A | v1.11 | Based on your use case, use the Policy-based Enterprise MFA or Login MFA supported in Vault OSS as of v1.10. | [Multi-Factor Authentication](/vault/docs/v1.10.x/auth/mfa) | -| *****Standalone DB Engines (OSS) | v0.8 | N/A | v1.13 | Use the alternative DB secrets engine feature. | [DB secrets engine](/vault/docs/secrets/databases) | -| *****AppID (OSS) | v0.6 | N/A | v1.13 | Use the alternative feature: [AppRole auth method](/vault/docs/auth/approle). | [AppID Auth Method Deprecation Notice](/vault/docs/auth/app-id) | +| Legacy MFA (Community) | v1.0 | N/A | v1.11 | Based on your use case, use the Policy-based Enterprise MFA or Login MFA supported in Vault Community Edition as of v1.10. | [Multi-Factor Authentication](/vault/docs/v1.10.x/auth/mfa) | +| *****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| -*If you use **Standalone DB Engines** or **AppID (OSS)**, you should actively plan to migrate away from their usage. If you use these features and upgrade to Release 1.12, Vault will log error messages and shut down, and any attempts to add new mounts will result in an error. +*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/enterprise/license/faq.mdx b/website/content/docs/enterprise/license/faq.mdx index 72247f70fb..d914081f5e 100644 --- a/website/content/docs/enterprise/license/faq.mdx +++ b/website/content/docs/enterprise/license/faq.mdx @@ -69,7 +69,7 @@ No, these changes will not impact HCP Vault. | Customer/licenses | Impacted? | | --------------------------------------------------------------------------------------------------------------------------- | --------- | | ENT binaries (evaluation or non-evaluation downloaded from [releases.hashicorp.com](https://releases.hashicorp.com/vault/)) | Yes | -| Open-Source (OSS) | No | +| Business-Source (BSL) | No | ### Q: what is the product behavior change introduced by the licensing changes? @@ -167,7 +167,7 @@ As of Vault Enterprise 1.8, the functionality formerly sold as the Vault ADP mod **ADP-KM includes**: - This is the first Vault Enterprise module that can be purchased standalone. This means it can be purchased without the purchase of a Vault Enterprise Standard license. -- ADP-KM still requires a Vault Enterprise binary. The Vault Enterprise Standard license is automatically included with the ADP-KM module, but customers are contractually prohibited from using any features besides those in Vault OSS and ADP-KM (KMSE and KMIP). +- ADP-KM still requires a Vault Enterprise binary. The Vault Enterprise Standard license is automatically included with the ADP-KM module, but customers are contractually prohibited from using any features besides those in Vault Community Edition and ADP-KM (KMSE and KMIP). **ADP-Transform includes**: diff --git a/website/content/docs/faq/ssct.mdx b/website/content/docs/faq/ssct.mdx index 73f7245a01..aaf5999c39 100644 --- a/website/content/docs/faq/ssct.mdx +++ b/website/content/docs/faq/ssct.mdx @@ -9,7 +9,7 @@ description: An list of frequently asked questions about server side consistent This FAQ section contains frequently asked questions about the Server Side Consistent Token feature. - [Q: What is the Server Side Consistent Token feature?](#q-what-is-the-server-side-consistent-token-feature) -- [Q: I have Vault OSS. How does this feature impact me?](#q-i-have-vault-oss-how-does-this-feature-impact-me) +- [Q: I have Vault Community Edition. How does this feature impact me?](#q-i-have-vault-community-edition-how-does-this-feature-impact-me) - [Q: What token changes does the Server Side Consistent Tokens feature introduce?](#q-what-token-changes-does-the-server-side-consistent-tokens-feature-introduce) - [Q: Why are we changing the token?](#q-why-are-we-changing-the-token) - [Q: What type of tokens are impacted by this feature?](#q-what-type-of-tokens-are-impacted-by-this-feature) @@ -31,9 +31,9 @@ To help with such cases, we’ve now added support for the Server Side Consisten This feature provides a way for Service tokens, returned from logins (or token create requests), to have the relevant minimum WAL state information embedded within the token itself. Clients can then use this token to authenticate subsequent requests. Thus, clients can obtain read-after-write consistency for the token without typically having to make changes to their code or architecture. If a performance standby does not have the state required to authenticate the token, it returns a 412 error to allow the client to retry. If client retry is not possible, there is a server config to allow for the consistency. -### Q: i have Vault OSS. how does this feature impact me? +### Q: i have Vault Community Edition. how does this feature impact me? -For the sake of standardization between OSS and Enterprise, and due to the value of adding token prefixes in OSS for token scanning use cases, the token formats are changed across OSS and Enterprise starting Vault 1.10. However, since there are no performance standbys or replication in Vault OSS, the new Vault OSS token will always show the local index of the WAL as 0 to indicate there is nothing to wait for. +For the sake of standardization between Community and Enterprise, and due to the value of adding token prefixes in Vault for token scanning use cases, the token formats are changed across all Vault versions starting Vault 1.10. However, since there are no performance standbys or replication in Vault Community Edition, the new Vault token will always show the local index of the WAL as 0 to indicate there is nothing to wait for. ### Q: what token changes does the server side consistent tokens feature introduce? diff --git a/website/content/docs/platform/aws/index.mdx b/website/content/docs/platform/aws/index.mdx index 32e4b7500e..ec18f0ffca 100644 --- a/website/content/docs/platform/aws/index.mdx +++ b/website/content/docs/platform/aws/index.mdx @@ -14,7 +14,7 @@ There are two varieties of Vault AMIs available through the AWS Marketplace. Vau The AWS Marketplace listings can be found below. -- [HashiCorp Vault OSS](http://aws.amazon.com/marketplace/pp/B07YLYPLYB) +- [HashiCorp Vault](http://aws.amazon.com/marketplace/pp/B07YLYPLYB) ## Use cases diff --git a/website/content/docs/platform/k8s/vso/index.mdx b/website/content/docs/platform/k8s/vso/index.mdx index 796e7cd29f..d3875101c2 100644 --- a/website/content/docs/platform/k8s/vso/index.mdx +++ b/website/content/docs/platform/k8s/vso/index.mdx @@ -36,8 +36,7 @@ The following features are supported by the Vault Secrets Operator: ## Supported Vault versions -- Vault OSS 1.11+ -- Vault Enterprise 1.11+ +- Vault 1.11+ - [HCP Vault](https://www.hashicorp.com/cloud) @include 'kubernetes-supported-versions.mdx' diff --git a/website/content/docs/platform/k8s/vso/installation.mdx b/website/content/docs/platform/k8s/vso/installation.mdx index b06a815af8..6a5e1c1228 100644 --- a/website/content/docs/platform/k8s/vso/installation.mdx +++ b/website/content/docs/platform/k8s/vso/installation.mdx @@ -10,7 +10,7 @@ description: >- ## Prerequisites - Kubernetes 1.22+ -- Vault OSS/Enterprise 1.11+ or [HCP Vault](https://www.hashicorp.com/cloud) +- Vault 1.11+ or [HCP Vault](https://www.hashicorp.com/cloud) ## Installation using helm diff --git a/website/content/docs/release-notes/1.10.0.mdx b/website/content/docs/release-notes/1.10.0.mdx index 3f169e3b9e..3f3b3a2ce7 100644 --- a/website/content/docs/release-notes/1.10.0.mdx +++ b/website/content/docs/release-notes/1.10.0.mdx @@ -17,7 +17,7 @@ Some of these enhancements and changes in this release include: - Ability to view client counts per auth and changes to clients over months, therefore, providing more granular visibility into clients. - Extended the `sys/remount` API endpoint to support moving secrets engines and auth method mounts from one location to another, within a namespace or across namespaces. -- Improved security posture that includes MFA on login for Vault OSS customers. +- Improved security posture that includes MFA on login for Vault Community Edition customers. - Ability to implicitely achieve consistency via tokens. - Support of PKCE on Vault’s OIDC auth method with Telemetry support for the Vault Agent. - Improvement of key areas and parity to support using Terraform Provider with Vault. @@ -26,13 +26,13 @@ Some of these enhancements and changes in this release include: This section describes the new features introduced as part of Vault -### Multi-Factor authentication (MFA) for Vault OSS +### Multi-Factor authentication (MFA) for Vault Community Edition Vault has had support for the [Step-up Enterprise MFA](/vault/docs/enterprise/mfa) as part of its Enterprise edition. The Step-up Enterprise MFA allows having an MFA on login, or for step-up access to sensitive resources in Vault. -With Vault 1.10.0, MFA as part of [login](/vault/docs/auth/login-mfa) is now supported for Vault OSS. This demonstrates HashiCorp’s thought leadership in security and its continued endeavor to enable all Vault users to employ strong security policies with Vault. +With Vault 1.10.0, MFA as part of [login](/vault/docs/auth/login-mfa) is now supported for Vault Community Edition. This demonstrates HashiCorp’s thought leadership in security and its continued endeavor to enable all Vault users to employ strong security policies with Vault. -~> **Note:** The Legacy MFA in Vault OSS is a [deprecated](/vault/docs/deprecation) feature and will be removed in Vault 1.11. +~> **Note:** The Legacy MFA in Vault Community Edition is a [deprecated](/vault/docs/deprecation) feature and will be removed in Vault 1.11. Refer to the [Login MFA FAQ](/vault/docs/auth/login-mfa/faq) to understand the various MFA workflows that are supported in Vault 1.10.0. @@ -138,7 +138,7 @@ We now support Server Side Consistent Tokens (See [Replication](/vault/docs/conf For more details, see the [Server Side Consistent Tokens FAQ](/vault/docs/faq/ssct). -Since service tokens are always created on the leader, as long as the leader is not upgraded before performance standbys, service tokens will be of the old format and still be usable during the upgrade process. However, the usual upgrade process we recommend can't be relied upon to always upgrade the leader last. Due to this known [issue](https://github.com/hashicorp/vault/issues/14153), a Vault cluster using Integrated Storage may result in a leader not being upgraded last, and this can trigger a re-election. This re-election can cause the upgraded node to become the leader, resulting in the newly created tokens on the leader to be unusable on nodes that have not yet been upgraded. Note that this issue does not impact Vault OSS users. +Since service tokens are always created on the leader, as long as the leader is not upgraded before performance standbys, service tokens will be of the old format and still be usable during the upgrade process. However, the usual upgrade process we recommend can't be relied upon to always upgrade the leader last. Due to this known [issue](https://github.com/hashicorp/vault/issues/14153), a Vault cluster using Integrated Storage may result in a leader not being upgraded last, and this can trigger a re-election. This re-election can cause the upgraded node to become the leader, resulting in the newly created tokens on the leader to be unusable on nodes that have not yet been upgraded. Note that this issue does not impact Vault Community Edition users. We will have a fix for this issue in Vault 1.10.1. Until this issue is fixed, you may be at risk of having performance standbys unable to service requests until all nodes are upgraded. We recommended that you plan for a maintenance window to upgrade. diff --git a/website/content/docs/release-notes/1.11.0.mdx b/website/content/docs/release-notes/1.11.0.mdx index 5e6db5a2d2..c4d2cd7321 100644 --- a/website/content/docs/release-notes/1.11.0.mdx +++ b/website/content/docs/release-notes/1.11.0.mdx @@ -82,7 +82,7 @@ We have made the following improvements to the Client Count tooling: ### MFA enhancements -Vault 1.10 introduced [Login MFA](/vault/docs/auth/login-mfa) support for Vault OSS. In this release, we included additional enhancements to the Login MFA feature by introducing the ability to configure Login MFA via the UI and providing an enhanced TOTP configuration experience via the QR code scan. +Vault 1.10 introduced [Login MFA](/vault/docs/auth/login-mfa) support for Vault Community Edition. In this release, we included additional enhancements to the Login MFA feature by introducing the ability to configure Login MFA via the UI and providing an enhanced TOTP configuration experience via the QR code scan. ### Vault agent: support for using an existing valid certificate upon re-authentication diff --git a/website/content/docs/release-notes/1.14.0.mdx b/website/content/docs/release-notes/1.14.0.mdx index 4153b289b9..ac019d8ab5 100644 --- a/website/content/docs/release-notes/1.14.0.mdx +++ b/website/content/docs/release-notes/1.14.0.mdx @@ -219,7 +219,7 @@ Follow the learn more links for more information, or browse the list of ENHANCED - Contributed by the OSS community. Support for public-key only Transit + Contributed by the Vault community. Support for public-key only Transit keys and BYOK-secured export of key material.

Learn more: Transit Secrets Engine diff --git a/website/content/docs/upgrading/index.mdx b/website/content/docs/upgrading/index.mdx index ba779cb488..957b7b7f47 100644 --- a/website/content/docs/upgrading/index.mdx +++ b/website/content/docs/upgrading/index.mdx @@ -56,9 +56,9 @@ do not allow external network connectivity during testing, in case credentials expire. This prevents the test cluster from trying to revoke these resources along with the non-test cluster. -## OSS to enterprise installations +## Upgrading from Community to Enterprise editions -Upgrading to Vault Enterprise installations follow the same steps as OSS upgrades except that the Vault Enterprise binary is to be used and the license file [applied](/vault/api-docs/system/license#install-license), when applicable. The Enterprise binary and license file can be obtained through your HashiCorp sales team. +Upgrading to Vault Enterprise installations follow the same steps as Community edition upgrades except that the Vault Enterprise binary is to be used and the license file [applied](/vault/api-docs/system/license#install-license), when applicable. The Enterprise binary and license file can be obtained through your HashiCorp sales team. ## Non-HA installations diff --git a/website/content/docs/upgrading/upgrade-to-1.10.x.mdx b/website/content/docs/upgrading/upgrade-to-1.10.x.mdx index 6522bccc59..09bf2c60c8 100644 --- a/website/content/docs/upgrading/upgrade-to-1.10.x.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.10.x.mdx @@ -107,7 +107,7 @@ We now support Server Side Consistent Tokens (See [Replication](/vault/docs/conf For more details, see the [Server Side Consistent Tokens FAQ](/vault/docs/faq/ssct). -Since service tokens are always created on the leader, as long as the leader is not upgraded before performance standbys, service tokens will be of the old format and still be usable during the upgrade process. However, the usual upgrade process we recommend can't be relied upon to always upgrade the leader last. Due to this known [issue](https://github.com/hashicorp/vault/issues/14153), a Vault cluster using Integrated Storage may result in a leader not being upgraded last, and this can trigger a re-election. This re-election can cause the upgraded node to become the leader, resulting in the newly created tokens on the leader to be unusable on nodes that have not yet been upgraded. Note that this issue does not impact Vault OSS users. +Since service tokens are always created on the leader, as long as the leader is not upgraded before performance standbys, service tokens will be of the old format and still be usable during the upgrade process. However, the usual upgrade process we recommend can't be relied upon to always upgrade the leader last. Due to this known [issue](https://github.com/hashicorp/vault/issues/14153), a Vault cluster using Integrated Storage may result in a leader not being upgraded last, and this can trigger a re-election. This re-election can cause the upgraded node to become the leader, resulting in the newly created tokens on the leader to be unusable on nodes that have not yet been upgraded. Note that this issue does not impact Vault Community Edition users. We will have a fix for this issue in Vault 1.10.3. Until this issue is fixed, you may be at risk of having performance standbys unable to service requests until all nodes are upgraded. We recommended that you plan for a maintenance window to upgrade. diff --git a/website/content/docs/upgrading/upgrade-to-1.12.x.mdx b/website/content/docs/upgrading/upgrade-to-1.12.x.mdx index 43036cc9d7..76027e5b1a 100644 --- a/website/content/docs/upgrading/upgrade-to-1.12.x.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.12.x.mdx @@ -15,7 +15,7 @@ for Vault 1.12.x compared to 1.11. Please read it carefully. ### Supported storage backends -Vault Enterprise will now perform a supported storage check at startup. There is no impact on open-source Vault users. +Vault Enterprise will now perform a supported storage check at startup. There is no impact on Vault Community Edition users. @include 'ent-supported-storage.mdx' diff --git a/website/content/docs/upgrading/upgrade-to-1.8.x.mdx b/website/content/docs/upgrading/upgrade-to-1.8.x.mdx index 70a8f0247a..cafc0a5471 100644 --- a/website/content/docs/upgrading/upgrade-to-1.8.x.mdx +++ b/website/content/docs/upgrading/upgrade-to-1.8.x.mdx @@ -15,7 +15,7 @@ for Vault 1.8.x compared to 1.7. Please read it carefully. Licenses and EULA enhancements have been introduced in the Vault 1.8 release. These changes are important for Enterprise customers to review. They do not affect -OSS users. Please see the [License](/vault/docs/enterprise/license) documentation for more details. +Vault Community Edition users. Please see the [License](/vault/docs/enterprise/license) documentation for more details. ## Deprecations diff --git a/website/content/partials/builds-without-ui.mdx b/website/content/partials/builds-without-ui.mdx index bdc5412364..3b5c0434d2 100644 --- a/website/content/partials/builds-without-ui.mdx +++ b/website/content/partials/builds-without-ui.mdx @@ -1,4 +1,4 @@ -### OSS binaries lacking Vault UI +### Core binaries lacking Vault UI -OSS binaries of Vault 1.5.1, 1.4.4, 1.3.8, and 1.2.5 were built without the +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.