Commit d9aed3af authored by Seth Vargo's avatar Seth Vargo
Browse files

Update website to remove a lot of copy-paste with Vault + improve images

parent 6a3623eb
Showing with 26 additions and 747 deletions
+26 -747
website/source/assets/images/eval-flow.png

41 KB

website/source/assets/images/global-arch.png

30.9 KB

website/source/assets/images/nomad-architecture-global.png

52 KB

website/source/assets/images/nomad-architecture-region.png

31.2 KB

website/source/assets/images/nomad-data-model.png

22.1 KB

website/source/assets/images/nomad-evaluation-flow.png

63.2 KB

website/source/assets/images/nomad-nouns.png

31.9 KB

website/source/assets/images/region-arch.png

52.9 KB

......@@ -34,54 +34,22 @@ the faces below, Nomad is a project by
employees actively contribute to Nomad.
</p>
<div class="people">
<div class="person">
<img class="pull-left" src="http://www.gravatar.com/avatar/54079122b67de9677c1f93933ce8b63a.png?s=125">
<div class="bio">
<h3>Mitchell Hashimoto (<a href="https://github.com/mitchellh">@mitchellh</a>)</h3>
<p>
Mitchell Hashimoto is the creator of Nomad and works on all
layers of Nomad from the core to backends. In addition to Nomad,
Mitchell is the creator of
<a href="https://www.vagrantup.com">Vagrant</a>,
<a href="https://www.packer.io">Packer</a>,
<a href="https://www.consul.io">Consul</a>, and
<a href="https://www.terraform.io">Terraform</a>.
</p>
</div>
</div>
<div class="person">
<img class="pull-left" src="http://www.gravatar.com/avatar/11ba9630c9136eef9a70d26473d355d5.png?s=125">
<img class="pull-left" src="https://www.gravatar.com/avatar/11ba9630c9136eef9a70d26473d355d5.png?s=125">
<div class="bio">
<h3>Armon Dadgar (<a href="https://github.com/armon">@armon</a>)</h3>
<p>
Armon Dadgar is a creator of Nomad. He works on all aspects of Nomad,
focusing on core architecture and security. Armon is also the creator of
<a href="https://www.consul.io">Consul</a>,
<a href="https://www.serfdom.io">Serf</a>,
<a href="https://www.terraform.io">Terraform</a>,
<a href="https://github.com/armon/statsite">Statsite</a>, and
<a href="https://github.com/armon/bloomd">Bloomd</a>.
</p>
</div>
</div>
<div class="person">
<img class="pull-left" src="http://www.gravatar.com/avatar/2acc31dd6370a54b18f6755cd0710ce6.png?s=125">
<div class="bio">
<h3>Jack Pearkes (<a href="https://github.com/pearkes">@pearkes</a>)</h3>
<p>
Jack Pearkes is the creator of the online interactive demo of Nomad.
He maintains this demo as well as the design and interaction of the
Nomad website. Jack is an employee of HashiCorp and a primary engineer
behind <a href="https://atlas.hashicorp.com">Atlas</a>.
He is also a core committer to
<a href="https://www.packer.io">Packer</a>,
<a href="https://www.consul.io">Consul</a>, and
<a href="https://www.terraform.io">Terraform</a>.
</p>
Armon Dadgar is a creator of Nomad. He works on all aspects of Nomad,
focusing on core architecture and security. Armon is also an author or
core contributor to:
<a href="https://www.consul.io">Consul</a>,
<a href="https://www.serfdom.io">Serf</a>,
<a href="https://www.terraform.io">Terraform</a>,
<a href="https://github.com/armon/statsite">Statsite</a>,
and <a href="https://github.com/armon/bloomd">Bloomd</a>.
</p>
</div>
</div>
<div class="clearfix"></div>
</div>
<div class="clearfix"></div>
</div>
......@@ -16,7 +16,7 @@ subcommands is in the navigation to the left.
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.
as you would most likely expect.
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
......
---
layout: "docs"
page_title: "Authentication"
sidebar_current: "docs-concepts-auth"
description: |-
Before performing any operation with Nomad, the connecting client must be authenticated.
---
# Authentication
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 Nomad.
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 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
about how to configure it and login.
Multiple authentication backends can be enabled, but only one is required
to gain authentication. It is not currently possible to force a user through
multiple authentication backends to gain access.
This allows you to enable human-friendly as well as machine-friendly
backends at the same time. For example, for humans you might use the
"github" auth backend, and for machines you might use the "app-id" backend.
## Tokens
There is an [entire page dedicated to tokens](/docs/concepts/tokens.html),
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,
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.
This token given for authentication with any backend can also be used
with the full set of token commands, such as creating new sub-tokens,
revoking tokens, and renewing tokens. This is all covered on the
[token concepts page](/docs/concepts/tokens.html).
## Authenticating
#### Via the CLI
To authenticate with the CLI, `vault auth` is used. This supports many
of the built-in authentication methods. For example, with GitHub:
```
$ vault auth -method=github token=<token>
...
```
After authenticating, you will be logged in. The CLI command will also
output your raw token. This token is used for revocation and renewal.
As the user logging in, the primary use case of the token is renewal,
covered below in the "Auth Leases" section.
To determine what variables are needed for an authentication method,
supply the `-method` flag without any additional arguments and help
will be shown.
If you're using a method that isn't supported via the CLI, then the API
must be used.
#### Via the API
API authentication is generally used for machine authentication. Each
auth backend implements is own login endpoint. Use the `vault path-help`
mechanism to find the proper endpoint.
For example, the GitHub login endpoint is located at `auth/github/login`.
And to determine the arguments needed, `vault path-help auth/github/login` can
be used.
## Auth Leases
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
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
how leasing is implemented.
And just like secrets, identities can be renewed without having to
completely reauthenticate. Just use `vault token-renew <token>` with the
token associated with your identity to renew it.
---
layout: "docs"
page_title: "Dev Server Mode"
sidebar_current: "docs-concepts-devserver"
description: |-
The dev server in Nomad can be used for development or to experiment with Nomad.
---
# "Dev" Server Mode
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 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.
~> **Warning:** Never, ever, ever run a "dev" mode server in production.
It is insecure and will lose data on every restart (since it stores data
in-memory). It is only made for development or experimentation.
## Properties
The properties of the dev server:
* **Initialized and unsealed** - The server will be automatically initialized
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. 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 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 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 Nomad features, such
as different authentication backends, secret backends, audit backends, etc.
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.
In addition to experimentation, the dev server is very easy to automate
for development environments.
......@@ -12,31 +12,4 @@ 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, 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 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
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
Currently there are several backends that support high availability mode,
including Consul, ZooKeeper and etcd. These may change over time, and the
[configuration page](/docs/config/index.html) should be referenced.
The Consul backend is the recommended HA backend, as it is used in production
by HashiCorp and it's customers with commercial support.
If you're interested in implementing another backend or adding HA support
to another backend, we'd love your contributions. Adding HA support
requires implementing the `physical.HABackend` interface for the storage backend.
TODO: Document HA
---
layout: "docs"
page_title: "Lease, Renew, and Revoke"
sidebar_current: "docs-concepts-lease"
description: |-
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, 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
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 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.
In addition to renewals, a lease can be _revoked_. When a lease is revoked,
it invalidates that secret immediately and prevents any further renewals.
For
[dynamic secrets](#),
the secrets themselves are often immediately disabled. For example, with
the
[AWS secret backend](/docs/secrets/aws/index.html), the access keys will
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 Nomad. When a lease is expired, Nomad will automatically revoke that
lease.
## Lease IDs
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.
## Lease Durations and Renewal
Along with the lease ID, a _lease duration_ can be read. The lease duration
is the time in seconds that the lease is valid for. A consumer of this
secret must renew the lease within that time.
When renewing the lease, the user can request a specific amount of time
from now to extend the lease. For example: `vault renew my-lease-id 3600`
would request to extend the lease of "my-lease-id" by 1 hour (3600 seconds).
The requested increment is completely advisory. The backend in charge
of the secret can choose to completely ignore it. For most secrets, the
backend does its best to respect the increment, but often limits it to
ensure renewals every so often.
As a result, the return value of renews should be carefully inspected
to determine what the new lease is.
## Prefix-based Revocation
In addition to revoking a single secret, operators with proper access
control can revoke multiple secrets based on their lease ID prefix.
Lease IDs are structured in a way that their prefix is always the path
where the secret was requested from. This lets you revoke trees of
secrets. For example, to revoke all AWS access keys, you can do
`vault revoke -prefix aws/`.
This is very useful if there is an intrusion within a specific system:
all secrets of a specific backend or a certain configured backend can
be revoked quickly and easily.
---
layout: "docs"
page_title: "Policies"
sidebar_current: "docs-concepts-policies"
description: |-
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 Nomad, the
next step is authorization. This is the process of determining what
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 Nomad a user is allowed to access. An example
of a policy is shown below:
```javascript
path "sys/*" {
policy = "deny"
}
path "secret/*" {
policy = "write"
}
path "secret/foo" {
policy = "read"
}
path "secret/super-secret" {
policy = "deny"
}
```
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, 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".
~> Policy paths are matched using the most specific defined policy. This may
be an exact match or the longest-prefix match of a glob. This means if you
define a policy for `"secret/foo*"`, the policy would also match `"secret/foobar"`.
The glob character is only supported at the end of the path specification.
## Policies
Allowed policies for a path are:
* `deny` - No access allowed. Highest precedence.
* `sudo` - Read, write, and root access to a path.
* `write` - Read, write access to a path.
* `read` - Read-only access to a path.
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.
For example, modifying the audit log backends is done via root paths.
Only root or "sudo" privilege users are allowed to do this.
## Root Policy
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 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
to create more strictly controlled users. The original root token should
be protected accordingly.
## Managing Policies
Policy management can be done via the API or CLI. The CLI commands are
`vault policies` and `vault policy-write`. Please see the help associated
with these commands for more information. They are very easy to use.
## Associating Policies
To associate a policy with a user, you must consult the documentation for
the authentication backend you're using.
For tokens, they are associated at creation time with `vault token-create`
and the `-policy` flags. Child tokens can be associated with a subset of
a parent's policies. Root users can assign any policies.
There is no way to modify the policies associated with an active
identity. The identity must be revoked and reauthenticated to receive
the new policy list.
If an _existing_ policy is modified, the modifications propagate
to all associated users instantly. The above paragraph is more specifically
stating that you can't add new or remove policies associated with an
active identity.
## Changes from 0.1
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
exact match could be specified.
The other change is that deny had the lowest precedence. This meant if there
were two policies being merged (e.g. "ops" and "prod") and they had a conflicting
policy like:
```
path "sys/seal" {
policy = "deny"
}
path "sys/seal" {
policy = "read"
}
```
The merge would previously give the "read" higher precedence. The current
version of Nomad prioritizes the explicit deny, so that the "deny" would
take precedence.
To make all Nomad 0.1 policies compatible with Nomad 0.2, the explicit
glob character must be added to all the path prefixes.
---
layout: "docs"
page_title: "Seal/Unseal"
sidebar_current: "docs-concepts-seal"
description: |-
A Nomad must be unsealed before it can access its data. Likewise, it can be sealed to lock it down.
---
# Seal/Unseal
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 Nomad.
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 Nomad and check the status
of the unseal.
## Why?
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, 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,
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.
This is the _unseal_ process: the shards are added one at a time (in any
order) until enough shards are present to reconstruct the key and
decrypt the data.
## Unsealing
The unseal process is done by running `vault unseal` or via the API.
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 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 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 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 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 Nomad data can be locked
quickly to try to minimize damages. It can't be accessed again without
access to the master key shards.
---
layout: "docs"
page_title: "Tokens"
sidebar_current: "docs-concepts-tokens"
description: |-
Tokens are a core authentication method in Nomad. Child tokens, token-based revocation, and more.
---
# 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 Nomad.
It is also the only authentication backend that cannot be disabled.
As stated in the [authentication concepts](/docs/concepts/auth.html),
all external authentication mechanisms such as GitHub map down to dynamically
created tokens. These tokens have all the same properties as a normal
manually created token.
On this page, we'll show you how to create and manage tokens.
## Token Creation
Tokens are created via the API or using `vault token-create` from the CLI.
This will create a new token that is a child of the currently authenticated
token. As a child, the new token will automatically be revoked if the parent
is revoked.
If you're logged in as root, you can create an _orphan_ token by
specifying the `-orphan` flag. An orphan token has no parent, and therefore
when your token is revoked, it will not revoke the orphan.
Metadata associated with the token with `-metadata` is used to annotate
the token with information that is added to the audit log.
Finally, the `-policy` flag can be used to set the policies associated
with the token. Learn more about policies on the
[policies concepts](/docs/concepts/policies.html) page.
## Token Leases
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, 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.
After a token is revoked, all of the secrets in use by that token will
also be revoked. Therefore, if a user requests AWS access keys, for example,
then after the token expires the AWS access keys will also be expired even
if they had remaining lease time.
......@@ -6,12 +6,14 @@ description: |-
Nomad server configuration reference.
---
# Server Configuration
# Nomad Configuration
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:
TODO: Document Nomad configuration. Examples below stolen from Vault.
```javascript
backend "consul" {
address = "127.0.0.1:8500"
......@@ -66,177 +68,3 @@ the Nomad executable access to the `mlock` syscall on Linux systems:
```shell
sudo setcap cap_ipc_lock=+ep $(readlink -f $(which vault))
```
## Backend Reference
For the `backend` section, the supported backends are shown below.
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 Nomad
and has been shown to work at high scale under heavy load.
* `etcd` - Store data within [etcd](https://coreos.com/etcd/).
This backend supports HA.
* `zookeeper` - Store data within [Zookeeper](https://zookeeper.apache.org/).
This backend supports HA.
* `s3` - Store data within an S3 bucket [S3](http://aws.amazon.com/s3/).
This backend does not support HA.
* `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 Nomad is
restarted.
* `file` - Store data on the filesystem using a directory structure.
This backend does not support HA.
#### Common Backend Options
All backends support the following options:
* `advertise_addr` (optional) - For backends that support HA, this
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.
#### Backend Reference: Consul
For Consul, the following options are supported:
* `path` (optional) - The path within Consul where data will be stored.
Defaults to "vault/".
* `address` (optional) - The address of the Consul agent to talk to.
Defaults to the local agent address, if available.
* `scheme` (optional) - "http" or "https" for talking to Consul.
* `datacenter` (optional) - The datacenter within Consul to write to.
This defaults to the local datacenter.
* `token` (optional) - An access token to use to write data to Consul.
* `tls_skip_verify` (optional) - If non-empty, then TLS host verification
will be disabled for Consul communication.
Defaults to false.
The following settings should be set according to your [Consul encryption settings](https://www.consul.io/docs/agent/encryption.html):
* `tls_ca_file` (optional) - The path to the CA certificate used for Consul communication.
Defaults to system bundle if not specified.
Set accordingly to the [ca_file](https://www.consul.io/docs/agent/options.html#ca_file) setting in Consul.
* `tls_cert_file` (optional) - The path to the certificate for Consul communication.
Set accordingly to the [cert_file](https://www.consul.io/docs/agent/options.html#cert_file) setting in Consul.
* `tls_key_file` (optional) - The path to the private key for Consul communication.
Set accordingly to the [key_file](https://www.consul.io/docs/agent/options.html#key_file) setting in Consul.
#### Backend Reference: Zookeeper
For Zookeeper, the following options are supported:
* `path` (optional) - The path within Zookeeper where data will be stored.
Defaults to "vault/".
* `address` (optional) - The address(es) of the Zookeeper instance(s) to talk to.
Can be comma separated list (host:port) of many Zookeeper instances.
Defaults to "localhost:2181" if not specified.
#### Backend Reference: etcd
For etcd, the following options are supported:
* `path` (optional) - The path within etcd where data will be stored.
Defaults to "vault/".
* `address` (optional) - The address(es) of the etcd instance(s) to talk to.
Can be comma separated list (protocol://host:port) of many etcd instances.
Defaults to "http://localhost:4001" if not specified.
#### Backend Reference: S3
For S3, the following options are supported:
* `bucket` (required) - The name of the S3 bucket to use.
* `access_key` - (required) The AWS access key. It must be provided, but it can also be sourced from the AWS_ACCESS_KEY_ID environment variable.
* `secret_key` - (required) The AWS secret key. It must be provided, but it can also be sourced from the AWS_SECRET_ACCESS_KEY environment variable.
* `session_token` - (optional) The AWS session_token. It can also be sourced from the AWS_SESSION_TOKEN environment variable.
* `region` (optional) - The AWS region. It can be sourced from the AWS_DEFAULT_REGION environment variable and will default to "us-east-1" if not specified.
#### Backend Reference: MySQL
The MySQL backend has the following options:
* `username` (required) - The MySQL username to connect with.
* `password` (required) - The MySQL password to connect with.
* `address` (optional) - The address of the MySQL host. Defaults to
"127.0.0.1:3306.
* `database` (optional) - The name of the database to use. Defaults to "vault".
* `table` (optional) - The name of the table to use. Defaults to "vault".
* `tls_ca_file` (optional) - The path to the CA certificate to connect using TLS
#### Backend Reference: Inmem
The in-memory backend has no configuration options.
#### Backend Reference: File
The file backend has the following options:
* `path` (required) - The path on disk to a directory where the
data will be stored.
## Listener Reference
For the `listener` section, the only supported listener currently
is "tcp". Regardless of future plans, this is the recommended listener,
since it allows for HA mode.
The supported options are:
* `address` (optional) - The address to bind to for listening. This
defaults to "127.0.0.1:8200".
* `tls_disable` (optional) - If non-empty, then TLS will be disabled.
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.
* `tls_key_file` (required unless disabled) - The path to the private key
for the certificate.
* `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
possible.
## Telemetry Reference
For the `telemetry` section, there is no resource name. All configuration
is within the object itself.
* `statsite_address` (optional) - An address to a [Statsite](https://github.com/armon/statsite)
instances for metrics. This is highly recommended for production usage.
* `statsd_address` (optional) - This is the same as `statsite_address` but
for StatsD.
* `disable_hostname` (optional) - Whether or not to prepend runtime telemetry
with the machines hostname. This is a global option. Defaults to false.
......@@ -8,10 +8,10 @@ description: |-
# Custom Drivers
Nomad doesn't currently support the creation of custom secret backends.
Nomad does not 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
in supporting custom secret backends, but do not yet have a clear strategy
or timeline to do.
In the mean time, you can use the
......
......@@ -28,11 +28,11 @@ a write, etc. This is a lot like a normal filesystem.
The "aws" backend, on the other hand, behaves differently. When you
write to `aws/config/root`, it expects a certain format and stores that
information as configuration. You can't read from this path. When you
information as configuration. You cannot read from this path. When you
read from `aws/<name>`, it looks up an IAM policy named `<name>` and
generates AWS access credentials on demand and returns them. It doesn't
behave at all like a typical filesystem: you're not simply storing and
retrieving values, you're interacting with an API.
generates AWS access credentials on demand and returns them. It does not
behave at all like a typical filesystem: you are not simply storing and
retrieving values, you are interacting with an API.
## Mounting/Unmounting Secret Backends
......@@ -53,7 +53,7 @@ with regards to mounting:
* **Remount** - This moves the mount point for an existing secret backend.
This revokes all secrets, since secret leases are tied to the path they
were created at. The data stored for the backend won't be deleted.
were created at. The data stored for the backend will not be deleted.
Once a secret backend is mounted, you can interact with it directly
at its mount point according to its own API. You can use the `vault path-help`
......@@ -68,8 +68,8 @@ 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 Nomad storage layer doesn't support relative access (such as `..`),
the Nomad storage layer does not 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 Nomad: even a malicious backend
can't access the data from any other backend.
cannot access the data from any other backend.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment