Plugin system

All Vault auth methods and secrets engines are considered plugins. This simple concept allows both built-in and external plugins to be treated like Legos. Any plugin can exist at multiple different locations. Different versions of a plugin may be at each location, with each version differing from Vault's version.

By default, Vault expects the plugin directory and files to be owned by the user running Vault. It also expects no write or execute permissions for group or others. Vault allows operators to specify the user and permissions of the plugin directory and binaries using parameters plugin_file_uid and plugin_file_permissions if an operator needs those to be different.
This check can be disabled via the environment variable VAULT_DISABLE_FILE_PERMISSIONS_CHECK.

Built-In plugins

Built-in plugins are shipped with Vault, often for commonly used implementations, and require no additional operator intervention to run. Built-in plugins are just like any other backend code inside Vault.

To use a different or edited version of a built-in plugin, the plugin must be run as an external plugin. See Overriding Built-in Plugins for details on how to override a built-in plugin in-place.

External plugins

External plugins are not shipped with Vault and require additional operator intervention to run.

To run an external plugin, a binary of the plugin is required. Plugin binaries can be obtained from releases.hashicorp.com or they can be built from source.

Vault's external plugins are completely separate, standalone applications that Vault executes and communicates with over RPC. Each time a Vault secret engine or auth method is mounted, a new process is spawned. However, database plugins can be made to implement plugin multiplexing which allows a single plugin process to be used for multiple database connections.