FoundationDB storage backend
The FoundationDB storage backend is used to persist Vault's data in FoundationDB.
The backend needs to be explicitly enabled at build time, and is not available in the standard Vault binary distribution. Please refer to the documentation accompanying the backend's source in the Vault source tree.
High Availability – the FoundationDB storage backend supports high availability. The HA implementation relies on the clocks of the Vault nodes inside the cluster being properly synchronized; clock skews are susceptible to cause contention on the locks.
Community Supported – the FoundationDB storage backend is supported by the community. 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.
foundationdb
parameters
api_version
(int)
- The FoundationDB API version to use; this is a required parameter and doesn't have a default value. The minimum required API version is 520.cluster_file
(string)
- The path to the cluster file containing the connection data for the target cluster; this is a required parameter and doesn't have a default value.tls_verify_peers
(string)
- The peer certificate verification criteria; this parameter is mandatory if TLS is enabled. Refer to the FoundationDB TLS documentation.tls_ca_file
(string)
- The path to the CA certificate bundle file; this parameter is mandatory if TLS is enabled.tls_cert_file
(string)
- The path to the certificate file; specifying this parameter together withtls_key_file
will enable TLS support.tls_key_file
(string)
- The path to the key file; specifying this parameter together withtls_cert_file
will enable TLS support.tls_password
(string)
- The password needed to decrypttls_key_file
, if it is encrypted; optional. This can also be specified via theFDB_TLS_PASSWORD
environment variable.path
(string: "vault")
- The path of the top-level FoundationDB directory (using the directory layer) under which the Vault data will reside.ha_enabled
(string: "false")
- Whether or not to enable Vault high-availability mode using the FoundationDB backend.
foundationdb
tips
Cluster file
The FoundationDB client expects to be able to update the cluster file at runtime, to keep it current with changes happening to the cluster.
It does so by first writing a new cluster file alongside the current one, then atomically renaming it into place.
This means the cluster file and the directory it resides in must be writable by the user Vault is running as. You probably want to isolate the cluster file into its own directory.
Multi-version client
The FoundationDB client library version is tightly coupled to the server version; during cluster upgrades, multiple server versions will be running in the cluster, and the client must cope with that situation.
This is handled by the (primary) client library having the ability to load a different, later version of the client library to connect to a particular server; it is referred to as the multi-version client feature.
Client setup with LD_LIBRARY_PATH
If you do not use mlock, you can use LD_LIBRARY_PATH
to point the linker at
the location of the primary client library.
Client setup with RPATH
When running Vault with mlock, the Vault binary must have capabilities set to allow the use of mlock.
The presence of the capabilities will cause the linker to ignore
LD_LIBRARY_PATH
, for security reasons.
In that case, we have to set an RPATH
on the Vault binary at build time
to replace the use of LD_LIBRARY_PATH
.
When building Vault, pass the -r /dest/dir/for/primary
option to the Go
linker, for instance:
(Note the trailing space in the variable value above).
You can verify RPATH
is set on the Vault binary using readelf
:
With the client libraries installed:
Now run Vault: