Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Infisical – open-source secrets manager

github.com

Post reply on HN
Print view View original

11–20 of 99 posts

Re: Show HN: Infisical – open-source secrets manager

#11

Post by gregwebs »

jbotz wrote: post #7

Environment variables are not a good way to pass secrets around. For a list of reasons see this 2017 blog post: https://blog.diogomonica.com//2017/03/27/why-you-shouldnt-us... The TLDR is, first environment variables are visible to every process running as the same user on the system (try 'ps eww') and second they leak very easily in debug logs, etc.

That is considered better, but there are still potential attack vectors such as directory traversal. More secure yet is to have the application decrypt the secret in memory.

Re: Show HN: Infisical – open-source secrets manager

#13

Post by idealmedtech »

gregwebs wrote: post #11
jbotz wrote: post #7

Environment variables are not a good way to pass secrets around. For a list of reasons see this 2017 blog post: https://blog.diogomonica.com//2017/03/27/why-you-shouldnt-us... The TLDR is, first environment variables are visible to every process running as the same user on the system (try 'ps eww') and second they leak very easily in debug logs, etc.

That is considered better, but there are still potential attack vectors such as directory traversal. More secure yet is to have the application decrypt the secret in memory.

Using which key?

Re: Show HN: Infisical – open-source secrets manager

#14

Post by mberning »

I just can’t get over using environment variables for this type of stuff. An attacker can bootstrap a lot just from compromising an ssh login. Platforms like JWS had the right idea. You used tokens in config files and the platform vault knew how to inject the value at runtime. Nothing was exposed in the environment variables or run command.

Re: Show HN: Infisical – open-source secrets manager

#15

Post by sofixa »

idealmedtech wrote: post #13
gregwebs wrote: post #11

Earlier quoted context omitted.

That is considered better, but there are still potential attack vectors such as directory traversal. More secure yet is to have the application decrypt the secret in memory.

Using which key?

Ideally a single use one.

Re: Show HN: Infisical – open-source secrets manager

#16

Post by ahofmann »

goodpoint wrote: post #12

meh.

"meh" as the only feedback I find extremely condescending. Someone has done (a lot of) work, written a tool that is considered useful enough, and kindly made it available to everyone with a free license. I feel only gratitude for this action, and if anything I would post constructive feedback. Not a coldhearted "meh".

Re: Show HN: Infisical – open-source secrets manager

#17

Post by vmatsiiako »

gregwebs wrote: post #8

This looks great! But after looking through the docs and Github, I don't know what the architecture is beyond there is a CLI and a browser UI that interact with some sort of central service. The main thing stopping me from using Vault is that it can become a central point of failure. If the cloud provider secret managers are down then its likely that something else in the cloud is having major issues as well so from…

Thank you! Besides the CLI and browser UI, we also support a range of integrations (we're still working on this but you can already see some of them in the Integrations section of our ReadMe: https://github.com/Infisical/infisical; or here in docs: https://infisical.com/docs/integrations/overview). With that, you can auto-inject your secrets into those 3-rd party services. You can also inject your secrets into Kubernetes etc (https://infisical.com/docs/integrations/platforms/kubernetes). For larger teams, the web UI is also very useful since they can control which user is accessing what secrets, check the version history, and more!

Vault's pricing is outrageous indeed! This is something that we tried to do differently with Infisical by providing a very generous free plan, so that community and small developer teams can use the service for free.

The point about downtime is fair! Though, being open-source is also a big advantage here. You can self-host Infisical in the same place where you self-host your main app. This (slightly) minimises the risk of downtime with respect to your main project.

Re: Show HN: Infisical – open-source secrets manager

#18

Post by dang »

goodpoint wrote: post #12

meh.

Could you please stop posting unsubstantive and/or flamebait comments? You've been doing it quite a bit, unfortunately. It's not what this site is for, and destroys what it is for.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

Re: Show HN: Infisical – open-source secrets manager

#20

Post by eranation »

tony-infisical wrote: post #2

Hey everyone! Stoked to show y'all what we've been working on this past few months. Appreciate your feedback and will be hanging out here to answer any questions :)

Love it and thanks for open sourcing it!

My 3 cents: To save issues with enterprise lawyers not approving to use your repo because it has a non standard MIT license, I would HIGHLY recommend creating a separate repo for the paid features, and leaving the open source one intact. A small additional effort to break your monorepo into 2, a huge time saver when you try to monetize it and realize this small addition goes from "automatically approved, regular MIT license" to "I need to open a ticket with legal as our open source compliance tools (e.g. blackduck) flagged it as non standard"

Post reply on HN