diff --git a/website/source/docs/concepts/ha.html.markdown b/website/source/docs/concepts/ha.html.markdown new file mode 100644 index 0000000000..54760ceb7a --- /dev/null +++ b/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. diff --git a/website/source/docs/concepts/seal.html.md b/website/source/docs/concepts/seal.html.md index e8894ad562..cda43cac84 100644 --- a/website/source/docs/concepts/seal.html.md +++ b/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 diff --git a/website/source/docs/config/index.html.md b/website/source/docs/config/index.html.md new file mode 100644 index 0000000000..ca1ba4a108 --- /dev/null +++ b/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. diff --git a/website/source/intro/index.html.markdown b/website/source/intro/index.html.markdown index 7815ff0a54..f6296cf18a 100644 --- a/website/source/intro/index.html.markdown +++ b/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. diff --git a/website/source/intro/use-cases.html.markdown b/website/source/intro/use-cases.html.markdown index 6722fa86ea..4f9df23815 100644 --- a/website/source/intro/use-cases.html.markdown +++ b/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. diff --git a/website/source/layouts/docs.erb b/website/source/layouts/docs.erb index 5ca752daf1..5fa6a004a8 100644 --- a/website/source/layouts/docs.erb +++ b/website/source/layouts/docs.erb @@ -45,9 +45,17 @@ > Lease, Renew, and Revoke + + > + High Availability + + > + Configuration + + > Commands (CLI)