I know that I’m hesitant to jump on the Vault ship now with the trend of putting more features behind closed doors. At least if they had a pricing page I wouldn’t be dependant on whatever their sales department would want me to cough up at every new term. Assuming Vault becomes a center piece of my infra, to me that’s a scary thing to be building a business on.
Edited for clarity.
Does anyone have any insight how Vault would compare for these tasks? Or if I'm going down the totally wrong road?
Vault is overkill for what you need and would create more maintenance and operations overhead.
One interrogation I have is that if I ever want to integrate cloud auto unseal into Vault and make a pull request, what is the incentive for Hashicorp to allow the merge? Wouldn’t it only remove value from their paid product?
* Identity / Group Management. This sounds like a minor bullet point, but an incredible amount of work went into supporting a unified identity system that could span multiple external identity brokers. Our goal was to allow Vault to act as a broker between many Identity Providers and apply a consistent access control and group management scheme to all of theme. This was something we originally landed in Enterprise with 0.8 so that we could bake it with a smaller number of customers and have since brought to open source as we feel more confident in the implementation and APIs.
* GCE integration. This is part of our ongoing partnership with Google and our goal of natively integrating Vault with all the common platforms our users want to use.
* K8S integration. Again, this is about the last mile integration into the platforms users want and is in the open source.
* Oracle database integration. The database backend provides dynamic secret functionality across a number of RDBMS and NoSQL systems, and we are continuing to broaden the supported systems.
* RSA support for transit encryption. The transit backend allows Vault to do key management and cryptographic offload, and we are continuing to extend the algorithms and operation types that are supported.
* Lazy loading of leases. Common feedback from our large scale users was that failover could take many minutes. We've improved the loading of leases and other metadata to be asynchronous resulting in a dramatically faster failovers for large scale deployments.
* Lots of other bug fixes and minor improvements.
This is only a small sample of what has been added in the Vault 0.8.3 and 0.9 releases as open source. In the last 6 months, we’ve added more to the OSS than ever before, because Vault Enterprise has allowed us to grow the team. By adding a small subset of features to our Pro and Premium Enterprise offerings we are able to continue developing Vault, and we take a similar approach for our other tools. I totally understand the frustration about our opaque pricing, and this is because we are still making pricing adjustments as we refine our fit and better understand the many different use cases customers have.
Mitchell has publically stated and I'll repeat, that our goal is to publish both our framework of determining what is open source versus commercial (largely a focus on compliance, governance, and collaboration) as well as our public pricing. Our goal is to be as transparent as possible, while still accommodating the need to understand product/market fit, refine pricing, and be a solvent business.
I'd almost certainly have personally pushed for purchasing your software a number of times, but simply refuse to play the "how much can you pay" game.
I'll answer your question directly at the end because I think context is everything. We're not trying to hide anything so I think being transparent will help here. If you want to just read direct answers to your questions you can scroll to the bottom but I think the context is extremely important.
We actually haven't dramatically changed pricing in the past 12 to 18 months (except for one product in particular, but its not Vault). And importantly we don't change pricing per deal: of the many deals we've closed with Vault in the past year, the price variance is extremely low. What we have done is dramatically changed the number and the quality of features. This is important.
18 months ago the only Vault Enterprise feature was HSM integration. At the time, the price of Vault Enterprise would've sounded outrageous. Part of getting on the phone with people is us educating them what they're getting today, as well as making sure they understand why its priced so high: features that are coming. Today, Vault Enterprise has a dozen or more major differentiating features and its clear what the value is that you're getting.
We of course have a long roadmap of big features and improvements to continue making to Vault. But we're now selling Vault successfully at a price that will sustain the company and as we build more features we can put them in at the same price point and/or (both) successfully move features back into open source.
There is a 2nd aspect to this: reseller ecosystems. We're now building an ecosystem of reseller partners around the world. If we have resellers, we absolutely have to a fixed price list and it is also difficult to change that (up or down). We announced our reseller program in the early fall this year and as part of that we are now distributing price lists to resellers, but the program is growing at a controlled pace currently to continue testing the waters.
And finally there is a 3rd aspect to this: quickly calling us and buying. For our "Pro" tier (and sometimes but more rarely our "Enterprise" too), we close those deals on the phone in less than an hour and we do a LOT of these. For deals happening that fast, you can be assured there is no negotiation play going on. Our inside sales folks on those calls are reading from a fixed price sheet.
Publishing pricing is a bit of a lose-lose scenario early on: if you price too low, you can almost never raise prices (especially significantly) without a big backslash. If you price too high, you get a lot of immediate backlash and complaints. We probably would've fallen into this latter tier initially.
We also made an important split earlier this year by splitting into both a Pro and an Enterprise tier. We recognized two distinct use cases and we wanted to appeal to the former (Pro) without the extra cost of the latter, since the value wasn't there for them since they'd be paying for features that really were under a completely different use case.
Of course, pricing is different for anyone and we'll always have people that balk at various price points so I definitely won't claim we'll please everyone.
To answer your question directly, finally: we only have public pricing for our Vagrant products (the plugin and Vagrant Cloud). We're close to publishing pricing for Vault. But I hope you can see from the above the challenges we've been working through and that we have been working towards that. And finally, again, I appreciate the question.
But, in the end, they're a company and need to make some money. I think it's fine to do this with certain features to encourage companies to support software that can be integral to their infrastructure.
A little breakdown of free vs beyond-average-developer-reach here (this is an assumption from the 'Enterprise' moniker for a security product, lack of pricing page, and no mid-level tier; I do not know their pricing):
* Identity (included) - Free; useful for non-enterprise. Agree here.
* Seal Wrap (enterprise) - FIPS-2 from HSM and FIPS-compliant cloud, with evaluation to meet regulatory compliance. Much more useful for enterprise. I consider this safe to be considered an Enterprise feature.
* Control Groups (enterprise) - Allows use of approval workflow in access policies, requiring multiple party consent for access to individual secrets. This classification is somewhat dicey, in that it seems fairly core to what gave it a lot early attention (sharded seal/unseal keys - require x of n pieces of a key to unlock). And yet.. if you have an organization which requires 'bob' to ask both 'alice' and 'jane' whether they can see the database password for 10 minutes, you probably run a business or at least have a budget. Workflow customization is usually a great spot to put that pesky Enterprise label. In the end I agree its worth siloing.
* Sentinel integration (enterprise) - Integration with other Enterprise product. Agree here.
* Vault UI (enterprise) - Web interface to manage vault clusters. I disagree here. If we need to tier it, that's fine. Maybe even make it closed-source if that reduces the development overhead (though, I dunno, with 369 contributors I think they would benefit from it being partially open). Require enterprise license to enable enterprise feature. Hide them from users unless they are enterprise. Let anyone use it for non-enterprise features. You throw away one of the benefits of open source by making this closed, namely that if it's open then you make it more accessible to people. People who use the open source version are a lot more likely to advocate for the enterprise version.
* Cloud Auto-Unseal (enterprise) - On the fence on this one. Plenty of people would use this if it was available, I think, because cloud HSM are a lot more accessible than your hardware HSM. But I don't know that anyone would legitimately pay money for this if they weren't a business. It's kind of a 'nice to have' as non-enterprise user. Meanwhile business will definitely pay for this. I am willing to side on 'enterprise' here a little.
So, that's it for the headlines. Only one non-enterprise headliner, but in the end I only really disagree with one decision, and have a couple ambivalents.
Some of the other, more interesting (because people can actually use it) stuff, that is mostly free, is in the 'Other features' item at the end. Kubernetes Auth backend, RSA for transit backend (though I'm not sure of the benefit of this over other types of keys), Google IAM auth backend, etc.
All that said, I don't know if they will really see a lot more traffic for their blogs on social media if we keep seeing see a bunch of enterprise-focused release announcements with most of the regular work pushed to a changelog linked at the end.