This is awesome! We use Doppler at the moment but this looks good to switch over.
Amazing! Let us know if you need any help setting up :)
Show HN: Infisical – open-source secrets manager
81–90 of 99 posts
Re: Show HN: Infisical – open-source secrets manager
#82Environment 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 mostly don't agree. Environment variables and the 12 factor app are still the common way to do things, and there is a lot of guidance out there on making it secure. Kubernetes lets you use a secret for the value of an environment variable, and it limits the scope to within the container and those who can access them like Kubernetes admins.
The post strongly recommends storing the secret in a file instead of an environment variable, but it doesn't say anything about unmounting the secrets after initialization. Usually if you have access to one you also have access to the other. It also doesn't mention that you might not have any subprocess, or that if you do have a subprocess the subprocess might need the secrets.
If you're using containers to maintain the principle of least privilege, it's important to carefully examine everything that has access to the container, but having different levels of access within the container beyond what the programming language provides is a niche use case.
The programming language helps you know what the inputs, outputs, and side effects are - so you can be confident a module doesn't actually have access to things it doesn't need, even if writing some code would do it. Things like WebAssembly, vm2, and Deno are helping with that, and all are guarded against environment variable leakage.
Edit: For WebAssembly I looked into WASI and there are some explicit and implicit ways of providing environment variables. Gotta be careful with the implicit ones. There's this that can be used to give a WASM module access only to specific environment variables or none - don't call inherit_env https://docs.rs/wasmtime-wasi/0.21.0/wasmtime_wasi/struct.Wa... There is this that provides a convenience function for creating a WasiCtx that has access to all environment variables though: https://docs.rs/wasmtime-wasi/0.21.0/wasmtime_wasi/struct.Wa...
Re: Show HN: Infisical – open-source secrets manager
#83This looks great! Vault is such a headache sometimes... Will consider switching
Re: Show HN: Infisical – open-source secrets manager
#84Earlier 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?
Plain-text (encrypted) files and/or sqlite would be a great complement to whatever else.
Re: Show HN: Infisical – open-source secrets manager
#85Environment 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.
plaint-text files (pick any of yaml/ini/toml/json/.env format) are all in a similar level of normal as env vars and can not be called niche, no?
Re: Show HN: Infisical – open-source secrets manager
#86Earlier quoted context omitted.
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…
> Environment variables are still by far the most popular approach for storing secrets
And `password` is still by far the most popular password.
Why not just call it environment management, and warn ENV is not secret, so you don't spread the wrongness?
Re: Show HN: Infisical – open-source secrets manager
#87Environment 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...
Sorry, there is no heated discussion, the issues are very clear and using ENV is a thing of the past, a bad practice that should not be propagated. Simple.
Re: Show HN: Infisical – open-source secrets manager
#88Earlier quoted context omitted.
Thank you. I wasn't asking whether the product could do that through integrations but whether it operates insecurely by default.
Infisical is secure by default :) It really depends on how you set it up. If you prefer, you can choose to split non-sensitive environment variables and sensitive secrets into different projects - and use them for different purposes / in different ways.
No, you seem to use the term "secure by default" in a different way as it is expected by industry standards. Please re-align your view.
Re: Show HN: Infisical – open-source secrets manager
#89Earlier quoted context omitted.
Thank you. I wasn't asking whether the product could do that through integrations but whether it operates insecurely by default.
It very much sounds like security is an after thought. Seems cool if you need to sync env vars, but you should probably just be using battle tested etcd+confd or console+console template. This product seems to be based on some incredibly misguided principles (from a security perspective). I don’t think a technology like this has any place in a modern enterprise. Part of the whole point of using a secret manager is to…
Thanks - sometimes it is so helpful to see other publish your own thoughts. I was wondering why such a product is posted here.
Re: Show HN: Infisical – open-source secrets manager
#90Earlier quoted context omitted.
Ideally a single use one.
This is my problem with key management; at some point you have to have some sort of bespoke key management strategy for the key manager itself . I've yet to find a satisfactorily clear and modern way to accomplish this securely.
It's not that complex, and many products and approaches handle this properly. Keep the key out of band with the secrets. Never keep the secrets in an unencrypted form. Keying material can be composed of or accessed by what you know, what you have, and what you are. Don't store the key anywhere, either by protecting the key with a kek, shared secrets, or any one of many other workable models. In some cases private keys can be a component of the security model.
It is important to understand the threat model in order to place the appropriate mitigations into the security architecture.