Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Infisical – open-source secrets manager (github.com/infisical)
232 points by vmatsiiako on Dec 19, 2022 | hide | past | favorite | 97 comments
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/




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...


You might want to look into supporting systemd's credentials interface to cover 95% of non-K8S Linux systems out there with a generic solution.

https://systemd.io/CREDENTIALS/


Thank you! We will take a look!


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.


I'm afraid I have to disagree. There are so many different needs it is impossible to discredit them so simply. I recommend that readers take inspiration from this model of maturity to see more clearly: https://www.gitguardian.com/files/secrets-management-maturit...


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.


> 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?


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?


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...


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.


Thank you for the feedback! Would you be able to provide a list? Then, I can easily tell you what differentiates us from them in a meaningful way. So far, we haven't found any alternatives that would have the same vision as Infisical :)


There is vaultwarden, gopass, Vault, SOPS, Conjur, dotenv, etc.


Well, without pointing fingers:

- some of these don't have a Web UI at all - which I think is very important

- some of these don't have integrations with 3rd party services

- some of these are only compatible with JS

- some of these are just so complicated so you need at least a week to figure them out :)


> Well, without pointing fingers: - some of these don't have a Web UI at all - which I think is very important

Why?

> some of these don't have integrations with 3rd party services

Like?

> some of these are only compatible with JS

What do you mean only compatible with JS?

> some of these are just so complicated so you need at least a week to figure them out :)

You could say the same about anything. So you want users to just trust yours but have to figure everyone elses out? If they had to understand yours from a more fundamental perspective I'd imagine yours would take just as long.


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


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.


It's Linux specific, but I would look into the in-kernel key management https://man7.org/linux/man-pages/man7/keyrings.7.html


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


In the environment of course. It is a step better than just keeping all the secrets there, because an env leak won't leak the encrypted values, so you'll have a key with no door, so to speak.


Using which key?


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.


But how do you protect the shared secrets? Do you see my point? I wish there was some sort of industry best practice tool or book for modelling your threats and suggesting an architecture.


I gave you the overarching theory and one specific method in my comment to which you replied. PS The shared secrets I mentioned were not in that context symmetric keys but split keys.

A tool will never solve a security problem by creating an optimal design. That requires someone with security knowledge. There are threat modeling tools that can help but only when the tools are used as designed.


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.


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.


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?


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.


MongoDB provides MongoDB Atlas, our own managed service. which is supported on every cloud (AWS, Azure, GCP).


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


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


SQLite/filesystem and etcd or some kind of distributed store.

The SQLite and fs option would get you usage in Homelabs.

That's a heavy order for the SOC 2, especially if you're just starting out as a company.

Imho, it's more important that the code base is audited and the company is transparent.


Plain-text (encrypted) files and/or sqlite would be a great complement to whatever else.


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.


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.


Indeed! We tried to make self-hosting as easy as possible, and we're planning to improve it even further! Let us know if you have any issues while self-hosting. We also have a community Slack where you can ask any questions: https://join.slack.com/t/infisical-users/shared_invite/zt-1k...


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.


I am wary of any company's claims of end-to-end encryption[1], especially when I have no experience with them. That being said, I think open-source is the right path. If I can compile the client myself, locally, and audit the code myself, that's a good first step. Perhaps even better would be for the data PUT/GET to be via an API, and I can bring my own client if I want. Then, the encrypted data is truly just an opaque blob from the service provider's POV. But you might as well be Google Drive at that point, no?

I haven't looked into the product much; I'm assuming that the server side is more than storage for opaque blobs. The less it is that, the less I can fully trust that my data is safe in their hands. And even if it's not my own secrets, but maybe some metadata (expiration times?), that is also sensitive data that would best not be leaked.

This is actually one space where I think certifications can be meaningful — such as FIPS, for the case of the US Federal Gov't. They tend not to mess around with security, so I trust that a little bit more (NSA backdoors notwithstanding).

[1] I remember when Zoom claimed that their video conferences were "end-to-end encrypted", and when it came out that they were not, they apologized, saying something along the lines of "we're sorry for any confusion we caused — when we used that term we meant XYZ, but we understand how some people could have interpreted it as ABC." So, in other words, they lied, used a well-established industry term to mean something else, and when caught in their lie, minced words to say "oh when we said _this_ we really meant _that_." Big frown from me.


This is totally valid! And that's why we decided that Infisical should be open-source. As you said, you can inspect everything yourself, and even self-host it, for even greater level of certainty. Infisical is by default end-to-end encrypted with exceptions for a couple integrations (Vercel/Heroku). This is because it is impossible to preserve end-to-end encryption there at the moment - this will be possible with custom integrations in future. We try to be very open about this with users (we mention it both in the app and in the docs multiple times).

Certifications are definitely important, and we're actively thinking of that.


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


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.


I see. Some of the integrations, such as K8s would offload the downtime to k8s itself so then it wouldn't be much of a problem (other than alerting if the secret sync is broken).

How do I stay up to date on developments for the AWS/GCP integration?


Indeed! Could you please join our community Slack (here is the link: https://join.slack.com/t/infisical-users/shared_invite/zt-1k...)? We will be posting about all the major updates such as AWS/GCP integrations there


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.


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!


Love this project but, please, give us a way to use it without the CLI. Not really keen on having the CLI on my package.json


Definitely and will keep y'all posted on this!


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!


Done https://github.com/Infisical/infisical/issues/138


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


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"


Thank you for the feedback. We are actually planning to have a second repo created that mirrors the main repo soon!


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.


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.


Thank you so much! This is something we will be releasing soon actually.

Since it's still early days for Infisical, we don't support more advanced organisational structures yet. You're very welcome to join our Slack to stay up-to-date when we release it: https://join.slack.com/t/infisical-users/shared_invite/zt-1k...


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!


  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?


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


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.


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 avoid storing them in environment variables.

That coupled with the lack of an API and the use of MongoDB are just too many red flags for me to ignore.


Thanks - sometimes it is so helpful to see other publish your own thoughts. I was wondering why such a product is posted here.


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 :)


Is this like an open-source version of Doppler? Love Doppler.


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.


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...


This looks great! Vault is such a headache sometimes... Will consider switching


Reminds be a bit of Vault but easier, I'll give it a try with Docker!


Let me know if you have any questions. Here are the Docker instructions: https://infisical.com/docs/integrations/platforms/docker


You lost me at - just enter username and password.


What are you referring to exactly? :)


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?


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.


Thanks guys looks very useful to us


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 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


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.


Hey there!

Not sure what you mean by "lack of an API" here as well as in other parts of this thread where you allude to the CLI connecting directly to MongoDB (it would be a terrible design choice if that was the case). Infisical does have a backend API with endpoint protection that the CLI pulls secrets from (you can inspect it yourself at the repo) — It just isn't publicly documented for folks to write their own clients for (we have this on our roadmap so do look out for it).

As mentioned though, Infisical is still new and in public alpha. We've put a lot of thought into security including our choice of cryptography and end-to-end encryption; there are certainly areas that can be fortified and those will be addressed. Check in on us a few months from now and we'll have something pretty compelling :)


You need to give us time since we just launched and are still in public alpha :) In the coming months, we will be adding many more advanced security features that also include API.


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.


"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".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: