Vault Secrets in a Browser Plugin

As the first engineer on the brand-new Vault Developer Experience team, it’s my goal to gain an understanding of the pain points developers run into when working with the product. This means that I often try out the same HashiCorp Learn tutorials that our users do.

Today I’ll be talking about my experience with the new summer activity on the Learn site: the Vault Secrets in a Browser Plugin Challenge!

»Getting to Know the Vault API

Having used Vault as a practitioner in a previous role, it’s been fascinating to realize that there are so many more ways to use Vault than I’d ever known about. I had used only the Vault CLI and then envconsul or consul-template to feed secrets into my application. While this is also a valid approach with minimal code change, it meant I hadn’t used the HTTP API much, which is the communication method used in this browser extension tutorial.

I found the documentation of the HTTP API to be quite extensive, and for languages like JavaScript that do not yet have an official Vault client library from HashiCorp, directly communicating with the API is the best choice for integrating with Vault.

Here’s a tip: If you ever know the Vault CLI version of a command and wish you knew how to do it in the API, just add the -output-curl-string flag to your CLI command and Vault will print the equivalent curl request without actually executing the command.

I’ve found that the more familiar I become with the HTTP API, the quicker I know what to look for when browsing the package documentation for the Go client as well.

»Authenticating to Vault

This tutorial was my first time trying out the Userpass auth method. It’s a great fit for a browser extension when you don’t have access to things like environment variables or cryptographically signed server identities like you might use with Vault’s AWS or Google Cloud auth methods. Users are created in Vault with specific policies attached to encourage least privilege access.

The question of how to securely introduce that first Vault client token to your backend application can require some consideration, so it was refreshing to be able to use this simple Userpass method.

For server-side applications, Vault Agent is becoming a popular pattern for making authentication to Vault simpler.

»Working with Secrets

One of the great things about Vault is that it can be extended with a variety of official and community-maintained backends for secret storage and authentication.

This challenge used the standard kv-v2 secrets engine, but unlike in some of the other tutorials, I noticed that this time the secrets engine was mounted to the contextually named path vaultpass. This shows that you can have multiple kv-v2 secrets engines mounted to different paths in Vault, such as having a payment-svc/ path for the key-value secrets of one microservice-based application, and shipping-svc/ for another.

One important thing I learned about the kv-v2 engine is the fact that the vault kv CLI commands automatically append /data to the secret path as a convenience for those who upgraded from kv-v1. However, when working with the Vault API, you need to always refer to a secret by its full path (which means including the /data in the path yourself).

So when creating a new secret via the CLI, you’ll do vault kv put vaultpass/foo, which actually creates a secret at vaultpass/data/foo, and then when you try to read the secret using the Vault API in your code, you will need to do a GET on vaultpass/data/foo.

»Conclusion

This challenge was a fun way to experiment with Vault outside of the usual backend service environment.

I’m looking forward to improving the client libraries and CLI commands so that they become just as intuitive to use as the HTTP API was here, and I’m excited to learn more about other creative ways that users integrate with Vault. Check out the Vault Secrets in a Browser Plugin Challenge tutorial for inspiration.