[HN Gopher] Infisical - open-source HashiCorp Vault alternative
___________________________________________________________________
Infisical - open-source HashiCorp Vault alternative
Author : vmatsiiako
Score : 179 points
Date : 2023-08-11 16:44 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mirzap wrote:
| I remember trying Infiscal, and I was excited to see how good it
| is, the feature list in the OSS version, and its ease of use...
| What cooled me off is this limitation in OSS: "3 Infisical
| Projects, 3 Environments & 5 Team Members."
|
| That's not nice. It's OK to limit SSO access to OSS and stuff
| like that. But limiting essential features - team members is a
| no-go.
| vmatsiiako wrote:
| This is very strange. There is no such limitation. You can
| create as many projects and environments as you need. You can
| also add an unlimited number of users
| dangtony98 wrote:
| Second this, we don't have any such limitations on OSS that
| is you can totally self-host Infisical on your own
| infrastructure and have unlimited users, projects, and
| environments.
|
| I think there may be a mix-up here with Infisical Cloud which
| is the managed service with subscription tiers.
| mirzap wrote:
| OK, that's great to hear. You may consider removing the
| "Usage & Billing" page from OSS when self-hosting. Because
| I thought I'd have to upgrade OSS with a business license
| once I reached the limit.
| mirzap wrote:
| Check the pricing page: https://infisical.com/pricing
|
| Yeah, I've noticed that the app is not enforcing that limit
| ATM, but the limit was clearly visible in the dashboard when
| I tried it a couple of months ago (OSS, docker)
| lars_francke wrote:
| Last time I saw this mentioned here a few weeks ago someone
| mentioned that the whole code has no tests.
|
| Is that (still) true? If so: No
| hereonout2 wrote:
| Was interested so had a look and it appears to be the case. I
| found a directory backend/src with 27K lines of typescript, and
| backend/tests with 303 lines.
| steeleduncan wrote:
| There appear to be some go tests as well, but again the ratio
| is not great
| dvrp wrote:
| Do you have other near-term next plans besides secret management?
| dangtony98 wrote:
| Definitely. Our plan is to double-down on secret management and
| branch outwards but incrementally starting with secret scanning
| to prevent and detect leaked secrets in codebases.
|
| Ultimately, we intend each initiative of our roadmap to have
| synergies with the rest of the platform.
|
| You can check out our past and immediate roadmap here:
| https://www.notion.so/be2d2585a6694e40889b03aef96ea36b?v=5b1...
| dvrp wrote:
| that's a sick roadmap! keep 'em coming :)
| vmatsiiako wrote:
| Thank you! If you have any feature suggestions, you're
| welcome to add those to
| https://github.com/Infisical/infisical/issues
| throwawaaarrgh wrote:
| Backed by another corporation trying to monetize it. This will go
| well. This repo available under the MIT expat
| license, with the exception of the ee directory which will
| contain premium enterprise features requiring a Infisical
| license.
|
| I just sprained my eye sockets from rolling my eyes too hard.
| [deleted]
| jrflowers wrote:
| > Backed by another corporation trying to monetize it. This
| will go well.
|
| This is a good point. Open source software by definition must
| be made by monks that have taken a vow of asceticism. I won't
| use any OSS made by anyone that eg drives a car or has been to
| a dentist.
| mirzap wrote:
| What's wrong with monetization? You understand that OSS's
| significant problem is a lack of funding, where authors don't
| want or don't know how to monetize their product?
|
| Sentry looks like a good model for OSS, and it's proof that you
| can make a living from OSS. I also don't have anything against
| "enterprise features" for which you need a license, while most
| features are available in OSS version.
| Znafon wrote:
| > What's wrong with monetization? You understand that OSS's
| significant problem is a lack of funding, where authors don't
| want or don't know how to monetize their product? > Sentry
| looks like a good model for OSS, and it's proof that you can
| make a living from OSS.
|
| Sentry is using the BSL, the very same license that HashiCorp
| has switched to but that change has not been received well.
| candiddevmike wrote:
| Sentry isn't OSS...
| vmatsiiako wrote:
| This is what Sentry says: https://open.sentry.io/
| candiddevmike wrote:
| Corporate blog spam doesn't magically make the BSL OSS:
| https://mariadb.com/bsl11/
|
| > The Business Source License (this document, or the
| "License") is not an Open Source license. However, the
| Licensed Work will eventually be made available under an
| Open Source License, as stated in this License.
| Pet_Ant wrote:
| I would argue (and have previously) that BSL is open
| source, it's just being held in escrow. So it has been
| released to open source... just that source hasn't been
| released to the public. (BSL triggers after a max of 4
| years into irrevocable OSS).
|
| I think the real issue is that people want more community
| driven OSS. Stuff that is collaboratively built and not
| built for a commercial purpose. They want something I
| think along the lines of KDE where there are paid people
| to work on it, but it's also contributed to by a
| community and there isn't someone constantly trying to a
| make a buck off of it.
| throwawaaarrgh wrote:
| Open Source is not a business model. It's marketing, for
| sure, but you can't make money solely by giving away your
| product.
|
| Every single open source company eventually learns this when
| they have a strong competitor. Eventually you are forced to
| stop being open source, because no business wants to compete
| solely on the strength of their service quality.
|
| Moreover: a community is antithetical to a corporation's
| interest in the software. Corporations don't give a shit what
| people want changed in the code, for good reason: their
| purpose is to make money, not make good software. So business
| source always ends up annoying and limited while community
| open source provides the functions the users need, in the way
| they want them.
|
| So, yeah, you can make money while letting people read your
| source code. But the actual quality of the end result, the
| user's happiness, the ability to contribute to the whole
| thing, is much different in a real community project.
| EspressoGPT wrote:
| > Every single open source company eventually learns this
| when they have a strong competitor.
|
| Many of the open source companies are their own strongest
| competitor, see HashiCorp.
| jsight wrote:
| If they aren't, then someone else will be. That is always
| worse for them.
|
| Either that or they have to go at least semi-proprietary.
| ritesofbryan wrote:
| I agree with this.
|
| TBH my view is that the frustration towards open source
| companies around changing their licenses is sort of
| misguided. If there's a bad guy in the room, it's AWS.
| AWS is very good at commercializing open source -- they
| make literally billions of dollars doing so: Elasticache
| (Redis), AWS Managed Elastic, RDS etc. Changing the
| license becomes one of the only ways to hold them off,
| and the companies that have done so more proactively have
| fared much better. I think everyone agrees that in an
| ideal world this wouldn't have to happen, and indeed it
| didn't really happen until recently when the AWS thing
| started to become an issue.
|
| Ultimately, SOMEONE is going to leverage the open source
| for financial gain. So, the question becomes which would
| you rather have:
|
| - The company commercializing the open source (which is
| in almost every successful case includes the original
| creator(s) as a founder, CEO, or employee) benefit from
| the projects success, which in turn allows them to make
| further investment in the project.
|
| - AWS benefit from the projects success and (generally
| speaking) contribute very little back.
|
| Of course, there are plenty of projects that are NOT
| venture funded that see great success through purely
| community development. That's great! I just think
| commercial open source is beneficial as well, especially
| for larger more complex projects (databases, etc.) that
| need the funding. The two are not mutually exclusive.
|
| I am also of the belief that the additional funding (both
| from revenue and from venture investment) that goes into
| these projects gives them the ability to hire more
| people, which in turn makes the software better for
| everyone.
|
| Disclaimer: I am investor that invests predominantly in
| commercial open source companies. Previously I was
| developer who used a lot of open source, which is what
| led me here.
| advaitruia wrote:
| More often than not, making money and making good software
| are complimentary outcomes. Its difficult to do the former
| without the latter.
|
| Infisical is an open core business model. While there is a
| proprietary crust, the core is truly open source.
|
| Disclaimer: I run an open core venture
| lopatin wrote:
| Open source core, paid premium features + support. It's a
| valid business model, not sure why it's worthy of eye
| rolling.
|
| For example: Open source database that works on one
| machine. If you like it and want want to scale up, you can
| pay for the replication and authorization features with
| paid support.
| josephcsible wrote:
| There's nothing wrong with monetization. There's just
| something wrong with making parts of the code proprietary.
| There'd be nothing wrong with monetizing by picking a
| copyleft license and selling exceptions, selling hosting, or
| selling support, for example.
| nine_k wrote:
| Dual licensing (copyleft + commercial) has been a thing for
| a long time.
|
| Open Core is also a thing, and I think it's better than BSL
| because at least the core part is truly open.
| josephcsible wrote:
| I have nothing against dual licensing, but that's not
| what "enterprise features" are.
|
| As for Open Core, there is one case in which I think
| that's fine: when none of the proprietary parts would be
| useful at all in an otherwise 100% FOSS environment. For
| example, if Linux support were FOSS but all the Windows-
| and macOS-specific code were proprietary, or if a plugin
| to talk to Bugzilla were FOSS but a plugin to talk to
| JIRA were proprietary, I wouldn't see a problem.
| vmatsiiako wrote:
| Curious why you think it's the wrong way to do it?
| josephcsible wrote:
| Because then you're making and monetizing a proprietary
| product rather than actually monetizing FOSS.
| vmatsiiako wrote:
| I'm not sure if I understand your point.
|
| OSS != FOSS
|
| https://opencoreventures.com/blog/2023-07-open-core-is-
| misun...
| josephcsible wrote:
| > OSS != FOSS
|
| While this statement is technically true, I don't think
| it has any relevance to the topic at hand. While there
| are some relatively obscure licenses that are OSS but not
| FOSS (e.g., the Sybase Open Watcom Public License), isn't
| everything under discussion here either both free and
| open source, or neither free nor open source? In
| particular, the "core" of Open Core is both, but the
| extras are neither.
| vmatsiiako wrote:
| This is indeed what we are going for. We want to provide a
| very predictable license that gives most of the features for
| free for developers while keeping the managerial features
| paid to make sure that we can support development and
| maintenance of Infisical.
| riku_iki wrote:
| I think OSS core + proprietary components (which can be
| replaced by OSS alternatives) is much less evil business model
| than what Hashi did: forced contributors to give up copyright
| and then locked everything under business license.
|
| There are many examples of such approach: Spark/Databricks,
| Cassandra/Datastax.
| JeremyNT wrote:
| I mean, sure, but there's no particular reason to believe
| that Infisical will keep its current licensing if and when
| when financial times get tough for them.
|
| When you rely on OSS products that are developed almost
| exclusively by companies, you just need to assume that one
| day there's going to be a rug pull and plan accordingly.
| riku_iki wrote:
| > Infisical will keep its current licensing
|
| I think license they chose doesn't allow to change
| licensing, unless they require 3p contributors to sign some
| agreement to give up copyright rights like Hashi asked to
| do.
|
| So, we can check right away if infisical asks to sign
| agreement or not.
| vmatsiiako wrote:
| We have not asked any contributors to sign a CLA
| agreement.
| jchw wrote:
| The problem, though, isn't the mere concept of trying to
| monetize open source work. It's the fine line between balancing
| profitability and openness vs deception and exploitation. Open
| source with community governance is clearly better at upholding
| ideals, but honestly, other models can work, too. As I see it
| today, the CLA is a major issue: it can be seen as insurance
| against existential threats for open source projects, but it's
| being used to make pulling the FOSS rug legal 99% of the time
| its ever exercised, it seems.
|
| Only solution I can see is to stigmatize the CLA.
| sergiotapia wrote:
| There has to be a middle ground where yes you can use this to
| your hearts content for free, but don't package and sell this to
| undercut our own hosted offering.
|
| It's pretty shitty what happened with mongodb and aws. Morally it
| always felt wrong.
| rstat1 wrote:
| MIT now, but in a few years when the inevitable need to make
| profit number bigger crops up they'll be doing the same thing.
|
| And there will the same backlash by people pretending that the
| change is some sort of grave slight and make bold claims about
| how they're switching away because they actually have to pay for
| stuff now.
|
| And the cycle will repeat ad nauseam.
| danenania wrote:
| EnvKey (https://www.envkey.com/) is another OSS alternative to
| Vault with a bit more focus on security (disclaimer: I'm the
| founder).
|
| We have a comparison with Vault here:
| https://www.envkey.com/compare/hashicorp-vault/
|
| We'll probably write up a comparison with Infisical soon as well
| but I'd say the main thing is that our end-to-end encryption has
| no opt-outs (as Infisical does for many of its integrations), and
| we use native apps and a CLI rather than offering a web UI. End-
| to-end encryption in a web browser offers minimal security
| benefit for reasons discussed in this thread:
| https://news.ycombinator.com/item?id=21838795 (the discussion is
| from 2019 and the original NCCGroup link from 2011 is now dead,
| but all the same issues still apply).
|
| Also, I'm not sure if this has been addressed yet, but it has
| previously been noted that Infisical was completely lacking in
| automated tests. EnvKey has an extensive test suite ( core tests
| here: https://github.com/envkey/envkey/tree/main/public/app/tests
| and tests for all our sdks are included in each:
| https://github.com/envkey/envkey/tree/main/public/sdks).
| vmatsiiako wrote:
| In my opinion, "having no opt-outs" is not a benefit. It's by
| definition having less functionality. Infisical offers native
| SDKs, API, and CLI too + many other features (such as native
| integrations, webhooks, dashboard, etc).
| danenania wrote:
| There's an inherent tradeoff for sure. In my opinion, I
| wouldn't say that any added functionality a secrets
| management service can offer is worth trusting all that
| service's servers, all its backend dependencies, all its
| employees and contractors, all its third party sub-
| processors, etc. with plaintext secrets.
|
| I'd also note that we are able to offer all the features you
| list without requiring users to opt-out of end-to-end
| encryption.
| vmatsiiako wrote:
| Interesting. We work with some of the largest companies out
| there, and none of them had an issue with this.
|
| Curious how you are able to create a native integration
| with, let's say, Vercel without requiring users to opt-out
| of end-to-end encryption?
| danenania wrote:
| "We work with some of the largest companies out there,
| and none of them had an issue with this."
|
| I imagine they'll regret this if you have a security
| incident.
|
| "Curious how you are able to create a native integration
| with, let's say, Vercel without requiring users to opt-
| out of end-to-end encryption?"
|
| We don't have a native integration with Vercel (you
| didn't list that in your comment, which is what I was
| referring to). We don't really have a need for one since
| all that's required to integrate EnvKey with Vercel is
| setting a single environment variable. That said, if we
| did decide to build an official Vercel integration, we
| wouldn't require removing end-to-end encryption to use
| it.
| nine_k wrote:
| In the security domain, you often _want_ fewer features,
| because every feature is another thing to audit, and another
| chance to introduce a vulnerability.
|
| But, of course, too few features can be just impractical.
| ckwalsh wrote:
| Any plans for OIDC support?
| vmatsiiako wrote:
| Yes, this has been requested quite a bit recently. Could you
| please comment in this issue:
| https://github.com/Infisical/infisical/issues/442
|
| We will make sure to prioritize the OIDC support depending on
| how many people ask for it
| chrisfrantz wrote:
| Congrats to the Infisical team, it's been cool getting to watch
| them grow from the start.
|
| What are some of the biggest challenges you've run into so far?
| dvrp wrote:
| i'm also interested in this.
|
| also how's it going with loops?
| chrisfrantz wrote:
| hey thanks, loops is going well!
| vmatsiiako wrote:
| Prioritizing feature requests and providing good quality
| support takes a lot of time and effort... You can check in our
| Slack (https://infisical.com/slack) that we try to reply to
| everyone within a couple minutes. This is definitely the
| biggest one, but it's worth it IMO!
| drdaeman wrote:
| So the introduction says it's "end-to-end encrypted" but all it
| does is a link to Wikipedia (which is useless). Is there any
| documentation on the security model?
|
| Vault has some at-rest encryption but IIRC explicitly says then
| don't have any mitigations against a compromised unsealed node.
| My understanding is that if someone ever gets a root access to a
| machine running Vault, the game is over. Which makes me wonder
| ifI can deploy Infiscial to some completely untrusted machine
| (without any orchestration or networking concerns) and still have
| some guarantees that all my secrets are safe in some way (cannot
| be decrypted, cannot be replaced, maybe even cannot be rolled
| back, etc)?
| Jishin wrote:
| Another option, for companies that want to go full security over
| automation is CyberArk Conjur. Its OpenSource is quite limited in
| features, but the Enterprise version is very complete.
| vmatsiiako wrote:
| HashiCorp switched Vault from MPL to BSL license yesterday. The
| terms of how they define "competitive" products are pretty vague,
| which means that any commercial product that uses Vault under the
| hood is at risk of violating the terms of the new license.
| Moreover, even if it's not violating the terms of license now, it
| doesn't mean that HashiCorp will not change its mind in future.
|
| Ultimately, it just means that HashiCorp is not an open source
| company anymore. One of the biggest benefits of open source is
| building on top of open source software to create even better
| software. HashiCorp's move makes it impossible and simply slows
| down innovation. In fact, in their blog post, they say that they
| will start referring to their previously-open-source product as
| "community".
|
| Infisical is an open source alternative to HashiCorp Vault. The
| main difference is that it provides more tools in one platform.
| Some examples of these are automatic secret scanning and leak
| prevention, CLI for local development, integrations with services
| like GitHub Actions, Circle CI, etc.
|
| The core of Infisical is available under the MIT license with
| only very few features being enterprise-licensed - some will say
| it's not ideal but at least this type of license does not impose
| legal risks on our users while gives us the ability to monetize
| the product efficiently and support the open source (MIT-based)
| part of the product.
|
| Over the last year, lots of developers and companies of all sizes
| (from tiny startups to Fortune 10 companies) have partially or
| fully switched to Infisical. For them, we now process over 300
| million secrets per month.
|
| Check out our git repo here:
| https://github.com/Infisical/infisical
| JonChesterfield wrote:
| Regarding the open core and proprietary extensions model. The
| usual endgame of that is what hashicorp seems to have just done
| - deprecate the open source part in favour of the part that
| makes money.
|
| This bait&switch is no longer novel. Be open source friendly to
| leverage the community and then pull the rug is probably taught
| strategy in VC themed business schools by this point.
|
| If you're going to do the same thing in a while anyway, one may
| as well stay with hashicorp. Is there a reason to believe you
| will remain viable as an open source product long into the
| future?
| brabel wrote:
| I don't know anything about this product, but just wanted to
| say that's a really pretty README page :D
| dangtony98 wrote:
| Thank you!
|
| Check out this demo as well: https://www.youtube.com/watch?v=
| PK23097-25I&ab_channel=Infis...
|
| We put a lot of work into engineering but also the design and
| messaging of the platform to developers as well :)
| fuddle wrote:
| FYI I noticed a typo in the readme - "take a look at our
| webiste"
| vmatsiiako wrote:
| Thank you. Fixed!
| steeleduncan wrote:
| This repo seems to have virtually no tests. Is that just the
| way it is? or do you charge for access to your test suite
| similar to what SQLite does?
| smartbit wrote:
| Does Infisical support an HSM?
| Maidul98 wrote:
| At the moment we don't offer support for HSM but please make a
| request for it in our github issues
| https://github.com/Infisical/infisical/issue
| vmatsiiako wrote:
| We have heard many requests for it recently. If you could
| create an issue for it on our Git repo, we will make sure to
| prioritize it!
| pluto_modadic wrote:
| I wish secret manager services were obsoleted by OIDC and HSMs.
| If everything negotiated via keypass & beyondprod style workload
| identification and... we never save passwords for DBs or web
| hooks ever again.
|
| ...it's annoying that a kubernetes-like complex system exists and
| it doesn't have to. And now they have a SaaS version for small
| numbers of secrets....
| iLoveOncall wrote:
| And still world-class testing:
| https://github.com/Infisical/infisical/blob/main/backend/tes...
|
| Don't use this untested mess to store your secrets.
___________________________________________________________________
(page generated 2023-08-11 23:00 UTC)