luxolus
/
open-nomad
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity

website: starting vs section

This commit is contained in:
Armon Dadgar 2015-09-19 16:29:06 -07:00
parent 34efee7e96
commit d0a48a0141
7 changed files with 6 additions and 207 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
website/source/intro/vs/consul.html.md
View File

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

25
website/source/intro/vs/dropbox.html.md
View File

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

39
website/source/intro/vs/hsm.html.md
View File

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

11
website/source/intro/vs/index.html.markdown
View File

@ -3,19 +3,20 @@ layout: "intro"
page_title: "Nomad vs. Other Software" page_title: "Nomad vs. Other Software"
sidebar_current: "vs-other" sidebar_current: "vs-other"
description: |- 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 # Nomad vs. Other Software
There are a number of other options in the market currently that claim Nomad is a cluster manager and scheduler. There are many related categories
to store secrets in some capacity. This section compares Nomad to these including cluster managers, resource managers, workload managers, and schedulers.
other software choices. 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 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 to only use facts. If you find something that is invalid or out of date
in the comparisons, please 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. address it as soon as possible.
Use the navigation on the left to read comparisons of Nomad versus other Use the navigation on the left to read comparisons of Nomad versus other

46
website/source/intro/vs/keywhiz.html.md
View File

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

40
website/source/intro/vs/kms.html.md
View File

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

20
website/source/layouts/intro.erb
View File

@ -17,26 +17,6 @@
<a href="/intro/vs/chef-puppet-etc.html">Chef, Puppet, etc.</a> <a href="/intro/vs/chef-puppet-etc.html">Chef, Puppet, etc.</a>
</li> </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") %>> <li<%= sidebar_current("vs-other-custom") %>>
<a href="/intro/vs/custom.html">Custom Solutions</a> <a href="/intro/vs/custom.html">Custom Solutions</a>
</li> </li>