A new platform for documentation and tutorials is launching soon.
We are migrating Vault documentation into HashiCorp Developer, our new developer experience.
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
plugin_file_permissions if an operator needs those to be different.
This check can be disabled via the environment variable
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 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 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.