scottk/vault
1
0
Fork 0
mirror of https://github.com/optim-enterprises-bv/vault.git synced 2025-11-02 03:27:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

convert OSS language to "community" (#22343) (#22347)

Browse Source
This commit is contained in:
Sarah Chavis
2023-08-15 11:44:45 -07:00
committed by GitHub
parent 1753e454ab
commit c062f56698
24 changed files with 49 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -32,7 +32,9 @@ The following list of tools is maintained by the community of Vault users; Hashi
- [Cruise Daytona](https://github.com/cruise-automation/daytona) - An alternative implementation of the Vault client CLI for services and containers. Its core features are the ability to automate authentication, fetching of secrets, and automated token renewal. Support for AWS, GCP, & Kubernetes Vault Auth Backends.
- [Vault-CRD](https://vault.koudingspawn.de/) - Synchronize secrets stored in HashiCorp Vault to Kubernetes Secrets for better GitOps without secrets stored in git manifest files.
- [vsh](https://github.com/fishi0x01/vsh) - Interactive shell with tab-completion. Allows recursive operations on paths. Allows migration of secrets between both KV versions.
- [HashiBox](https://github.com/nunchistudio/hashibox) - Vagrant environment to simulate highly-available cloud with Consul, Nomad, Vault, and optional support for Waypoint. OSS & Enterprise supported.
- [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. 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).

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

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

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

@@ -3791,7 +3791,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 |

2
website/content/api-docs/system/internal-counters.mdx
View File

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

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

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

14
website/content/docs/auth/login-mfa/faq.mdx
View File

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

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

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

4
website/content/docs/concepts/mount-migration.mdx
View File

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

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

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

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

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

10
website/content/docs/deprecation/index.mdx
View File

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

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

@@ -70,7 +70,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?
@@ -168,7 +168,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**:

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

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

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

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

3
website/content/docs/platform/k8s/vso/index.mdx
View File

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

2
website/content/docs/platform/k8s/vso/installation.mdx
View File

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

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

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

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

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

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

@@ -219,7 +219,7 @@ Follow the learn more links for more information, or browse the list of
</td>
<td style={{verticalAlign: 'middle', textAlign: 'center'}}>ENHANCED</td>
<td style={{verticalAlign: 'middle'}}>
<b>Contributed by the OSS community</b>. Support for public-key only Transit
<b>Contributed by the Vault community</b>. Support for public-key only Transit
keys and BYOK-secured export of key material.
<br /><br />
Learn more: <a href="/vault/api-docs/secret/transit">Transit Secrets Engine</a>

4
website/content/docs/upgrading/index.mdx
View File

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

2
website/content/docs/upgrading/upgrade-to-1.10.x.mdx
View File

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

2
website/content/docs/upgrading/upgrade-to-1.12.x.mdx
View File

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

2
website/content/docs/upgrading/upgrade-to-1.8.x.mdx
View File

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

4
website/content/partials/builds-without-ui.mdx
View File

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