Hashicorp Vault for file storage?

trevorgrayson picture trevorgrayson · Jan 16, 2016 · Viewed 8.5k times · Source

I'm expecting to save a lot of documents of considerable size, from 1M to potentially multiple orders of magnitude larger. I know Hashicorp's Vault is great for secret keys and smaller values. I would love to get the "glass break" functionality and the key rolling functionality from it.

Has anyone done any benchmarking of Vault with large secrets? I'm presuming I'm not going to have trouble with the number of secrets in the vault?

Answer

neokyle picture neokyle · Jan 21, 2019

The performance would depend entirely on the storage backend you use. If your doing something like a repo for secrets with fine grain access control, then you probably wouldn't need HA so filestore backend would be fine, and you could use SSDs to have fine performance.

I would advise against using the Transit backend to encrypt and store files for several reasons:

1.) Migration from 1 storage backend to another (like file storage to an HA backend) is relatively easy/straight forward if you're only using KV, when you use the advanced features of vault, it's not always easy/possible. (BTW migration between backends is a relatively new feature I noticed it in Vault 1.0++)
2.) You can list all secrets stored in KV store and you have versioning. You'd have to code this yourself if you went with Transit.
3.) Transit wasn't designed for that, wrong tool for the job, KV is what you're looking for.


If you want to store large files inside of Vault:
Don't use Consul by itself (or you'll be limited to 0.5mb max size)
It should be possible to start with:

storage "file" { path = "C:/Vault" }

and then transition to S3/Azure Blob + Consul, when you need HA

ha_backend "consul" {...}
storage "s3" {...} 

(I'd recommend you do a PoC to confirm you can transition.)

Note: In practice I've found I'm never storing a secret larger than 0.375mb, so Consul by itself is fine. It's a simpler setup and you can do point in time live snapshots. Plus if you find you need the space in the future, you can just migrate your storage backend.


Also you should still avoid large file sizes for the following reason of inconvenience/overhead:
Vault is a Key Value store that uses the following syntax:

vault kv put secret/KEY key=value
vault kv put secret/dev config.json=base64'dstring

If you want to store a binary file or multiline string you need to base64 it to convert it to a 1 line string, and store that as the value. Well if you end up with a 300mb file, you'd have to make a 400mb base64 encoded string. (Since base64 encoding adds a consistent 33% overhead)

If you really wanted to do this in a scalable way:
I think the ideal way to do this would be to store symmetric encryption/decryption keys + Encrypted File Location in Vault. Use Consul as your Vault Backend. Use S3 as your File Storage.

If I was going to do it I'd host Consul + Minio/Rook/Ceph(Self Hosted S3) on Kubernetes + 2-3 vault servers either on Kubernetes as well, or for top security on Intel SGX enabled boxes with Vault SCONE Secure Enclaves (encrypted ram) to protect against Spectre/Meltdown/0 day root access memory dump exploits. And store the files symmetrically encrypted on your DIY S3, and the decryption keys + file location references in Vault, and then some middle ware to abstract that out. (I only suggest self hosted S3 so you can be multi cloud + 100% Infrastructure as Code, but yeah mix and match parts of the design to your requirements.)