How does a custom secret backend benefit from Vault's encryption?

Vault
1

I need to write a custom secret backend. Conceptually, it will look like the transit backend with an API that looks like this:

  1. Create a key that will stay in the backend
  2. Encrypt the data using a proprietary algorithm (but don’t store it)
  3. Decrypt the data (you must specify the key identifier)

Key generation and encryption are custom. I have the mock sample in Vault guides running, but it stores the secrets in a Go map, in memory. I want them persistent and encrypted.

I was reading through transit source and I need some help… Is there an internal piece of Vault that will provide me with a Go interface (or similar) that I can call to store the secret my custom backend generated or must I handle that myself ?

2

Great question! When you implement API endpoints, for each endpoint you’ll need to feed it one function that has a signature essentially like this. One of its parameters is the “req” object, which has a “req.Storage” attribute. Storage has a Get and a Put function and treats everything as a key/value pair. It abstracts away the need to worry about what kind of storage is configured in any particular Vault cluster. Whether someone’s using Consul, S3, or a SQL database, it will just work. There is also a caching layer underneath it, so you don’t need to worry about caching high-traffic items yourself.

3

Thanks!

For the record, your link lead me to Storage.go:

// Storage is the way that logical backends are able read/write data.
type Storage interface {
    List(context.Context, string) ([]string, error)
    Get(context.Context, string) (*StorageEntry, error)
    Put(context.Context, *StorageEntry) error
    Delete(context.Context, string) error
}