Discover Vault plugins
Vault uses a plugin architecture to power all functionality offered by auth methods, database engines, and secrets engines. This idea includes a rich set of built-in plugins, that extends to enable external third-party plugins.
Scenario
The HashiCups team would like to understand how Vault operates. They understand from their initial meeting with HashiCorp that Vault supports different auth methods and secrets engines, but would like to better understand how each of these operates.
The HashiCups team would also like to understand how they can extend Vault for their various use cases.
Vault plugins
HashiCups can use the flexibility of the Vault plugin system to implement new use cases or expand existing ones. As a developer, Danielle can build a custom database plugin that implements dynamic secrets for projects which must interface with a particular legacy SQL database.
The team can also use existing official external plugins from partners or the community to support a wide range of use cases.
Authentication plugins
Authentication plugins, or auth methods, provide integration with different services to allow both individuals or workloads to authentcate with Vault.
For the HashiCups proof-of-concept (POC) Alice has worked with the different
teams involved with testing Vault and selected the userpass
auth method. Auth
methods to authenticate individuals generally require an interaction with Vault,
such as supplying a username and password to verify their identity.
To test authentication for workloads, Alice has worked with Danielle to select
the kubernetes
auth method. Auth methods for workloads integrate with a
specific platforms application programming interface (API) to validate the
workload can access Vault.
What is the difference between the userpass
and kubernetes
auth methods?
Certain auth methods focus on human interaction, such as the userpass
auth method, others support workloads that do not interactively log in to Vault
such as the kubernetes
auth method.
Secret engine plugins
Secret engine plugins, or secret engines can store static secrets or generate
just-in-time or dynamic secrets for different platforms. During the POC, HashiCups
engineering teams will store static secrets in the Vault Key Value (k/v
)
secret engine.
Database plugins
Database plugins are an extension of secret engines that allow you to create
dynamic secrets. Alice and Danielle have selected the postgres
database secret
engine. The database
secret engine works similar to other dynamic secret
engines to generate time-boxed credentials to supported services. This will
allow HashiCups to eliminated long lived, static credentials - reducing the
security impact on leaked credentials.
Plugin lifecycle
The lifecycle for plugins differs slightly between built-in and external plugins as detailed in the following sections.
Built-in plugins
HashiCorp maintains a set of core plugins built into the Vault binary. The team can enable and use these plugins without first registering them. These built-in plugins are also not individually upgradable, but are instead upgraded whenever Danielle upgrades the Vault binary version.
Built-in plugin workflow
The team can use any of the built-in plugins by following a workflow that includes these steps.
Enable plugin instance at the desired path.
Configure plugin settings.
Create roles for database type plugins.
Plugins of the database type make use of roles, which can have ACL policies attached to help enforce role based access control.
Upgrade Vault binary to upgrade plugins.
Tip
Always review the Vault CHANGELOG and upgrade guide documentation for the target upgrade version before performing any Vault upgrade.
Disable plugin instance at time of deprecation or sunset.
Danielle can't disable or de-register a built-in plugin from the catalog, but they can disable an enabled instance of the plugin so that it is no longer usable on the originally configured path.
External plugins
In addition to the set of built-in plugins, Vault can also use external plugins, which run as sub-processes that share the user and environment variables of the server. Vault loads these external plugins from a predefined path specified in the server configuration file.
This means that Danielle can't use an external plugin with their Vault dev server because the dev server doesn't support configuration files. They need to use a self-hosted Vault server with configuration file to develop and test the external plugin.
Tip
It is possible to operate Vault as a single node server with configuration file for the purposes of development or testing.
The following Vault configuration example shows usage of the plugin_directory
option that Danielle or Oliver in operations can define to specify the location
where the server can expect to find plugin binaries.
1 2 3 4 5 6 7 8 9 1011121314151617
In this example, the Vault server would search for external plugins in the path /vault/plugins
.
Tip
The Vault server process user must have access to execute the plugin binary from
plugin_directory
value defined in the server configuration. Ensure that the
process owner user account has read access to the binary path and execute
permission on the plugin binary file.
External plugin workflow
The external plugin lifecycle workflow includes these steps:
Configure Vault server with the
plugin_directory
option and reload Vault configuration to enable the option.Place the plugin binary in the path specified as the value of the server's
plugin_directory
configuration option.Use the register plugin API or Vault CLI to register the plugin binary file using its SHA 256 summary value with the Vault plugin catalog.
Enable plugin instance at the desired path.
Configure plugin settings.
Create roles for database type plugins.
Plugins of the database type make use of roles, which can have ACL policies attached to help enforce role based access control.
Upgrade the plugin binary for upgrades.
Disable plugin instance at time of deprecation or sunset
Containerized plugins
Vault can directly execute external plugin binaries registered in the catalog, but what if the team wants to isolate plugins to ensure higher levels of security?
Vault can also help in that case too, as it supports executing containerized plugins within the following constraints:
The Vault server must be running on Linux, with access to the Docker Engine API.
The server environment must have a container runtime environment, like gVisor.
The developer or operator must manually pull all required container images into the server environment.
Once Danielle has an established Vault server environment that meets these constraints, they can deploy the containerized plugin and register it with the plugin runtime API or CLI.
Vault manages containerized plugin lifecycle in the same way it does for binary plugins, and restarts stopped plugin containers as needed. It also labels each plugin container with metadata to help identify the container, including the cluster ID, Vault's own process ID, and the plugin's name, type, and version.
Summary
Vault supports a wide range of plugins to enable different use cases. Vault includes several plugins as part of the Vault binary. Some plugins are available from and supported by HashiCorp. You can also extend native functionality through community or custom developed plugins.