a3dfde5cec
* conversion stage 1 * correct image paths * add sidebar title to frontmatter * docs/concepts and docs/internals * configuration docs and multi-level nav corrections * commands docs, index file corrections, small item nav correction * secrets converted * auth * add enterprise and agent docs * add extra dividers * secret section, wip * correct sidebar nav title in front matter for apu section, start working on api items * auth and backend, a couple directory structure fixes * remove old docs * intro side nav converted * reset sidebar styles, add hashi-global-styles * basic styling for nav sidebar * folder collapse functionality * patch up border length on last list item * wip restructure for content component * taking middleman hacking to the extreme, but its working * small css fix * add new mega nav * fix a small mistake from the rebase * fix a content resolution issue with middleman * title a couple missing docs pages * update deps, remove temporary markup * community page * footer to layout, community page css adjustments * wip downloads page * deps updated, downloads page ready * fix community page * homepage progress * add components, adjust spacing * docs and api landing pages * a bunch of fixes, add docs and api landing pages * update deps, add deploy scripts * add readme note * update deploy command * overview page, index title * Update doc fields Note this still requires the link fields to be populated -- this is solely related to copy on the description fields * Update api_basic_categories.yml Updated API category descriptions. Like the document descriptions you'll still need to update the link headers to the proper target pages. * Add bottom hero, adjust CSS, responsive friendly * Add mega nav title * homepage adjustments, asset boosts * small fixes * docs page styling fixes * meganav title * some category link corrections * Update API categories page updated to reflect the second level headings for api categories * Update docs_detailed_categories.yml Updated to represent the existing docs structure * Update docs_detailed_categories.yml * docs page data fix, extra operator page remove * api data fix * fix makefile * update deps, add product subnav to docs and api landing pages * Rearrange non-hands-on guides to _docs_ Since there is no place for these on learn.hashicorp, we'll put them under _docs_. * WIP Redirects for guides to docs * content and component updates * font weight hotfix, redirects * fix guides and intro sidenavs * fix some redirects * small style tweaks * Redirects to learn and internally to docs * Remove redirect to `/vault` * Remove `.html` from destination on redirects * fix incorrect index redirect * final touchups * address feedback from michell for makefile and product downloads
128 lines
4 KiB
Markdown
128 lines
4 KiB
Markdown
---
|
||
layout: "docs"
|
||
page_title: "Etcd - Storage Backends - Configuration"
|
||
sidebar_title: "Etcd"
|
||
sidebar_current: "docs-configuration-storage-etcd"
|
||
description: |-
|
||
The Etcd storage backend is used to persist Vault's data in Etcd. It supports
|
||
both the v2 and v3 Etcd APIs, and the version is automatically detected based
|
||
on the version of the Etcd cluster.
|
||
---
|
||
|
||
# Etcd Storage Backend
|
||
|
||
The Etcd storage backend is used to persist Vault's data in [Etcd][etcd]. It
|
||
supports both the v2 and v3 Etcd APIs, and the version is automatically detected
|
||
based on the version of the Etcd cluster.
|
||
|
||
- **High Availability** – the Etcd storage backend supports high availability.
|
||
The v2 API has known issues with HA support and should not be used in HA
|
||
scenarios.
|
||
|
||
- **Community Supported** – the Etcd storage backend is supported by CoreOS.
|
||
While it has undergone review by HashiCorp employees, they may not be as
|
||
knowledgeable about the technology. If you encounter problems with them, you
|
||
may be referred to the original author.
|
||
|
||
```hcl
|
||
storage "etcd" {
|
||
address = "http://localhost:2379"
|
||
etcd_api = "v3"
|
||
}
|
||
```
|
||
|
||
## `etcd` Parameters
|
||
|
||
- `address` `(string: "http://localhost:2379")` – Specifies the addresses of the
|
||
Etcd instances as a comma-separated list. This can also be provided via the
|
||
environment variable `ETCD_ADDR`.
|
||
|
||
- `discovery_srv` `(string: "example.com")` - Specifies the domain name to
|
||
query for SRV records describing cluster endpoints. This can also be provided
|
||
via the environment variable `ETCD_DISCOVERY_SRV`.
|
||
|
||
- `etcd_api` `(string: "<varies>")` – Specifies the version of the API to
|
||
communicate with. By default, this is derived automatically. If the cluster
|
||
version is 3.1+ and there has been no data written using the v2 API, the
|
||
auto-detected default is v3.
|
||
|
||
- `ha_enabled` `(string: "false")` – Specifies if high availability should be
|
||
enabled. This can also be provided via the environment variable
|
||
`ETCD_HA_ENABLED`.
|
||
|
||
- `path` `(string: "/vault/")` – Specifies the path in Etcd where Vault data will
|
||
be stored.
|
||
|
||
- `sync` `(string: "true")` – Specifies whether to sync the list of available
|
||
Etcd services on startup. This is a string that is coerced into a boolean
|
||
value. You may want to set this to false if your cluster is behind a proxy
|
||
server and syncing causes Vault to fail.
|
||
|
||
- `username` `(string: "")` – Specifies the username to use when authenticating
|
||
with the Etcd server. This can also be provided via the environment variable
|
||
`ETCD_USERNAME`.
|
||
|
||
- `password` `(string: "")` – Specifies the password to use when authenticating
|
||
with the Etcd server. This can also be provided via the environment variable
|
||
`ETCD_PASSWORD`.
|
||
|
||
- `tls_ca_file` `(string: "")` – Specifies the path to the CA certificate used
|
||
for Etcd communication. This defaults to system bundle if not specified.
|
||
|
||
- `tls_cert_file` `(string: "")` – Specifies the path to the certificate for
|
||
Etcd communication.
|
||
|
||
- `tls_key_file` `(string: "")` – Specifies the path to the private key for Etcd
|
||
communication.
|
||
|
||
## `etcd` Examples
|
||
|
||
### DNS Discovery of cluster members
|
||
|
||
This example configures vault to discover the Etcd cluster members via SRV
|
||
records as outlined in the
|
||
[DNS Discovery protocol documentation][dns discovery].
|
||
|
||
```hcl
|
||
storage "etcd" {
|
||
discovery_srv = "example.com"
|
||
}
|
||
```
|
||
|
||
### Custom Authentication
|
||
|
||
This example shows connecting to the Etcd cluster using a username and password.
|
||
|
||
```hcl
|
||
storage "etcd" {
|
||
username = "user1234"
|
||
password = "pass5678"
|
||
}
|
||
```
|
||
|
||
### Custom Path
|
||
|
||
This example shows storing data in a custom path.
|
||
|
||
```hcl
|
||
storage "etcd" {
|
||
path = "my-vault-data/"
|
||
}
|
||
```
|
||
|
||
### Enabling High Availability
|
||
|
||
This example show enabling high availability for the Etcd storage backend.
|
||
|
||
```hcl
|
||
api_addr = "https://vault-leader.my-company.internal"
|
||
|
||
storage "etcd" {
|
||
ha_enabled = "true"
|
||
...
|
||
}
|
||
```
|
||
|
||
[etcd]: https://coreos.com/etcd "Etcd by CoreOS"
|
||
[dns discovery]: https://coreos.com/etcd/docs/latest/op-guide/clustering.html#dns-discovery "Etcd cluster DNS Discovery"
|