Vault supports 3 types of plugins; auth methods, secret engines, and database plugins. This concept allows both built-in and external plugins to be treated like building blocks. Any plugin can exist at multiple different mount paths. Different versions of a plugin may be at each location, with each version differing from Vault's version.
A plugin is uniquely identified by its type (one of
database), name (e.g.
aws), and version (e.g
v1.0.0). An empty version
implies either the built-in plugin or the single unversioned plugin that can
See Plugin Upgrade Procedure for details on how to upgrade a built-in plugin in-place.
Built-in plugins are shipped with Vault, often for commonly used integrations, and can be used without any prerequisite steps.
External plugins are not shipped with Vault and require additional operator intervention to run.
Vault's external plugins are completely separate, standalone applications that Vault executes and communicates with over RPC. Each time a Vault secret engine, auth method, or database plugin is mounted, a new process is spawned. However, plugins can be made to implement plugin multiplexing to improve performance. Plugin multiplexing allows plugin processes to be reused across all mounts of a given type.
NOTE: See the Vault Integrations page to find a curated collection of official, partner, and community Vault plugins.
Vault supports managing, running and upgrading plugins using semantic version information.
The plugin catalog optionally supports specifying a semantic version when registering an external plugin. Multiple versions of a plugin can be registered in the catalog simultaneously, and a version can be selected when mounting a plugin or tuning an existing mount in-place.
If no version is specified when creating a new mount, the following precedence is used for any available plugins whose type and name match:
- The plugin registered with no version
- The plugin with the most recent semantic version among any registered versions
- The plugin built into Vault
Vault will report a version for built-in plugins to indicate what version of the plugin code got built into Vault as a dependency. For example:
$ vault plugin list secret Name Version ---- ------- ad v0.14.0+builtin alicloud v0.13.0+builtin aws v1.12.0+builtin.vault # ...
Here, Vault has a dependency on
v0.14.0 of the hashicorp/vault-plugin-secrets-ad
repo, and the
vault metadata identifier for
aws indicates that plugin's code was
within the Vault repo. For plugins within the Vault repo, Vault's own major, minor,
and patch versions are used to form the plugin version.
builtin metadata identifier is reserved and cannot be used when registering