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`
|
||||
/guides/partnerships/index.html /docs/partnerships
|
||||
/intro/use-cases.html /docs/use-cases
|
||||
/intro/vs/index.html /docs/vs
|
||||
/intro/vs/chef-puppet-etc.html /docs/vs/chef-puppet-etc
|
||||
/intro/vs/consul.html /docs/vs/consul
|
||||
/intro/vs/custom.html /docs/vs/custom
|
||||
/intro/vs/dropbox.html /docs/vs/dropbox
|
||||
/intro/vs/hsm.html /docs/vs/hsm
|
||||
/intro/vs/index.html /docs/vs
|
||||
/intro/vs/keywhiz.html /docs/vs/keywhiz
|
||||
/intro/vs/kms.html /docs/vs/kms
|
||||
/intro/use-cases.html /docs/use-cases
|
||||
/intro/vs/index.html /docs/vs
|
||||
/intro/vs/chef-puppet-etc.html /docs/vs
|
||||
/docs/vs/chef-puppet-etc /docs/vs
|
||||
/intro/vs/consul.html /docs/vs
|
||||
/docs/vs/consul /docs/vs
|
||||
/intro/vs/custom.html /docs/vs
|
||||
/docs/vs/custom /docs/vs
|
||||
/intro/vs/dropbox.html /docs/vs
|
||||
/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 getting started content -> Learn
|
||||
|
|
|
|||
|
|
@ -301,18 +301,6 @@ export default [
|
|||
{
|
||||
category: 'partnerships'
|
||||
},
|
||||
{
|
||||
category: 'vs',
|
||||
content: [
|
||||
'chef-puppet-etc',
|
||||
'hsm',
|
||||
'dropbox',
|
||||
'consul',
|
||||
'kms',
|
||||
'keywhiz',
|
||||
'custom'
|
||||
]
|
||||
},
|
||||
'----------------',
|
||||
{
|
||||
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
|
||||
page_title: Vault vs. Other Software
|
||||
sidebar_title: Vault vs. Other Software
|
||||
description: >-
|
||||
Comparisons between Vault and other software that claim to store secrets in
|
||||
some capacity.
|
||||
page_title: Versus Other Software
|
||||
---
|
||||
|
||||
# Vault vs. Other Software
|
||||
# Versus Other Software
|
||||
|
||||
There are a number of other options in the market currently that claim
|
||||
to store secrets in some capacity. This section compares Vault to these
|
||||
other software choices.
|
||||
|
||||
Due to the bias of the comparisons being on the Vault website, we attempt
|
||||
to only use facts. If you find something that is invalid or out of date
|
||||
in the comparisons, please
|
||||
[open an issue](https://github.com/hashicorp/vault/issues) and we'll
|
||||
address it as soon as possible.
|
||||
|
||||
Use the navigation on the left to read comparisons of Vault versus other
|
||||
systems.
|
||||
Although we used to publish information about Vault versus other software, we
|
||||
no longer do. Partly this is because the information grew exceedingly
|
||||
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
|
||||
ways that we prefer, we felt it wasn't appropriate to describe the capabilities
|
||||
of other projects or products in ways other than their own terms. As a result,
|
||||
we have decided to remove this section; please consult other projects or
|
||||
products for information on how they might meet your needs, and use our
|
||||
documentation or product pages to understand how Vault might meet your needs.
|
||||
|
|
|
|||
|
|
@ -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