We use Vagrant at work and I'm considering whether and how we could use more of their tooling. But I always want to know about the business model behind the tools I recommend before I recommend them.
Anyone?
The adjacent comment about Atlas is correct. Atlas itself is admittingly poorly marketed (something we're working on right this very moment) right now. The best way to describe how we make money is: we target the enterprise user and give them the features, integrations, and support they need in their regulated, legacy-encumbered, etc. environments. Atlas in particular is focused on giving enterprises a flexible application delivery pipeline that is opinionated in a certain way, but flexible enough to support their diverse environments (all at once: containers, VMs, physical machines. Windows, Mac, Linux. Etc.)
Due to our adoption we have the rare benefit of primarily letting open source adoption happen organically, and having large companies approach us as they get more serious about our software.
Vault, in particular, is a good example of this. Vault suffers from an issue where most impressive people who use Vault can't actually publicly say they use Vault. So we have a hard time talking about how widely adopted it is. The best I can give you is from what I said at our HashiConf keynote: "If you traded stocks, used a credit card, or did anything involving a bank, then you've interacted with Vault-secured data." As specific as I can be as to how widely spread Vault is right now.
Anyways, a digression from the original question: enterprises have interesting needs they're willing to pay for. We address those needs in enterprise products (Atlas, others that aren't public yet) and support. We don't have any SaaS-like "enter your credit card and pay us" (other than the Vagrant VMware plugin which predates all of this), and instead do deals with larger companies in a way that most of HN would likely perceive as old school in some sense. :)
Note when I say "enterprise" I'm not trying to exclude anyone. If you're a relatively small company (I didn't click your name to find out), then still feel free to email us any of your concerns and we should be able to either help you ourselves or route you in the right direction.
> As the founder of HashiCorp, I feel qualified to answer this.
And that's why I stick with HN. Really good citations :-)
> As the founder of HashiCorp, I feel qualified to answer this.
Thanks for taking the time to write down such a thoughtful reply. We are a relatively small company, but a lot of the products we make are enterprise-focused. I'll be sure to check out Atlas here in the near future.
* I would also bet they do consulting & support for companies that are using their products, and/or other automation advice. Whether that accounts for more or less revenue than Atlas, I have no idea :)
For example let's say I store an API token in Vault and want to use that in my Node.js application.
That means I can't do "var api_token = MY_API_TOKEN;" because the secret needs to come from vault and get refreshed, etc...
I'd imagine you will need some agent to manage the secret lease/expiry and for that to reload your entire application to ensure you don't end up with old secrets hanging around in the memory.
This topic is not addressed anywhere in the Vault documentation, I looked everywhere I could.
As for how you can more easily use it, we recommend [the now weirdly named] consul-template or envconsul. The former (https://github.com/hashicorp/consul-template) will put secrets automatically into files and watch for changes, update the file, and refresh the process. If you put the files onto a non-swappable ramdisk, then it is reasonably secure (relative to most things, less secure than deeply integrating with Vault).
Envconsul, on the other hand, injects secrets as environment variables to a process. This is also reasonably secure but users have to be aware of the various ways that env vars can be read out of process (/proc for example).
These are the two easiest ways to get started that allow Vault to be used with brownfield software. If you greenfield something, integrating Vault 1st class is the way to go for the most security and is what we're seeing bigger users go for.
[1] https://lyft.github.io/confidant/ [2] https://square.github.io/keywhiz/
Have you looked at https://vaultproject.io/intro/vs/index.html ?
Examples:
* Does it integrate with my existing infrastructure security policies? * Does it introduce a new set of principals for me to track and manage? * Are the configurations stored in a cleartext manner suitable for storing in version control? * Will the audit logs integrate with my existing audit log tooling? * Does it help or hinder continuous deployment? In other words, will my code be littered by conditionals to support non-prod jobs? * Can my devops team run this or does it require additional staffing? * How many layers is this adding between me and the security primitives offered by my platform (Windows AD, AWS IAM, etc) * Is it serverless, or does it require me to run additional servers? * How do I ensure continuity if the software is no longer actively developed? * Can it deploy secrets to dev and test environments in the same way? * What's the revocation story?
The answers to most of these questions for most of the tools that have made it to HN recently are not promising. For AWS the best choice seems to be using KMS directly and integrating your app with the declarative configuration tools AWS offers (IAM, CF, MFA).
Outside of AWS, Vault is the only one that I've seen which handles real-world end-to-end in a responsible way. For example, Vault is the only one that doesn't focus strictly on storing static values: Vault can integrate with services such as Postgres and SSH to dynamically provision time-limited credentials (https://vaultproject.io/docs/secrets/postgresql/index.html).
For example using Vault v. Keywhiz [1] since I made that comparison earlier, this page feels like it's written to say "Vault does X. Keywhiz does too." That's not really what I'm looking for; I can diff the two projects' features in that way as well, but I want to know why it is that Vault is better, i.e., why is it that it exists, what sets it apart from other solutions I can use? Why should I invest my time and port my infrastructure into this project? Should I expect it to be around or abandoned in a year if there is no adoption?
I probably should have clarified this in my original post; sorry for the confusion.
And yesterday I got it to build and run on SmartOS too, for extra security and scalability. Thanks to Hashicorp team for their work, and their commitment to open-source.