kemko/nomad
1
0
Fork 0
mirror of https://github.com/kemko/nomad.git synced 2026-01-06 18:35:44 +03:00
Code Issues Packages Projects Releases Wiki Activity

website: Replace Vault -> Nomad

Browse Source
This commit is contained in:
Armon Dadgar
2015-09-17 16:33:37 -07:00
parent c2364f12c7
commit 6bf4bebaab
83 changed files with 693 additions and 693 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
website/source/docs/audit/index.html.md
View File

@@ -3,25 +3,25 @@ layout: "docs"
page_title: "Audit Backends"
sidebar_current: "docs-audit"
description: |-
Audit backends are mountable backends that log requests and responses in Vault.
Audit backends are mountable backends that log requests and responses in Nomad.
---
# Audit Backends
Audit backends are the components in Vault that keep a detailed log
of all requests and response to Vault. Because _every_ operation with
Vault is an API request/response, the audit log contains _every_ interaction
with Vault, including errors.
Audit backends are the components in Nomad that keep a detailed log
of all requests and response to Nomad. Because _every_ operation with
Nomad is an API request/response, the audit log contains _every_ interaction
with Nomad, including errors.
Vault ships with multiple audit backends, depending on the location you want
the logs sent to. Multiple audit backends can be enabled and Vault will send
Nomad ships with multiple audit backends, depending on the location you want
the logs sent to. Multiple audit backends can be enabled and Nomad will send
the audit logs to both. This allows you to not only have a redundant copy,
but also a second copy in case the first is tampered with.
## Sensitive Information
The audit logs contain the full request and response objects for every
interaction with Vault. The data in the request and the data in the
interaction with Nomad. The data in the request and the data in the
response (including secrets and authentication tokens) will be hashed
without a salt using SHA1.
@@ -31,7 +31,7 @@ secrets by SHA-ing it yourself.
## Enabling/Disabling Audit Backends
When a Vault server is first initialized, no auditing is enabled. Audit
When a Nomad server is first initialized, no auditing is enabled. Audit
backends must be enabled by a root user using `vault audit-enable`.
When enabling an audit backend, options can be passed to it to configure it.
@@ -51,17 +51,17 @@ The existing logs that it did store are untouched.
## Blocked Audit Backends
If there are any audit backends enabled, Vault requires that at least
one be able to persist the log before completing a Vault request.
If there are any audit backends enabled, Nomad requires that at least
one be able to persist the log before completing a Nomad request.
If you have only one audit backend enabled, and it is blocking (network
block, etc.), then Vault will be _unresponsive_. Vault _will not_ complete
block, etc.), then Nomad will be _unresponsive_. Nomad _will not_ complete
any requests until the audit backend can write.
If you have more than one audit backend, then Vault will complete the request
If you have more than one audit backend, then Nomad will complete the request
as long as one audit backend persists the log.
Vault will not respond to requests if audit backends are blocked because
Nomad will not respond to requests if audit backends are blocked because
audit logs are critically important and ignoring blocked requests opens
an avenue for attack. Be absolutely certain that your audit backends cannot
block.

2
website/source/docs/audit/syslog.html.md
View File

@@ -14,7 +14,7 @@ The "syslog" audit backend writes audit logs to syslog.
It currently does not support a configurable syslog destination, and
always sends to the local agent. This backend is only supported on Unix systems,
and should not be enabled if any standby Vault instances do not support it.
and should not be enabled if any standby Nomad instances do not support it.
## Options

12
website/source/docs/auth/app-id.html.md
View File

@@ -3,7 +3,7 @@ layout: "docs"
page_title: "Auth Backend: App ID"
sidebar_current: "docs-auth-appid"
description: |-
The App ID auth backend is a mechanism for machines to authenticate with Vault.
The App ID auth backend is a mechanism for machines to authenticate with Nomad.
---
# Auth Backend: App ID
@@ -11,13 +11,13 @@ description: |-
Name: `app-id`
The App ID auth backend is a mechanism for machines to authenticate with
Vault. It works by requiring two hard-to-guess unique pieces of information:
Nomad. It works by requiring two hard-to-guess unique pieces of information:
a unique app ID, and a unique user ID.
The goal of this credential provider is to allow elastic users
(dynamic machines, containers, etc.) to authenticate with Vault without
having to store passwords outside of Vault. It is a single method of
solving the chicken-and-egg problem of setting up Vault access on a machine.
(dynamic machines, containers, etc.) to authenticate with Nomad without
having to store passwords outside of Nomad. It is a single method of
solving the chicken-and-egg problem of setting up Nomad access on a machine.
With this provider, nobody except the machine itself has access to both
pieces of information necessary to authenticate. For example:
configuration management will have the app IDs, but the machine itself
@@ -40,7 +40,7 @@ An example, real world process for using this provider:
4. A new server is provisioned. Configuration management configures the
app ID, the server itself detects its user ID. With both of these
pieces of information, Vault can be accessed according to the policy
pieces of information, Nomad can be accessed according to the policy
set by the app ID.
More details on this process follow:

2
website/source/docs/auth/cert.html.md
View File

@@ -3,7 +3,7 @@ layout: "docs"
page_title: "Auth Backend: TLS Certificates"
sidebar_current: "docs-auth-cert"
description: |-
The "cert" auth backend allows users to authenticate with Vault using TLS client certificates.
The "cert" auth backend allows users to authenticate with Nomad using TLS client certificates.
---
# Auth Backend: TLS Certificates

10
website/source/docs/auth/github.html.md
View File

@@ -3,17 +3,17 @@ layout: "docs"
page_title: "Auth Backend: GitHub"
sidebar_current: "docs-auth-github"
description: |-
The GitHub auth backend allows authentication with Vault using GitHub.
The GitHub auth backend allows authentication with Nomad using GitHub.
---
# Auth Backend: GitHub
Name: `github`
The GitHub auth backend can be used to authenticate with Vault using
The GitHub auth backend can be used to authenticate with Nomad using
a GitHub personal access token.
This method of authentication is most useful for humans: operators or
developers using Vault directly via the CLI.
developers using Nomad directly via the CLI.
## Authentication
@@ -63,7 +63,7 @@ Success! Data written to: auth/github/config
```
After configuring that, you must map the teams of that organization to
policies within Vault. Use the `map/teams/<team>` endpoints to do that.
policies within Nomad. Use the `map/teams/<team>` endpoints to do that.
Example:
```
@@ -71,7 +71,7 @@ $ vault write auth/github/map/teams/owners value=root
Success! Data written to: auth/github/map/teams/owners
```
The above would make anyone in the "owners" team a root user in Vault
The above would make anyone in the "owners" team a root user in Nomad
(not recommended).
You can then auth with a user that is a member of the "owners" team using a Personal Access Token with the `read:org` scope.

8
website/source/docs/auth/index.html.md
View File

@@ -3,17 +3,17 @@ layout: "docs"
page_title: "Auth Backends"
sidebar_current: "docs-auth"
description: |-
Auth backends are mountable backends that perform authentication for Vault.
Auth backends are mountable backends that perform authentication for Nomad.
---
# Auth Backends
Auth backends are the components in Vault that perform authentication
Auth backends are the components in Nomad that perform authentication
and are responsible for assigning identity and a set of policies to a
user.
Having multiple auth backends enables you to use an auth backend
that makes the sense for your use case of Vault and your organization.
that makes the sense for your use case of Nomad and your organization.
For example, on developer machines, the [GitHub auth backend](/docs/auth/github.html)
is easiest to use. But for servers the [App ID](/docs/auth/app-id.html)
@@ -27,7 +27,7 @@ To learn more about authentication, see the
Auth backends can be enabled/disabled using the CLI or the API.
When enabled, auth backends are similar to [secret backends](/docs/secrets/index.html):
they are mounted within the Vault mount table and can be accessed
they are mounted within the Nomad mount table and can be accessed
and configured using the standard read/write API. The only difference
is that all auth backends are mounted underneath the `auth/` prefix.

12
website/source/docs/auth/ldap.html.md
View File

@@ -3,7 +3,7 @@ layout: "docs"
page_title: "Auth Backend: LDAP"
sidebar_current: "docs-auth-ldap"
description: |-
The "ldap" auth backend allows users to authenticate with Vault using LDAP credentials.
The "ldap" auth backend allows users to authenticate with Nomad using LDAP credentials.
---
# Auth Backend: LDAP
@@ -11,11 +11,11 @@ description: |-
Name: `ldap`
The "ldap" auth backend allows authentication using an existing LDAP
server and user/password credentials. This allows Vault to be integrated
server and user/password credentials. This allows Nomad to be integrated
into environments using LDAP without duplicating the user/pass configuration
in multiple places.
The mapping of groups in LDAP to Vault policies is managed by using the
The mapping of groups in LDAP to Nomad policies is managed by using the
`users/` and `groups/` paths.
## Authentication
@@ -100,13 +100,13 @@ $ vault write auth/ldap/config url="ldap://ldap.forumsys.com" \
The above configures the target LDAP server, along with the parameters
specifying how users and groups should be queried from the LDAP server.
Next we want to create a mapping from an LDAP group to a Vault policy:
Next we want to create a mapping from an LDAP group to a Nomad policy:
```
$ vault write auth/ldap/groups/scientists policies=foo,bar
```
This maps the LDAP group "scientists" to the "foo" and "bar" Vault policies.
This maps the LDAP group "scientists" to the "foo" and "bar" Nomad policies.
We can also add specific LDAP users to additional (potentially non-LDAP) groups:
@@ -116,7 +116,7 @@ $ vault write auth/ldap/users/tesla groups=engineers
```
This adds the LDAP user "tesla" to the "engineers" group, which maps to
the "foobar" Vault policy.
the "foobar" Nomad policy.
Finally, we can test this by authenticating:

2
website/source/docs/auth/token.html.md
View File

@@ -14,7 +14,7 @@ built-in CLI methods such as `vault token-create`. It allows users to
authenticate using a token, as well to create new tokens, revoke
secrets by token, and more.
When any other auth backend returns an identity, Vault core invokes the
When any other auth backend returns an identity, Nomad core invokes the
token backend to create a new unique token for that identity.
The token store can also be used to bypass any other auth backend:

4
website/source/docs/auth/userpass.html.md
View File

@@ -3,14 +3,14 @@ layout: "docs"
page_title: "Auth Backend: Username & Password"
sidebar_current: "docs-auth-userpass"
description: |-
The "userpass" auth backend allows users to authenticate with Vault using a username and password.
The "userpass" auth backend allows users to authenticate with Nomad using a username and password.
---
# Auth Backend: Username & Password
Name: `userpass`
The "userpass" auth backend allows users to authenticate with Vault using
The "userpass" auth backend allows users to authenticate with Nomad using
a username and password combination.
The username/password combinations are configured directly to the auth

22
website/source/docs/commands/help.html.md
View File

@@ -3,28 +3,28 @@ layout: "docs"
page_title: "Path Help"
sidebar_current: "docs-commands-path-help"
description: |-
The Vault CLI has a built-in help system that can be used to get help for not only the CLI itself, but also any paths that the CLI can be used with within Vault.
The Nomad CLI has a built-in help system that can be used to get help for not only the CLI itself, but also any paths that the CLI can be used with within Nomad.
---
# Help
In addition to standard CLI help using the `-h` or `-help` flag for
commands, Vault has a built-in `path-help` command that can be used to get
help for specific paths within Vault. These paths are used with the
API or `read, write, delete` commands in order to interact with Vault.
commands, Nomad has a built-in `path-help` command that can be used to get
help for specific paths within Nomad. These paths are used with the
API or `read, write, delete` commands in order to interact with Nomad.
The help system is the easiest way to learn how to use the various systems
in Vault, and also allows you to discover new paths.
in Nomad, and also allows you to discover new paths.
-> **Important!** The help system is incredibly important in day-to-day
use of Vault. As a beginner or experienced user of Vault, you'll be using
use of Nomad. As a beginner or experienced user of Nomad, you'll be using
the help command a lot to remember how to use different components of
Vault. Note that the Vault Server must be running and the client configured
Nomad. Note that the Nomad Server must be running and the client configured
properly to execute this command to look up paths.
## Discovering Paths
Before using `path-help`, it is important to understand "paths" within Vault.
Before using `path-help`, it is important to understand "paths" within Nomad.
Paths are the parameters used for `vault read`, `vault write`, etc. An
example path is `secret/foo`, or `aws/config/root`. The paths available
depend on the mounted secret backends. Because of this, the interactive
@@ -36,7 +36,7 @@ For example, if you mounted the AWS secret backend, you can use
will be shown with regular expressions, which can make them hard to
parse, but they're also extremely exact.
You can try it right away with any Vault with `vault path-help secret`, since
You can try it right away with any Nomad with `vault path-help secret`, since
`secret` is always mounted initially. The output from this command is shown
below and contains both a description of what that backend is for, along with
the paths it supports.
@@ -46,7 +46,7 @@ $ vault path-help secret
## DESCRIPTION
The generic backend reads and writes arbitrary secrets to the backend.
The secrets are encrypted/decrypted by Vault: they are never stored
The secrets are encrypted/decrypted by Nomad: they are never stored
unencrypted in the backend and the backend never has an opportunity to
see the unencrypted value.
@@ -99,7 +99,7 @@ The pass-through backend reads and writes arbitrary data into secret storage,
encrypting it along the way.
A lease can be specified when writing with the "lease" field. If given, then
when the secret is read, Vault will report a lease with that duration. It
when the secret is read, Nomad will report a lease with that duration. It
is expected that the consumer of this backend properly writes renewed keys
before the lease is up. In addition, revocation must be handled by the
user of this backend.

12
website/source/docs/commands/index.html.md
View File

@@ -3,21 +3,21 @@ layout: "docs"
page_title: "Commands (CLI)"
sidebar_current: "docs-commands"
description: |-
Vault can be controlled via a command-line interface. This page documents all the commands Vault accepts.
Nomad can be controlled via a command-line interface. This page documents all the commands Nomad accepts.
---
# Vault Commands (CLI)
# Nomad Commands (CLI)
Vault is controlled via a very easy to use command-line interface (CLI).
Vault is only a single command-line application: `vault`. This application
Nomad is controlled via a very easy to use command-line interface (CLI).
Nomad is only a single command-line application: `vault`. This application
then takes a subcommand such as "read" or "write". The complete list of
subcommands is in the navigation to the left.
The Vault CLI is a well-behaved command line application. In erroneous cases,
The Nomad CLI is a well-behaved command line application. In erroneous cases,
a non-zero exit status will be returned. It also responds to `-h` and `--help`
as you'd most likely expect.
To view a list of the available commands at any time, just run Vault
To view a list of the available commands at any time, just run Nomad
with no arguments. To get help for any specific subcommand, run the subcommand
with the `-h` argument.

16
website/source/docs/commands/read-write.html.md
View File

@@ -3,15 +3,15 @@ layout: "docs"
page_title: "Reading and Writing Data"
sidebar_current: "docs-commands-readwrite"
description: |-
The Vault CLI can be used to read, write, and delete secrets. This page documents how to do this.
The Nomad CLI can be used to read, write, and delete secrets. This page documents how to do this.
---
# Reading and Writing Data with the CLI
The Vault CLI can be used to read, write, and delete data from Vault.
The Nomad CLI can be used to read, write, and delete data from Nomad.
This data might be raw secrets, it might be configuration for
a backend, etc. Whatever it is, the interface to read and write data
to Vault is the same.
to Nomad is the same.
To determine what paths can be used to read and write data,
please use the built-in [help system](/docs/commands/help.html)
@@ -19,7 +19,7 @@ to discover the paths.
## Writing Data
To write data to Vault, you use `vault write`. It is very easy to use:
To write data to Nomad, you use `vault write`. It is very easy to use:
```
$ vault write secret/password value=itsasecret
@@ -36,15 +36,15 @@ $ vault write secret/password value=itsasecret username=something
For the `secret/` backend, the key/value pairs are arbitrary and can be
anything. For other backends, they're generally more strict, and the
help system can tell you what data to send to Vault.
help system can tell you what data to send to Nomad.
In addition to writing key/value pairs, Vault can write from a variety
In addition to writing key/value pairs, Nomad can write from a variety
more sources.
#### stdin
`vault write` can read data to write from stdin by using "-" as the value.
If you use "-" as the entire argument, then Vault expects to read a JSON
If you use "-" as the entire argument, then Nomad expects to read a JSON
object from stdin. The example below is equivalent to the first example
above.
@@ -59,7 +59,7 @@ from stdin: if they're after the "-" (positionally on the command-line),
then they will overwrite it, otherwise the values in stdin will overwrite
the command line values.
In addition to reading full JSON objects, Vault can read just a JSON
In addition to reading full JSON objects, Nomad can read just a JSON
value. The example below is also identical to the previous example.
```

16
website/source/docs/concepts/auth.html.md
View File

@@ -3,23 +3,23 @@ layout: "docs"
page_title: "Authentication"
sidebar_current: "docs-concepts-auth"
description: |-
Before performing any operation with Vault, the connecting client must be authenticated.
Before performing any operation with Nomad, the connecting client must be authenticated.
---
# Authentication
Before performing any operation with Vault, the connecting client must be
Before performing any operation with Nomad, the connecting client must be
_authenticated_. Authentication is the process of verifying a person or
machine is who they say they are and assigning an identity to them. This
identity is then used when making requests with Vault.
identity is then used when making requests with Nomad.
Authentication in Vault is pluggable via authentication backends. This
allows you to authenticate with Vault using a method that works best for your
Authentication in Nomad is pluggable via authentication backends. This
allows you to authenticate with Nomad using a method that works best for your
organization. For example, you can authenticate using GitHub, certs, etc.
## Authentication Backends
There are many authentication backends available for Vault. They
There are many authentication backends available for Nomad. They
are enabled using `vault auth-enable`. After they're enabled, you can
learn more about them using `vault path-help auth/<name>`. For example,
if you enable GitHub, you can use `vault path-help auth/github` to learn more
@@ -40,7 +40,7 @@ but it is important to understand that authentication works by verifying
your identity and then generating a token to associate with that identity.
For example, even though you may authenticate using something like GitHub,
Vault generates a unique access token for you to use for future requests.
Nomad generates a unique access token for you to use for future requests.
The CLI automatically attaches this token to requests, but if you're using
the API you'll have to do this manually.
@@ -88,7 +88,7 @@ be used.
Just like secrets, identities have
[leases](/docs/concepts/lease.html) associated with them. This means that
you must reauthenticate after the given lease period to continue accessing
Vault.
Nomad.
To set the lease associated with an identity, reference the help for
the specific authentication backend in use. It is specific to each backend

18
website/source/docs/concepts/dev-server.html.md
View File

@@ -3,15 +3,15 @@ layout: "docs"
page_title: "Dev Server Mode"
sidebar_current: "docs-concepts-devserver"
description: |-
The dev server in Vault can be used for development or to experiment with Vault.
The dev server in Nomad can be used for development or to experiment with Nomad.
---
# "Dev" Server Mode
You can start Vault as a server in "dev" mode like so: `vault server -dev`.
You can start Nomad as a server in "dev" mode like so: `vault server -dev`.
This dev-mode server requires no further setup, and your local `vault` CLI will
be authenticated to talk to it. This makes it easy to experiment with Vault or
start a Vault instance for development. Every feature of Vault is available in
be authenticated to talk to it. This makes it easy to experiment with Nomad or
start a Nomad instance for development. Every feature of Nomad is available in
"dev" mode. The `-dev` flag just short-circuits a lot of setup to insecure
defaults.
@@ -27,25 +27,25 @@ The properties of the dev server:
and unsealed. You don't need to use `vault unseal`. It is ready for use
immediately.
* **In-memory storage** - All data is stored (encrypted) in-memory. Vault
* **In-memory storage** - All data is stored (encrypted) in-memory. Nomad
server doesn't require any file permissions.
* **Bound to local address without TLS** - The server is listening on
`127.0.0.1:8200` (the default server address) _without_ TLS.
* **Automatically Authenticated** - The server stores your root access
token so `vault` CLI access is ready to go. If you are accessing Vault
token so `vault` CLI access is ready to go. If you are accessing Nomad
via the API, you'll need to authenticate using the token printed out.
* **Single unseal key** - The server is initialized with a single unseal
key. The Vault is already unsealed, but if you want to experiment with
key. The Nomad is already unsealed, but if you want to experiment with
seal/unseal, then only the single outputted key is required.
## Use Case
The dev server should be used for experimentation with Vault features, such
The dev server should be used for experimentation with Nomad features, such
as different authentication backends, secret backends, audit backends, etc.
If you're new to Vault, you may want to pick up with [Your First
If you're new to Nomad, you may want to pick up with [Your First
Secret](http://vaultproject.io/intro/getting-started/first-secret.html) in
our getting started guide.

20
website/source/docs/concepts/ha.html.markdown
View File

@@ -3,29 +3,29 @@ layout: "docs"
page_title: "High Availability"
sidebar_current: "docs-concepts-ha"
description: |-
Vault can be highly available, allowing you to run multiple Vaults to protect against outages.
Nomad can be highly available, allowing you to run multiple Nomads to protect against outages.
---
# High Availability Mode (HA)
Vault supports multi-server mode for high availability. This mode protects
against outages by running multiple Vault servers. High availability mode
Nomad supports multi-server mode for high availability. This mode protects
against outages by running multiple Nomad servers. High availability mode
is automatically enabled when using a storage backend that supports it.
You can tell if a backend supports high availability mode ("HA") by
starting the server and seeing if "(HA available)" is outputted next to
the backend information. If it is, then HA will begin happening automatically.
To be highly available, Vault elects a leader and does request forwarding to
To be highly available, Nomad elects a leader and does request forwarding to
the leader. Due to this architecture, HA does not enable increased scalability.
In general, the bottleneck of Vault is the storage backend itself, not
Vault core. For example: to increase scalability of Vault with Consul, you
would scale Consul instead of Vault.
In general, the bottleneck of Nomad is the storage backend itself, not
Nomad core. For example: to increase scalability of Nomad with Consul, you
would scale Consul instead of Nomad.
In addition to using a backend that supports HA, you have to configure
Vault with an _advertise address_. This is the address that Vault advertises
to other Vault servers in the cluster for request forwarding. By default,
Vault will use the first private IP address it finds, but you can override
Nomad with an _advertise address_. This is the address that Nomad advertises
to other Nomad servers in the cluster for request forwarding. By default,
Nomad will use the first private IP address it finds, but you can override
this to any address you want.
## Backend Support

6
website/source/docs/concepts/index.html.md
View File

@@ -3,14 +3,14 @@ layout: "docs"
page_title: "Basic Concepts"
sidebar_current: "docs-concepts"
description: |-
Basic concepts that are important to understand for Vault usage.
Basic concepts that are important to understand for Nomad usage.
---
# Basic Concepts
This section covers some high level basic concepts that are important
to understand for day to day Vault usage and operation. Every page in
to understand for day to day Nomad usage and operation. Every page in
this section is recommended reading for anyone consuming or operating
Vault.
Nomad.
Please use the navigation to the left to learn more about a topic.

18
website/source/docs/concepts/lease.html.md
View File

@@ -3,22 +3,22 @@ layout: "docs"
page_title: "Lease, Renew, and Revoke"
sidebar_current: "docs-concepts-lease"
description: |-
Vault provides a lease with every secret. When this lease is expired, Vault will revoke that secret.
Nomad provides a lease with every secret. When this lease is expired, Nomad will revoke that secret.
---
# Lease, Renew, and Revoke
With every secret and authentication token, Vault provides a _lease_:
an amount of time that Vault promises that the data will be valid for.
Once the lease is up, Vault can automatically revoke the data, and the
With every secret and authentication token, Nomad provides a _lease_:
an amount of time that Nomad promises that the data will be valid for.
Once the lease is up, Nomad can automatically revoke the data, and the
consumer of the secret can no longer be certain that it is valid.
The benefit should be clear: consumers of secrets need to check in with
Vault routinely to either renew the lease (if allowed) or request a
replacement secret. This makes the Vault audit logs more valuable and
Nomad routinely to either renew the lease (if allowed) or request a
replacement secret. This makes the Nomad audit logs more valuable and
also makes key rolling a lot easier.
All secrets in Vault are required to have a lease. Even if the data is
All secrets in Nomad are required to have a lease. Even if the data is
meant to be valid for eternity, a lease is required to force the consumer
to check in routinely.
@@ -33,12 +33,12 @@ be deleted from AWS the moment a secret is revoked. This renders the access
keys invalid from that point forward.
Revocation can happen manually via the API or `vault revoke`, or automatically
by Vault. When a lease is expired, Vault will automatically revoke that
by Nomad. When a lease is expired, Nomad will automatically revoke that
lease.
## Lease IDs
When reading a secret, such as via `vault read`, Vault always returns
When reading a secret, such as via `vault read`, Nomad always returns
a `lease_id`. This is the ID used with commands such as `vault renew` and
`vault revoke` to manage the lease of the secret.

22
website/source/docs/concepts/policies.html.md
View File

@@ -3,18 +3,18 @@ layout: "docs"
page_title: "Policies"
sidebar_current: "docs-concepts-policies"
description: |-
Policies are how authorization is done in Vault, allowing you to restrict which parts of Vault a user can access.
Policies are how authorization is done in Nomad, allowing you to restrict which parts of Nomad a user can access.
---
# Access Control Policies
After [authenticating](/docs/concepts/auth.html) with Vault, the
After [authenticating](/docs/concepts/auth.html) with Nomad, the
next step is authorization. This is the process of determining what
a user is allowed to do. Authorization is unified in Vault in the form
a user is allowed to do. Authorization is unified in Nomad in the form
of _policies_.
Policies are [HCL](https://github.com/hashicorp/hcl) or JSON documents
that describe what parts of Vault a user is allowed to access. An example
that describe what parts of Nomad a user is allowed to access. An example
of a policy is shown below:
```javascript
@@ -37,8 +37,8 @@ path "secret/super-secret" {
Policies use path based matching to apply rules. A policy may be an exact
match, or might be a glob pattern which uses a prefix. The default policy
is always deny so if a path isn't explicitly allowed, Vault will reject access to it.
This works well due to Vault's architecture of being like a filesystem:
is always deny so if a path isn't explicitly allowed, Nomad will reject access to it.
This works well due to Nomad's architecture of being like a filesystem:
everything has a path associated with it, including the core configuration
mechanism under "sys".
@@ -59,7 +59,7 @@ Allowed policies for a path are:
* `read` - Read-only access to a path.
The only non-obvious policy is "sudo". Some routes within Vault and mounted
The only non-obvious policy is "sudo". Some routes within Nomad and mounted
backends are marked as _root_ paths. Clients aren't allowed to access root
paths unless they are a root user (have the special policy "root") or
have access to that path with the "sudo" policy.
@@ -71,7 +71,7 @@ Only root or "sudo" privilege users are allowed to do this.
The "root" policy is a special policy that can not be modified or removed.
Any user associated with the "root" policy becomes a root user. A root
user can do _anything_ within Vault.
user can do _anything_ within Nomad.
There always exists at least one root user (associated with the token
when initializing a new server). After this root user, it is recommended
@@ -104,7 +104,7 @@ active identity.
## Changes from 0.1
In Vault versions prior to 0.2, the ACL policy language had a slightly
In Nomad versions prior to 0.2, the ACL policy language had a slightly
different specification and semantics. The current specification requires
that glob behavior explicitly be specified by adding the `*` character to
the end of a path. Previously, all paths were glob based matches and no
@@ -125,9 +125,9 @@ path "sys/seal" {
```
The merge would previously give the "read" higher precedence. The current
version of Vault prioritizes the explicit deny, so that the "deny" would
version of Nomad prioritizes the explicit deny, so that the "deny" would
take precedence.
To make all Vault 0.1 policies compatible with Vault 0.2, the explicit
To make all Nomad 0.1 policies compatible with Nomad 0.2, the explicit
glob character must be added to all the path prefixes.

32
website/source/docs/concepts/seal.html.md
View File

@@ -3,36 +3,36 @@ layout: "docs"
page_title: "Seal/Unseal"
sidebar_current: "docs-concepts-seal"
description: |-
A Vault must be unsealed before it can access its data. Likewise, it can be sealed to lock it down.
A Nomad must be unsealed before it can access its data. Likewise, it can be sealed to lock it down.
---
# Seal/Unseal
When a Vault server is started, it starts in a _sealed_ state. In this
state, Vault is configured to know where and how to access the physical
When a Nomad server is started, it starts in a _sealed_ state. In this
state, Nomad is configured to know where and how to access the physical
storage, but doesn't know how to decrypt any of it.
_Unsealing_ is the process of constructing the master key necessary to
read the decryption key to decrypt the data, allowing access to the Vault.
read the decryption key to decrypt the data, allowing access to the Nomad.
Prior to unsealing, almost no operations are possible with Vault. For
Prior to unsealing, almost no operations are possible with Nomad. For
example authentication, managing the mount tables, etc. are all not possible.
The only possible operations are to unseal the Vault and check the status
The only possible operations are to unseal the Nomad and check the status
of the unseal.
## Why?
The data stored by Vault is stored encrypted. Vault needs the
The data stored by Nomad is stored encrypted. Nomad needs the
_encryption key_ in order to decrypt the data. The encryption key is
also stored with the data, but encrypted with another encryption key
known as the _master key_. The master key isn't stored anywhere.
Therefore, to decrypt the data, Vault must decrypt the encryption key
Therefore, to decrypt the data, Nomad must decrypt the encryption key
which requires the master key. Unsealing is the process of reconstructing
this master key.
Instead of distributing this master key as a single key to an operator,
Vault uses an algorithm known as
Nomad uses an algorithm known as
[Shamir's Secret Sharing](http://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing)
to split the key into shards. A certain threshold of shards is required to
reconstruct the master key.
@@ -48,25 +48,25 @@ This process is stateful: each key can be entered via multiple mechanisms
on multiple computers and it will work. This allows each shard of the master
key to be on a distinct machine for better security.
Once a Vault is unsealed, it remains unsealed until one of two things happens:
Once a Nomad is unsealed, it remains unsealed until one of two things happens:
1. It is resealed via the API (see below).
2. The server is restarted.
-> **Note:** Unsealing makes the process of automating a Vault install
difficult. Automated tools can easily install, configure, and start Vault,
-> **Note:** Unsealing makes the process of automating a Nomad install
difficult. Automated tools can easily install, configure, and start Nomad,
but unsealing it is a very manual process. We have plans in the future to
make it easier. For the time being, the best method is to manually unseal
multiple Vault servers in [HA mode](/docs/concepts/ha.html). Use a tool such
as Consul to make sure you only query Vault servers that are unsealed.
multiple Nomad servers in [HA mode](/docs/concepts/ha.html). Use a tool such
as Consul to make sure you only query Nomad servers that are unsealed.
## Sealing
There is also an API to seal the Vault. This will throw away the encryption
There is also an API to seal the Nomad. This will throw away the encryption
key and require another unseal process to restore it. Sealing only requires
a single operator with root privileges.
This way, if there is a detected intrusion, the Vault data can be locked
This way, if there is a detected intrusion, the Nomad data can be locked
quickly to try to minimize damages. It can't be accessed again without
access to the master key shards.

8
website/source/docs/concepts/tokens.html.md
View File

@@ -3,18 +3,18 @@ layout: "docs"
page_title: "Tokens"
sidebar_current: "docs-concepts-tokens"
description: |-
Tokens are a core authentication method in Vault. Child tokens, token-based revocation, and more.
Tokens are a core authentication method in Nomad. Child tokens, token-based revocation, and more.
---
# Tokens
Tokens are the core method for _authentication_ within Vault. Tokens
Tokens are the core method for _authentication_ within Nomad. Tokens
can be used directly or [authentication backends](/docs/concepts/auth.html)
can be used to dynamically generate tokens based on external identities.
If you've gone through the getting started guide, you probably noticed that
`vault server -dev` (or `vault init` for a non-dev server) outputs an
initial "root token." This is the first method of authentication for Vault.
initial "root token." This is the first method of authentication for Nomad.
It is also the only authentication backend that cannot be disabled.
As stated in the [authentication concepts](/docs/concepts/auth.html),
@@ -47,7 +47,7 @@ with the token. Learn more about policies on the
Every token has a lease associated with it. These leases behave in much
the same way as [leases for secrets](/docs/concepts/lease.html). After
the lease period is up, the token will no longer function. In addition
to no longer functioning, Vault will revoke it.
to no longer functioning, Nomad will revoke it.
In order to avoid your token being revoked, the `vault token-renew`
command should be used to renew the lease on the token periodically.

24
website/source/docs/config/index.html.md
View File

@@ -3,12 +3,12 @@ layout: "docs"
page_title: "Server Configuration"
sidebar_current: "docs-config"
description: |-
Vault server configuration reference.
Nomad server configuration reference.
---
# Server Configuration
Outside of development mode, Vault servers are configured using a file.
Outside of development mode, Nomad servers are configured using a file.
The format of this file is [HCL](https://github.com/hashicorp/hcl) or JSON.
An example configuration is shown below:
@@ -34,11 +34,11 @@ to specify where the configuration is.
## Reference
* `backend` (required) - Configures the storage backend where Vault data
* `backend` (required) - Configures the storage backend where Nomad data
is stored. There are multiple options available for storage backends,
and they're documented below.
* `listener` (required) - Configures how Vault is listening for API requests.
* `listener` (required) - Configures how Nomad is listening for API requests.
"tcp" is currently the only option available. A full reference for the
inner syntax is below.
@@ -59,9 +59,9 @@ to specify where the configuration is.
In production, you should only consider setting the `disable_mlock` option
on Linux systems that only use encrypted swap or do not use swap at all.
Vault does not currently support memory locking on Mac OS X and Windows
Nomad does not currently support memory locking on Mac OS X and Windows
and so the feature is automatically disabled on those platforms. To give
the Vault executable access to the `mlock` syscall on Linux systems:
the Nomad executable access to the `mlock` syscall on Linux systems:
```shell
sudo setcap cap_ipc_lock=+ep $(readlink -f $(which vault))
@@ -70,11 +70,11 @@ sudo setcap cap_ipc_lock=+ep $(readlink -f $(which vault))
## Backend Reference
For the `backend` section, the supported backends are shown below.
Vault requires that the backend itself will be responsible for backups,
Nomad requires that the backend itself will be responsible for backups,
durability, etc.
* `consul` - Store data within [Consul](http://www.consul.io). This
backend supports HA. It is the most recommended backend for Vault
backend supports HA. It is the most recommended backend for Nomad
and has been shown to work at high scale under heavy load.
* `etcd` - Store data within [etcd](https://coreos.com/etcd/).
@@ -89,7 +89,7 @@ durability, etc.
* `mysql` - Store data within MySQL. This backend does not support HA.
* `inmem` - Store data in-memory. This is only really useful for
development and experimentation. Data is lost whenever Vault is
development and experimentation. Data is lost whenever Nomad is
restarted.
* `file` - Store data on the filesystem using a directory structure.
@@ -100,7 +100,7 @@ durability, etc.
All backends support the following options:
* `advertise_addr` (optional) - For backends that support HA, this
is the address to advertise to other Vault servers in the cluster
is the address to advertise to other Nomad servers in the cluster
for request forwarding. Most HA backends will attempt to determine
the advertise address if not provided.
@@ -213,7 +213,7 @@ The supported options are:
defaults to "127.0.0.1:8200".
* `tls_disable` (optional) - If non-empty, then TLS will be disabled.
This is an opt-in; Vault assumes by default that TLS will be used.
This is an opt-in; Nomad assumes by default that TLS will be used.
* `tls_cert_file` (required unless disabled) - The path to the certificate
for TLS.
@@ -221,7 +221,7 @@ The supported options are:
* `tls_key_file` (required unless disabled) - The path to the private key
for the certificate.
* `tls_min_version` (optional) - **(Vault > 0.2)** If provided, specifies
* `tls_min_version` (optional) - **(Nomad > 0.2)** If provided, specifies
the minimum supported version of TLS. Accepted values are "tls10", "tls11"
or "tls12". This defaults to "tls12". WARNING: TLS 1.1 and lower
are generally considered less secure; avoid using these if

28
website/source/docs/http/index.html.md
View File

@@ -3,14 +3,14 @@ layout: "http"
page_title: "HTTP API"
sidebar_current: "docs-http-overview"
description: |-
Vault has an HTTP API that can be used to control every aspect of Vault.
Nomad has an HTTP API that can be used to control every aspect of Nomad.
---
# HTTP API
The Vault HTTP API gives you full access to Vault via HTTP. Every
aspect of Vault can be controlled via this API. The Vault CLI uses
the HTTP API to access Vault.
The Nomad HTTP API gives you full access to Nomad via HTTP. Every
aspect of Nomad can be controlled via this API. The Nomad CLI uses
the HTTP API to access Nomad.
## Version Prefix
@@ -18,10 +18,10 @@ All API routes are prefixed with `/v1/`.
This documentation is only for the v1 API.
~> **Backwards compatibility:** At the current version, Vault does
~> **Backwards compatibility:** At the current version, Nomad does
not yet promise backwards compatibility even with the v1 prefix. We'll
remove this warning when this policy changes. We expect we'll reach API
stability by Vault 0.3.
stability by Nomad 0.3.
## Transport
@@ -33,10 +33,10 @@ depending on user settings.
## Authentication
Once the Vault is unsealed, every other operation requires
Once the Nomad is unsealed, every other operation requires
a _client token_. A user may have a client token explicitly.
The client token must be sent as the `token` cookie or the
`X-Vault-Token` HTTP header.
`X-Nomad-Token` HTTP header.
Otherwise, a client token can be retrieved via
[authentication backends](/docs/auth/index.html).
@@ -49,7 +49,7 @@ to each authentication backend.
Login endpoints for authentication backends that generate an identity
will be sent down with a `Set-Cookie` header as well as via JSON. If you have a
well-behaved HTTP client, then authentication information will
automatically be saved and sent to the Vault API.
automatically be saved and sent to the Nomad API.
## Reading and Writing Secrets
@@ -66,7 +66,7 @@ Here is an example of reading a secret using cURL:
```shell
curl \
-H "X-Vault-Token: f3b09679-3001-009d-2b80-9c306ab81aa6" \
-H "X-Nomad-Token: f3b09679-3001-009d-2b80-9c306ab81aa6" \
-X GET \
http://127.0.0.1:8200/v1/secret/foo
```
@@ -89,18 +89,18 @@ Here is an example of writing a secret using cURL:
```shell
curl \
-H "X-Vault-Token: f3b09679-3001-009d-2b80-9c306ab81aa6" \
-H "X-Nomad-Token: f3b09679-3001-009d-2b80-9c306ab81aa6" \
-H "Content-Type: application/json" \
-X POST \
-d '{"value":"bar"}' \
http://127.0.0.1:8200/v1/secret/baz
```
For more examples, please look at the Vault API client.
For more examples, please look at the Nomad API client.
## Help
To retrieve the help for any API within Vault, including mounted
To retrieve the help for any API within Nomad, including mounted
backends, credential providers, etc. then append `?help=1` to any
URL. If you have valid permission to access the path, then the help text
will be returned with the following structure:
@@ -144,5 +144,5 @@ The following HTTP status codes are used throughout the API.
of time.
- `500` - Internal server error. An internal error has occurred,
try again later. If the error persists, report a bug.
- `503` - Vault is down for maintenance or is currently sealed.
- `503` - Nomad is down for maintenance or is currently sealed.
Try again later.

6
website/source/docs/http/libraries.html.md
View File

@@ -3,7 +3,7 @@ layout: "http"
page_title: "HTTP API: Libraries"
sidebar_current: "docs-http-libraries"
description: |-
List of official and community contributed libraries for interacting with the Vault HTTP API.
List of official and community contributed libraries for interacting with the Nomad HTTP API.
---
# Libraries
@@ -13,11 +13,11 @@ Some are officially maintained while others are provided by the community.
## Go
* [Vault Go Client](https://github.com/hashicorp/vault/tree/master/api) (official)
* [Nomad Go Client](https://github.com/hashicorp/vault/tree/master/api) (official)
## Ruby
* [Vault Ruby Client](https://github.com/hashicorp/vault-ruby) (official)
* [Nomad Ruby Client](https://github.com/hashicorp/vault-ruby) (official)
## Python

2
website/source/docs/http/sys-auth.html.md
View File

@@ -3,7 +3,7 @@ layout: "http"
page_title: "HTTP API: /sys/auth"
sidebar_current: "docs-http-auth-auth"
description: |-
The `/sys/auth` endpoint is used to manage auth backends in Vault.
The `/sys/auth` endpoint is used to manage auth backends in Nomad.
---
# /sys/auth

6
website/source/docs/http/sys-health.html.md
View File

@@ -3,7 +3,7 @@ layout: "http"
page_title: "HTTP API: /sys/health"
sidebar_current: "docs-http-debug-health"
description: |-
The '/sys/health' endpoint is used to check the health status of Vault.
The '/sys/health' endpoint is used to check the health status of Nomad.
---
# /sys/health
@@ -11,8 +11,8 @@ description: |-
<dl>
<dt>Description</dt>
<dd>
Returns the health status of Vault. This matches the semantics of a Consul HTTP health
check and provides a simple way to monitor the health of a Vault instance.
Returns the health status of Nomad. This matches the semantics of a Consul HTTP health
check and provides a simple way to monitor the health of a Nomad instance.
</dd>
<dt>Method</dt>

6
website/source/docs/http/sys-init.html.md
View File

@@ -3,7 +3,7 @@ layout: "http"
page_title: "HTTP API: /sys/init"
sidebar_current: "docs-http-sys-init"
description: |-
The '/sys/init' endpoint is used to initialize a new Vault.
The '/sys/init' endpoint is used to initialize a new Nomad.
---
# /sys/init
@@ -13,7 +13,7 @@ description: |-
<dl>
<dt>Description</dt>
<dd>
Return the initialization status of a Vault.
Return the initialization status of a Nomad.
</dd>
<dt>Method</dt>
@@ -39,7 +39,7 @@ description: |-
<dl>
<dt>Description</dt>
<dd>
Initializes a new Vault. The Vault must've not been previously
Initializes a new Nomad. The Nomad must've not been previously
initialized.
</dd>

4
website/source/docs/http/sys-key-status.html.md
View File

@@ -3,7 +3,7 @@ layout: "http"
page_title: "HTTP API: /sys/key-status"
sidebar_current: "docs-http-rotate-key-status"
description: |-
The '/sys/key-status' endpoint is used to query info about the current encryption key of Vault.
The '/sys/key-status' endpoint is used to query info about the current encryption key of Nomad.
---
# /sys/key-status
@@ -11,7 +11,7 @@ description: |-
<dl>
<dt>Description</dt>
<dd>
Returns information about the current encryption key used by Vault.
Returns information about the current encryption key used by Nomad.
</dd>
<dt>Method</dt>

4
website/source/docs/http/sys-leader.html.md
View File

@@ -3,7 +3,7 @@ layout: "http"
page_title: "HTTP API: /sys/leader"
sidebar_current: "docs-http-ha-leader"
description: |-
The '/sys/leader' endpoint is used to check the high availability status and current leader of Vault.
The '/sys/leader' endpoint is used to check the high availability status and current leader of Nomad.
---
# /sys/leader
@@ -11,7 +11,7 @@ description: |-
<dl>
<dt>Description</dt>
<dd>
Returns the high availability status and current leader instance of Vault.
Returns the high availability status and current leader instance of Nomad.
</dd>
<dt>Method</dt>

2
website/source/docs/http/sys-mounts.html.md
View File

@@ -3,7 +3,7 @@ layout: "http"
page_title: "HTTP API: /sys/mounts"
sidebar_current: "docs-http-mounts-mounts"
description: |-
The '/sys/mounts' endpoint is used manage secret backends in Vault.
The '/sys/mounts' endpoint is used manage secret backends in Nomad.
---
# /sys/mounts

2
website/source/docs/http/sys-policy.html.md
View File

@@ -3,7 +3,7 @@ layout: "http"
page_title: "HTTP API: /sys/policy"
sidebar_current: "docs-http-auth-policy"
description: |-
The `/sys/policy` endpoint is used to manage ACL policies in Vault.
The `/sys/policy` endpoint is used to manage ACL policies in Nomad.
---
# /sys/policy

2
website/source/docs/http/sys-raw.html.md
View File

@@ -3,7 +3,7 @@ layout: "http"
page_title: "HTTP API: /sys/raw"
sidebar_current: "docs-http-debug-raw"
description: |-
The `/sys/raw` endpoint is access the raw underlying store in Vault.
The `/sys/raw` endpoint is access the raw underlying store in Nomad.
---
# /sys/raw

6
website/source/docs/http/sys-rekey.html.md
View File

@@ -3,7 +3,7 @@ layout: "http"
page_title: "HTTP API: /sys/rekey/"
sidebar_current: "docs-http-rotate-rekey"
description: |-
The `/sys/rekey/` endpoints are used to rekey the unseal keys for Vault.
The `/sys/rekey/` endpoints are used to rekey the unseal keys for Nomad.
---
# /sys/rekey/init
@@ -116,8 +116,8 @@ description: |-
<dl>
<dt>Description</dt>
<dd>
Enter a single master key share to progress the rekey of the Vault.
If the threshold number of master key shares is reached, Vault
Enter a single master key share to progress the rekey of the Nomad.
If the threshold number of master key shares is reached, Nomad
will complete the rekey. Otherwise, this API must be called multiple
times until that threshold is met.
</dd>

4
website/source/docs/http/sys-seal-status.html.md
View File

@@ -3,7 +3,7 @@ layout: "http"
page_title: "HTTP API: /sys/seal-status"
sidebar_current: "docs-http-seal-status"
description: |-
The '/sys/seal-status' endpoint is used to check the seal status of a Vault.
The '/sys/seal-status' endpoint is used to check the seal status of a Nomad.
---
# /sys/seal-status
@@ -11,7 +11,7 @@ description: |-
<dl>
<dt>Description</dt>
<dd>
Returns the seal status of the Vault.
Returns the seal status of the Nomad.
</dd>
<dt>Method</dt>

4
website/source/docs/http/sys-seal.html.md
View File

@@ -3,7 +3,7 @@ layout: "http"
page_title: "HTTP API: /sys/seal"
sidebar_current: "docs-http-seal-seal"
description: |-
The '/sys/seal' endpoint seals the Vault.
The '/sys/seal' endpoint seals the Nomad.
---
# /sys/seal
@@ -11,7 +11,7 @@ description: |-
<dl>
<dt>Description</dt>
<dd>
Seals the Vault.
Seals the Nomad.
</dd>
<dt>Method</dt>

8
website/source/docs/http/sys-unseal.html.md
View File

@@ -3,7 +3,7 @@ layout: "http"
page_title: "HTTP API: /sys/seal-unseal"
sidebar_current: "docs-http-seal-unseal"
description: |-
The '/sys/seal-unseal' endpoint is used to unseal the Vault.
The '/sys/seal-unseal' endpoint is used to unseal the Nomad.
---
# /sys/unseal
@@ -11,9 +11,9 @@ description: |-
<dl>
<dt>Description</dt>
<dd>
Enter a single master key share to progress the unsealing of the Vault.
If the threshold number of master key shares is reached, Vault
will attempt to unseal the Vault. Otherwise, this API must be
Enter a single master key share to progress the unsealing of the Nomad.
If the threshold number of master key shares is reached, Nomad
will attempt to unseal the Nomad. Otherwise, this API must be
called multiple times until that threshold is met.
</dd>

2
website/source/docs/index.html.markdown
View File

@@ -10,5 +10,5 @@ description: |-
Welcome to the Nomad documentation! This documentation is more of a reference
guide for all available features and options of Nomad. If you're just getting
started with Vault, please start with the
started with Nomad, please start with the
[introduction and getting started guide](/intro/index.html) instead.

28
website/source/docs/install/index.html.md
View File

@@ -1,24 +1,24 @@
---
layout: "docs"
page_title: "Install Vault"
page_title: "Install Nomad"
sidebar_current: "docs-install"
description: |-
Learn how to install Vault.
Learn how to install Nomad.
---
# Install Vault
# Install Nomad
Installing Vault is simple. There are two approaches to installing Vault:
Installing Nomad is simple. There are two approaches to installing Nomad:
downloading a precompiled binary for your system, or installing from source.
Downloading a precompiled binary is easiest, and we provide downloads over
TLS along with SHA256 sums to verify the binary is what we say it is. We
also distribute a PGP signature with the SHA256 sums that can be verified.
However, we use a 3rd party storage host, and some people feel that
due to the importance of security with Vault, they'd rather compile it
due to the importance of security with Nomad, they'd rather compile it
from source.
For this reason, we also document on this page how to compile Vault
For this reason, we also document on this page how to compile Nomad
from source, from the same versions of all dependent libraries that
we used for the official builds.
@@ -26,13 +26,13 @@ we used for the official builds.
To install the precompiled binary,
[download](/downloads.html) the appropriate package for your system.
Vault is currently packaged as a zip file. We don't have any near term
Nomad is currently packaged as a zip file. We don't have any near term
plans to provide system packages.
Once the zip is downloaded, unzip it into any directory. The
`vault` binary inside is all that is necessary to run Vault (or
`vault` binary inside is all that is necessary to run Nomad (or
`vault.exe` for Windows). Any additional files, if any, aren't
required to run Vault.
required to run Nomad.
Copy the binary to anywhere on your system. If you intend to access it
from the command-line, make sure to place it somewhere on your `PATH`.
@@ -42,22 +42,22 @@ from the command-line, make sure to place it somewhere on your `PATH`.
To compile from source, you'll need [Go](https://golang.org) installed
and configured properly. You'll also need Git.
1. Clone the Vault repository into your GOPATH: https://github.com/hashicorp/vault
1. Clone the Nomad repository into your GOPATH: https://github.com/hashicorp/vault
1. Verify that the file `$GOPATH/src/github.com/hashicorp/vault/main.go`
exists. If it doesn't, then you didn't clone Vault into the proper
exists. If it doesn't, then you didn't clone Nomad into the proper
path.
1. Run `make dev`. This will build Vault for your current system
1. Run `make dev`. This will build Nomad for your current system
and put the binary in `bin` (relative to the git checkout).
~> **Note:** All the dependencies of Vault are vendored and the command
~> **Note:** All the dependencies of Nomad are vendored and the command
above will use these vendored binaries. This is to avoid malicious
upstream dependencies if possible.
## Verifying the Installation
To verify Vault is properly installed, execute the `vault` binary on
To verify Nomad is properly installed, execute the `vault` binary on
your system. You should see help output. If you are executing it from
the command line, make sure it is on your PATH or you may get an error
about `vault` not being found.

30
website/source/docs/internals/high-availability.html.md
View File

@@ -3,45 +3,45 @@ layout: "docs"
page_title: "High Availability"
sidebar_current: "docs-internals-ha"
description: |-
Learn about the high availability design of Vault.
Learn about the high availability design of Nomad.
---
# High Availability
Vault is primarily used in production environments to manage secrets.
As a result, any downtime of the Vault service can affect downstream clients.
Vault is designed to support a highly available deploy to ensure a machine
Nomad is primarily used in production environments to manage secrets.
As a result, any downtime of the Nomad service can affect downstream clients.
Nomad is designed to support a highly available deploy to ensure a machine
or process failure is minimally disruptive.
~> **Advanced Topic!** This page covers technical details
of Vault. You don't need to understand these details to
effectively use Vault. The details are documented here for
of Nomad. You don't need to understand these details to
effectively use Nomad. The details are documented here for
those who wish to learn about them without having to go
spelunking through the source code. However, if you're an
operator of Vault, we recommend learning about the architecture
due to the importance of Vault in an environment.
operator of Nomad, we recommend learning about the architecture
due to the importance of Nomad in an environment.
# Design Overview
The primary design goal in making Vault highly availability (HA) was to
minimize downtime and not horizontal scalability. Vault is typically
The primary design goal in making Nomad highly availability (HA) was to
minimize downtime and not horizontal scalability. Nomad is typically
bound by the IO limits of the storage backend rather than the compute
requirements. This simplifies the HA approach and allows more complex
coordination to be avoided.
Certain storage backends, such as Consul, provide additional coordination
functions that enable Vault to run in an HA configuration. When supported
by the backend, Vault will automatically run in HA mode without additional
functions that enable Nomad to run in an HA configuration. When supported
by the backend, Nomad will automatically run in HA mode without additional
configuration.
When running in HA mode, Vault servers have two additional states they
can be in: standby and active. For multiple Vault servers sharing a storage
When running in HA mode, Nomad servers have two additional states they
can be in: standby and active. For multiple Nomad servers sharing a storage
backend, only a single instance will be active at any time while all other
instances are hot standbys.
The active server operates in a standard fashion and processes all requests.
The standby servers do not process requests, and instead redirect to the active
Vault. Meanwhile, if the active server is sealed, fails, or loses network connectivity
Nomad. Meanwhile, if the active server is sealed, fails, or loses network connectivity
then one of the standbys will take over and become the active instance.
It is important to note that only _unsealed_ servers act as a standby.

14
website/source/docs/internals/index.html.md
View File

@@ -3,15 +3,15 @@ layout: "docs"
page_title: "Internals"
sidebar_current: "docs-internals"
description: |-
This section covers the internals of Vault and explains technical details of Vaults operation.
This section covers the internals of Nomad and explains technical details of Nomads operation.
---
# Vault Internals
# Nomad Internals
This section covers the internals of Vault and explains the technical
details of how Vault functions, its architecture and security properties.
This section covers the internals of Nomad and explains the technical
details of how Nomad functions, its architecture and security properties.
-> **Note:** Knowledge of Vault internals is not
required to use Vault. If you aren't interested in the internals
of Vault, you may safely skip this section. If you're operating Vault,
-> **Note:** Knowledge of Nomad internals is not
required to use Nomad. If you aren't interested in the internals
of Nomad, you may safely skip this section. If you're operating Nomad,
we recommend understanding the internals.

16
website/source/docs/internals/rotation.html.md
View File

@@ -3,18 +3,18 @@ layout: "docs"
page_title: "Key Rotation"
sidebar_current: "docs-internals-rotation"
description: |-
Learn about the details of key rotation within Vault.
Learn about the details of key rotation within Nomad.
---
# Key Rotation
Vault has multiple encryption keys that are used for various purposes. These keys support
Nomad has multiple encryption keys that are used for various purposes. These keys support
rotation so that they can be periodically changed or in response to a potential leak or
compromise. It is useful to first understand the
[high-level architecture](/docs/internals/architecture.html) before learning about key rotation.
As a review, Vault starts in a _sealed_ state. Vault is unsealed by providing the unseal keys.
By default, Vault uses a technique known as [Shamir's secret sharing algorithm](http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing)
As a review, Nomad starts in a _sealed_ state. Nomad is unsealed by providing the unseal keys.
By default, Nomad uses a technique known as [Shamir's secret sharing algorithm](http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing)
to split the master key into 5 shares, any 3 of which are required to reconstruct the master
key. The master key is used to protect the encryption key, which is ultimately used to protect
data written to the storage backend.
@@ -32,7 +32,7 @@ performing a rekey and invaliding the existing master key.
Performing a rekey is fairly straightforward. The rekey operation must be initialized with
the new parameters for the split and threshold. Once initialized, the current unseal keys
must be provided until the threshold is met. Once met, Vault will generate the new master
must be provided until the threshold is met. Once met, Nomad will generate the new master
key, perform the splitting, and re-encrypt the encryption key with the new master key.
The new unseal keys are then provided to the operator, and the old unseal keys are no
longer usable.
@@ -47,12 +47,12 @@ be decrypted since older keys are saved in the keyring. This allows key rotation
done online, without an expensive re-encryption process.
Both the `rekey` and `rotate` operations can be done online and in a highly available
configuration. Only the active Vault instance can perform either of the operations
configuration. Only the active Nomad instance can perform either of the operations
but standby instances can still assume an active role after either operation. This is
done by providing an online upgrade path for standby instances. If the current encryption
key is `N` and a rotation installs `N+1`, Vault creates a special "upgrade" key, which
key is `N` and a rotation installs `N+1`, Nomad creates a special "upgrade" key, which
provides the `N+1` encryption key protected by the `N` key. This upgrade key is only available
for a few minutes enabling standby instances do a periodic check for upgrades.
This allows standby instances to update their keys and stay in-sync with the active Vault
This allows standby instances to update their keys and stay in-sync with the active Nomad
without requiring operators to perform another unseal.

76
website/source/docs/internals/security.html.md
View File

@@ -3,13 +3,13 @@ layout: "docs"
page_title: "Security Model"
sidebar_current: "docs-internals-security"
description: |-
Learn about the security model of Vault.
Learn about the security model of Nomad.
---
# Security Model
Due to the nature of Vault and the confidentiality of data it is managing,
the Vault security model is very critical. The overall goal of Vault's security
Due to the nature of Nomad and the confidentiality of data it is managing,
the Nomad security model is very critical. The overall goal of Nomad's security
model is to provide [confidentiality, integrity, availability, accountability,
authentication](http://en.wikipedia.org/wiki/Information_security).
@@ -21,14 +21,14 @@ attempts to bypass any of its access controls.
# Threat Model
The following are the various parts of the Vault threat model:
The following are the various parts of the Nomad threat model:
* Eavesdropping on any Vault communication. Client communication with Vault
should be secure from eavesdropping as well as communication from Vault to
* Eavesdropping on any Nomad communication. Client communication with Nomad
should be secure from eavesdropping as well as communication from Nomad to
its storage backend.
* Tampering with data at rest or in transit. Any tampering should be detectable
and cause Vault to abort processing of the transaction.
and cause Nomad to abort processing of the transaction.
* Access to data or controls without authentication or authorization. All requests
must be proceeded by the applicable security policies.
@@ -37,20 +37,20 @@ The following are the various parts of the Vault threat model:
is enabled, requests and responses must be logged before the client receives
any secret material.
* Confidentiality of stored secrets. Any data that leaves Vault to rest in the
* Confidentiality of stored secrets. Any data that leaves Nomad to rest in the
storage backend must be safe from eavesdropping. In practice, this means all
data at rest must be encrypted.
* Availability of secret material in the face of failure. Vault supports
* Availability of secret material in the face of failure. Nomad supports
running in a highly available configuration to avoid loss of availability.
The following are not parts of the Vault threat model:
The following are not parts of the Nomad threat model:
* Protecting against arbitrary control of the storage backend. An attacker
that can perform arbitrary operations against the storage backend can
undermine security in any number of ways that are difficult or impossible to protect
against. As an example, an attacker could delete or corrupt all the contents
of the storage backend causing total data loss for Vault. The ability to control
of the storage backend causing total data loss for Nomad. The ability to control
reads would allow an attacker to snapshot in a well-known state and rollback state
changes if that would be beneficial to them.
@@ -58,55 +58,55 @@ The following are not parts of the Vault threat model:
that can read from the storage backend may observe that secret material exists
and is stored, even if it is kept confidential.
* Protecting against memory analysis of a running Vault. If an attacker is able
to inspect the memory state of a running Vault instance then the confidentiality
* Protecting against memory analysis of a running Nomad. If an attacker is able
to inspect the memory state of a running Nomad instance then the confidentiality
of data may be compromised.
# External Threat Overview
Given the architecture of Vault, there are 3 distinct systems we are concerned with
for Vault. There is the client, which is speaking to Vault over an API. There is Vault
Given the architecture of Nomad, there are 3 distinct systems we are concerned with
for Nomad. There is the client, which is speaking to Nomad over an API. There is Nomad
or the server more accurately, which is providing an API and serving requests. Lastly,
there is the storage backend, which the server is utilizing to read and write data.
There is no mutual trust between the Vault client and server. Clients use
There is no mutual trust between the Nomad client and server. Clients use
[TLS](http://en.wikipedia.org/wiki/Transport_Layer_Security) to verify the identity
of the server and to establish a secure communication channel. Servers require that
a client provides a client token for every request which is used to identify the client.
A client that does not provide their token is only permitted to make login requests.
The storage backends used by Vault are also untrusted by design. Vault uses a security
The storage backends used by Nomad are also untrusted by design. Nomad uses a security
barrier for all requests made to the backend. The security barrier automatically encrypts
all data leaving Vault using the [Advanced Encryption Standard (AES)](http://en.wikipedia.org/wiki/Advanced_Encryption_Standard)
all data leaving Nomad using the [Advanced Encryption Standard (AES)](http://en.wikipedia.org/wiki/Advanced_Encryption_Standard)
cipher in the [Galois Counter Mode (GCM)](http://en.wikipedia.org/wiki/Galois/Counter_Mode).
The nonce is randomly generated for every encrypted object. When data is read from the
security barrier the GCM authentication tag is verified prior to decryption to detect
any tampering.
Depending on the backend used, Vault may communicate with the backend over TLS
Depending on the backend used, Nomad may communicate with the backend over TLS
to provide an added layer of security. In some cases, such as a file backend this
is not applicable. Because storage backends are untrusted, an eavesdropper would
only gain access to encrypted data even if communication with the backend was intercepted.
# Internal Threat Overview
Within the Vault system, a critical security concern is an attacker attempting
Within the Nomad system, a critical security concern is an attacker attempting
to gain access to secret material they are not authorized to. This is an internal
threat if the attacker is already permitted some level of access to Vault and is
threat if the attacker is already permitted some level of access to Nomad and is
able to authenticate.
When a client first authenticates with Vault, a credential backend is used to
When a client first authenticates with Nomad, a credential backend is used to
verify the identity of the client and to return a list of associated ACL policies.
This association is configured by operators of Vault ahead of time. For example,
This association is configured by operators of Nomad ahead of time. For example,
GitHub users in the "engineering" team may be mapped to the "engineering" and "ops"
Vault policies. Vault then generates a client token which is a randomly generated
Nomad policies. Nomad then generates a client token which is a randomly generated
UUID and maps it to the policy list. This client token is then returned to the client.
On each request a client provides this token. Vault then uses it to check that the token
On each request a client provides this token. Nomad then uses it to check that the token
is valid and has not been revoked or expired, and generates an ACL based on the associated
policies. Vault uses a strict default deny or whitelist enforcement. This means unless
policies. Nomad uses a strict default deny or whitelist enforcement. This means unless
an associated policy allows for a given action, it will be denied. Each policy specifies
a level of access granted to a path in Vault. When the policies are merged (if multiple
a level of access granted to a path in Nomad. When the policies are merged (if multiple
policies are associated with a client), the highest access level permitted is used.
For example, if the "engineering" policy permits read/write access to the "eng/" path,
and the "ops" policy permits read access to the "ops/" path, then the user gets the
@@ -114,35 +114,35 @@ union of those. Policy is matched using the most specific defined policy, which
an exact match or the longest-prefix match glob pattern.
Certain operations are only permitted by "root" users, which is a distinguished
policy built into Vault. This is similar to the concept of a root user on a Unix system
policy built into Nomad. This is similar to the concept of a root user on a Unix system
or an Administrator on Windows. Although clients could be provided with root tokens
or associated with the root policy, instead Vault supports the notion of "sudo" privilege.
or associated with the root policy, instead Nomad supports the notion of "sudo" privilege.
As part of a policy, users may be granted "sudo" privileges to certain paths, so that
they can still perform security sensitive operations without being granted global
root access to Vault.
root access to Nomad.
Lastly, Vault supports using a [Two-man rule](http://en.wikipedia.org/wiki/Two-man_rule) for
Lastly, Nomad supports using a [Two-man rule](http://en.wikipedia.org/wiki/Two-man_rule) for
unsealing using [Shamir's Secret Sharing technique](http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing).
When Vault is started, it starts in an _sealed_ state. This means that the encryption key
When Nomad is started, it starts in an _sealed_ state. This means that the encryption key
needed to read and write from the storage backend is not yet known. The process of unsealing
requires providing the master key so that the encryption key can be retrieved. The risk of distributing
the master key is that a single malicious actor with access to it can decrypt the entire
Vault. Instead, Shamir's technique allows us to split the master key into multiple shares or parts.
The number of shares and the threshold needed is configurable, but by default Vault generates
Nomad. Instead, Shamir's technique allows us to split the master key into multiple shares or parts.
The number of shares and the threshold needed is configurable, but by default Nomad generates
5 shares, any 3 of which must be provided to reconstruct the master key.
By using a secret sharing technique, we avoid the need to place absolute trust in the holder
of the master key, and avoid storing the master key at all. The master key is only
retrievable by reconstructing the shares. The shares are not useful for making any requests
to Vault, and can only be used for unsealing. Once unsealed the standard ACL mechanisms
to Nomad, and can only be used for unsealing. Once unsealed the standard ACL mechanisms
are used for all requests.
To make an analogy, a bank puts security deposit boxes inside of a vault.
Each security deposit box has a key, while the vault door has both a combination and a key.
The vault is encased in steel and concrete so that the door is the only practical entrance.
The analogy to Vault, is that the cryptosystem is the steel and concrete protecting the data.
The analogy to Nomad, is that the cryptosystem is the steel and concrete protecting the data.
While you could tunnel through the concrete or brute force the encryption keys, it would be
prohibitively time consuming. Opening the bank vault requires two-factors: the key and the combination.
Similarly, Vault requires multiple shares be provided to reconstruct the master key.
Similarly, Nomad requires multiple shares be provided to reconstruct the master key.
Once unsealed, each security deposit boxes still requires the owner provide a key, and similarly
the Vault ACL system protects all the secrets stored.
the Nomad ACL system protects all the secrets stored.

10
website/source/docs/internals/telemetry.html.md
View File

@@ -3,21 +3,21 @@ layout: "docs"
page_title: "Telemetry"
sidebar_current: "docs-internals-telemetry"
description: |-
Learn about the telemetry data available in Vault.
Learn about the telemetry data available in Nomad.
---
# Telemetry
The Vault agent collects various runtime metrics about the performance of
The Nomad agent collects various runtime metrics about the performance of
different libraries and subsystems. These metrics are aggregated on a ten
second interval and are retained for one minute.
To view this data, you must send a signal to the Vault process: on Unix,
this is `USR1` while on Windows it is `BREAK`. Once Vault receives the signal,
To view this data, you must send a signal to the Nomad process: on Unix,
this is `USR1` while on Windows it is `BREAK`. Once Nomad receives the signal,
it will dump the current telemetry information to the agent's `stderr`.
This telemetry information can be used for debugging or otherwise
getting a better view of what Vault is doing.
getting a better view of what Nomad is doing.
Telemetry information can be streamed to both [statsite](http://github.com/armon/statsite)
as well as statsd based on providing the appropriate configuration options.

8
website/source/docs/internals/token.html.md
View File

@@ -3,7 +3,7 @@ layout: "docs"
page_title: "Token Authentication"
sidebar_current: "docs-internals-token"
description: |-
Learn about the client token authentication in Vault.
Learn about the client token authentication in Nomad.
---
# Token Authentication
@@ -25,7 +25,7 @@ Every token has a number of properties:
The properties of a token are immutable once created. The exception to this
is the number of uses, which is decremented on each request. Each of these
properties enable Vault to do a number of interesting things.
properties enable Nomad to do a number of interesting things.
Each token maintains the source path, or the login path, that was used
to create the token. This is used to allow source based revocation. For example,
@@ -39,7 +39,7 @@ procedure during a potential compromise.
If a token is created by another authentication backend, they do not have
a parent token. However, any tokens created by the `auth/token/create` API
have a parent token, namely the token used to make that request. By maintaining
this parent-child relationship, Vault models token trees. Child tokens can
this parent-child relationship, Nomad models token trees. Child tokens can
be created with a subset of the parent policies, allowing for dropping of
privileges. When a token is revoked, the entire sub-tree of tokens is revoked
with it. This allows clients to safely generate child tokens and then revoke
@@ -50,4 +50,4 @@ When a token is created, its use count can be optionally specified. Providing
a use count of one makes a _one time token_. This means the token can be used
for a single request before being automatically revoked. This can be generalized
to any number of uses. Limited use tokens cannot be used to create sub-tokens,
but they can be a powerful way to allow extremely limited access to Vault.
but they can be a powerful way to allow extremely limited access to Nomad.

8
website/source/docs/secrets/aws/index.html.md
View File

@@ -3,16 +3,16 @@ layout: "docs"
page_title: "Secret Backend: AWS"
sidebar_current: "docs-secrets-aws"
description: |-
The AWS secret backend for Vault generates access keys dynamically based on IAM policies.
The AWS secret backend for Nomad generates access keys dynamically based on IAM policies.
---
# AWS Secret Backend
Name: `aws`
The AWS secret backend for Vault generates AWS access credentials dynamically
The AWS secret backend for Nomad generates AWS access credentials dynamically
based on IAM policies. This makes IAM much easier to use: credentials could
be generated on the fly, and are automatically revoked when the Vault
be generated on the fly, and are automatically revoked when the Nomad
lease is expired.
This page will show a quick start for this backend. For detailed documentation
@@ -59,7 +59,7 @@ This path will create a named role along with the IAM policy used
to restrict permissions for it. This is used to dynamically create
a new pair of IAM credentials when needed.
The `@` tells Vault to load the policy from the file named `policy.json`. Here
The `@` tells Nomad to load the policy from the file named `policy.json`. Here
is an example IAM policy to get started:
```javascript

18
website/source/docs/secrets/cassandra/index.html.md
View File

@@ -3,17 +3,17 @@ layout: "docs"
page_title: "Secret Backend: Cassandra"
sidebar_current: "docs-secrets-cassandra"
description: |-
The Cassandra secret backend for Vault generates database credentials to access Cassandra.
The Cassandra secret backend for Nomad generates database credentials to access Cassandra.
---
# Cassandra Secret Backend
Name: `cassandra`
The Cassandra secret backend for Vault generates database credentials
The Cassandra secret backend for Nomad generates database credentials
dynamically based on configured roles. This means that services that need
to access a database no longer need to hardcode credentials: they can request
them from Vault, and use Vault's leasing mechanism to more easily roll keys.
them from Nomad, and use Nomad's leasing mechanism to more easily roll keys.
Additionally, it introduces a new ability: with every service accessing
the database with unique credentials, it makes auditing much easier when
@@ -33,7 +33,7 @@ $ vault mount cassandra
Successfully mounted 'cassandra' at 'cassandra'!
```
Next, Vault must be configured to connect to Cassandra. This is done by
Next, Nomad must be configured to connect to Cassandra. This is done by
writing one or more hosts, a username, and a password:
```text
@@ -41,8 +41,8 @@ $ vault write cassandra/config/connection \
hosts=localhost username=cassandra password=cassandra
```
In this case, we've configured Vault with the user "cassandra" and password "cassandra",
It is important that the Vault user is a superuser, in order to manage other user accounts.
In this case, we've configured Nomad with the user "cassandra" and password "cassandra",
It is important that the Nomad user is a superuser, in order to manage other user accounts.
The next step is to configure a role. A role is a logical name that maps
to a policy used to generated those credentials. For example, lets create
@@ -58,14 +58,14 @@ Success! Data written to: cassandra/roles/readonly
By writing to the `roles/readonly` path we are defining the `readonly` role.
This role will be created by evaluating the given `creation_cql` statements. By
default, the `{{username}}` and `{{password}}` fields will be populated by
Vault with dynamically generated values. This CQL statement is creating
Nomad with dynamically generated values. This CQL statement is creating
the named user, and then granting it `SELECT` or read-only privileges
to keyspaces. More complex `GRANT` queries can be used to
customize the privileges of the role. See the [CQL Reference Manual](http://docs.datastax.com/en/cql/3.1/cql/cql_reference/grant_r.html)
for more information.
To generate a new set of credentials, we simply read from that role:
Vault is now configured to create and manage credentials for Cassandra!
Nomad is now configured to create and manage credentials for Cassandra!
```text
$ vault read cassandra/creds/readonly
@@ -77,7 +77,7 @@ password dfa80eea-ccbe-b228-ebf7-e2f62b245e71
username vault-root-1434647667-9313
```
By reading from the `creds/readonly` path, Vault has generated a new
By reading from the `creds/readonly` path, Nomad has generated a new
set of credentials using the `readonly` role configuration. Here we
see the dynamically generated username and password, along with a one
hour lease.

12
website/source/docs/secrets/consul/index.html.md
View File

@@ -3,14 +3,14 @@ layout: "docs"
page_title: "Secret Backend: Consul"
sidebar_current: "docs-secrets-consul"
description: |-
The Consul secret backend for Vault generates tokens for Consul dynamically.
The Consul secret backend for Nomad generates tokens for Consul dynamically.
---
# Consul Secret Backend
Name: `consul`
The Consul secret backend for Vault generates
The Consul secret backend for Nomad generates
[Consul](http://consul.io)
API tokens dynamically based on Consul ACL policies.
@@ -27,7 +27,7 @@ $ vault mount consul
Successfully mounted 'consul' at 'consul'!
```
Next, we must configure Vault to know how to contact Consul.
Next, we must configure Nomad to know how to contact Consul.
This is done by writing the access information:
```
@@ -35,9 +35,9 @@ $ vault write consul/config/access address=127.0.0.1:8500 token=root
Success! Data written to: consul/config/access
```
In this case, we've configured Vault to connect to Consul
In this case, we've configured Nomad to connect to Consul
on the default port with the loopback address. We've also provided
an ACL token to use with the `token` parameter. Vault must have a management
an ACL token to use with the `token` parameter. Nomad must have a management
type token so that it can create and revoke ACL tokens.
The next step is to configure a role. A role is a logical name that maps
@@ -64,7 +64,7 @@ lease_duration 3600
token 973a31ea-1ec4-c2de-0f63-623f477c2510
```
Here we can see that Vault has generated a new Consul ACL token for us.
Here we can see that Nomad has generated a new Consul ACL token for us.
We can test this token out, and verify that it is read-only:
```

6
website/source/docs/secrets/custom.html.md
View File

@@ -3,13 +3,13 @@ layout: "docs"
page_title: "Secret Backend: Custom"
sidebar_current: "docs-secrets-custom"
description: |-
Create custom secret backends for Vault.
Create custom secret backends for Nomad.
---
# Custom Secret Backends
Vault doesn't currently support the creation of custom secret backends.
The primary reason is because we want to ensure the core of Vault is
Nomad doesn't currently support the creation of custom secret backends.
The primary reason is because we want to ensure the core of Nomad is
secure before attempting any sort of plug-in system. We're interested
in supporting custom secret backends, but don't yet have a clear strategy
or timeline to do.

4
website/source/docs/secrets/generic/index.html.md
View File

@@ -11,9 +11,9 @@ description: |-
Name: `generic`
The generic secret backend is used to store arbitrary secrets within
the configured physical storage for Vault. If you followed along with
the configured physical storage for Nomad. If you followed along with
the getting started guide, you interacted with a generic secret backend
via the `secret/` prefix that Vault mounts by default.
via the `secret/` prefix that Nomad mounts by default.
Writing to a key in the `secret/` backend will replace the old value,
the sub-fields are not merged together.

14
website/source/docs/secrets/index.html.md
View File

@@ -3,12 +3,12 @@ layout: "docs"
page_title: "Secret Backends"
sidebar_current: "docs-secrets"
description: |-
Secret backends are mountable backends that store or generate secrets in Vault.
Secret backends are mountable backends that store or generate secrets in Nomad.
---
# Secret Backends
Secret backends are the components in Vault which store and generate
Secret backends are the components in Nomad which store and generate
secrets.
Some secret backends, such as "generic", simply store and read
@@ -17,12 +17,12 @@ secrets_: secrets that are made on demand.
Secret backends are part of the
[mount system](#)
in Vault. They behave very similarly to a virtual filesystem:
in Nomad. They behave very similarly to a virtual filesystem:
any read/write/delete is sent to the secret backend, and the secret
backend can choose to react to that operation however it sees fit.
For example, the "generic" backend passes through any operation back
to the configured storage backend for Vault. A "read" turns into a
to the configured storage backend for Nomad. A "read" turns into a
"read" of the storage backend at the same path, a "write" turns into
a write, etc. This is a lot like a normal filesystem.
@@ -62,14 +62,14 @@ system to determine the paths it responds to.
## Barrier View
An important concept around secret backends is that they receive a
_barrier view_ to the configured Vault physical storage. This is a lot
_barrier view_ to the configured Nomad physical storage. This is a lot
like a [chroot](http://en.wikipedia.org/wiki/Chroot).
Whenever a secret backend is mounted, a random UUID is generated. This
becomes the data root for that backend. Whenever that backend writes to
the physical storage layer, it is prefixed with that UUID folder. Since
the Vault storage layer doesn't support relative access (such as `..`),
the Nomad storage layer doesn't support relative access (such as `..`),
this makes it impossible for a mounted backend to access any other data.
This is an important security feature in Vault: even a malicious backend
This is an important security feature in Nomad: even a malicious backend
can't access the data from any other backend.

6
website/source/docs/secrets/jwt/index.html.md
View File

@@ -2,7 +2,7 @@
Name: `jwt`
The JWT secret backend for Vault generates JSON Web Tokens dynamically based on configured roles. This means services can get tokens needed for authentication without going through the usual manual process of generating a private key and signing the token and maintaining the private key's security. Vault's built-in authentication and authorization mechanisms provide the verification functionality.
The JWT secret backend for Nomad generates JSON Web Tokens dynamically based on configured roles. This means services can get tokens needed for authentication without going through the usual manual process of generating a private key and signing the token and maintaining the private key's security. Nomad's built-in authentication and authorization mechanisms provide the verification functionality.
This page will show a quick start for this backend. For detailed documentation on every path, use `vault path-help` after mounting the backend.
@@ -62,8 +62,8 @@ Generating a token requires passing of additional information so we use the
```text
$ vault write jwt/issue/webauth \
issuer="Vault" \
audience="Vault Client" \
issuer="Nomad" \
audience="Nomad Client" \
expiration="1538096292" \
claims=@extra.json
```

20
website/source/docs/secrets/mysql/index.html.md
View File

@@ -3,24 +3,24 @@ layout: "docs"
page_title: "Secret Backend: MySQL"
sidebar_current: "docs-secrets-mysql"
description: |-
The MySQL secret backend for Vault generates database credentials to access MySQL.
The MySQL secret backend for Nomad generates database credentials to access MySQL.
---
# MySQL Secret Backend
Name: `mysql`
The MySQL secret backend for Vault generates database credentials
The MySQL secret backend for Nomad generates database credentials
dynamically based on configured roles. This means that services that need
to access a database no longer need to hardcode credentials: they can request
them from Vault, and use Vault's leasing mechanism to more easily roll keys.
them from Nomad, and use Nomad's leasing mechanism to more easily roll keys.
Additionally, it introduces a new ability: with every service accessing
the database with unique credentials, it makes auditing much easier when
questionable data access is discovered: you can track it down to the specific
instance of a service based on the SQL username.
Vault makes use of its own internal revocation system to ensure that users
Nomad makes use of its own internal revocation system to ensure that users
become invalid within a reasonable time of the lease expiring.
This page will show a quick start for this backend. For detailed documentation
@@ -36,7 +36,7 @@ $ vault mount mysql
Successfully mounted 'mysql' at 'mysql'!
```
Next, we must configure Vault to know how to connect to the MySQL
Next, we must configure Nomad to know how to connect to the MySQL
instance. This is done by providing a DSN (Data Source Name):
```
@@ -44,13 +44,13 @@ $ vault write mysql/config/connection value="root:root@tcp(192.168.33.10:3306)/"
Success! Data written to: mysql/config/connection
```
In this case, we've configured Vault with the user "root" and password "root,
In this case, we've configured Nomad with the user "root" and password "root,
connecting to an instance at "192.168.33.10" on port 3306. It is not necessary
that Vault has the root user, but the user must have privileges to create
that Nomad has the root user, but the user must have privileges to create
other users, namely the `GRANT OPTION` privilege.
Optionally, we can configure the lease settings for credentials generated
by Vault. This is done by writing to the `config/lease` key:
by Nomad. This is done by writing to the `config/lease` key:
```
$ vault write mysql/config/lease lease=1h lease_max=24h
@@ -74,7 +74,7 @@ Success! Data written to: mysql/roles/readonly
By writing to the `roles/readonly` path we are defining the `readonly` role.
This role will be created by evaluating the given `sql` statements. By
default, the `{{name}}` and `{{password}}` fields will be populated by
Vault with dynamically generated values. This SQL statement is creating
Nomad with dynamically generated values. This SQL statement is creating
the named user, and then granting it `SELECT` or read-only privileges
to tables in the database. More complex `GRANT` queries can be used to
customize the privileges of the role. See the [MySQL manual](https://dev.mysql.com/doc/refman/5.7/en/grant.html)
@@ -91,7 +91,7 @@ password 132ae3ef-5a64-7499-351e-bfe59f3a2a21
username root-aefa635a-18
```
By reading from the `creds/readonly` path, Vault has generated a new
By reading from the `creds/readonly` path, Nomad has generated a new
set of credentials using the `readonly` role configuration. Here we
see the dynamically generated username and password, along with a one
hour lease.

32
website/source/docs/secrets/pki/index.html.md
View File

@@ -3,14 +3,14 @@ layout: "docs"
page_title: "Secret Backend: PKI"
sidebar_current: "docs-secrets-pki"
description: |-
The PKI secret backend for Vault generates TLS certificates.
The PKI secret backend for Nomad generates TLS certificates.
---
# PKI Secret Backend
Name: `pki`
The PKI secret backend for Vault generates X.509 certificates dynamically based on configured roles. This means services can get certificates needed for both client and server authentication without going through the usual manual process of generating a private key and CSR, submitting to a CA, and waiting for a verification and signing process to complete. Vault's built-in authentication and authorization mechanisms provide the verification functionality.
The PKI secret backend for Nomad generates X.509 certificates dynamically based on configured roles. This means services can get certificates needed for both client and server authentication without going through the usual manual process of generating a private key and CSR, submitting to a CA, and waiting for a verification and signing process to complete. Nomad's built-in authentication and authorization mechanisms provide the verification functionality.
By keeping leases relatively short, revocations are less likely to be needed, keeping CRLs short and helping the backend scale to large workloads. This in turn allows each instance of a running application to have a unique certificate, eliminating sharing and the accompanying pain of revocation and rollover.
@@ -24,7 +24,7 @@ To successfully deploy this backend, there are a number of important considerati
### Never use root CAs
Vault storage is secure, but not as secure as a piece of paper in a bank vault. It is, after all, networked software. Your long-lived self-signed root CA's private key should instead be used to issue a shorter-lived intermediate CA certificate, and this is what you should put into Vault. This aligns with industry best practices.
Nomad storage is secure, but not as secure as a piece of paper in a bank vault. It is, after all, networked software. Your long-lived self-signed root CA's private key should instead be used to issue a shorter-lived intermediate CA certificate, and this is what you should put into Nomad. This aligns with industry best practices.
### One CA Certificate, One Backend
@@ -34,13 +34,13 @@ This also provides a convenient method of switching to a new CA certificate whil
### Keep certificate lifetimes short, for CRL's sake
This backend aligns with Vault's philosophy of short-lived secrets. As such it is not expected that CRLs will grow large; the only place a private key is ever returned is to the requesting client (this backend does *not* store generated private keys). In most cases, if the key is lost, the certificate can simply be ignored, as it will expire shortly.
This backend aligns with Nomad's philosophy of short-lived secrets. As such it is not expected that CRLs will grow large; the only place a private key is ever returned is to the requesting client (this backend does *not* store generated private keys). In most cases, if the key is lost, the certificate can simply be ignored, as it will expire shortly.
If a certificate must truly be revoked, the normal Vault revocation function can be used; alternately a root token can be used to revoke the certificate using the certificate's serial number. Any revocation action will cause the CRL to be regenerated. When the CRL is regenerated, any expired certificates are removed from the CRL (and any revoked, expired certificate are removed from backend storage).
If a certificate must truly be revoked, the normal Nomad revocation function can be used; alternately a root token can be used to revoke the certificate using the certificate's serial number. Any revocation action will cause the CRL to be regenerated. When the CRL is regenerated, any expired certificates are removed from the CRL (and any revoked, expired certificate are removed from backend storage).
This backend does not support multiple CRL endpoints with sliding date windows; often such mechanisms will have the transition point a few days apart, but this gets into the expected realm of the actual certificate validity periods issued from this backend. A good rule of thumb for this backend would be to simply not issue certificates with a validity period greater than your maximum comfortable CRL lifetime. Alternately, you can control CRL caching behavior on the client to ensure that checks happen more often.
Often multiple endpoints are used in case a single CRL endpoint is down so that clients don't have to figure out what to do with a lack of response. Run Vault in HA mode, and the CRL endpoint should be available even if a particular node is down.
Often multiple endpoints are used in case a single CRL endpoint is down so that clients don't have to figure out what to do with a lack of response. Run Nomad in HA mode, and the CRL endpoint should be available even if a particular node is down.
### You must configure CRL information *in advance*
@@ -48,7 +48,7 @@ This backend serves CRLs from a predictable location. That location must be enco
### No OCSP support, yet
Vault's architecture does not currently allow for a binary protocol such as OCSP to be supported by a backend. As such, you should configure your software to use CRLs for revocation information, with a caching lifetime that feels good to you. Since you are following the advice above about keeping lifetimes short (right?), CRLs should not grow too large.
Nomad's architecture does not currently allow for a binary protocol such as OCSP to be supported by a backend. As such, you should configure your software to use CRLs for revocation information, with a caching lifetime that feels good to you. Since you are following the advice above about keeping lifetimes short (right?), CRLs should not grow too large.
## Quick Start
@@ -62,7 +62,7 @@ crlDistributionPoints = URI:https://vault.example.com:8200/v1/pki/crl
Adjust the URI as appropriate.
### Vault
### Nomad
The first step to using the PKI backend is to mount it. Unlike the `generic` backend, the `pki` backend is not mounted by default.
@@ -71,7 +71,7 @@ $ vault mount pki
Successfully mounted 'pki' at 'pki'!
```
Next, Vault must be configured with a root certificate and associated private key. This is done by writing the contents of a file or *stdin*:
Next, Nomad must be configured with a root certificate and associated private key. This is done by writing the contents of a file or *stdin*:
```text
$ vault write pki/config/ca pem_bundle="@ca_bundle.pem"
@@ -85,7 +85,7 @@ $ cat bundle.pem | vault write pki/config/ca pem_bundle="-"
Success! Data written to: pki/config/ca
```
Although in this example the value being piped into *stdin* could be passed directly into the Vault CLI command, a more complex usage might be to use [Ansible](http://www.ansible.com) to securely store the certificate and private key in an `ansible-vault` file, then have an `ansible-playbook` command decrypt this value and pass it in to Vault.
Although in this example the value being piped into *stdin* could be passed directly into the Nomad CLI command, a more complex usage might be to use [Ansible](http://www.ansible.com) to securely store the certificate and private key in an `ansible-vault` file, then have an `ansible-playbook` command decrypt this value and pass it in to Nomad.
The next step is to configure a role. A role is a logical name that maps to a policy used to generated those credentials. For example, let's create an "example-dot-com" role:
@@ -96,7 +96,7 @@ $ vault write pki/roles/example-dot-com \
Success! Data written to: pki/roles/example-dot-com
```
By writing to the `roles/example-dot-com` path we are defining the `example-dot-com` role. To generate a new set of credentials, we simply write to the `issue` endpoint with that role name: Vault is now configured to create and manage certificates!
By writing to the `roles/example-dot-com` path we are defining the `example-dot-com` role. To generate a new set of credentials, we simply write to the `issue` endpoint with that role name: Nomad is now configured to create and manage certificates!
```text
$ vault write pki/issue/example-dot-com common_name=blah.example.com
@@ -123,7 +123,7 @@ serial 5e:62:eb:2e:44:dd:04:83:8e:21:88:36:fc:15:ce:ed:da:1c:29:f5
Note that this is a write, not a read, to allow values to be passed in at request time.
Vault has now generated a new set of credentials using the `example-dot-com` role configuration. Here we see the dynamically generated private key and certificate. The issuing CA certificate is returned as well.
Nomad has now generated a new set of credentials using the `example-dot-com` role configuration. Here we see the dynamically generated private key and certificate. The issuing CA certificate is returned as well.
Using ACLs, it is possible to restrict using the pki backend such that trusted operators can manage the role definitions, and both users and applications are restricted in the credentials they are allowed to read.
@@ -139,7 +139,7 @@ If you get stuck at any time, simply run `vault path-help pki` or with a subpath
<dd>
Retrieves the CA certificate *in raw DER-encoded form*.
This is a bare endpoint that does not return a
standard Vault data structure. If `/pem` is added to the
standard Nomad data structure. If `/pem` is added to the
endpoint, the CA certificate is returned in PEM format.
<br /><br />This is an unauthenticated endpoint.
</dd>
@@ -218,7 +218,7 @@ If you get stuck at any time, simply run `vault path-help pki` or with a subpath
command similar to the following:<br/>
```text
curl -X POST --data "@cabundle.json" http://127.0.0.1:8200/v1/pki/config/ca -H X-Vault-Token:06b9d...
curl -X POST --data "@cabundle.json" http://127.0.0.1:8200/v1/pki/config/ca -H X-Nomad-Token:06b9d...
```
Note that if you provide the data through the HTTP API it must be
@@ -261,7 +261,7 @@ If you get stuck at any time, simply run `vault path-help pki` or with a subpath
Retrieves the current CRL *in raw DER-encoded form*. This endpoint
is suitable for usage in the CRL Distribution Points extension in a
CA certificate. This is a bare endpoint that does not return a
standard Vault data structure. If `/pem` is added to the endpoint,
standard Nomad data structure. If `/pem` is added to the endpoint,
the CRL is returned in PEM format.
<br /><br />This is an unauthenticated endpoint.
</dd>
@@ -408,7 +408,7 @@ If you get stuck at any time, simply run `vault path-help pki` or with a subpath
<dd>
Revokes a certificate using its serial number. This is an
alternative option to the standard method of revoking
using Vault lease IDs. A successful revocation will
using Nomad lease IDs. A successful revocation will
rotate the CRL.
<br /><br />This is a root-protected endpoint.
</dd>

22
website/source/docs/secrets/postgresql/index.html.md
View File

@@ -3,24 +3,24 @@ layout: "docs"
page_title: "Secret Backend: PostgreSQL"
sidebar_current: "docs-secrets-postgresql"
description: |-
The PostgreSQL secret backend for Vault generates database credentials to access PostgreSQL.
The PostgreSQL secret backend for Nomad generates database credentials to access PostgreSQL.
---
# PostgreSQL Secret Backend
Name: `postgresql`
The PostgreSQL secret backend for Vault generates database credentials
The PostgreSQL secret backend for Nomad generates database credentials
dynamically based on configured roles. This means that services that need
to access a database no longer need to hardcode credentials: they can request
them from Vault, and use Vault's leasing mechanism to more easily roll keys.
them from Nomad, and use Nomad's leasing mechanism to more easily roll keys.
Additionally, it introduces a new ability: with every service accessing
the database with unique credentials, it makes auditing much easier when
questionable data access is discovered: you can track it down to the specific
instance of a service based on the SQL username.
Vault makes use both of its own internal revocation system as well as the
Nomad makes use both of its own internal revocation system as well as the
`VALID UNTIL` setting when creating PostgreSQL users to ensure that users
become invalid within a reasonable time of the lease expiring.
@@ -37,7 +37,7 @@ $ vault mount postgresql
Successfully mounted 'postgresql' at 'postgresql'!
```
Next, Vault must be configured to connect to the PostgreSQL. This is done by
Next, Nomad must be configured to connect to the PostgreSQL. This is done by
writing either a PostgreSQL URL or PG connection string:
```text
@@ -45,12 +45,12 @@ $ vault write postgresql/config/connection \
value="postgresql://root:vaulttest@vaulttest.ciuvljjni7uo.us-west-1.rds.amazonaws.com:5432/postgres"
```
In this case, we've configured Vault with the user "root" and password "vaulttest",
In this case, we've configured Nomad with the user "root" and password "vaulttest",
connecting to a PostgreSQL instance in AWS RDS. The "postgres" database name is being used.
It is important that the Vault user have the `GRANT OPTION` privilege to manage users.
It is important that the Nomad user have the `GRANT OPTION` privilege to manage users.
Optionally, we can configure the lease settings for credentials generated
by Vault. This is done by writing to the `config/lease` key:
by Nomad. This is done by writing to the `config/lease` key:
```
$ vault write postgresql/config/lease lease=1h lease_max=24h
@@ -76,14 +76,14 @@ Success! Data written to: postgresql/roles/readonly
By writing to the `roles/readonly` path we are defining the `readonly` role.
This role will be created by evaluating the given `sql` statements. By
default, the `{{name}}`, `{{password}}` and `{{expiration}}` fields will be populated by
Vault with dynamically generated values. This SQL statement is creating
Nomad with dynamically generated values. This SQL statement is creating
the named user, and then granting it `SELECT` or read-only privileges
to tables in the database. More complex `GRANT` queries can be used to
customize the privileges of the role. See the [PostgreSQL manual](http://www.postgresql.org/docs/9.4/static/sql-grant.html)
for more information.
To generate a new set of credentials, we simply read from that role:
Vault is now configured to create and manage credentials for Postgres!
Nomad is now configured to create and manage credentials for Postgres!
```text
$ vault read postgresql/creds/readonly
@@ -94,7 +94,7 @@ password 34205e88-0de1-68b7-6267-72d8e32c5d3d
username vault-root-1430162075-7887
```
By reading from the `creds/readonly` path, Vault has generated a new
By reading from the `creds/readonly` path, Nomad has generated a new
set of credentials using the `readonly` role configuration. Here we
see the dynamically generated username and password, along with a one
hour lease.

42
website/source/docs/secrets/ssh/index.html.md
View File

@@ -3,14 +3,14 @@ layout: "docs"
page_title: "Secret Backend: SSH"
sidebar_current: "docs-secrets-ssh"
description: |-
The SSH secret backend for Vault generates dynamic SSH keys or One-Time-Passwords.
The SSH secret backend for Nomad generates dynamic SSH keys or One-Time-Passwords.
---
# SSH Secret Backend
Name: `ssh`
Vault SSH backend generates SSH credentials for remote hosts dynamically. This
Nomad SSH backend generates SSH credentials for remote hosts dynamically. This
backend increases the security by removing the need to share the private key to
everyone who needs access to infrastructures. It also solves the problem of
management and distribution of keys belonging to remote hosts.
@@ -27,14 +27,14 @@ on every path, use `vault path-help` after mounting the backend.
----------------------------------------------------
## I. Dynamic Type
Register the shared secret key (having super user privileges) with Vault and let
Vault take care of issuing a dynamic secret key every time a client wants to SSH
Register the shared secret key (having super user privileges) with Nomad and let
Nomad take care of issuing a dynamic secret key every time a client wants to SSH
into the remote host.
When a Vault authenticated client requests for a dynamic credential, Vault server
When a Nomad authenticated client requests for a dynamic credential, Nomad server
creates a key-pair, uses the previously shared secret key to login to the remote
host and appends the newly generated public key to `~/.ssh/authorized_keys` file for
the desired username. Vault uses an install script (configurable) to achieve this.
the desired username. Nomad uses an install script (configurable) to achieve this.
To run this script in super user mode without password prompts, `NOPASSWD` option
for sudoers should be enabled at all remote hosts.
@@ -45,8 +45,8 @@ File: `/etc/sudoers`
```
The private key returned to the user will be leased and can be renewed if desired.
Once the key is given to the user, Vault will not know when it gets used or how many
time it gets used. Therefore, Vault **WILL NOT** and cannot audit the SSH session
Once the key is given to the user, Nomad will not know when it gets used or how many
time it gets used. Therefore, Nomad **WILL NOT** and cannot audit the SSH session
establishments. An alternative is to use OTP type, which audits every SSH request
(see below).
@@ -60,7 +60,7 @@ $ vault mount ssh
Successfully mounted 'ssh' at 'ssh'!
```
Next, we must register infrastructures with Vault. This is done by writing the role
Next, we must register infrastructures with Nomad. This is done by writing the role
information. The type of credentials created are determined by the `key_type` option.
To do this, first create a named key and then create a role.
@@ -95,7 +95,7 @@ are explained in the comments.
# $1: "install" or "uninstall"
#
# $2: File name containing public key to be installed. Vault server uses UUID
# $2: File name containing public key to be installed. Nomad server uses UUID
# as file name to avoid collisions with public keys generated for requests.
#
# $3: Absolute path of the authorized_keys file.
@@ -175,7 +175,7 @@ username@ip:~$
### Automate it!
Creation of new key, saving it in a file and establishing an SSH session will all be done
via a single Vault CLI.
via a single Nomad CLI.
```shell
$ vault ssh -role dynamic_key_role username@ip
@@ -184,18 +184,18 @@ username@ip:~$
----------------------------------------------------
## II. One-Time-Password (OTP) Type
Install Vault SSH Agent in remote hosts and let Vault server issue an OTP every time
Install Nomad SSH Agent in remote hosts and let Nomad server issue an OTP every time
a client wants to SSH into remote hosts.
Vault authenticated clients request for a credential from Vault server and get an OTP
Nomad authenticated clients request for a credential from Nomad server and get an OTP
issued. When clients try to establish SSH connection with the remote host, OTP typed
in at the password prompt will be received by the Vault agent and gets validated
by the Vault server. Vault server deletes the OTP after validating it once (hence one-time).
in at the password prompt will be received by the Nomad agent and gets validated
by the Nomad server. Nomad server deletes the OTP after validating it once (hence one-time).
Since Vault server is contacted for every successful connection establishment, unlike
Since Nomad server is contacted for every successful connection establishment, unlike
Dynamic type, every login attempt **WILL** be audited.
See [Vault-SSH-Agent](https://github.com/hashicorp/vault-ssh-agent) for details
See [Nomad-SSH-Agent](https://github.com/hashicorp/vault-ssh-agent) for details
on how to configure the agent.
### Mounting SSH
@@ -212,7 +212,7 @@ Successfully mounted 'ssh' at 'ssh'!
Create a role, say `otp_key_role` for key type `otp`. All the machines represented
by CIDR block should have agent installed in them and have their SSH configuration
modified to support Vault SSH Agent client authentication.
modified to support Nomad SSH Agent client authentication.
```shell
$ vault write ssh/roles/otp_key_role key_type=otp default_user=username cidr_list=x.x.x.x/y,m.m.m.m/n
@@ -411,7 +411,7 @@ username@ip:~$
<span class="param">key</span>
<span class="param-flags">required for Dynamic type, NA for OTP type</span>
(String)
Name of the registered key in Vault. Before creating the role, use
Name of the registered key in Nomad. Before creating the role, use
the `keys/` endpoint to create a named key.
</li>
<li>
@@ -420,7 +420,7 @@ username@ip:~$
(String)
Admin user at remote host. The shared key being registered should be
for this user and should have root privileges. Everytime a dynamic
credential is being generated for other users, Vault uses this admin
credential is being generated for other users, Nomad uses this admin
username to login to remote host and install the generated credential
for the other user.
</li>
@@ -446,7 +446,7 @@ username@ip:~$
Port number for SSH connection. Default is '22'. Port number does not
play any role in creation of OTP. For 'otp' type, this is just a way
to inform client about the port number to use. Port number will be
returned to client by Vault server along with OTP.
returned to client by Nomad server along with OTP.
</li>
<li>
<span class="param">key_type</span>

12
website/source/docs/secrets/transit/index.html.md
View File

@@ -3,25 +3,25 @@ layout: "docs"
page_title: "Secret Backend: Transit"
sidebar_current: "docs-secrets-transit"
description: |-
The transit secret backend for Vault encrypts/decrypts data in-transit. It doesn't store any secrets.
The transit secret backend for Nomad encrypts/decrypts data in-transit. It doesn't store any secrets.
---
# Transit Secret Backend
Name: `transit`
The transit secret backend is used to encrypt/data in-transit. Vault doesn't
The transit secret backend is used to encrypt/data in-transit. Nomad doesn't
store the data sent to the backend. It can also be viewed as "encryption as
a service."
The primary use case for the transit backend is to encrypt data from
applications while still storing that encrypted data in some primary data
store. This relieves the burden of proper encryption/decryption from
application developers and pushes the burden onto the operators of Vault.
Operators of Vault generally include the security team at an organization,
application developers and pushes the burden onto the operators of Nomad.
Operators of Nomad generally include the security team at an organization,
which means they can ensure that data is encrypted/decrypted properly.
As of Vault 0.2, the transit backend also supports doing key derivation. This
As of Nomad 0.2, the transit backend also supports doing key derivation. This
allows data to be encrypted within a context such that the same context must be
used for decryption. This can be used to enable per transaction unique keys which
further increase the security of data at rest.
@@ -87,7 +87,7 @@ ciphertext vault:v0:czEwyKqGZY/limnuzDCUUe5AK0tbBObWqeZgFqxCuIqq7A84SeiOq3sKD0Y/
```
The encryption endpoint expects the plaintext to be provided as a base64 encoded
strings, so we must first convert it. Vault does not store the plaintext or the
strings, so we must first convert it. Nomad does not store the plaintext or the
ciphertext, but only handles it _in transit_ for processing. The application
is free to store the ciphertext in a database or file at rest.