[HN Gopher] Launch HN: Infisical (YC W23) - Open-source secrets ...
___________________________________________________________________
Launch HN: Infisical (YC W23) - Open-source secrets manager for
developers
Hi HN, we're the co-founders of Infisical (https://infisical.com),
an open-source platform to sync application secrets and configs
across your engineering team and infrastructure. We enable teams to
store their secrets in a centralized location and distribute them
anywhere from local development processes to staging/production
environments. Our Github is at
https://github.com/infisical/infisical. We previously worked at
AWS, Figma, and another startup, where we frequently ran into
problems dealing with secret management. For example, many
companies used .env files to maintain their development secrets and
struggled to keep secrets in sync amongst their teams (this
routinely posed security and efficiency issues -- secrets can get
leaked or go missing). Some companies (especially bigger ones) used
solutions like Vault which can be difficult to set up, maintain,
and afford. While secret managers exist, they're imperfect for
many reasons: open-source solutions are either too complicated, not
comprehensive, not user-friendly, or a mix of all three; there are
nicer closed-source solutions but with no self-hosted options
available. The gap we see is to make something that's simple, open-
source, and powerful. On the open-source front, our goal is to
provide full transparency of our codebase and enable anyone in the
community to build anything they want in an optimal secret
management solution. If you need any feature or integration that we
don't yet support, you can post an issue about it or directly send
in a PR to be reviewed immediately. You can inject the right set
of secrets for any environment into your application by using the
Infisical CLI together with your application start command (e.g.
infisical run -- npm run dev). This removes the need to use a .env
file. Everything stays encrypted with encryption/decryption
operations occurring on the client-side -- under the hood, secrets
are encrypted by vault keys for which there are multiple copies of
vault keys encrypted under the public key of each member of a vault
(ensuring only members of vaults can decrypt secrets pertaining to
that vault locally). An alternative way is to use our Open API -
though it's a little complicated, and we're working on adding SDKs
to abstract away the cryptography. Infisical integrates with
staging and production cloud services like AWS, Vercel, GitHub
Actions, and Circle CI. We also added support for integrations with
Docker, Kubernetes, and Terraform. Infisical is now a central
source of truth for secrets across the entire development cycle
from development to production with new integration releases every
week. One interesting thing is that, by default, our platform is
end-to-end encrypted but users can opt out of that if they need to
integrate with cloud platforms that require secrets to be sent in
decrypted format (e.g. GitHub Actions, Vercel, Render). We're the
only solution that we know of that offers this E2EE-with opt-out
ability. Since our last Show HN
(https://news.ycombinator.com/item?id=34510516), we've layered
authentication with 2FA (more MFA options coming soon) and upgraded
all private key encryption/decryption steps to involve a 256-bit
protected key decrypted by another key generated via Argon2id KDF
from the user's password. We are starting the process of obtaining
SOC2 and other security and compliance certifications. You can read
more about our security here:
https://infisical.com/docs/security/overview Beyond this, we've
added integrations with PM2, AWS Secrets Manager, AWS Parameter
Store, Circle CI, Travis CI, GitLab CI/CD, Terraform and more.
We've also redesigned the main dashboard and added more advanced
organizational structure for secrets. Lastly, we have added role-
based access control, and improved our Kubernetes operator: your
clusters are now auto-redeployed when secrets in Infisical change.
In the coming weeks and months, we plan to add features like secret
rotation, improved audit logs, SDKs and alerts; as well as increase
the range of our integrations; and continue fortifying platform
security and stability. We've launched this repo under the MIT
license so any developer can use the platform. We don't charge
individual developers or small teams--all the integrations are
fully available to everyone. We make money by charging a license
fee for enterprise features as well as providing a hosted version
and support. If you found it interesting, you can see a demo video
here: https://www.loom.com/share/9a8904c6ecc84d0899d53ee1f7a36385
We'd love for you to give Infisical a try (https://infisical.com)
and provide any feedback. If you're interested, our code is
available here: https://github.com/infisical/infisical. If we don't
have something, let us know and we'd be happy to build it for you.
We look forward to your comments!
Author : vmatsiiako
Score : 188 points
Date : 2023-02-27 12:39 UTC (10 hours ago)
| [deleted]
| Terretta wrote:
| OK, aside from "open source", and assuming clients will be
| comparing paid enterprise to paid enterprise, how would you
| describe your value prop relative to Doppler?
| vmatsiiako wrote:
| 2 main points:
|
| - Infisical is by default end-to-end encrypted which means that
| we are not able to read you secrets (unless you give us
| explicit permissions for integrations that require it). This is
| not the case for many other products in the market, like
| Doppler.
|
| - "Open source" is actually a big differentiator in this case,
| because people and companies can self-host Infisical on their
| own infrastructure. I can't really imagine JP Morgan storing
| their secrets on someone else's cloud. Many companies we talk
| to have very strict compliance restrictions, and this is where
| Infisical come in
| candiddevmike wrote:
| If being open source is such a big differentiator, why do you
| not reference it on your pricing page at all?
| https://infisical.com/pricing
|
| I really wish companies would stop using open source as a
| growth hack.
| vmatsiiako wrote:
| It is actually mentioned on the pricing page! (in one of
| the FAQ questions)
| mynameisvlad wrote:
| I wouldn't exactly consider a mention in passing on a
| "What is Infisical" to be exactly headlining the fact
| that it's open source.
| vmatsiiako wrote:
| There is actually a question about self-hosted Infisical
| too. But I agree with you - we will do a better job for
| mentioning open source - we think this is VERY important,
| so this is definitely not our intention to hide it
| nonethewiser wrote:
| How does getting permission make you "able" to read secrets?
| It seems like maybe you can read everyone's secrets but
| you're promising not to.
| dangtony98 wrote:
| This has to do with how our underlying cryptography works;
| it's end-to-end encrypted by default with opt-out ability
| for integrations that need it. You'd have to manually login
| to Infisical and grant that permission but the platform
| itself would be unable to read your secrets otherwise.
|
| Technical details: In Infisical, secrets are stored in
| vaults (we call them projects). They are encrypted
| symmetrically by vault keys for which there are multiple
| copies of vault keys encrypted under the public key of each
| vault member (your teammates). Vault members decrypt their
| copy of the vault key locally and use that to decrypt
| secrets (in browser or via CLI similar to platforms like
| 1Password and Bitwarden); this client-side decryption
| process makes it impossible for the platform itself to
| decrypt the secrets itself.
|
| What is meant by users having the ability to give
| permission to Infisical to access/read secrets is to share
| a copy of the vault key by encrypting it under one of the
| public keys of Infisical -- we employ an abstract concept
| of "bots" that have public-private key pairs assigned to
| each vault. When you share a copy of the vault key with
| Infisical (which can't happen without your explicit
| action), it grants Infisical the ability to access your
| secrets for integrations like Vercel, Render, GitHub, etc.
| nonethewiser wrote:
| Very well explained, thank you.
| nicoburns wrote:
| Presumably the permissions switch is in the client rather
| than the server. It's true that you have to trust the
| client, but that's unavoidable.
| dangtony98 wrote:
| Yeah that's correct.
|
| The permissions switch can only be on the client because
| that's where sharing the vault key with Infisical by
| encrypting it under one of its public keys occurs.
| debarshri wrote:
| Open source is a distribution strategy. Dont forget cyberark,
| thycotic et al in the enterprise space. They have super
| strong sales motion in the JP Morgans of the world.
| dangtony98 wrote:
| Open source is a lot to unpack haha -- There's a ton there
| but yea I think giving the ability for people to self-host
| the solution is a really important in our mission to
| increase access to secret management tools to all
| developers.
|
| Infisical is already pretty easy to self-host but we want
| it to be even easier -- Likely by introducing a 1-click
| deploy to Heroku/Digital Ocean for folks that need that.
|
| And yea ack with the enterprise space solutions you
| mentioned. We've a long way to go as a secret manager but I
| have hopes that one day we'll get to a world-class product
| that's as good and better!
| vishnumohandas wrote:
| Hey, congratulations on the launch. How does this compare to
| EnvKey[1]?
|
| [1]: https://envkey.com
| dangtony98 wrote:
| 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.
| danenania wrote:
| 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.
| lopkeny12ko wrote:
| Does anyone have suggestions for a _truly_ free-as-in-freedom and
| open source secrets manager? I 'm so tired of seeing these quasi-
| open source products that dual-license their source code and lock
| essential features like SSO behind an enterprise paywall. Every
| one of these VC-funded startups always eventually goes down the
| drain as their backers seek to recoup these investment dollars.
| log101 wrote:
| Not related but who or what tool designs these "startup pages"? I
| need it for my own work.
| vmatsiiako wrote:
| I designed it actually :)
|
| Happy to help if you have any questions! It's a combination of
| Next.js + Tailwind + Figma. Oh, and we also use Framer Motion
| for animations on the landing page.
|
| I also get a lot of inspiration on Dribbble.com
| corywatilo wrote:
| Some of it was sourced from posthog.com
| vmatsiiako wrote:
| Indeed! Especially the idea for the Slider part. We love
| PostHog
| iLoveOncall wrote:
| Have you invested in automated testing since the last HN post?
|
| Basic good practices like this being ignored does not give
| confidence in other aspects of the business and is a deal breaker
| for anything related to sensitive data like secrets.
| dangtony98 wrote:
| We received a ton of feedback since our last HN post regarding
| many aspects of Infisical. We've had to prioritize user
| feedback in the last month, and one of the decisions we made
| together with our community was to move robust testing to March
| in order (see roadmap here: https://www.notion.so/infisical/be2
| d2585a6694e40889b03aef96e...) to address some other feedback
| first.
|
| In terms of stability/security, I'm happy to say that we made
| HUGE improvements to platform-wide security, primarily
| revamping cryptography dealing with managing private key
| encryption/decryption operations (adding a protected key
| mechanism and Argon2id KDF - happy to elaborate more if needed)
| and adding MFA. Now that we're done with these updates, we'll
| be adding robust testing going into March and discussing it
| along with our community.
| hekike wrote:
| This is awesome! So no more pbpaste | base64 | pbcopy with
| Kubernetes secrets? I won't miss base64 and yamls.
| vmatsiiako wrote:
| Indeed! You should check out out docs for Kubernetes here:
| https://infisical.com/docs/integrations/platforms/kubernetes
| ianpurton wrote:
| Hi. I'm also working on an E2E secrets manager.
| https://github.com/purton-tech/cloak
|
| A few tips.
|
| 1. It looks like I'm able to do account enumeration on your login
| page. For a secure app you want to make sure this is not
| possible.
|
| 2. Your CSP https://csp-evaluator.withgoogle.com/ has unsafe-
| eval. I would lock that down.
|
| 3. Your app seems to be JS based, which is OK but it means you
| have a whole bunch of supply chain attacks on nodejs to worry
| about. You should only run the bare minimum JS on the frontend
| when dealing with encryption keys.
|
| 4. You're storing keys in local storage. There's a trick you can
| do, if you store an actual CrypoKey object instead of a string
| and set non extractable to true you can stop JS extracting
| private keys.
|
| 5. For key stretching looks like your using Argon2-browser.
| Actually browsers come with a built in with PBKDF2 that runs
| faster than a JS based argon. So I'm able to get 10 million
| iterations in a few seconds which is an NIST recommendation.
|
| 6. Some of your dependencies look like they are not maintained
| anymore. i.e. argon2-browser.
|
| This is what I was able to find so far. Hope this helps.
| chromatin wrote:
| Feedback on Cloak:
|
| The javascript for the sign-up form doesn't activate the
| password-strength meter unless ther are keypresses in the
| primary (not verify) password box. This means when using
| Firefox auto-suggest strong password, we have to go type and
| then remove characters from the box to proceed.
| ianpurton wrote:
| Thanks. I'll take a look at that.
| dangtony98 wrote:
| Ack. Thanks for the points. Un-packing a few things:
|
| 3. Definitely -- We're working to cut our dependencies in the
| coming months. Most existing dependencies (the backend at least
| - I focus more on this area) we stick to those widely used and
| those essential to the platform; there're also certain
| dependencies directly linked to integrations with third-party
| platforms (e.g. AWS, Octokit - GitHub, etc.).
|
| 4. We'll definitely take a look at this -- This is on our
| immediate roadmap as well. We had a few ideas in mind related
| to a mix of components in browser-memory, session-storage, etc.
| as well but wanted to make sure we get it 100% right before
| deploying any changes - based on recommended practices like
| from Auth0. This article may be relevant:
| https://auth0.com/docs/secure/security-guidance/data-securit...
|
| 5. We actually did evaluate both PKDF2 and Argon2id options in
| addition to seeing what other secure platforms are doing. We
| found most to start out with PKDF2 but overtime to introduce
| support for Argon2id -- Take Bitwarden and Dashlane as two
| examples of this; Bitwarden of which introduced it as of only a
| few months back. This article may help:
| https://soatok.blog/2022/12/29/what-we-do-in-the-etc-shadow-...
|
| The choice of Argon2id KDF is sound and recommended; we have it
| with memory cost of 64MiB, ops cost of 3, and parallelism of 1.
|
| 6. argon2-browser is still used well and reliably throughout
| the ecosystem -- take Bitwarden as the biggest example of a
| solution recently making the switch to use it.
|
| Anyways, happy to move this discussion to email!
| Hansenq wrote:
| Check out https://socket.dev/ Been super impressed by their
| approach to identifying and securing codebases against supply
| chain attacks (and I believe they have a special deal for
| open source repos too!)
| vmatsiiako wrote:
| Thank you for pointing this out! Happy to take a look and
| discuss what you're building! I agree with some of these tips,
| but I think it's best to report them privately to
| team@infisical.com. We can then see with our team if these
| points are correct. Otherwise, this goes against responsible
| practices of security notifications and sounds more like an ad
| for your project.
| pc86 wrote:
| Wow, this comment is more than enough to make sure I never
| use your product.
| sveme wrote:
| You open-sourced your code - isn't this scrutiny exactly what
| you would want to achieve? Alternatively, I would expect
| these reports to be reported via your issues tracker.
| dangtony98 wrote:
| Yup!
|
| We appreciate feedback we can get across all aspects
| including security but employ a security policy of
| reporting any security concerns via email - this is pretty
| standard practice we've seen.
| 1ba9115454 wrote:
| Standard practice is to do a full security audit before
| you onboard customers.
| dangtony98 wrote:
| We're preparing to do a SOC2 with Vanta first followed by
| a security audit with some firm like Trail of Bits next.
|
| We're fortifying the codebase every day and would expect
| this process to be complete in the next 2 quarters.
| Implicated wrote:
| > the next 2 quarters
|
| 6 months? I'm not being sarcastic here - I'm not on the
| security or enterprise side of things, but this seems
| like a long way off for something like a secrets manager.
| Just out of curiosity, what would hold you back from
| doing this _prior_ to launching?
| dangtony98 wrote:
| Getting certified is unfortunately not an overnight task
| ... SOC2 alone will likely take months and that's not yet
| factoring in the security audit as well. As much as we'd
| like to have it done ASAP, a lot of it is dependent on
| the length of the process and requirements to be met -
| that's why my estimate is within the next 2 quarters
| (sooner the better).
|
| As an open source company, we've basically "launched"
| since the moment we open sourced the codebase - it's a
| constant iteration process for us and every week we
| release security updates as part of our roadmap. Security
| certifications and audits are something we're starting to
| do in parallel at the moment whilst still being early in
| our journey (open sourced 3 months ago roughly).
| vmatsiiako wrote:
| I completely agree! I must say though, this is not fully
| dependent on us! SOC2 is a very lengthy process that also
| depends on auditors. This is one of our main priorities
| at the moment.
| whylo wrote:
| > employ a security policy of reporting any security
| concerns via email
|
| You don't have a security.txt,
| https://infisical.com/docs/security/overview doesn't
| mention it and it's not on your FAQ, so I don't blame
| ianpurton for not finding it. You have a 'Report a
| vulnerability' issue template on GitHub (https://github.c
| om/Infisical/infisical/security/advisories/n...) but then
| your readme points to a security policy which says to
| email:
| https://github.com/Infisical/infisical/security/policy
| dangtony98 wrote:
| There are 3 different locations in the GitHub repo
| regarding the security policy: a SECURITY.md file
| containing instructions to report security
| vulnerabilities to team@infisical.com -- this is employed
| in other open core repos like Strapi, PostHog, Chatwoot;
| a security policy on the sidebar that links to the
| SECURITY.md; and a security section in our README that
| also links to the SECURITY.md.
|
| There's also an issue template for reporting
| vulnerabilities as well as you mentioned.
|
| That said, we'll add info to the security page in our
| docs to contact us regarding vulnerabilities.
|
| Thanks!
| JoBrad wrote:
| I took it as establishing credentials. They didn't compare
| your project to their's, and they offered helpful
| alternatives.
| camjw wrote:
| > sounds more like an ad for your project
|
| I feel like somehow your response is the opposite of an ad
| for your project.
| ianpurton wrote:
| OK. I'll stop looking now. However if you do require a
| security review then I would be happy to oblige.
| nodesocket wrote:
| How does the Kubernetes integration work? Can we specify a
| infisical secret to reference inside of a Kubernetes secret
| manifest yaml? Thanks.
| maidul wrote:
| The Kubernetes integration allows you to periodically fetch
| secrets from an Infisical project and save them to a native
| Kubernetes secret. You simply specify the service token that
| should be used to retrieve the secrets from infisical and the
| operator handles the rest. Read more about it here!
| https://infisical.com/docs/integrations/platforms/kubernetes
| naaabs wrote:
| Great job team!!
| xs83 wrote:
| I don't see Terraform in your docs? Is it hidden away somewhere
| or not fully supported?
| vmatsiiako wrote:
| It seems like they haven't been merged yet. Check out the PR
| here: https://github.com/Infisical/infisical/pull/380
|
| We also have a full provider under development here:
| https://github.com/asheliahut/infisical-provider-terraform
| ensignavenger wrote:
| As soon as I see a product is open core, I immediately start
| wondering what critical features are going to be proprietary. I
| don't see this information immediately on your website- is there
| a page where you outline what features you plan to keep
| proprietary?
| vmatsiiako wrote:
| Right now most of the features are available under the MIT
| license. For example, absolutely all the integrations, CLI,
| API, etc are available like that.
|
| Basically, all the features that are needed by individuals and
| small teams will always stay completely free.
|
| Some of the features that we are thinking to make proprietary
| are audit logs, sso, role-based access controls. Would love to
| hear your thoughts on this, because this is still in the very
| active stage of development!
| ensignavenger wrote:
| What you decide is "needed by individuals and small teams" is
| not always what an individual or small team actually needs.
| This makes the open core model extremely difficult to get
| right (I am not sure I know any examples of anyone who has
| continued to do it right for very long).
|
| For example, I would love SSO for my homeserver, so that I
| can share secrets with my family. I would guess that my
| family is a "small team", but many open core products don't
| open source SSO features. Many small actual businesses would
| prefer SSO too, as juggling multiple logins is as much a pain
| for a small team member as it is for a member of a big team.
|
| I appreciate any open source contribution even if it is
| missing features. I understand it can be difficult to sell a
| product that is 100% open source.
|
| Even when I am implementing something for a larger
| organization, I always prefer to specify open source over
| open core.
|
| I end up very rarely adopting any open core product due to
| missing features- and when I do, I am often spending money
| re-implementing the closed source features, and thus the
| money isn't there to pay the company for support. I don't
| know how common this approach is, I just know a lot of open
| core products get skipped by me because of limitations.
| vmatsiiako wrote:
| Would you say GitLab didn't manage to keep it right over
| the period of many years?
|
| I agree that it's very hard but that's also why we talk to
| our community and wee what they say about what features
| they need. I really happy hope that we can create a great
| open product for small teams and individuals over a long
| term too.
| ensignavenger wrote:
| Actually, Gitlab used to be my go-to example of "Open
| Core done right", but now they have so many closed source
| features mixed in with open source features it is hard to
| use the open source product at all. I am either looking
| for a smaller product with fewer features anyway, or a
| product with more features (like maybe Gitlab tries to
| be) and the ones I want are the ones Gitlab happens to
| keep proprietary!
|
| Ultimately, small teams often have the same challenges
| large teams have. I wish you great luck!
|
| PS
|
| At some point you might want to do product comparisons on
| you site- one of you competitors, Hashicorp does a pretty
| good job of outlining the similarities and differences as
| they see it with similiar options, I would suggest
| following their example. Even if Hashicorp ultimately
| adds a comparison with your product, having your own
| perspective is very helpful in making a quick comparison.
| dangtony98 wrote:
| I definitely share the concerns/thoughts around open core
| and keeping too many features closed source here; it's a
| very difficult thing for companies to figure out what the
| right balance is for public/closed-source features.
| There's never a correct balance that satisfies everyone
| but the best we can do is deliberate which features would
| be more individual/team-oriented and which would be more
| enterprise-oriented to be charged.
|
| In terms of Infisical, this is honestly something we're
| still figuring out as we're mapping out our roadmap ahead
| -- We try to get feedback from our community in thinking
| about this since we all contribute to the codebase (also
| do feel free to suggest what you think would be
| appropriate).
|
| And yea thanks for the suggestion regarding product
| comparisons with competitors. We have that on the TODO
| list in addition to other tasks all related to enriching
| product information like providing more granular product
| pricing breakdowns!
| mynameisvlad wrote:
| I will definitely echo everything said here. Gitlab _used
| to be_ an amazing example of doing it right but nowadays
| looking at their release notes, they sprinkle in one or
| two free features while the vast majority are locked
| away.
|
| They do sometimes give the peasants access to the
| features months or years later, but the majority of
| features are still locked away.
| nicce wrote:
| Main selling point for GitLab was the CI/CD couple years
| ago, and now it is so restricted that I just had to
| leave.
|
| After they got that big funding when going public
| company, free features have been stripped and prices have
| increased. Same story as usual.
| jedberg wrote:
| 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.
| dangtony98 wrote:
| 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...
| plasma wrote:
| +1 to providing SSO to smaller plans, hard requirement for
| me.
|
| I manage small teams and it would be a requirement for us,
| and if pricing for a few users is $14/month, normally
| enterprise is higher than that and an annual commitment, but
| you wouldn't be able to get much budget out of me at this
| moment due to team size, but there is some there.
|
| When choosing tools like this, I pick ones I can grow with so
| I don't need to solve it again in the future, so while the
| team may be small, it can't adopt it if I cant start from
| that point.
| w4eg324g wrote:
| Why should someone use this when there are options within each
| Cloudprovider as well as Github and the like as well?
| heliodor wrote:
| They gave some reasons at the top.
| dangtony98 wrote:
| In many cases, your infrastructure may be sprawled from local
| development to cloud providers and CI/CD pipelines like you
| mention; you may have many environments each requiring their
| own set of secrets. This phenomenon is known technically as
| "secret sprawl" (see here for a fuller read:
| https://www.conjur.org/blog/what-is-secrets-sprawl-how-to-
| av...).
|
| There's a lot of issues with secret sprawl but I think the
| relevant one to your specific question mentioning other cloud
| providers would be having missing secrets across infrastructure
| (you introduce a new secret to the codebase and forget to
| update it everywhere else, as well as communicate it or sync it
| through to other developers on your team) -- applications
| crash, you lose time.
|
| A big idea in secret management amongst others is the idea of *
| _centralizing*_ your secret management in one place -- update
| here, update everywhere. We help achieve that across your
| entire infrastructure and have a handy dandy CLI that also
| helps you inject secrets back into your programs (achieving
| secret management for local development with zero application
| dependencies) if you need that :D
|
| I may be misinterpreting your question actually -- Unless you
| mean why use Infisical versus other alternatives on cloud
| providers like AWS Secret Manager / Parameter Store, Azure Key
| Vault, etc?
| aosmith wrote:
| This is cool, LMK if / when you're hiring.
| vmatsiiako wrote:
| Wow, sounds good! I followed you on twitter, so let's stay in
| touch!
| mikaeln wrote:
| Awesome work! Congrats on the launch.
| maidul wrote:
| Thank you!
| linsomniac wrote:
| TIL that systemd has a credentials component:
| https://systemd.io/CREDENTIALS/
| lifewallet_dev wrote:
| Thank you, 'cause I don't wanna do the wrap command thing they
| do. Besides that, this is a great idea.
| vmatsiiako wrote:
| This is actually not the only way to use Infisical (though
| it's probably the easiest one). You can also use our Open API
| and we are adding SDKs for the most popular languages in the
| next few weeks: https://infisical.com/docs/api-
| reference/overview/introducti....
| dangtony98 wrote:
| 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?
| oigursh wrote:
| systemd can cut your hair and mow your lawn but you'll never
| remember the commands to take the blindfold off and see it
| e12e wrote:
| Interesting that this uses mongodb[1] - doesn't that mean the
| service is open under the mongodb license? Or does the managed
| service not use mongodb? Or did they (mongodb) go back to a more
| sane license? Or is the infisical Mongo image based off a fork?
|
| [1] https://github.com/Infisical/infisical/blob/main/docker-
| comp...
| warp wrote:
| I thought there were a bunch of dead links on the page, but
| looking closer it's actually the "Star us on GitHub" banner
| extending some invisible element to the bottom of the page and
| blocking certain elements from being clicked on. (Firefox 111 on
| mac).
| vmatsiiako wrote:
| Thank you for pointing this out! Will try to fix this right
| now!
| vmatsiiako wrote:
| Just fixed this! Thank you!
| chromatin wrote:
| Website feedback:
|
| Click to start video only works at the edges of the video, not
| the center (Firefox 110.0, MacOS)
| vmatsiiako wrote:
| This should work now! Thank you!
| vmatsiiako wrote:
| Fixing this!
| s1k3s wrote:
| > All content that resides under any "ee/" directory of this
| repository, if such directories exists, are licensed under the
| license defined in "ee/LICENSE".
|
| Man I really hate how the term "Open Source" is used nowadays.
| vmatsiiako wrote:
| 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, advanced access
| controls). This helps us get the financial means to also
| maintain the free ope-source product better.
| pc86 wrote:
| 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.
| grinich wrote:
| I'm the founder of https://WorkOS.com ("Stripe for SSO")
| and I can _definitely_ say it takes a lot of eng work to
| build and maintain. The complexity is fractal as you scale
| to more and more enterprise users with esoteric systems.
| dangtony98 wrote:
| Big fans of WorkOS! Happy to be talking with your team
| about SSO options for Infisical :)
|
| We built out all our OAuth2 integrations with other
| platforms (different from SSO but something relatable),
| so we have an idea of how much work it is to maintain
| these types of "integrations" and related services...
| Clearly enough to warrant entire solutions like WorkOS
| dedicated for this exact purpose.
| jacobsenscott wrote:
| 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.
| dbmikus wrote:
| 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.
| dabeeeenster wrote:
| We just spent about 3 months refactoring our audit logging.
| If it requires "no" additional effort, you can just fork
| the project and provide that "no" effort yourself.
| dangtony98 wrote:
| 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 the platform not counting other
| events -- I hope this sheds more light on the audit logging
| side of things?
|
| Re SSO: Totally get this one and I'm aware of the SSO tax
| -- we're still figuring this one out but know currently
| that it's an absolute must for enterprises.
| pc86 wrote:
| 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.
| mbarneyme wrote:
| https://sso.tax/
| Kiro wrote:
| 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?
| mdekkers wrote:
| 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
| Kiro wrote:
| You're right. I misread the original post and also
| managed to do a double fail and misunderstand the SSO
| Wall of Shame as well. Sorry, mbarneyme!
| brandonmenc wrote:
| Why, what do you think it means?
|
| https://www.gnu.org/philosophy/open-source-misses-the-point....
| vmatsiiako wrote:
| Indeed! We are also planning to add the MIT-only copy of our
| repository that is going to remove all the ee licensed code.
| vmatsiiako wrote:
| [dead]
| andersonmvd wrote:
| previous discussion 2 months ago
| https://news.ycombinator.com/item?id=34055132
| vmatsiiako wrote:
| Also, check out roadmap and let us know if you have any
| suggestions:
| https://www.notion.so/infisical/be2d2585a6694e40889b03aef96e...
___________________________________________________________________
(page generated 2023-02-27 23:01 UTC)