Plugin management

External plugins are the components in Vault that can be implemented separately from Vault's built-in plugins. These plugins can be either authentication or secrets engines.

The api_addr must be set in order for the plugin process to establish communication with the Vault server during mount time. If the storage backend has HA enabled and supports automatic host address detection (e.g. Consul), Vault will automatically attempt to determine the api_addr as well.

Detailed information regarding the plugin system can be found in the internals documentation.

Registering external plugins

Before an external plugin can be mounted, it needs to be registered in the plugin catalog to ensure the plugin invoked by Vault is authentic and maintains integrity:

$ vault plugin register -sha256=<SHA256 Hex value of the plugin binary> \    secret \                  # type    passthrough-plugin Success! Registered plugin: passthrough-plugin

Enabling/Disabling external plugins

After the plugin is registered, it can be mounted by specifying the registered plugin name:

$ vault secrets enable -path=my-secrets passthrough-pluginSuccess! Enabled the passthrough-plugin secrets engine at: my-secrets/

Listing secrets engines will display secrets engines that are mounted as plugins:

$ vault secrets listPath         Type       Accessor            Plugin              Default TTL  Max TTL  Force No Cache  Replication Behavior  Descriptionmy-secrets/  plugin     plugin_deb84140     passthrough-plugin  system       system   false           replicated

Disabling an external plugins is identical to disabling a built-in plugin:

$ vault secrets disable my-secrets

Upgrading plugins

Upgrade instructions can be found in the Upgrading Plugins - Guides page.

Plugin environment variables

An advantage for external plugins over builtin plugins is they can specify additional environment variables because they are run in their own process.

Vault 1.16.0 changed the precedence given to plugin-specific environment variables so they take priority over Vault's environment. See full details in the upgrade notes.

Use the -env flag once per environment variable that a plugin should be started with:

$ vault plugin register -sha256=<SHA256 Hex value of the plugin binary> \    -env REGION=eu \    -env TOKEN_FILE=/var/run/token \    secret \                  # type    passthrough-plugin Success! Registered plugin: passthrough-plugin

Plugin-specific HTTP proxy settings

Many tools and libraries automatically consume HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables to configure HTTP proxy settings, including the Go standard library's default HTTP client. You can use these environment variables to configure different network proxies for different plugins:

You must be using an external plugin to take advantage of custom environment variables. If you are using a builtin plugin, you can still download and register an external version of it in order to use this workflow. Check the releases page for the latest prebuilt plugin binaries.

$ vault plugin register -sha256=<SHA256 Hex value of the plugin binary> \    -env HTTP_PROXY=eu.example.com \    auth \    jwt-eu Success! Registered plugin: jwt-eu $ vault plugin register -sha256=<SHA256 Hex value of the plugin binary> \    -env HTTP_PROXY=us.example.com \    auth \    jwt-us Success! Registered plugin: jwt-us

You can then enable each plugin on its own path, and configure clients that should be associated with one or the other appropriately:

$ vault auth enable jwt-euSuccess! Enabled the jwt-eu auth method at: auth/jwt-eu/ $ vault auth enable jwt-usSuccess! Enabled the jwt-us auth method at: auth/jwt-us/