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?

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.

1. Enable plugin instance at the desired path.

2. Configure plugin settings.

3. 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.

4. 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.

5. 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.

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.

api_addr          = "https://127.0.0.1:8200"cluster_addr      = "https://127.0.0.1:8201"cluster_name      = "learn-vault-cluster"disable_mlock     = trueplugin_directory  = "/vault/plugins"ui                = true listener "tcp" {address       = "127.0.0.1:8200"tls_cert_file = "/tmp/vault-cert.pem"tls_key_file  = "/tmp/vault-key.pem"} backend "raft" {path    = "/tmp/vault-data"node_id = "learn-vault-server"}

In this example, the Vault server would search for external plugins in the path /vault/plugins.

External plugin workflow

The external plugin lifecycle workflow includes these steps:

1. Configure Vault server with the plugin_directory option and reload Vault configuration to enable the option.

2. Place the plugin binary in the path specified as the value of the server's plugin_directory configuration option.

3. 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.

4. Enable plugin instance at the desired path.

5. Configure plugin settings.

6. 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.

7. Upgrade the plugin binary for upgrades.

8. 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.