|
|
 |
|
I probably won't contribute, but I want to extend some useless but genuine moral support.
|
|
|
|
|
|
Has anyone figured out if it's possible to join these rooms from a federated Matrix account?
|
|
|
|
Just joined from :matrix.org. Haven’t tried other servers but should be fine I think.
|
|
|
|
|
|
Because Hashicorp changed the license. It’s been all over the (tech) news so it’s easily googlable.
|
|
|
|
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.
|
|
|
|
> OpenBao wouldn’t solve this for me. I'd bet OpenBao gets native HSM support. The problem will be doing it in a clean room setting to avoid any legal issues.
|
|
|
|
Someone would have to fund it. The compliance issues alone are very expensive.
|
|
|
|
Forgive my ignorance, but what does compliance have to do with HSM support? Aren't they orthogonal features?
|
|
|
|
The "HSM support" bit is totally dependant on compliance; it's not about APIs.
|
|
|
|
You didn't answer my question. How is it dependent?
|
|
|
|
The reason people pay Hashicorp for HSM support is so that they can run Vault in a FIPS-certified mode.
|
|
|
|
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.
|
|
|
|
> overengineered design Having operated a large Vault (FOSS, not commercial) installation, "overengineered" is not the word I'd use.
|
|
|
|
|
Cleverly designed to make you go commercial.
|
|
|
|
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.
|
|
|
|
We have a Vault cluster running in containers. It is working well
|
|
|
|
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?
|
|
|
|
|
That's real cool, still hoping for a Nomad fork.
|
|
|
|
|
|
Not exactly. The linked post is from theregister announcing the fork. This post is the fork itself.
|
|
|
|
> Please note: We take OpenBao's security and our users' trust very seriously. Funny how that sentence is one of the quickest ways to make me mistrust something (even if possibly undeserved).
|
|
|
|
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.
|
|
|
|
What are the alternatives to both that don't make your life harder? Curious if there are any.
|
|
|
|
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.
|
|
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
Your "Comparison with Vault" page is not a fair comparison. It pretends like 90% of Vaults functionality doesn't exist.
|
|
|
|
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. Looks well polished at first glance.
|
|
|
|
Harder how? 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)
|
|
|
|
Is it "OSS" Vault or paid Enterprise Vault? Good luck with Enterprise being easy.
|
|
|
|
OSS. No more enterprise here in Russia for any foreseeable future.
|
|
|
|
Does your company have a dedicated team for operating vault? Is it reliable?
|
|
|
|
We use consul/vault/nomad at $DAYJOB. It's been a mostly stable platform for us. Me the other hand, I can assure you... I am not reliable. /jk
|
|
|
|
We do have devops team, yeah. Heard no bad (or any) words from them so far.
|
|
|
|
Curious about your take on consul -- it's been instrumental for service discovery in our non-K8S environment...
|
|
|
|
Had three major cluster collapses. Elections that never worked out. Weird state inconsistency problems. I don’t sleep well any more. Never entrust consistent state to things based on arguments and opinions.
|
|
|
|
|
Hi, 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. Is there any assurance this won't happen?
|
|
|
|
Hashicorp’s offering won’t be more vulnerable now than before, so use it instead of the fork.
|
|
|
|
|
|
What could Hashicorp have done to preserve trust while maintaining some kind of business model and being able to charge companies monetizing their software?
|
|
|
|
Outcompete them. Do more, do better, do faster
|
|
|
|
But "move fast and break things" is precisely the opposite of what I want for a place where I store my passwords.
|
|
|
|
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.
|
|
|
|
So the answer is that I can't trust either Hashicorp or the forks?
|
|
|
|
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?
|
|
|
|
I encrypt my dogecoins with base64 before putting them in Vault so...
|
|
|
|
|
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. Sure it is. This is what third party security audits exist for. For example:
https://www.hashicorp.com/solutions/auditing-and-compliance This isn't unique to Hashicorp. Any organization which claims to offer secure protection should be willing to share this kind of information. https://docs.securedrop.org/en/stable/what_is_securedrop.htm... https://threatpost.com/openssl-security-audit-ready-to-start... 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 [email protected]. You might wanna change Vault to OpenBao
|
|
|
|
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.
|
|
|
|
Like OpenTofu, this will likely take some time and likely will be a blocking step that prevents other contributions until it is done.
|
|
|
|
|
|
|
They aren't. https://imgur.com/a/tNRuEpbBut how much variance can you reasonably expect from a logo based on an anthropomorphized bao bun?
|
|
|
|
> how much variance can you reasonably expect from a logo based on an anthropomorphized bao bun Agreed. Try this: do an image search for cute cartoon bao bun https://duckduckgo.com/?q=cute+cartoon+bao+bun&iar=images&ia... There are, completely as expected, a bunch of different pictures that fundamentally look very similar.
|
|
|
|
>But how much variance can you reasonably expect from a logo based on an anthropomorphized bao bun? Not much. But taking a similar logo from a current hot / hyped tech in a similar vertical just strike me as poor taste.
|
|
|
|
They're so unrelated though it seems like it's not a big deal. If they were playing in the same space I'd agree.
|
|
|
|
Bun is kinda DOA last I was asked to evaluate it...
|
|
|
|
How long ago? I have no idea why you would say this. Genuinely confused.
|
|
|
|
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.
|
|
|
|
|
Maybe bao in a steamer. If the boa are the secrets the steamer is the vault.
|
|
|
|
> If the boa are the secrets the steamer is the vault I think the inside of the bao is the secret, and the bao is the vault.
|
|
|
|
|
There are minor differences, but the similarity is indeed striking.
|
|
|
|
|
It looks extremely similar to me. I would not be pleased if I was behind Bun.
|
|
|
|
Sounds like Bun chose a bad logo then. They're not going to own the concept of a bao bun with a face.
|
|
|
|
What about the concept of a window? Can anyone own that? Or, a cat octopus? How about a discarded piece of fruit?
|
|
|
|
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.
|
|
|
|
Who cares? It’s not like they’re in a remotely related niche. Nobody’s gonna confuse the two.
|
|
|
|
The only real similarity is that it's a bao bun with a face, which Bun didn't create the concept of.
|
|
|
|
|
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). Check out Infisical for secret management: https://github.com/Infisical/infisical Disclaimer: I'm one of the maintainers.
|
|
|
|
This is a terrible advertisement, you should at least sell your tool on it's own merits.
|
|
|
|
Doesn't seem to support one of our major use cases as a private CA.
|
|
|
|
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.
|
|
|
|
Who is IMB here? IBM? Can you say what is their Vault competitor?
|
|
|
|
|
|
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. Comparison with Vault: https://www.envkey.com/compare/hashicorp-vault/
|
|
