Skip to content

Hashicorp Vault CLI Part 3: Plugin Management and General CRUD Operations

By Sebastian Günther

—

The management of encrypted data and secrets in on-premise or cloud environments is a crucial task. Hashicorp Vault is a flexible tool, supporting a wide range of secret types and helping to provide short-lived access tokens to various systems.

All Vault operation and configuration tasks can be implemented with the Vault CLI tool. In an ongoing article series, all commands are explored systematically. This article continues commands from the configuration group. You will learn how to manage plugins, and how to perform general create-read-update-delete operations on any configuration or data.

The technical context of this article is hashicorp_vault_v1.21.1, released 2025-11-18. All provided information and command examples should be valid with newer versions too, baring update to the syntax of CLI commands.

The background material for this article stems from the official Hashicorp Vault documentation about Vault CLI and subsequent pages, as well as information from the binary itself.

Vault CLI Overview

The Vault CLI provides more than 30 commands. For systematically explaining and contextualizing each command, they can be structured as follows.

Groups and commands marked with a checkmark were covered in an earlier article, and the commands marked with an at sign are the focus for this article. In particular, this article covers all commands from the configuration group, except vault operator.

  • ✅ Initialization
    • server: Starts a server process
    • agent: Starts an agent process, a utility to communicate with a vault server to gain access to tokens
    • proxy: Starts a vault proxy process
  • Configuration
    • ✅ operator: Cluster management operations, including memberships, encryption and unseal keys
    • 🌀 plugin: Manage and install additional plugins
    • 🌀 read / list: Access stored configuration and secrets
    • 🌀 write / patch: Modify or create any data
    • 🌀 delete: Delete configuration data or secrets
  • Introspection
    • status: Show status information of the vault server
    • version: Shows compact version information and build timestamp
    • version-history: Shows detailed version information about all previously used vault server instances
    • print: Detailed view of the vault’s server runtime configuration
    • path-help: Detailed documentation about API endpoints
    • events: Subscribe to the event stream of a running vault instance
    • monitor: Print vault log messages
    • debug: Shows debug information of the connected Vault server
    • audit: Interact with connected audit devices
  • Vault Enterprise
    • hcp: Operate a managed Hashicorp Vault cluster
    • namespace: Interact with configured namespaces of the cluster
  • Authorization
    • policy: Manage policy definitions that govern all vault operations
    • tokens: General token management
    • lease: Manage current token leases, including renewal, revocation and TTL modification
  • Authentication
    • auth: Interact with configured authentication options
    • login: Authenticates access to a Vault server
  • Secrets Management
    • secrets: General configuration of secret engines
    • kv: Access to the essential key-value store
    • transform: Interact with the transform secrets engine
    • transit: Interact with the Vaults transit secrets engine
    • unwrap: One-time access to arbitrary encrypted data
    • pki: Access the private key infrastructure secrets engine
    • ssh: Initiates SSH sessions via the SSH secrets engine

Plugin Management Commands

Plugin is the technical name and architectural implementation of extended Vault functionality. They are separated into three groups: auth, database, and secrets. Each plugin exposes common functionality hooked with, and accessible by, the Vault CLI.

To manage plugins themselves, the same named command plugin can be used. Its subcommands either interact with the plugin catalog, a database that stores information about available plugins, or modify loaded plugins of a Vault instance.

plugin list

Show all available plugins that are configured in a Vaults instance plugin catalog. Naturally, on a fresh installation, these plugins reflect the complete list of built-in variants.

The following code blocks show which auth, database, and secret plugins are available in hashicorp_vault_v1.21.1.

> vault plugin list auth

# Log messages
Name          Version
----          -------
alicloud      v0.22.0+builtin
approle       v1.21.1+builtin.vault
aws           v1.21.1+builtin.vault
azure         v0.22.0+builtin
cert          v1.21.1+builtin.vault
cf            v0.22.0+builtin
gcp           v0.22.0+builtin
github        v1.21.1+builtin.vault
jwt           v0.25.0+builtin
kerberos      v0.16.0+builtin
kubernetes    v0.23.1+builtin
ldap          v1.21.1+builtin.vault
oci           v0.20.0+builtin
oidc          v1.21.1+builtin.vault
okta          v1.21.1+builtin.vault
pcf           v1.21.1+builtin.vault
radius        v1.21.1+builtin.vault
userpass      v1.21.1+builtin.vault

> vault plugin list database

# Log messages
Name                                 Version
----                                 -------
cassandra-database-plugin            v1.21.1+builtin.vault
couchbase-database-plugin            v0.15.0+builtin
elasticsearch-database-plugin        v0.19.0+builtin
hana-database-plugin                 v1.21.1+builtin.vault
influxdb-database-plugin             v1.21.1+builtin.vault
mongodb-database-plugin              v1.21.1+builtin.vault
mongodbatlas-database-plugin         v0.16.0+builtin
mssql-database-plugin                v1.21.1+builtin.vault
mysql-aurora-database-plugin         v1.21.1+builtin.vault
mysql-database-plugin                v1.21.1+builtin.vault
mysql-legacy-database-plugin         v1.21.1+builtin.vault
mysql-rds-database-plugin            v1.21.1+builtin.vault
postgresql-database-plugin           v1.21.1+builtin.vault
redis-database-plugin                v0.7.0+builtin
redis-elasticache-database-plugin    v0.8.0+builtin
redshift-database-plugin             v1.21.1+builtin.vault
snowflake-database-plugin            v0.15.0+builtin

> vault plugin list secret

# Log messages
Name            Version
----            -------
ad              v0.21.0+builtin
alicloud        v0.21.0+builtin
aws             v1.21.1+builtin.vault
azure           v0.23.0+builtin
consul          v1.21.1+builtin.vault
gcp             v0.23.0+builtin
gcpkms          v0.22.0+builtin
kubernetes      v0.12.0+builtin
kv              v0.25.0+builtin
ldap            v1.21.1+builtin.vault
mongodbatlas    v0.16.0+builtin
nomad           v1.21.1+builtin.vault
openldap        v0.17.0+builtin
pki             v1.21.1+builtin.vault
rabbitmq        v1.21.1+builtin.vault
ssh             v1.21.1+builtin.vault
terraform       v0.13.0+builtin
totp            v1.21.1+builtin.vault
transit         v1.21.1+builtin.vault

plugin info

Prints detailed information about a plugin.

For example, the built-in kv secret plugin is shown as this:

> vault plugin info secret kv

# Log messages
Key                   Value
---                   -----
args                  []
builtin               true
command               n/a
deprecation_status    supported
name                  kv
oci_image             n/a
runtime               n/a
sha256                n/a
version               v0.25.0+builtin

plugin register

In addition to the built-in plugins provided with the vault binary itself, several external and community plugins can be added too. This command assumes that the plugin is provided as a binary, executable file stored in the plugin directory path. Additional flags to this command control metainformations like the version, plugin parameters, and a sh256 sum of the binary file.

The documentation about Vault plugin ecosystem provides additional information and sources for different plugin types.

plugin deregister

Removes a manually added plugin from the local catalog, either completely, or a dedicated version by passing the same named flag to the command.

It is not possible to remove a built-in plugin - an attempt is shown in the following:

> vault plugin deregister secret aws

# Log messages
Plugin "aws" (type: "secret") is a built-in plugin and cannot be deregistered

plugin reload

Re-initializes a configured plugin with the default options. This method is helpful when a newer version of a plugin is installed, and should be loaded without a shutdown of the complete Vault instance. All type of plugins can be reloaded as shown by the following example.

> vault plugin reload -type=secret -plugin=kv

# Log messages
Success! Reloaded plugin: kv

plugin reload-status

Shows metainformation about a concrete reload action, requiring the reload ID.

However, I could not find information about where to obtain a reload ID. And when running the command with an example ID from its documentation, the following error message is returned.

> vault plugin reload-status d60a3e83-a598-4f3a-879d-0ddd95f11d4e

# Log messages
Error retrieving plugin reload status: Error making API request.

URL: GET http://127.0.0.1:8210/v1/sys/plugins/reload/backend/status?reload_id=d60a3e83-a598-4f3a-879d-0ddd95f11d4e
Code: 404. Errors:

* enterprise-only feature

plugin runtime

This subcommand interacts directly with the running Vault instance plugins, and supports the sub-subcommands info, list, register and deregister which work similarly as their plugin catalog counterparts.

At the time of writing, the runtime command only supports custom plugins of type container as the following explanation from the CLI itself exposes:

> vault plugin runtime --help

# Log messages
Usage: vault plugin runtime <subcommand> [options] [args]

  This command groups subcommands for interacting with Vaults plugin runtimes and the
  plugin runtime catalog. The plugin runtime catalog is divided into types. Currently,
  Vault only supports "container" plugin runtimes

CRUD Operations

Hashicorp Vault exposes its complete functionality via API endpoints. And these endpoints can be operated via CRUD operations directly via the CLI. Internally, the CLI will transform the commands to confirm with the REST-API design of its endpoint, issuing HTTP requests.

To see the CRUD operations in action, two different types of data are covered in the following examples: A kv-v2 secret engine, and their appropriate access policies.

The kv-v2 secret engine will be mounted at /kv-secrets with the following command.

> vault secrets enable -max-lease-ttl=1h -path=kv-secrets kv-v2

# Log messages
Success! Enabled the kv-v2 secrets engine at: kv-secrets/

write

The write operation creates a new dataset.

To add a new kv-v2 secret, the path structure <mount_path>/data/<secret_name> must be used. Furthermore, the data needs to be stored in a file, and provide via the @ sign.

First, create a file with the following content:

{
  "data": {
    "admin": "CjE3OjAwIEtvY2hlbiwg"
  },
  "options": {
    "cas": 0
  }
}

Second, write the secret config-db-credentials with the following command:

> vault write kv-secrets/data/config-db-credentials @secret.json

# Log messages
Key                Value
---                -----
created_time       2025-12-16T11:03:52.838769Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

Next, create a read-only policy for non-admin users:

vault write sys/policy/kv-secrets policy='path "kv-secrets/*" {
  capabilities = ["read"]
}'

# Log messages
Success! Data written to: sys/policy/kv-secrets

read

The read operation prints stored data.

To access the secret, the path kv-secrets/metadata must be used in the request:

> vault read kv-secrets/metadata/config-db-credentials

# Log messages
Key                     Value
---                     -----
cas_required            false
created_time            2025-12-16T11:03:52.838769Z
current_version         1
custom_metadata         <nil>
delete_version_after    0s
last_updated_by         map[actor:root client_id:0DHqvq2D77kL2/JTPSZkTMJbkFVmUu0TzMi0jiXcFy8= operation:create]
max_versions            0
oldest_version          0
updated_time            2025-12-16T11:03:52.838769Z
versions                map[1:map[created_by:map[actor:root client_id:0DHqvq2D77kL2/JTPSZkTMJbkFVmUu0TzMi0jiXcFy8= operation:create] created_time:2025-12-16T11:03:52.838769Z deleted_by:<nil> deletion_time: destroyed:false]]

> vault read sys/policy/kv-secrets

# Log message
Key      Value
---      -----
name     kv-secrets
rules    path "kv-secrets/*" {
  capabilities = ["read"]
}

list

While the read operation returns a single entry with complete details, calling list shows all defined entries with their names.

Assuming additional secrets were added to the kv-v2 secret store:

> vault list kv-secrets/metadata

# Log messages
Keys
----
app-credentials
config-db-credentials
config-portal-credentials

The same operation applied to the policies returns the complete set of all system and user defined objects.

> vault list sys/policy/

# Log messages
Keys
----
default
kv-secrets
root

patch

To update configuration parts of an existing entry, the patch command can be used.

To update a kv-v2 entry, the payload file needs to be changed as follows:

// change cas value to the current version of the secret
{
  "data": {
    "admin": "CjE3OjAwIEtvY2hlbiwg"
  },
  "options": {
    "cas": 1
  }
}

Then perform the update:

> vault patch kv-secrets/data/config-db-credentials @secret.json

# Log messages
Key                Value
---                -----
created_time       2025-12-16T13:29:38.764223Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            2

And for the policy, the access rights shall be expanded.

However, executing the patch command returns an error - policies cannot be changed, merely redefined.

> vault patch sys/policy/kv-secrets policy='path "kv-secrets/*" {
  capabilities = ["read", "create"]
}'

# Log messages
Error writing data to sys/policy/kv-secrets: Error making API request.

URL: PATCH http://127.0.0.1:8210/v1/sys/policy/kv-secrets
Code: 405. Errors:

* 1 error occurred:
 * unsupported operation

The redefinition takes the form of another write command.

> vault write sys/policy/kv-secrets policy='path

# Log messages
"kv-secrets/*" {
  capabilities = ["read", "create"]
}'
Success! Data written to: sys/policy/kv-secrets

delete

When data is not required anymore, a delete command safely erases it.

To delete a stored secret in the kv-v2 store:

> vault delete kv-secrets/metadata/config-db-credentials

# Log messages
Success! Data deleted (if it existed) at: kv-secrets/metadata/config-db-credentials

And to delete the policy:

> vault delete sys/policy/kv-secrets

# Log messages
Success! Data deleted (if it existed) at: sys/policy/kv-secrets

Conclusion

All operational and configurational Vault tasks can be implemented with the vault binary. In this article, CLI commands from the configuration group were explored. First, you learned about the plugin command, which gives either access to a static database, or reflects respectively modifies the runtime status of plugins. Second, you learned about the generic CRUD commands write, read, list, patch and delete, which can modify core Vault configuration data as well as data stored in its activated plugins.