Within Vault, data is split into multiple backends. For example, when you write data to secret/foo, it is communicating with a different secret backend than when you read a PostgreSQL credential from postgresql/creds. Each backend is given a restricted view to the backend data. The backend at secret/foo can never access the data at postgresql/creds, for example. This isn’t just an ACL; the backends themselves simply do not have a way to address data from other backends. This ensures that even within Vault there is protection against malicious activity.
Anyone know how it actually does this? Does it run each backend in a container or VM or process? What is to stop, for example, a backend from walking the memory of the vault process?
Backends can’t be plugins, meaning they’d have to accepted via PR into the codebase. The only way to walk the memory space of Go is to use unsafe pointers and that would be really obvious in a code review. So unless you’re running a fork with custom backends that you wrote that happen to walk memory space with unsafe pointers, your data is going to be safe (from backends within Vault).
Thanks. IMO the wording is a bit misleading. Backends do have a way to address data from other backends, you just rely on humans from letting that code in. I would have expected a qmail-style architecture where each backend runs in a different process under a different user and communication is only through some sort of I/O channel.
But Vault looks quite nice. Clean.
I use Vagrant every single day and am not sure how I feel about this news. On one hand, I’m very excited that Mitchell will be able to spend his full time hacking and improving Vagrant. While I’m fine with Vagrant’s VirtualBox dependency, many people inside my company would love to use VMWare Fusion.
However, I’m concerned that he decided to base his company on Vagrant. Unlike antirez’s agreement with VMWare, Mitchell will have to derive revenue from Vagrant. What if the paid support / training doesn’t work? Will he be forced to release more code as paid add-ons instead of open source?
I hope that HashiCorp is very successfully, because I depend on Vagrant would hate to see the open-source version become crippled.
While I can’t tell the future, I can perhaps make you feel a bit better:
Due to the project’s licensing, if HashiCorp fails, then nothing really changes. Things just go back to the way they were before. With that said, I’m not raising any money, but I have enough saved up and I have enough open contracting bids that I personally should be fine for quite awhile. So I have “quite awhile” to make money.
As I said in the blog post, none of the add-ons will be required to run Vagrant. I have zero intention of making Vagrant cost anything for its usage today.
If I sway from this track, I expect the community will let me know.
Thanks for the reply Mitchell. I hope my post didn’t come across as too negative. Vagrant has become a part of my daily workflow, so I’m really pulling for HashiCorp to succeed. Best of luck, and I can’t wait for the next version of Vagrant.