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

61–70 of 99 posts

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

#61

Post by linuxdude314 »

mberning wrote: post #14

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.

Yes, same here. It’s such an absurd design decision it makes me question if this isn’t a honeypot of sorts.

Injection at runtime is the target secret managers should be trying to hit.

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

#62

Post by vmatsiiako »

linuxdude314 wrote: post #57
vmatsiiako wrote: post #54

Earlier quoted context omitted.

This is something that we are actively thinking about actually! It's currently CLI only. API's definitely quite a lot of work, but it's probably worth it. Could you please create an issue for it here: https://github.com/Infisical/infisical/issues This way, you can stay updated about when it's ready. Thank you!

Does that imply that your CLI is directly connecting to MongoDB without some sort of backend service running?

No, our CLI is connecting to our backend service which then connects to our database. The backend is not ready to be used by the public as it's not super user-friendly and not well-documented; however, this is a great idea and would increase the use case for Infisical

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

#63

Post by vmatsiiako »

klabb3 wrote: post #59
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.

This is not something a startup can change directly. If you are too purist you’ll never get traction. What they can do however, is push towards better options, publish or reuse an interoperable spec, and offer it on an opt-in with good dx.

Thank you! This is our plan indeed! Environment variables are still by far the most popular approach for storing secrets - and we are trying to create a better (more secure) alternative for managing environment variables and secrets than, let's say, .env files, and at the same time an easier alternative compared to other secrets managers. With time, we will be adding more niche and secure approaches mentioned in this thread to direct the developer community.

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

#64

Post by linuxdude314 »

vmatsiiako wrote: post #6
candiddevmike wrote: post #4

Obligatory how does this compare to Vault or Conjur?

The main goal is to provide similar levels of security at a reduced learning curve. While Hashicorp Vault has a lot of features, I found it to be quite overwhelming... We created Infisical to take a modern approach to secret management by simplifying the whole process of configuring secrets and injecting them into your stack with the least friction possible. We also invested a lot of effort in the UI/UX in order to m…

It doesn’t provide even remotely close to the same level of security as Vault because of how it’s designed with environment variables in mind.

The lack of an API means if they want to add secret injection without env vars, you will be launching a CLI command in a thread or subprocess as opposed to using a native library.

There is something to be said about creating a secret manager that is easier to use than vault, but this misses the mark in way to many areas for me to consider it a serious contender.

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

#65

Post by 9dev »

vmatsiiako wrote: post #44
bearzdev wrote: post #39

Earlier quoted context omitted.

Has anyone on staff been through a soc audit? Which trust criteria will be used? Does the app support data stores other than mongo?

Yes, we're quite familiar with SOC guidelines. We will be including all of Security, Confidentiality, Privacy, Availability, and Processing integrity categories into the SOC 2 examination. I think, given that Infisical is a secret-manager, all of these are very important! Currently, we only support Mongo, although we received requests for some other ones. Which one are you interested in?

Oh, Mongo is a major turnoff. The only sensible data store to support in 2022 and beyond is Postgres, maybe SQLite IMO.

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

#66

Post by hardwaresofton »

bearzdev wrote: post #39
vmatsiiako wrote: post #31

Earlier quoted context omitted.

This is actually something that we are planning to do very soon. We are currently in the public Alpha stage, but our plan is to get both a security audit and SOC 2 compliance in the coming months!

Has anyone on staff been through a soc audit? Which trust criteria will be used? Does the app support data stores other than mongo?

Postgres!

But better yet you might want to make sure there is an abstraction layer so people can plug stuff in.

It’s a extra work but it only gets harder to do later.

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

#68

Post by NathanFlurry »

DrBenCarson wrote: post #43
NathanFlurry wrote: post #38

Congrats on the launch! The first thing that strikes me is the flat organizational structure of secrets. We have at least 45 KV secrets per environment in Vault organized in a directory structure over at Rivet. Managing access policies and organizing these without a directory structure would not be fun.

Do you mind sharing a bit more about Rivet? Never heard of it before. Thanks!

We help developers build and scale multiplayer games (https://rivet.gg). Our backend has a lot of moving parts, so we spend a lot of time dealing with moving secrets around. We recently joined the YC W23 batch and launching an open beta next month. Cheers!

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

#69

Post by Aeolun »

linuxdude314 wrote: post #56
vmatsiiako wrote: post #44

Earlier quoted context omitted.

Yes, we're quite familiar with SOC guidelines. We will be including all of Security, Confidentiality, Privacy, Availability, and Processing integrity categories into the SOC 2 examination. I think, given that Infisical is a secret-manager, all of these are very important! Currently, we only support Mongo, although we received requests for some other ones. Which one are you interested in?

Almost any other standard database would be a better choice: Postgres, MySQL, even Redis. Most companies avoid using MongoDb and lack the staff needed to administer it properly. It’s also hard to find a managed solution for Mongo in most cloud providers.

But you don’t need any cloud provider other than AWS, so why worry about that?

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

#70

Post by vmatsiiako »

stuaxo wrote: post #67

Great ! I will have to have a play with this. After losing a laptop I've been wanting setting to manage env vars for local dev projects that keeps on them encrypted at rest.

Let me know if you have any questions or issues.

You can join our Slack if you need anything: https://join.slack.com/t/infisical-users/shared_invite/zt-1k...

Post reply on HN