website: HA concepts, configuration

website/source/docs/concepts/ha.html.markdown

@@ -0,0 +1,38 @@
+---
+layout: "docs"
+page_title: "High Availibility"
+sidebar_current: "docs-concepts-ha"
+description: |-
+  Vault can be highly available, allowing you to run multiple Vaults 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
+is automatically enabled when using a physical 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
+the leader. Due to this architecture, HA does not enable increased scalability.
+In general, the bottleneck of Vault is the physical backend itself, not
+Vault core. For example: to increase scalability of Vault with Consul, you
+would scale Consul instead of Vault.
+
+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
+this to any address you want.
+
+## Backend Support
+
+Currently, the only backend that supports HA is Consul.
+
+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 physical
+backend.

website/source/docs/concepts/seal.html.md

@@ -57,9 +57,9 @@ Once a Vault is unsealed, it remains unsealed until one of two things happens:
 -> **Note:** Unsealing makes the process of automating a Vault install
 difficult. Automated tools can easily install, configure, and start Vault,
 but unsealing it is a very manual process. We have plans in the future to
-address this, but for now it is a design decision: you want the unsealing
-shards to be in the hands of operators, and you want each unseal to be
-a careful event. For HA, please use multiple Vault servers.
+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.
 
 ## Sealing
 

website/source/docs/config/index.html.md

@@ -0,0 +1,118 @@
+---
+layout: "docs"
+page_title: "Server Configuration"
+sidebar_current: "docs-config"
+description: |-
+  Vault server configuration reference.
+---
+
+# Server Configuration
+
+Outside of development mode, Vault 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:
+
+```
+backend "consul" {
+    address = "demo.consul.io:80"
+    path = "vault"
+}
+
+listener "tcp" {
+   address = "127.0.0.1:8200"
+   tls_disable = 1
+}
+```
+
+After the configuration is written, use the `-config` flag with `vault server`
+to specify where the configuration is.
+
+## Reference
+
+* `backend` (required) - Configures the physical backend where Vault data
+  is stored. There are multiple options available for physical backends,
+  and they're documented below.
+
+* `listener` (required) - Configures how Vault is listening for API requests.
+  "tcp" is currently the only option available. A full reference for the
+   inner syntax is below.
+
+* `statsite_addr` (optional) - An address to a [Statsite](https://github.com/armon/statsite)
+  instances for metrics. This is highly recommended for production usage.
+
+* `statsd_addr` (optional) - This is the same as `statsite_addr` but
+  for StatsD.
+
+## Backend Reference
+
+For the `backend` section, the supported backends are shown below.
+Vault 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
+      and has been shown to work at high scale under heavy load.
+
+  * `inmem` - Store data in-memory. This is only really useful for
+      development and experimentation. Data is lost whenever Vault 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 Vault servers in the cluster
+      for request forwarding. If this isn't specified, it'll default to
+      the first private address on the machine running Vault.
+
+#### 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.
+
+#### 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; Vault 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.

website/source/intro/index.html.markdown

@@ -50,6 +50,11 @@ The key features of Vault are:
   creating these dynamic secrets, Vault will also automatically revoke them
   after the lease is up.
 
+* **Data Encryption**: Vault can encrypt and decrypt data without storing
+  it. This allows security teams to define encryption parameters and
+  developers to store encrypted data in a location such as SQL without
+  having to design their own encryption methods.
+
 * **Leasing and Renewal**: All secrets in Vault have a _lease_ associated
   with it. At the end of the lease, Vault will automatically revoke that
   secret. Clients are able to renew leases via built-in renew APIs.

website/source/intro/use-cases.html.markdown

@@ -41,3 +41,15 @@ creation of the keys are completely logged.
 
 This is an improvement over using something like Amazon IAM but still
 effectively hardcoding limited-access access tokens in various places.
+
+#### Data Encryption
+
+In addition to being able to store secrets, Vault can be used to
+encrypt/decrypt data that is stored elsewhere. The primary use of this is
+to allow applications to encrypt their data while still storing it in the
+primary data store.
+
+The benefit of this is that developers do not need to worry about how to
+properly encrypt data. The responsibility of encryption is on Vault
+and the security team managing it, and developers just encrypt/decrypt
+data as needed.

website/source/layouts/docs.erb

@@ -45,9 +45,17 @@
 						<li<%= sidebar_current("docs-concepts-lease") %>>
 							<a href="/docs/concepts/lease.html">Lease, Renew, and Revoke</a>
 						</li>
+
+						<li<%= sidebar_current("docs-concepts-ha") %>>
+							<a href="/docs/concepts/ha.html">High Availability</a>
+						</li>
 					</ul>
 				</li>
 
+				<li<%= sidebar_current("docs-config") %>>
+					<a href="/docs/config/index.html">Configuration</a>
+				</li>
+
 				<li<%= sidebar_current("docs-commands") %>>
 					<a href="/docs/commands/index.html">Commands (CLI)</a>
 					<ul class="nav">