The Vault encryption provider enables Jerakia to use the Transit Secret backend of Vault to perform encryption and decryption on the fly, essensially using Vault as an encryption as a service provider.
You will first need to configure vault with the correct backend, keys, polciies and app_role in order for Jerakia to be able to successfully authenticate and use the transit endpoint. For more in depth information on configuring Vault, see the post Managing Puppet Secrets with Jerakia and Vault which gives a step by step guide to preparing Vault for integration with Jerakia.
The Vault encryption provider requires at least the following information in order to be configured
Although using a regular token will work, it will eventually expire and require manual intervention to renew. We recommend using a
secret_id to enable Jerakia to automatically renew it’s expired tokens.
The following options are accepted in the
encryption section of
provider: Must be set to
vault_addr: The URL to access vault (default: https://127.0.0.1:8200)
vault_use_ssl: Must be set to false if you are using HTTP (default: true)
vault_ssl_key: Path to the SSL key (if using SSL)
vault_ssl_cert: Path to the SSL certificate (if using SSL)
vault_ssl_verify: Whether or not verify the SSL connection (default true)
vault_token: A regular Vault authentication token (not recommended)
vault_role_id: The AppRole ID to use to connect to Vault
vault_secret_id: The Secret ID that corresponds to the
vault_api_version: The API version for vault (default: 1)
vault_keyname: The name of the key to use for transit backend (default: jerakia)
Once configured correctly, you can encrypt and decrypt values on the command line, eg:
The resulting encrypted string can be placed along side your regular data. When the encryption output filter is enabled in a lookup, this string will automatically be detected as encrypted and the provider will be called to decrypt it before passing the results back to the lookup requestor