website: starting vs section
This commit is contained in:
Armon Dadgar
parent
34efee7e96
commit
d0a48a0141
|
|
@ -1,32 +0,0 @@
|
|||
---
|
||||
layout: "intro"
|
||||
page_title: "Nomad vs. Consul"
|
||||
sidebar_current: "vs-other-consul"
|
||||
description: |-
|
||||
Comparison between Nomad and attempting to store secrets with Consul.
|
||||
---
|
||||
|
||||
# Nomad vs. Consul
|
||||
|
||||
[Consul](https://consul.io) is 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.
|
||||
|
||||
Nomad 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 Nomad 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 Nomad, you get the best of both. Consul
|
||||
is used for durable storage of encrypted data at rest and provides coordination
|
||||
so that Nomad can be highly available and fault tolerant. Nomad provides
|
||||
the higher level policy management, secret leasing, audit logging, and automatic
|
||||
revocation.
|
||||
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
---
|
||||
layout: "intro"
|
||||
page_title: "Nomad vs. Dropbox"
|
||||
sidebar_current: "vs-other-dropbox"
|
||||
description: |-
|
||||
Comparison between Nomad and attempting to store secrets with Dropbox.
|
||||
---
|
||||
|
||||
# Nomad 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 Nomad 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,39 +0,0 @@
|
|||
---
|
||||
layout: "intro"
|
||||
page_title: "Nomad vs. HSMs"
|
||||
sidebar_current: "vs-other-hsm"
|
||||
description: |-
|
||||
Comparison between Nomad and HSM systems.
|
||||
---
|
||||
|
||||
# Nomad vs. HSMs
|
||||
|
||||
A [hardware security module (HSM)](http://en.wikipedia.org/wiki/Hardware_security_module)
|
||||
is a hardware device that is meant to secure various secrets. They generally
|
||||
have very strong security models and adhere to many compliance regulations.
|
||||
|
||||
The primary issue with HSMs is that they are expensive and not very
|
||||
cloud friendly. Amazon provides CloudHSM, but the minimum price point to
|
||||
even begin using CloudHSM is in the thousands of US dollars.
|
||||
|
||||
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.
|
||||
|
||||
Nomad **doesn't replace an HSM**. There are many benefits to an HSM if
|
||||
you can afford it. Instead, an HSM is a fantastic potential secret backend
|
||||
for Nomad. This would allow Nomad to access the HSM data via the Nomad API,
|
||||
making it significantly easier to use an HSM, while also retaining all the
|
||||
audit logs. In fact, you'd have multiple audit logs: requests to Nomad
|
||||
as well as to the HSM.
|
||||
|
||||
Nomad can also do many things that HSMs cannot currently do, such
|
||||
as generating _dynamic secrets_. Instead of storing AWS access keys directly
|
||||
within Nomad, Nomad can generate access keys according to a specific
|
||||
policy on the fly. Nomad has the potential of doing this for any
|
||||
system through its mountable secret backend system.
|
||||
|
||||
For most companies, an HSM is overkill, and Nomad is enough. For companies
|
||||
that can afford an HSM, it can be used with Nomad to get the best of both
|
||||
worlds.
|
||||
|
|
@ -3,19 +3,20 @@ layout: "intro"
|
|||
page_title: "Nomad vs. Other Software"
|
||||
sidebar_current: "vs-other"
|
||||
description: |-
|
||||
Comparisons between Nomad and other software that claim to store secrets in some capacity.
|
||||
Comparisons between Nomad and other cluster managers.
|
||||
---
|
||||
|
||||
# Nomad vs. Other Software
|
||||
|
||||
There are a number of other options in the market currently that claim
|
||||
to store secrets in some capacity. This section compares Nomad to these
|
||||
other software choices.
|
||||
Nomad is a cluster manager and scheduler. There are many related categories
|
||||
including cluster managers, resource managers, workload managers, and schedulers.
|
||||
There are many existing tools in each category, and the comparisons are not exhaustive
|
||||
of the entire space.
|
||||
|
||||
Due to the bias of the comparisons being on the Nomad 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
|
||||
[open an issue](https://github.com/hashicorp/nomad/issues) and we'll
|
||||
address it as soon as possible.
|
||||
|
||||
Use the navigation on the left to read comparisons of Nomad versus other
|
||||
|
|
|
|||
|
|
@ -1,46 +0,0 @@
|
|||
---
|
||||
layout: "intro"
|
||||
page_title: "Nomad vs. Keywhiz"
|
||||
sidebar_current: "vs-other-keywhiz"
|
||||
description: |-
|
||||
Comparison between Nomad and Keywhiz.
|
||||
---
|
||||
|
||||
# Nomad 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.
|
||||
|
||||
Nomad similarly is designed as a comprehensive secret management
|
||||
solution. The client interaction with Nomad is flexible
|
||||
both for authentication and usage of secrets. Nomad supports [mTLS
|
||||
authentication](/docs/auth/cert.html) along with many [other
|
||||
mechanisms](/docs/auth/index.html). The goal being to make it easy to
|
||||
authenticate as a machine for programmatic access and as a human for
|
||||
operator usage.
|
||||
|
||||
Nomad and Keywhiz expose secrets via an API. The Nomad
|
||||
[ACL system](/docs/concepts/policies.html) is used
|
||||
to protect secrets and gate access, similarly to the
|
||||
Keywhiz ACL system. With Nomad, All auditing is done
|
||||
server side using [audit backends](/docs/audit/index.html).
|
||||
|
||||
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. Nomad 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 Nomad, so
|
||||
that no external systems need to be used.
|
||||
|
||||
Lastly Nomad forces a mandatory lease contract with clients. All secrets read
|
||||
from Nomad have an associated lease which enables operators to audit key usage,
|
||||
perform key rolling, and ensure automatic revocation. Nomad provides multiple
|
||||
revocation mechanisms to give operators a clear "break glass" procedure after
|
||||
a potential compromise.
|
||||
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
---
|
||||
layout: "intro"
|
||||
page_title: "Nomad vs. Amazon Key Management Service"
|
||||
sidebar_current: "vs-other-kms"
|
||||
description: |-
|
||||
Comparison between Nomad and Amazon Key Management Service.
|
||||
---
|
||||
|
||||
# Nomad 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.
|
||||
|
||||
Nomad and KMS differ in the scope of problems they are trying to solve.
|
||||
The KMS service 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, Nomad provides a comprehensive secret management solution.
|
||||
The [`transit` backend](/docs/secrets/transit/index.html)
|
||||
provides similar capabilities as the KMS service, allowing for encryption keys
|
||||
to be stored and cryptographic operations to be performed. However, Nomad goes
|
||||
much futher than just key management.
|
||||
|
||||
The flexible secret backends allow Nomad to handle any type of secret data,
|
||||
including database credentials, API keys, PKI keys, and encryption keys.
|
||||
Nomad also supports dynamic secrets, generating credentials on-demand for
|
||||
fine-grained security controls, auditing, and non-repudiation.
|
||||
|
||||
Lastly Nomad forces a mandatory lease contract with clients. All secrets read
|
||||
from Nomad have an associated lease which enables operations to audit key usage,
|
||||
perform key rolling, and ensure automatic revocation. Nomad provides multiple
|
||||
revocation mechansims to give operators a clear "break glass" procedure after
|
||||
a potential compromise.
|
||||
|
||||
Nomad 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.
|
||||
|
||||
|
|
@ -17,26 +17,6 @@
|
|||
<a href="/intro/vs/chef-puppet-etc.html">Chef, Puppet, etc.</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("vs-other-hsm") %>>
|
||||
<a href="/intro/vs/hsm.html">HSMs</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("vs-other-dropbox") %>>
|
||||
<a href="/intro/vs/dropbox.html">Dropbox</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("vs-other-consul") %>>
|
||||
<a href="/intro/vs/consul.html">Consul</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("vs-other-kms") %>>
|
||||
<a href="/intro/vs/kms.html">Amazon KMS</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("vs-other-keywhiz") %>>
|
||||
<a href="/intro/vs/keywhiz.html">Keywhiz</a>
|
||||
</li>
|
||||
|
||||
<li<%= sidebar_current("vs-other-custom") %>>
|
||||
<a href="/intro/vs/custom.html">Custom Solutions</a>
|
||||
</li>
|
||||
|
|
|
|||
Loading…
Reference in a new issue