Upgrading Vault plugins
External plugin upgrade procedure
The following procedure details steps for upgrading an external plugin that has been registered to the catalog on a running server. This procedure is applicable to secret engines, auth methods, and database plugins.
Vault executes plugin binaries when they are configured and roles are established around them. The binary cannot be modified or replaced while running, so upgrades cannot be performed by simply swapping the binary and updating the hash in the plugin catalog.
Instead, you can restart or reload a plugin with the
sys/plugins/reload/backend
API. Follow these steps to
replace or upgrade a Vault plugin binary:
Register version 1 of
my-db-plugin
to the catalog. Skip this step if your plugin is already registered.Mount the plugin backend. Skip this step if the backend is already mounted.
Register version 2 of
my-db-plugin
to the catalog under the same plugin name, but with updated command to run version 2 ofmy-db-plugin
and updated sha256 of the new binaryTrigger a plugin reload to reload all mounted backends using that plugin or a subset of the mounts using that plugin with either the
plugin
ormounts
parameter respectively.
Until step 4, the mount will still use version 1 of my-db-plugin
, and when
the reload is triggered, Vault will kill my-db-plugin
’s process and start the
new plugin process for my-db-plugin
version 2.
Important: Plugin reload of a new plugin binary must be performed on each Vault instance. Performing a plugin upgrade on a single instance or through a load balancer can result in mismatched plugin binaries within a cluster. On a replicated cluster this may be accomplished by setting the 'scope' parameter of the reload to 'global'.
Overriding built-in plugins
Background
Vault's auth methods and secrets engines are structured as plugins, but this design is not obvious since many of them are built into Vault.
You can see them with the Vault plugin list command, for example, the list of Secrets engines:
This will list all Secrets engines, internal (built-in) or external. To find out if a plugin is built-in, we can query its info:
Because these built-in engines are plugins, they can be overridden. This can be a useful way to leverage features or bug fixes in plugins that are newer than the version of Vault you're using, without updating or even restarting Vault, and while retaining the data for your existing mount.
Assume you have a new version of Azure Secrets and the binary is called "azure_new". The binary needs to be in the plugin directory and can then be registered as either a distinct plugin, or overriding the current one.
Important: do not disable (vault secrets disable ...
) any mount that has
data you're interested in; that would erase storage. For the in-place update,
register a new plugin atop the built-in one and leave any mounts alone.
Procedure for overriding built-in plugins
The syntax is the same as an external plugin, with the difference being you name it the same as a built-in:
"-command=azure_new" is the name of the binary, "secret" is the plugin type, and "azure" is the name of the built-in plugin that we're overriding. We can verify that the override is in place:
At this point we've overridden the built-in, but it is not yet actively handling requests. For that we run:
Procedure for reverting after overriding a built-in plugin
To revert the override, first deregister the plugin:
Next, verify the override has been reverted and we are now using the built-in plugin:
Finally, reload the plugin:
Caveats to overriding built-in plugins
- As mentioned earlier, disabling existing mounts will wipe the existing data.
- This type of upgrade affects all uses of the plugin. So if you have 5 different Azure Secrets mounts, they'll all change after the replacement. If you don't want that, you'll need to register the plugin under a different name and start with a fresh mount.
- In most cases, data upgrade and downgrade is not an issue. If the "new" version introduces new data and you downgrade, the "old" version will ignore the extraneous data. In some cases upgrading changes existing data in non-backwards compatible ways, so it is good to check whether this is an issue.