Konubinix' opinionated web of thoughts

Debug Vault Plugin

Fleeting

Debug Vault Plugin with VS Code - Vault - HashiCorp Discuss

The plugin is a process that is spawned by Vault. To debug it, you must attach to it. But Vault actually launches the plugin twice. First time is to get some metadata about it (I guess). The second run is a lazy load when required.

I use Delve to debug. I am used to debug on the command line, in black and white (just like my hair color).

With that knowledge in hand, here is how I debug my plugin. YMMV.

I do the build-debug cycle on WSL2, Ubuntu 20.04. WSL1 does not work because of some kernel bug in ptrace. I edit the code in Windows (I use gvim, but VSCode is just another editor after all) Build your plugin with this command line go build -o vault/plugins/myplugin -gcflags “all=-N -l” cmd/myplugin/main.go I always disable and re-register a fresh plugin at each build-debug cycle. That will clear your plugin’s storage. It avoids weird bugs if you change the internal layout of your plugin’s storage. I did not any other way to test with seal_wrap. I do something like this: vault secrets disable myplugin vault plugin deregister myplugin vault plugin register –sha256=$(sha256sum vault/plugins/myplugin|cut -f1 -d " “) myplugin Run any command against your plug-in to make sure it is loaded by Vault, like vault list myplugin/path/load-me. Path resolution is done by your plugin so the path does not need to exist On the command line, attach to your plugin process with dlv attach $(pgrep myplugin) You should get a Delve prompt. Try this to get started: func myplugin.* b myplugin.my_function_I_want_to_debug c Then run a command that will trigger that breakpoint. Set/Export a large VAULT_CLIENT_TIMEOUT to your environment because you might end up looking at your code at the breakpoint for more than the default 60 seconds.

— https://discuss.hashicorp.com/t/debug-vault-plugin-with-vs-code/14806/2