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

31–40 of 99 posts

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

#31

Post by vmatsiiako »

thamer wrote: post #25

I didn't see any reference to an external security audit on your website, so have you done one and if not are you planning to? All serious products in this space publish these third-party audits and sometimes certifications. See the page for Vault: https://www.hashicorp.com/vault-compliance Or 1Password: https://support.1password.com/security-assessments/ As the comment from jbotz mentioned, exposing secrets in envir…

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!

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

#32

Post by IncRnd »

vmatsiiako wrote: post #30
IncRnd wrote: post #27

HN Title: Infisical – open-source secrets manager Github text: Infisical is an open-source, end-to-end encrypted tool to sync environment variables across your team and infrastructure. Which does it do? Does it manage secrets, or does it sync environment variables?

It's both, actually! Sorry for the lack of clarity. Infisical is designed to be both easy and efficient enough to store any environment variables, but also secure and end-to-end encrypted to store secrets.

Do I understand correctly that if I place secrets into the store that those secrets will be synced to environment variables across machines?

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

#33

Post by dakiol »

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.

And where do you store the key to decrypt the secret?

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

#34

Post by maidul »

IncRnd wrote: post #32
vmatsiiako wrote: post #30

Earlier quoted context omitted.

It's both, actually! Sorry for the lack of clarity. Infisical is designed to be both easy and efficient enough to store any environment variables, but also secure and end-to-end encrypted to store secrets.

Do I understand correctly that if I place secrets into the store that those secrets will be synced to environment variables across machines?

Yes, if you have integrations set up (docker, kubernetes, etc.) then those secrets in the store will be synced to the respective environment

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

#35

Post by alexeldeib »

simonw wrote: post #23
sofixa wrote: post #15

Earlier quoted context omitted.

Ideally a single use one.

How do single use keys work? I had a quick search but couldn't find a pattern for them in Python.

Check out vault’s response wrapping with cubbyhole for one such case.

Note this still takes a dependency on the service.

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

#36

Post by vmatsiiako »

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 always a very heated discussion topic :)

We started developing Infisical for the majority of people using environment variables right now. We actually have some plans for accommodating for other more secure approaches very soon. Stay tuned.

Feel free to join our Slack for any updates: https://join.slack.com/t/infisical-users/shared_invite/zt-1k...

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

#37

Post by eyakubovich »

turtledragonfly wrote: post #19

Ahhh, a self-hosting option. I might actually take a look at it! I'm so tired of systems handling highly-confidential information (such as passwords and secrets material) being Cloud-only. Or even cloud-first.

IIUC, Infisical uses end-to-end encryption. Does that change your attitude towards cloud-only options? I'm genuinely curios to understand how SaaS products can be made secure so people are comfortable using them for sensitive data.

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

#38

Post by NathanFlurry »

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.

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

#39

Post by bearzdev »

vmatsiiako wrote: post #31
thamer wrote: post #25

I didn't see any reference to an external security audit on your website, so have you done one and if not are you planning to? All serious products in this space publish these third-party audits and sometimes certifications. See the page for Vault: https://www.hashicorp.com/vault-compliance Or 1Password: https://support.1password.com/security-assessments/ As the comment from jbotz mentioned, exposing secrets in envir…

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?

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

#40

Post by wryun »

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.

I believe you can somewhat mitigate these concerns by reading and removing the secrets on startup, ideally whitelisting the entire env.
Post reply on HN