Live data from Hacker News

Launch HN: Infisical (YC W23) – Open-source secrets manager for developers

news.ycombinator.com

71–80 of 124 posts

Re: Launch HN: Infisical (YC W23) – Open-source secrets manager for developers

#71

TIL that systemd has a credentials component: https://systemd.io/CREDENTIALS/

Thank you, 'cause I don't wanna do the wrap command thing they do. Besides that, this is a great idea.

Down to jam on your use-case!

The CLI "wrap command" is the main way of using Infisical at the moment and works for injecting secrets for local development as well as embedding into your Docker images if you use that; it definitely has pros and cons (a pro is not having to bundle any packages into your application code - in that sense, "dependency-less") but I can see it not being for everyone.

As mentioned we have an open API that we're working to make easier to use because E2EE ops for encrypting/decrypting secrets are not pleasant honestly to have to piece together yourself — because of this we have plans to release SDKs to abstract-away the cryptography (reading/writing secrets from/to Infisical would be one function call away).

What options would you want for interacting with a secret manager, just wondering?

Re: Launch HN: Infisical (YC W23) – Open-source secrets manager for developers

#72
Hey there, I wanted to offer you some unsolicited advice. You're building a security product, so you have an uphill battle ahead of you. There is a reason security engineers get paid more than any other engineer, and why security companies can charge more -- because security is fraught with peril and just a single mistake can ruin your company/career.

You need to show that you are extremely competent at security -- more so than anyone I can hire myself. You also need to show that you care deeply about security.

For example, the fact that you lock SSO behind a paywall says that you don't care about security. Yes, SSO tends to be an enterprise ask, but it's also important for two person companies. I'd suggest changing at least that part to be 10+ SSO users or something like that, and make the first few free.

Also, your response to security reports in this thread is not what I'd want from a security company. Sure, the right way to report these things is via email, but you should still be grateful for the free security audit you got and approach that with a bit more tact.

At least make it look like you care more about security than revenue and adherence to policy.

Good luck, it looks like an interesting product, just make sure you don't turn users off with your security posture.

Re: Launch HN: Infisical (YC W23) – Open-source secrets manager for developers

#73
post #70

Earlier quoted context omitted.

https://sso.tax/

Really strange thing to reply to this with. Did you find it just now and searched for "sso" on HN just to get a chance to randomly post it?

Why strange? That was the first thing that came to mind when I read “sso” as part of the “enterprise’ offering, and was not surprised to see that someone else linked the sso tax website

Re: Launch HN: Infisical (YC W23) – Open-source secrets manager for developers

#74
post #60

Earlier quoted context omitted.

Audit logging and SSO is pretty basic functionality that requires very little (many people would argue no ) additional effort or cost to maintain on the development side.

Surprisingly, audit logging has been deceivingly complex for us. There are many types of events (part of logs) triggered throughout the platform carrying different payloads/formats (e.g. events related to secrets, users, etc.). The variation in such events is increasing with the complexity of the product not to mention costs required to handle accumulating events. Last month, we served 14.2M+ secrets alone through th…

You know what you're definitely right about audit logging. It does seem like one of those "easy on the surface, will absolutely kill you in the details" sorts of things.

Re: Launch HN: Infisical (YC W23) – Open-source secrets manager for developers

#75
post #72

Hey there, I wanted to offer you some unsolicited advice. You're building a security product, so you have an uphill battle ahead of you. There is a reason security engineers get paid more than any other engineer, and why security companies can charge more -- because security is fraught with peril and just a single mistake can ruin your company/career. You need to show that you are extremely competent at security -- m…

Thanks so much for this comment - very valuable insights.

RE security: 100% agree with everything you said. This is at the end of the day a security product. Even though we're very early, we've put a ton of thought into the security and especially the cryptography behind our product (e.g. we decided E2EE since the start) and intend on maximizing security posture in the coming months and years ahead — earning trust will definitely be an uphill battle but we hope to do it and have an optimal solution for everyone.

RE SSO: Initially, we started by exploring what other solutions on the market are doing about this and noticed SSO as an enterprise ask even for security products like Bitwarden. That said, I think you have a great point here that I'll discuss with the team: SSO doesn't have to be available/not available across plans but that it could be available across all plans and larger organizations would need to pay for it anyways on the basis of needing it for more users — this preserves the SSO benefit for individuals and small teams as well as enterprises.

PS: I'll work on doing a better job responding to security reports; I appreciate everyone's input a lot in this thread and hope to express that better over writing...

Re: Launch HN: Infisical (YC W23) – Open-source secrets manager for developers

#77
post #60

Earlier quoted context omitted.

We provide all the main functionality completely for free under the MIT license. What this means is that all the integrations (Docker, AWS, Vercel, Kubernetes, Terraform, etc) are available completely to everyone. Next to that, all the features related to secret sharing, and security are also available under MIT. ee is only reserved for some features that are (mostly) needed by enterprises (e.g., audit logs, sso, adv…

Audit logging and SSO is pretty basic functionality that requires very little (many people would argue no ) additional effort or cost to maintain on the development side.

Actually I've never seen SAML based sso go completely smoothly. There is always some additional support there. That's not the reason everyone charges for SSO, but it is never plug and play.

Re: Launch HN: Infisical (YC W23) – Open-source secrets manager for developers

#78
post #60

Earlier quoted context omitted.

We provide all the main functionality completely for free under the MIT license. What this means is that all the integrations (Docker, AWS, Vercel, Kubernetes, Terraform, etc) are available completely to everyone. Next to that, all the features related to secret sharing, and security are also available under MIT. ee is only reserved for some features that are (mostly) needed by enterprises (e.g., audit logs, sso, adv…

Audit logging and SSO is pretty basic functionality that requires very little (many people would argue no ) additional effort or cost to maintain on the development side.

One of the tenants pricing is you don't charge based on your development cost but based on the value to the customer. So, I don't think it's worth thinking about the complexity of a feature or the cost to maintain in when thinking about pricing besides making sure the maintenance cost is less than what you charge.

Generally, the reason all these companies go and charge for SSO and audit logging is because open core is a land and expand strategy. They offer a free tool that's useful for individual developers, and then when they start demanding enterprise features that means they are integrated into the enterprise and have the opportunity to extract value.

Re: Launch HN: Infisical (YC W23) – Open-source secrets manager for developers

#79

Hey, congratulations on the launch. How does this compare to EnvKey[1]? [1]: https://envkey.com

Thanks!

We're both in the same domain, open-source, and E2EE. Right off the bat, I'd say there are a few key observable differences:

- Infisical is open-source more-or-less from the get go and, as a testament to that, we've grown our community and contributors a lot (50+ now); Envkey was closed-source for a long time before deciding to open-source more recently.

- Infisical is E2EE with opt-out ability so user's can sync secrets directly to cloud platforms like Vercel, Render, GitHub, Netlify, etc. via their APIs; Envkey doesn't have this capability.

- Infisical's client is browser-based; Envkey's is an application you can download back.

Depending on your circumstance and needs, you may find pros and cons for going with either solution.

I will acknowledge that Envkey has been around for much longer, so it may have broader functionality in some respects (e.g. they have SDKs developed across most major languages that we have on our roadmap for the following quarters). Lastly, (small mention) I think that we do care about UI/UX more than a lot of other solutions in the market.

These are just some early thoughts; will add on as more come in.

Re: Launch HN: Infisical (YC W23) – Open-source secrets manager for developers

#80

Hey, congratulations on the launch. How does this compare to EnvKey[1]? [1]: https://envkey.com

Thanks! We're both in the same domain, open-source, and E2EE. Right off the bat, I'd say there are a few key observable differences: - Infisical is open-source more-or-less from the get go and, as a testament to that, we've grown our community and contributors a lot (50+ now); Envkey was closed-source for a long time before deciding to open-source more recently. - Infisical is E2EE with opt-out ability so user's can…

Hey, CEO of EnvKey here. Congrats on the launch! Adding a few points to your points:

- The server portion of our v1 was closed source, but all client-side code has been open source all along. Now we're fully open source, as you say.

- Syncing to other platforms can be useful, but apart from breaking end-to-end encryption, it more or less guarantees that you're going to end up with consistency bugs. This is just the nature of failure modes in distributed systems. EnvKey's single source of truth architecture ensures consistency. Config and secrets are always pulled from EnvKey rather than being duplicated across platforms. Also, since all that is needed to integrate with any platform is to set a single environment variable, custom-built integrations are rarely needed (we do have a light-weight one for Heroku, but that's it).

- Browser-based is good for UX and convenience, but it nullifies most of the security benefits of end-to-end encryption. Browser-based end-to-end encryption doesn't protect against attackers or insider threats.

I'd also add that we care a lot about UI and UX as well, but we see our goal as making the best UI and UX that is possible while offering real, uncompromising end-to-end encryption. This does require some UX tradeoffs, but in our view, given the sensitivity the data involved, they are worth it.

Post reply on HN