Hey HN, I'm involved with this project, glad you found it interesting! Keep in mind it's still a _very_ early stage and not in a usable state. A lot of work in progress but also plenty of opportunities if you want to contribute.
Generally I would agree, but in this case, I was asking the person directly. I thought it would open an interesting discussion. I didn’t realize it would only result in a reprimand. <shrug>
Can’t say for everyone else, I personally see this as an opportunity to have a version of Vault that’s a bit less centered around the needs of a single organization.
I use HashiCorp Vault paid version to interface with an on premises HSM and for its FIPS compliance. I don’t know of any other software that is as lightweight and easy to use with an HSM as vault. We are using Vault to store the signed intermediate CA and automatically unseal Vault by storing the shards in the HSM (along with the Root CA). OpenBao wouldn’t solve this for me.
IBM, somewhat unofficially, is behind this recent fork. It might take a bit but if this fork gains traction then I would assume it gets this functionality.
Vault isn't easy to use at any kind of larger scale, though. It works well enough for small deployment infrastructure. Once you get to a certain size, all of HashiCorp's tech starts to show its poor, overengineered design in both performance and stability.
Could you elaborate a bit on what you consider large size? Did you have issues with Vault specifically? In my experience Terraform is the troublesome Hashicorp tool, not Vault.
Can I ask what regulatory domain you are in that requires on-prem HSM(vs cloud offering)? Also do you have a recommendation for on-prem HSM vendors that work well with Vault?
As much as I appreciate open source forks of things like this I’d rather just completely avoid vault if I can. This and consul are bits of software that make my life harder not better in the last few years.
I just replaced a clunky secrets manager with Mozilla SOPS and secrets-in-code that we keep in git encrypted and can version like any other file. I like this approach better than any alternative I've used so far.
SOPS is only an alternative for vault KV Store. Even then, it requires a lot of manual plumbing when you have operators and Terraform pushing secrets or keys into Vault KV.
To replace SSH Sign and Cert Authority or databases engines, both generating short-lived credentials on-demand, SOPS will not easily solve the issue.
If you only need KV Store, SOPS experience is way better than Vault and maintenance cost is low.
I readily admit it's not the same amount of :fu: as BuSL or whatever the fuck is going on over at Sentry but still :-( as compared to their much friendlier Apache 2
Well, that actually may be a good hint for me for a project I'm working on right now. I just fell of the chair when I realized how Vault charges for Enterprise "clients" (identities). This could be some fresh air.
Their pricing was laughable when we investigated it a couple of years back; I imagine it's only gotten worse since.
When I told them how ridiculously expensive it was for our use-case they suddenly managed to find a ~50% discount for us. That brought it down to just laughably expensive. Needless to say, we stuck with DIY.
It’s simple, has real client-side end-to-end encryption with no backdoors or compromises, is open source, and gives you a bunch of ways to manage and de-duplicate config.
Does envkey have a concept like Vaults secret engines? E.g Vault can automatically create temporary service accounts in AWS and GCP on demand. It can also create credentials in dbs like postgres on demand and rotate them. Also, can it be set up as a private CA and sign certs on demand?
It has a CLI that can be used for this purpose, but you would have to script it.
It also doesn’t have private CA or cert generation features, so if you need that then perhaps Vault or OpenBao would be a better fit. Though if you wanted to use EnvKey for simplicity and security reasons, you could potentially do your cert generation with openssl or another tool and then store the certs in EnvKey.
The featureset isn’t 1-to-1. EnvKey is more focused on config management and ease-of-use and not so much on slotting into more complex custom infra that needs eg a private CA. Though like I said it is quite flexible so you could make it fit into just about any system if you’re willing to do a bit of scripting.
Can you be more specific? It clearly mentions encryption-as-a-service and secrets generation as advantages of Vault, among others.
The point of the comparison is not to have an itemized list of every feature, but to compare the most important features and tradeoffs at a high level. It includes the disclaimer that Vault could be better for some more complex use cases (as I have also done here in my reply to you).
Your "Quick Compare" table has EnvKey winning on everything and doesn't mention anything about the fact it only does about 10% of what Vault does. The 90% of stuff that Vault does that EnvKey doesn't, gets one sentence in the advantages list and is downplayed in the conclusion.
A fair comparison would point out that EnvKey only does a small but important part of what Vault does, and explain why it does it well. Somebody who didn't know either piece of software, might read your comparison and get the false impression that they had equivalent functionality.
I don't expect you to agree, because that would mean you had to change the page to one which maybe doesn't convert so well.
I think your “90%” is quite unfair as EnvKey also has a lot of features that Vault doesn’t have, and the comparison is focused specifically on secrets management.
Vault has some long tail infra/enterprise features that EnvKey lacks and perhaps those are relevant to you, but a lot of them aren’t really secrets management per se, and for the core objective of managing secrets and config, EnvKey has a lot in terms of de-duplication, automation, and UI/UX/DX that Vault lacks. But for sure it depends on your use case.
Of course we are going to be somewhat biased, but everything in the quick compare section is backed up below. On security, EnvKey has end-to-end encryption; Vault doesn’t and requires trusting the host server. EnvKey is clearly easier to set up and use. EnvKey has an MIT license. EnvKey fits into a local development workflow and keeps config in sync much more effectively.
For sure you could write something that gives more attention to Vault’s specific strengths, but I stand by the comparison as broadly accurate.
Thanks, looks quite cool and a bit more in line with my Kubernetes setup than KeyEnv mentioned above. I'll give it a try, especially if I can start with self hosted opensource version when the team is still tiny.
My company has started using Vault a few months ago - seems pretty easy for me (store secret in vault, get it during gitlab's pipeline pass it as a kuber secret)
This is concerning. To me it looks like there is a holy war going on with devs who maintain a secrets manager. The last thing I want is instability with the tool that holds my passwords and credentials. On the low end of my concern is the annoyance of constantly updating names in yaml files, and on the high end is worry that a rogue dev could deliberately add in a security hole that would compromise my secrets.
What could Hashicorp have done to preserve trust while maintaining some kind of business model and being able to charge companies monetizing their software?
So software makers should give their competitors their software with a liberal free “as in beer” license and then try to compete with them.
This isn’t a workable or sustainable model. The companies leveraging free software don’t have to work nearly as hard on software which means they can focus 100% on ops and marketing. And of course they don’t give anything back to the software creators.
> So software makers should give their competitors their software with a liberal free “as in beer” license and then try to compete with them.
This is literally what they did when they released their product code under an OSS license. It was their free choice.
> This isn’t a workable or sustainable model. The companies leveraging free software don’t have to work nearly as hard on software which means they can focus 100% on ops and marketing. And of course they don’t give anything back to the software creators
The other companies might not need to work so hard, but they also have little to no control.
If you can't build a sustainable business on a piece of software when you are the steward of that software, control the product direction and backlog etc., then you're not very good at the business.
Or, put another way, if your business success hinges on people not competing when they have access to (and license to use) your source code, when releasing it under an OSS license demonstrates that you're not very good at the business.
> If you can't build a sustainable business on a piece of software when you are the steward of that software, control the product direction and backlog etc., then you're not very good at the business.
The elephant in the room here is that software is incredibly expensive. Developing and maintaining a large project requires a large team of high salary software devs.
I’d estimate the cost of building, supporting, and maintaining Vault at $3-4M a year bare minimum for the core team and related overhead. It also takes a ton of energy and focus all the way to the top of the organization.
The company building and maintaining the software must spend that. Someone just using the software to resell in the cloud or rebranding it can instead put all that money and mental energy into marketing and ops.
The company that does not have to maintain the software has a massive advantage. They’re freed from that burden.
> The elephant in the room here is that software is incredibly expensive. Developing and maintaining a large project requires a large team of high salary software devs.
There's plenty of expensive, major open source projects that seem to have figured this out. The fact that Hashicop can't doesn't mean the model is broken, it just means Hashicorp aren't very good at this.
> Someone just using the software to resell in the cloud or rebranding it can instead put all that money and mental energy into marketing and ops.
It's not that simple. Once again, the "reseller" doesn't have control over the direction of their business. Which means they should always fail, long term, relative to the org that actually spends the money on controlling the development.
If you can't compete and outmanoeuvre someone who's simply slapping a label on your software, you probably shouldn't release your software under an OSS license.
> The company that does not have to maintain the software has a massive advantage. They’re freed from that burden.
I think it's pretty clear that we both take very different views on what maintaining and developing software means. You see it as a massive burden, I see it as an enormous advantage / opportunity.
> There's plenty of expensive, major open source projects that seem to have figured this out
Like? Red Hat are the only one, and they sell very special software. I can't think of any other ones that are successful as a fully open source project that also has a sustainable profitable business build on top of it.
You can only trust code you write and control yourself ultimately. How can you trust your operating system isn’t siphoning your doge coins as we speak?
It's a bit scary how much I am being downvoted for asking what I believe to be a reasonable question. I was expecting someone from the new project to give a quick response with a few points of assurance, and instead I am getting told to go to the very group that downvoters do not trust. This does not make sense to me.
There's nothing scary about being downvoted on HN, but if karma is your goal, I wouldn't start by labeling a simple (and frankly 100% expected) fork a holy war.
I'm not sure I understand your concerns in the previous comment. What would cause you to constantly update your YAML, and why are you just now worried about a rogue dev? Also, who doesn't trust whom?
I see three primary differences between HashiCorp Vault and OpenBao:
1. License: BSL vs. MPLv2.
2. Development model: cathedral vs. bazaar.
3. Maturity: production vs. barely started.
It sounds to me like you don't care about the license, trust cathedral more than bazaar, and value the maturity of the incumbent Vault project. If you're currently a Vault user, I would stay the course for now.
I don't think there's any particular mistrust of HashiCorp in the sense that they will compromise your security, either deliberately or incompetently. However, there is an awareness that their interests aren't necessarily aligned with their customers'.
> It's a bit scary how much I am being downvoted for asking what I believe to be a reasonable question.
> On the low end of my concern is the annoyance of constantly updating names in yaml files, and on the high end is worry that a rogue dev could deliberately add in a security hole that would compromise my secrets.
> Is there any assurance this won't happen?
This isn’t really a reasonable request. You can do any of this yourself as well, so your assurances are your own. If you want someone else to own those assurances you need to pay up.
> This isn’t really a reasonable request. You can do any of this yourself as well, so your assurances are your own. If you want someone else to own those assurances you need to pay up.
The point here is not "we pay more money and get better security." That's the kind of garbage logic the SSL CA cabal used for decades to maintain a monopoly before LetsEncrypt showed up. The question is, what is an indication that, although there is clearly some drama, that I can trust the software with my secrets? Did some of the people come to this new project from the Hashicorp security team? Could it be that the majority of changes in codebase are on the UX/UI, and not the security protocol implementation? There are plenty of ways to publish trust validation without demanding that a potential user spend hours poring through code looking for exploits.
The Devs probably know this (grepping code for "vault" is trivial). The fork was announced yesterday, so it is bound to be in need of polishing here and there.
> Please note: We take OpenBao's security and our users' trust very seriously. If you believe you have found a security issue in Vault, please responsibly disclose by contacting us at openbao-security@lists.lfedge.org.
I think they're asking for responsible disclosure that's sent to Hashicorp to also be sent to them so they can test and help fix before public disclosure.
Huh?
Please elaborate. Even just bullet points from your eval would be appreciated. There are any number of reasons not to go with the bleeding edge, but bun's solving for ESM / CJS is kind of a big deal. V interested to hear meaningful objections.
There is nothing distinct about a window or piece of fruit. Obviously if you made an operating system called Windows and used a window as a logo that would be trademark violation, but there's nothing stopping me from opening John's Windows with the logo being a window.
None. OpenTofu name comes from Terraform => TF => Tofu. Bao is another asian food, so it kinda fits (people involved with OpenTofu are not the same as people working on OpenBao, but why not have some common theme).
Appreciate the fork, but I think it's time for people to move on from Vault and other HashiCorp tools (especially that I'm hearing this is financed by IMB to keep their Vault competitor going).
I honestly believe both you and the Akeyless folks should join the steering committee once one forms, and together work towards common standards y'all can benefit from.
Another option that focuses on ease-of-use and security is EnvKey - https://envkey.com (I’m the founder)
It’s has client-side end-to-end encryption with no backdoors or compromises, is open source, and, apart from secrets management, provides a robust set of tools to manage and de-duplicate config.
HashiCorp Vault forked into OpenBAO - https://news.ycombinator.com/item?id=38578247 - Dec 2023 (70 comments)