Inspect data in BoltDB
Vault clusters configured to use Integrated Storage (Raft), the cluster persists all encrypted data to a bbolt key/value store.
You can inspect data in clusters which use Integrated Storage by operating Vault in recovery mode and using the sys/raw
API as described in Inspect Data in Integrated Storage. That process is useful for troubleshooting issues in operable Vault clusters and provides the greatest detail possible for issue resolution and troubleshooting.
You can also use information in this tutorial to access low level details from the database by directly examining the database files.
This is a tool of last resort, but it's helpful when you suspect database corruption, when a Vault cluster is inoperable, or for querying the free list.
Warning
DO NOT inspect data in-place on a running production Vault cluster with the techniques and tools described in this tutorial. Use a copy of the database files as required instead.
Prerequisites
To follow the examples in this tutorial, you need the following.
- A Go development environment to install the tools
Learn monitoring repository
You can get some example Vault database files to use when following along in this tutorial by cloning the learn-vault-monitoring repository or downloading a zip file from GitHub.
Clone the repository:
Or, download the repository contents:
Tip
If you downloaded the zip archive, be sure to unzip the file before proceeding.
This repository has supporting content for Vault learn tutorials. The content specific to this tutorial is in a subdirectory.
Change the working directory to
learn-vault-monitoring/example-raft-database
.Examine the directory structure of a data directory from a Vault server configured to use Integrated Storage.
This is the most minimal example, with a
raft
directory containing the cluster coordinating data inraft.db
, and avault.db
that holds the Vault operational data and secrets.Were this from a busier cluster, the
snapshots
directory would also contain some snapshot data.
With your example Vault data in place, you are now ready to inspect the files with the bbolt CLI and via a web browser with boltd.
Notes about storage architecture and terms
bbolt
uses a database file represented by pages. The first 2 pages store important database metadata, while the third page holds the "free list". The free list keeps track of pages marked as deleted, which are free for writing to again.
All remaining pages contain the buckets. All keys and values get stored in buckets, represented by B-tree data structures.
Using the bbolt CLI
The bbolt
CLI tool is part of the bbolt distribution.
Install
bbolt
into your$GOBIN
path whereGOBIN
is the directory wherego install
andgo get
will place binaries after buildingmain
packages.Check the
bbolt
installation to make sure it's on your$PATH
.Tip
If you meet with an error instead, ensure that the
go install
succeeded and thatbbolt
is in your$PATH
withwhich bbolt
.
Check database file integrity
One useful feature of bbolt
is the check
command. It verifies that all pages are accessible or marked as freed, and also checks that no pages are double referenced.
If you suspect issues with the database file, the first thing you can do is check its integrity.
The expected successful result is OK
.
If there are issues with the database, the tool will emit errors.
Statistics
You can also gather essential statistics about the database.
The stats command performs an extensive search of the database to track every page reference. It starts at the current meta page and recursively iterates through every accessible bucket. The command will emit errors if the database is corrupt.
From the example output, you learn that this database consists of 1314 key/value pairs and that there have been 1238220 bytes actually used for the leaf data.
More information is available from the help output with bbolt stats -h
.
List buckets
The Vault database starts with 2 buckets: config
and data
.
You can list them like this:
List and get keys
The goal of this section is for you to learn how to list keys in more detail.
List all keys present in the
config
bucket.The keys in the
config
bucket contain information about the latest cluster configuration, including a list of cluster members, latest index state, and whether the local node is a voter.Get count of the keys in the
data
bucket.The
data
bucket holds the majority of all data in Vault, and should also represent the majority of the keys found in the database.Since there are several keys present in this example, you can explore a smaller subset of the keys contained in the
data
bucket.List just the keys which make up the Vault core information.
These keys represent the Vault core, and Vault uses them internally to contain critical configuration information.
A more practical example than demonstrating exploration is to find the count of valid tokens in the current Vault data. You can do so by counting the entries under the path
sys/token/id/
.Another practical example is confirming the existence of a particular policy by name. If for some reason you need to verify that the cluster has a particular named policy, you can list all names.
Note
Along with listing keys, you can get key values for a limited subset of keys which allow unauthenticated access. Vault encrypts all user supplied inputs at rest, and you will not be able to decrypt them using the techniques and tools in this tutorial.
One such exception is the list of cluster members found in the
latest_config
key in theconfig
bucket.Get the
latest_config
key values.These are the 5 servers which made up the Vault cluster these data are from.
Warning
Attempting to get key values results in binary data, which when directed to the standard output can result in terminal session issues. You might instead consider redirecting the output to a file and examining the file in an editor that can handle binary files.
If you have concerns about your terminal session, you can also try testing the output with file
. Using the earlier examples from listing keys making up the Vault core, you can check if it might be safe to view the server's seal configuration in core/seal-config
.
This is JSON data that provides some helpful information about the server's seal configuration.
While generally not as useful as the vault.db
, you can also inspect data in the raft.db
. For example, to find the cluster member which was the last candidate voted a leader, you can check the LastVoteTerm
key in the conf bucket.
Pages and the free list
This section is most useful for users of Vault 1.8.0 and higher who wish to learn more about the free list status.
To begin, list the first 2 pages.
The list has 2 meta pages. You can use the most current one with the highest transaction ID value to find the freelist location.
Check the transaction ID for page 0.
Check the transaction ID for page 1.
Page 0 has the highest Txn ID value, and is the meta page you should examine to find the root of the tree. Note that its
Freelist
value points to the correct freelist page ID.List page 0 to find the root page ID.
The root page ID is 235, and from here you can walk the entire tree of pages. Begin by listing page 235.
The output shows the pages representing the
config
anddata
buckets.You can retrieve the data page at 212.
Page 162 represents a username and password auth method lease id value. You can list this page ID to view its contents.
Now you can view the leaf page for an individual lease id, for example the one at page ID 64.
The result is a key
sys/expire/id/auth/userpass/login/lab-user-1/h04a2ea39ac9f9b5fca932aab0f7ed25140db7e06e620926ffb43530a6911b61b
with a long hexadecimal string representing the encrypted value.You can explore the entire tree this way.
With the freelist itself, recall that meta page 0 was the page ID containing the most recent Txn ID. Check the Freelist value for meta page 0.
The freelist page ID is 174. Go ahead and list it next.
Note the presence of 31 pages in the freelist.
The other way to verify a page is free, is to check for its page ID in the pages output, and ensure that
free
appears next to it.Confirm that page 313 is free.
Using the boltd web UI
Note
You will just read from the database using this boltd
workflow, and the tool doesn't have any potentially destructive functionality.
Another tool from the original BoltDB project, boltd exists to explore the database visually.
You can use boltd by attaching it to a Vault database and connecting a web browser to the web UI it exposes.
Install
boltd
.Start
boltd
and attach it tovault.db
.Access
http://localhost:9000
in a browser.The user interface is minimal, and defaults to displaying a view of pages.
You can use it to browse facets of your Vault data like the
bbolt
CLI tool, by navigating links or jumping directly to page numbers in the Go to page input.You can also explore a page usage histogram by selecting Show Page Usage.
Summary
You have learned about how to inspect data in the bbolt database file for a Vault server using the Integrated Storage backend. You learned about 2 tools which you can use for this purpose along with caveats around their usage.
You can learn more about inspecting Vault data in Inspect Data in Integrated Storage and Inspecting Data in Consul Storage.
Clean up
When you finish the hands on lab, you can clean up by changing to the parent directory and removing the learn-vault-monitoring
directory.