WingNews logo WingNews GitHub [2]
top | item 34055132

Show HN: Infisical – open-source secrets manager

232 points| vmatsiiako | 3 years ago |github.com

Last month, we open-sourced Infisical (https://github.com/Infisical/infisical) - a simple, end-to-end encrypted tool to sync environment variables across your team and infrastructure. You can use it to store environment variables and inject them into your applications locally or into CI/CD and production infrastructure. It can be used with any language/framework and is platform independent with a super easy setup.

We know secret managers exist but, in our experience, they’re too complicated, not comprehensive, not user-friendly, or a mix of all three — other nicer ones are closed-source and don’t have self-hosted options available. That’s why we’re on a mission to make secret management more accessible to every developer — not just security teams.

We’ve launched this repo under the MIT license so any developer can use the tool. The goal is to not charge individual developers. We make money by charging a license fee for some future enterprise features as well as providing a hosted version and support.

In the coming weeks, we plan to add features like key rotation, access logs + more integrations. We’d love to hear your thoughts and any feature requests!

Give it a try (https://github.com/Infisical/infisical), and let us know what you think!

Main website: https://infisical.com/

97 comments

order
[+] jbotz|3 years ago|reply
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.

[+] vmatsiiako|3 years ago|reply
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...

[+] klabb3|3 years ago|reply
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.
[+] benatkin|3 years ago|reply
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...

[+] encryptluks2|3 years ago|reply
I'm just as critical as anyone else in this space, but several popular Docker images do this and it is on the software not the management solution to enact best practices. However, as noted this software is sort of designed to accommodate those bad practices and I can give you a list of open source alternatives in this space with more security options so I don't think they are going to be able to compete well with other alternatives if they are still in the alpha phase unless they already have something that differentiates their solution that is appealing. So far I've found nothing.
[+] wryun|3 years ago|reply
I believe you can somewhat mitigate these concerns by reading and removing the secrets on startup, ideally whitelisting the entire env.
[+] gregwebs|3 years ago|reply
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.
[+] thamer|3 years ago|reply
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 environment variables seems like a major issue and it would be one of the first points covered in such an audit.

[+] vmatsiiako|3 years ago|reply
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!
[+] turtledragonfly|3 years ago|reply
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.

[+] eyakubovich|3 years ago|reply
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.
[+] gregwebs|3 years ago|reply
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 an uptime perspective and easy of operations that has always seemed a safe approach, although the pricing is kind of outrageous. But just storing (e2e encrypted, etc) in cloud object storage is also an option. Berglass for example gives the option of storing in the secret manager or in cloud storage directly: https://github.com/GoogleCloudPlatform/berglas

[+] vmatsiiako|3 years ago|reply
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.

[+] ponytech|3 years ago|reply
Is there an API to programmatically retrieve secrets or is it CLI only?

On a previous project I used the HVAC python library to get secrets from Vault and configure a Django project. (thus not using env vars at all) It would be nice to be able to do the same with Infisical.

[+] tony-infisical|3 years ago|reply
Hello!

There is a backend API (that the web UI and CLI connect to) but it's not yet publicly documented. We've wanted to do that for a while now but have just been swamped with requests for features honestly — It's just a matter of time :)

Would love to keep you updated with the progress of that over at our Slack community!

[+] vmatsiiako|3 years ago|reply
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!

[+] tony-infisical|3 years ago|reply
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 :)

[+] eranation|3 years ago|reply
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"

[+] mberning|3 years ago|reply
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.
[+] linuxdude314|3 years ago|reply
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.

[+] NathanFlurry|3 years ago|reply
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.

[+] DrBenCarson|3 years ago|reply
Do you mind sharing a bit more about Rivet? Never heard of it before. Thanks!
[+] IncRnd|3 years ago|reply 

  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?
[+] vmatsiiako|3 years ago|reply
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.

[+] TommyDANGerous|3 years ago|reply
This is awesome! We use Doppler at the moment but this looks good to switch over.
[+] tony-infisical|3 years ago|reply
Amazing! Let us know if you need any help setting up :)
[+] mousetree|3 years ago|reply
Is this like an open-source version of Doppler? Love Doppler.
[+] vmatsiiako|3 years ago|reply
You can think of it this way. Unlike Doppler, Infisical is open-source, so you can self-host it. Plus, Infisical is by default end-to-end encrypted (with an exception of some integrations). Doppler could in theory read you secrets if they wanted to since their main service is not end-to-end encrypted.
[+] shrisukhani|3 years ago|reply
This looks great! Vault is such a headache sometimes... Will consider switching
[+] olekenneth|3 years ago|reply
You lost me at - just enter username and password.
[+] vorpalhex|3 years ago|reply
It looks like part of your plan is to charge for premium plugins.

How do you intend to react to open source clones of such plugins?

[+] vmatsiiako|3 years ago|reply
Actually not! Most of the integrations are going to be completely free. Only a few very-enterprise integrations that are not needed for individual developers or small teams will be paid. We intend to earn money from some advanced compliance and security enterprise features while providing a service to small developer teams for free.
[+] yardenst|3 years ago|reply
Thanks guys looks very useful to us
[+] candiddevmike|3 years ago|reply
Obligatory how does this compare to Vault or Conjur?
[+] vmatsiiako|3 years ago|reply
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 make everything more intuitive for developers when compared to Vault or Conjur. Plus, we have a handful of features in store for the future that Vault does not have yet! You should try and let me know what you think

[+] goodpoint|3 years ago|reply
meh.
[+] dang|3 years ago|reply
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.

[+] ahofmann|3 years ago|reply
"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".