Remove the versus section on the website. (#8538)
* Remove the versus section on the website. We don't keep it maintained, it's very out of date, and we don't really like comparing ourselves to other software anyways; it's not fair to describe other software or solutions in ways that may not align with how they want to be described. Co-authored-by: Jeff Escalante <jescalan@users.noreply.github.com>
This commit is contained in:
Jeff Mitchell
GitHub
parent
3f25dd8081
commit
8dd936d738
|
|
@ -160,16 +160,23 @@
|
||||||
|
|
||||||
# Rearranged out of `guides` but still on `.io`
|
# Rearranged out of `guides` but still on `.io`
|
||||||
/guides/partnerships/index.html /docs/partnerships
|
/guides/partnerships/index.html /docs/partnerships
|
||||||
/intro/use-cases.html /docs/use-cases
|
/intro/use-cases.html /docs/use-cases
|
||||||
/intro/vs/index.html /docs/vs
|
/intro/vs/index.html /docs/vs
|
||||||
/intro/vs/chef-puppet-etc.html /docs/vs/chef-puppet-etc
|
/intro/vs/chef-puppet-etc.html /docs/vs
|
||||||
/intro/vs/consul.html /docs/vs/consul
|
/docs/vs/chef-puppet-etc /docs/vs
|
||||||
/intro/vs/custom.html /docs/vs/custom
|
/intro/vs/consul.html /docs/vs
|
||||||
/intro/vs/dropbox.html /docs/vs/dropbox
|
/docs/vs/consul /docs/vs
|
||||||
/intro/vs/hsm.html /docs/vs/hsm
|
/intro/vs/custom.html /docs/vs
|
||||||
/intro/vs/index.html /docs/vs
|
/docs/vs/custom /docs/vs
|
||||||
/intro/vs/keywhiz.html /docs/vs/keywhiz
|
/intro/vs/dropbox.html /docs/vs
|
||||||
/intro/vs/kms.html /docs/vs/kms
|
/docs/vs/dropbox /docs/vs
|
||||||
|
/intro/vs/hsm.html /docs/vs
|
||||||
|
/docs/vs/hsm /docs/vs
|
||||||
|
/intro/vs/index.html /docs/vs
|
||||||
|
/intro/vs/keywhiz.html /docs/vs
|
||||||
|
/docs/vs/keywhiz /docs/vs
|
||||||
|
/intro/vs/kms.html /docs/vs
|
||||||
|
/docs/vs/kms /docs/vs
|
||||||
/intro/what-is-vault/index.html /docs/what-is-vault
|
/intro/what-is-vault/index.html /docs/what-is-vault
|
||||||
|
|
||||||
# Intro getting started content -> Learn
|
# Intro getting started content -> Learn
|
||||||
|
|
|
||||||
|
|
@ -301,18 +301,6 @@ export default [
|
||||||
{
|
{
|
||||||
category: 'partnerships'
|
category: 'partnerships'
|
||||||
},
|
},
|
||||||
{
|
|
||||||
category: 'vs',
|
|
||||||
content: [
|
|
||||||
'chef-puppet-etc',
|
|
||||||
'hsm',
|
|
||||||
'dropbox',
|
|
||||||
'consul',
|
|
||||||
'kms',
|
|
||||||
'keywhiz',
|
|
||||||
'custom'
|
|
||||||
]
|
|
||||||
},
|
|
||||||
'----------------',
|
'----------------',
|
||||||
{
|
{
|
||||||
category: 'platform',
|
category: 'platform',
|
||||||
|
|
|
||||||
|
|
@ -1,51 +0,0 @@
|
||||||
---
|
|
||||||
layout: docs
|
|
||||||
page_title: 'Vault vs. Chef, Puppet, etc.'
|
|
||||||
sidebar_title: 'Chef, Puppet, etc.'
|
|
||||||
description: >-
|
|
||||||
Comparison between Vault and configuration management solutions such as Chef,
|
|
||||||
Puppet, etc.
|
|
||||||
---
|
|
||||||
|
|
||||||
# Vault vs. Chef, Puppet, etc.
|
|
||||||
|
|
||||||
A big part of configuring software is setting up secrets: configuring a
|
|
||||||
web application to talk to a service, configuring the credentials of a
|
|
||||||
database, etc. Because of this, configuration management systems all face
|
|
||||||
a problem of safely storing these secrets.
|
|
||||||
|
|
||||||
Chef, Puppet, etc. all solve this in a similar way: single-key
|
|
||||||
encrypted storage. Chef has encrypted data bags, Puppet has encrypted
|
|
||||||
Hiera, and so on. The encrypted data is always one secret (a password,
|
|
||||||
a key, etc.) away from being decrypted, and this secret is generally
|
|
||||||
not well protected since in an elastic environment, every server needs
|
|
||||||
to somehow get this secret to decrypt the data. Additionally, access to
|
|
||||||
the encrypted data isn't always logged, so if there is an intrusion, it
|
|
||||||
isn't clear what data has been accessed and by who.
|
|
||||||
|
|
||||||
Vault is not tied to any specific configuration management system. You can
|
|
||||||
read secrets from configuration management, but you can also use the API
|
|
||||||
directly to read secrets from applications. This means that configuration
|
|
||||||
management requires fewer secrets, and in many cases doesn't ever have to
|
|
||||||
persist them to disk.
|
|
||||||
|
|
||||||
Vault encrypts the data onto physical storage and requires multiple
|
|
||||||
keys to even read it. If an attacker were to gain access to the physical
|
|
||||||
encrypted storage, it couldn't be read without multiple keys which are generally
|
|
||||||
distributed to multiple individuals. This is known as _unsealing_, and happens
|
|
||||||
once whenever Vault starts.
|
|
||||||
|
|
||||||
For an unsealed Vault, every interaction is logged in via the audit devices.
|
|
||||||
Even erroneous requests (invalid access tokens, for example) are logged.
|
|
||||||
To access any data, an access token is required. This token is usually
|
|
||||||
associated with an identity coming from a system such as GitHub, LDAP, etc.
|
|
||||||
This identity is also written to the audit log.
|
|
||||||
|
|
||||||
Access tokens can be given fine-grained control over what secrets can be
|
|
||||||
accessed. It is rare to have a single key that can access all secrets. This
|
|
||||||
makes it easier to have fine-grained access for consumers of Vault.
|
|
||||||
|
|
||||||
For tips on how to integrate Vault using configuration management, please see
|
|
||||||
[Using HashiCorp's Vault with Chef](https://www.hashicorp.com/blog/using-hashicorps-vault-with-chef/).
|
|
||||||
Although this post is about Chef, the principles can be broadly applied to many
|
|
||||||
of the tools listed here.
|
|
||||||
|
|
@ -1,30 +0,0 @@
|
||||||
---
|
|
||||||
layout: docs
|
|
||||||
page_title: Vault vs. Consul
|
|
||||||
sidebar_title: Consul
|
|
||||||
description: Comparison between Vault and attempting to store secrets with Consul.
|
|
||||||
---
|
|
||||||
|
|
||||||
# Vault vs. Consul
|
|
||||||
|
|
||||||
[Consul](https://www.consul.io) is a system for service discovery, monitoring,
|
|
||||||
and configuration that is distributed and highly available. Consul also
|
|
||||||
supports an ACL system to restrict access to keys and service information.
|
|
||||||
|
|
||||||
While Consul can be used to store secret information and gate access using
|
|
||||||
ACLs, it is not designed for that purpose. As such, data is not encrypted
|
|
||||||
in transit nor at rest, it does not have pluggable authentication mechanisms,
|
|
||||||
and there is no per-request auditing mechanism.
|
|
||||||
|
|
||||||
Vault is designed from the ground up as a secret management solution. As such,
|
|
||||||
it protects secrets in transit and at rest. It provides multiple authentication
|
|
||||||
and audit logging mechanisms. Dynamic secret generation allows Vault to avoid
|
|
||||||
providing clients with root privileges to underlying systems and makes
|
|
||||||
it possible to do key rolling and revocation.
|
|
||||||
|
|
||||||
The strength of Consul is that it is fault tolerant and highly scalable.
|
|
||||||
By using Consul as a backend to Vault, you get the best of both. Consul
|
|
||||||
is used for durable storage of encrypted data at rest and provides coordination
|
|
||||||
so that Vault can be highly available and fault tolerant. Vault provides
|
|
||||||
the higher level policy management, secret leasing, audit logging, and automatic
|
|
||||||
revocation.
|
|
||||||
|
|
@ -1,27 +0,0 @@
|
||||||
---
|
|
||||||
layout: docs
|
|
||||||
page_title: Vault vs. Custom Solutions
|
|
||||||
sidebar_title: Custom Solutions
|
|
||||||
description: Comparison between Vault and writing a custom solution.
|
|
||||||
---
|
|
||||||
|
|
||||||
# Vault vs. Custom Solutions
|
|
||||||
|
|
||||||
Many organizations resort to custom solutions for storing secrets,
|
|
||||||
whether that be Dropbox, encrypted disk images, encrypted SQL columns,
|
|
||||||
etc.
|
|
||||||
|
|
||||||
These systems require time and resources to build and maintain.
|
|
||||||
Storing secrets is also an incredibly important piece of infrastructure
|
|
||||||
that must be done correctly. This increases the pressure to maintain
|
|
||||||
the internal systems.
|
|
||||||
|
|
||||||
Vault is designed for secret storage. It provides a simple interface
|
|
||||||
on top of a strong security model to meet your secret storage needs.
|
|
||||||
|
|
||||||
Furthermore, Vault is an open source tool. This means that the tool is
|
|
||||||
as good as the entire community working together to improve it. This
|
|
||||||
isn't just features and bug fixes, but finding potential security holes.
|
|
||||||
Additionally, since it is open source, your own security teams can
|
|
||||||
review and contribute to Vault and verify it meets your standards
|
|
||||||
for security.
|
|
||||||
|
|
@ -1,16 +0,0 @@
|
||||||
---
|
|
||||||
layout: docs
|
|
||||||
page_title: Vault vs. Dropbox
|
|
||||||
sidebar_title: Dropbox
|
|
||||||
description: Comparison between Vault and attempting to store secrets with Dropbox.
|
|
||||||
---
|
|
||||||
|
|
||||||
# Vault vs. Dropbox
|
|
||||||
|
|
||||||
It is an unfortunate truth that many organizations, big and small, often use Dropbox as a mechanism for storing secrets. It is so common that we've decided to make a special section for it instead of throwing it under the "custom solutions" header.
|
|
||||||
|
|
||||||
Dropbox is not made for storing secrets. Even if you're using something such as an encrypted disk image within Dropbox, it is subpar versus a real secret storage server.
|
|
||||||
|
|
||||||
A real secret management tool such as Vault has a stronger security model, integrates with many different authentication services, stores audit logs, can generate dynamic secrets, and more.
|
|
||||||
|
|
||||||
And, due to `vault` CLI, using `vault` on a developer machine is simple!
|
|
||||||
|
|
@ -1,44 +0,0 @@
|
||||||
---
|
|
||||||
layout: docs
|
|
||||||
page_title: Vault vs. HSMs
|
|
||||||
sidebar_title: HSMs
|
|
||||||
description: Comparison between Vault and HSM systems.
|
|
||||||
---
|
|
||||||
|
|
||||||
# Vault vs. HSMs
|
|
||||||
|
|
||||||
A [hardware security module
|
|
||||||
(HSM)](https://en.wikipedia.org/wiki/Hardware_security_module) is a hardware
|
|
||||||
device that is meant to secure various secrets using protections against access
|
|
||||||
and tampering at both the software and hardware layers.
|
|
||||||
|
|
||||||
The primary issue with HSMs is that they are expensive and not very cloud
|
|
||||||
friendly. An exception to the latter is Amazon's CloudHSM service, which is
|
|
||||||
friendly for AWS users but still costs more than \$14k per year per instance,
|
|
||||||
and not as useful for heterogenous cloud architectures.
|
|
||||||
|
|
||||||
Once an HSM is up and running, configuring it is generally very tedious, and
|
|
||||||
the API to request secrets is also difficult to use. Example: CloudHSM requires
|
|
||||||
SSH and setting up various keypairs manually. It is difficult to automate. APIs
|
|
||||||
tend to require the use of specific C libraries (e.g. PKCS#11) or
|
|
||||||
vendor-specific libraries.
|
|
||||||
|
|
||||||
However, although configuring and running an HSM can be a challenge, they come
|
|
||||||
with a significant advantage in that they conform to government-mandated
|
|
||||||
compliance requirements (e.g. FIPS 140), which often require specific hardware
|
|
||||||
protections and security models in addition to software.
|
|
||||||
|
|
||||||
Vault doesn't replace an HSM. Instead, they can be complementary; a compliant
|
|
||||||
HSM can protect Vault's master key to help Vault comply with regulatory
|
|
||||||
requirements, and Vault can provide easy client APIs for tasks such as
|
|
||||||
encryption and decryption.
|
|
||||||
|
|
||||||
Vault can also do many things that HSMs cannot currently do, such as generating
|
|
||||||
_dynamic secrets_. Instead of storing AWS access keys directly within Vault,
|
|
||||||
Vault can generate access keys according to a specific policy on the fly. Vault
|
|
||||||
has the potential of doing this for any system through its mountable secret
|
|
||||||
backend system.
|
|
||||||
|
|
||||||
For many companies' security requirements, Vault alone is enough. For companies
|
|
||||||
that can afford an HSM or with specific regulatory requirements, it can be used
|
|
||||||
with Vault to get the best of both worlds.
|
|
||||||
|
|
@ -1,23 +1,16 @@
|
||||||
---
|
---
|
||||||
layout: docs
|
layout: docs
|
||||||
page_title: Vault vs. Other Software
|
page_title: Versus Other Software
|
||||||
sidebar_title: Vault vs. Other Software
|
|
||||||
description: >-
|
|
||||||
Comparisons between Vault and other software that claim to store secrets in
|
|
||||||
some capacity.
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Vault vs. Other Software
|
# Versus Other Software
|
||||||
|
|
||||||
There are a number of other options in the market currently that claim
|
Although we used to publish information about Vault versus other software, we
|
||||||
to store secrets in some capacity. This section compares Vault to these
|
no longer do. Partly this is because the information grew exceedingly
|
||||||
other software choices.
|
out-of-date as Vault gained new functionality and features. More importantly,
|
||||||
|
just as we like to present information about Vault and its capabilities in the
|
||||||
Due to the bias of the comparisons being on the Vault website, we attempt
|
ways that we prefer, we felt it wasn't appropriate to describe the capabilities
|
||||||
to only use facts. If you find something that is invalid or out of date
|
of other projects or products in ways other than their own terms. As a result,
|
||||||
in the comparisons, please
|
we have decided to remove this section; please consult other projects or
|
||||||
[open an issue](https://github.com/hashicorp/vault/issues) and we'll
|
products for information on how they might meet your needs, and use our
|
||||||
address it as soon as possible.
|
documentation or product pages to understand how Vault might meet your needs.
|
||||||
|
|
||||||
Use the navigation on the left to read comparisons of Vault versus other
|
|
||||||
systems.
|
|
||||||
|
|
|
||||||
|
|
@ -1,42 +0,0 @@
|
||||||
---
|
|
||||||
layout: docs
|
|
||||||
page_title: Vault vs. Keywhiz
|
|
||||||
sidebar_title: Keywhiz
|
|
||||||
description: Comparison between Vault and Keywhiz.
|
|
||||||
---
|
|
||||||
|
|
||||||
# Vault vs. Keywhiz
|
|
||||||
|
|
||||||
Keywhiz is a secret management solution built by Square. Keywhiz has a
|
|
||||||
client/server architecture based on a RESTful API. Clients of Keywhiz access
|
|
||||||
secrets through the API by authenticating with a client certificate or cookie.
|
|
||||||
To allow for flexible consumption of secrets by arbitrary software, clients may
|
|
||||||
also make use of a FUSE filesystem to expose secrets as files on disk, and use
|
|
||||||
Unix file permissions for access control. Human operators may authenticate
|
|
||||||
using a cookie-based authentication either via command line utilities or
|
|
||||||
through a management web interface.
|
|
||||||
|
|
||||||
Vault similarly is designed as a comprehensive secret management solution. The
|
|
||||||
client interaction with Vault is flexible both for authentication and usage of
|
|
||||||
secrets. Vault supports [mTLS authentication](/docs/auth/cert) along with
|
|
||||||
many [other mechanisms](/docs/auth). The goal is to make it easy
|
|
||||||
to authenticate as a machine for programmatic access and as a human for
|
|
||||||
operator usage.
|
|
||||||
|
|
||||||
Vault and Keywhiz expose secrets via an API. The Vault [ACL
|
|
||||||
system](/docs/concepts/policies) is used to protect secrets and gate
|
|
||||||
access, similarly to the Keywhiz ACL system. With Vault, all auditing is done
|
|
||||||
server side using [audit devices](/docs/audit).
|
|
||||||
|
|
||||||
Keywhiz focuses on storage and distribution of secrets and supports rotation
|
|
||||||
through secret versioning, which is possible in the Keywhiz UI and command-line
|
|
||||||
utilities. Vault also supports dynamic secrets and generating credentials
|
|
||||||
on-demand for fine-grained security controls, but adds first class support for
|
|
||||||
non-repudiation. Key rotation is a first class concern for Keywhiz and Vault,
|
|
||||||
so that no external systems need to be used.
|
|
||||||
|
|
||||||
Lastly, Vault forces a mandatory lease contract with clients. All secrets read
|
|
||||||
from Vault have an associated lease which enables operators to audit key usage,
|
|
||||||
perform key rolling, and ensure automatic revocation. Vault provides multiple
|
|
||||||
revocation mechanisms to give operators a clear "break glass" procedure after a
|
|
||||||
potential compromise.
|
|
||||||
|
|
@ -1,38 +0,0 @@
|
||||||
---
|
|
||||||
layout: docs
|
|
||||||
page_title: Vault vs. Amazon Key Management Service
|
|
||||||
sidebar_title: Amazon KMS
|
|
||||||
description: Comparison between Vault and Amazon Key Management Service.
|
|
||||||
---
|
|
||||||
|
|
||||||
# Vault vs. Amazon KMS
|
|
||||||
|
|
||||||
Amazon Key Management Service (KMS) is a service provided in the AWS ecosystem
|
|
||||||
for encryption key management. It is backed by Hardware Security Modules (HSM)
|
|
||||||
for physical security.
|
|
||||||
|
|
||||||
Vault and KMS differ in the scope of problems they are trying to solve. KMS is
|
|
||||||
focused on securely storing encryption keys and supporting cryptographic
|
|
||||||
operations (encrypt and decrypt) using those keys. It supports access controls
|
|
||||||
and auditing as well.
|
|
||||||
|
|
||||||
In contrast, Vault provides a comprehensive secret management solution. The
|
|
||||||
[`transit` backend](/docs/secrets/transit) provides similar
|
|
||||||
capabilities as KMS, allowing for encryption keys to be stored and
|
|
||||||
cryptographic operations to be performed. However, Vault goes much further than
|
|
||||||
just key management.
|
|
||||||
|
|
||||||
The flexible secrets engines allow Vault to handle any type of secret data,
|
|
||||||
including database credentials, API keys, PKI keys, and encryption keys. Vault
|
|
||||||
also supports dynamic secrets, generating credentials on-demand for
|
|
||||||
fine-grained security controls, auditing, and non-repudiation.
|
|
||||||
|
|
||||||
Lastly, Vault forces a mandatory lease contract with clients. All secrets read
|
|
||||||
from Vault have an associated lease which enables operations to audit key
|
|
||||||
usage, perform key rolling, and ensure automatic revocation. Vault provides
|
|
||||||
multiple revocation mechanisms to give operators a clear "break glass"
|
|
||||||
procedure after a potential compromise.
|
|
||||||
|
|
||||||
Vault is an open source tool that can be deployed to any environment, and does
|
|
||||||
not require any special hardware. This makes it well suited for cloud
|
|
||||||
environments where HSMs are not available or are cost prohibitive.
|
|
||||||
Loading…
Reference in New Issue