Vault Integration

hashicorp vault can be used both for storing encryption keys and database credentials using vault helps ensure that secrets are maintained in a secure and robust way for both keys and credentials, the jumpwire engine will treat vault as the source of truth once configured restarting or even fully deleting and recreating the cluster will cause credentials to be loaded from vault without data loss backing up vault is critical, particularly when storing encryption keys see the vault tutorial https //developer hashicorp com/vault/tutorials/standard procedures/sop backup for details on how to setup data backups vault is enabled by setting either a token or approle id and secret in the engine at runtime see the configuration docid\ and6t wc2kywbr p1y gr page for all configuration options encryption keys jumpwire can be configured to use hashicorp vault for managing encryption keys keys are initially generated in the jumpwire engine and then stored in a vault kv backend the next time that the engine starts up, it will retrieve the stored keys from vault instead of generating new ones authentication with either the approle or token methods are supported jumpwire needs to have write access to a kv path in vault the base path can be configured by setting jumpwire kv path using v2 of the kv secrets engine is recommended since the stored keys allow decryption of any encrypted data without going through jumpwire policies or authorization, the kv paths in vault should be restricted to a minimal set of allowed administrators vault policy write jumpwire <\<eof path "secret/data/jumpwire/ " { capabilities = \["create", "update", "read", "delete"] } path "secret/metadata/jumpwire/ " { capabilities = \["list", "read"] } eof vault write auth/approle/role/jumpwire token policies=jumpwire token ttl=1h token max ttl=4h docker run d \\ e "vault kv path=secret/jumpwire" \\ e "vault token= " \\ jumpwire/jumpwire paths jumpwire will store encryption keys under the provided path the master key is stored at /master key a new key will automatically be generated if one is not found subkeys are stored under the path /aes keys database credentials jumpwire can use dynamically generated credentials from vault to authenticate to a database being proxied databases and roles under the provided mount point are listed and shown in the ui when configuring a new proxy the database mount point can be configured by setting vault db path dynamic credentials are generated when a client connects to the jumpwire engine, and automatically renewed at half of the configured ttl eg setting a 1 hour ttl will cause the credentials to try to renew after 30 minutes the role used must have broad permissions on the proxied database to enable in database encryption an example role for proxying the user info database in a postgresql server is shown below vault write database/roles/jumpwire \\ db name=my postgresql database \\ creation statements="create role \\"{{name}}\\" with login password '{{password}}' valid until '{{expiration}}'; \\ grant all on all tables in schema public to \\"{{name}}\\"; \\ grant all on all sequences in schema public to \\"{{name}}\\"; \\ grant all on all functions in schema public to \\"{{name}}\\";" default ttl="1h" \\ max ttl="24h" docker run d \\ e "vault token= " \\ jumpwire/jumpwire kv storage as an alternative to using generated credentials from vault, jumpwire can also store static credentials using the vault kv store this works almost identically to the encryption key storage described above when a databases docid\ rx fnn4aau9eafcbjvsq is created or updated and the jumpwire engine is set to use static credentials from vault, the credentials entered in the ui are stored in the vault kv mount the mount path can be configured by setting vault kv path