[HN Gopher] Show HN: Infisical - open-source secrets manager
___________________________________________________________________
Show HN: Infisical - open-source secrets manager
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/
Author : vmatsiiako
Score : 137 points
Date : 2022-12-19 17:52 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mberning wrote:
| 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 wrote:
| 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.
| IncRnd wrote:
| 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 wrote:
| 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.
| IncRnd wrote:
| Do I understand correctly that if I place secrets into the
| store that those secrets will be synced to environment
| variables across machines?
| maidul wrote:
| Yes, if you have integrations set up (docker, kubernetes,
| etc.) then those secrets in the store will be synced to the
| respective environment
| IncRnd wrote:
| Thank you. I wasn't asking whether the product could do
| that through integrations but whether it operates
| insecurely by default.
| linuxdude314 wrote:
| 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.
| vmatsiiako wrote:
| 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.
| gregwebs wrote:
| 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 wrote:
| 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.
| gregwebs wrote:
| 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?
| vmatsiiako wrote:
| 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
| candiddevmike wrote:
| Obligatory how does this compare to Vault or Conjur?
| vmatsiiako wrote:
| 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
| linuxdude314 wrote:
| 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.
| tony-infisical wrote:
| 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 wrote:
| 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"
| maidul wrote:
| Thank you for the feedback. We are actually planning to have
| a second repo created that mirrors the main repo soon!
| ponytech wrote:
| 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.
| vmatsiiako wrote:
| 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!
| linuxdude314 wrote:
| Does that imply that your CLI is directly connecting to
| MongoDB without some sort of backend service running?
| vmatsiiako wrote:
| 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
| mousetree wrote:
| Is this like an open-source version of Doppler? Love Doppler.
| vmatsiiako wrote:
| 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.
| olekenneth wrote:
| You lost me at - just enter username and password.
| vmatsiiako wrote:
| What are you referring to exactly? :)
| Alifatisk wrote:
| Reminds be a bit of Vault but easier, I'll give it a try with
| Docker!
| vmatsiiako wrote:
| Let me know if you have any questions. Here are the Docker
| instructions:
| https://infisical.com/docs/integrations/platforms/docker
| thamer wrote:
| 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 wrote:
| 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!
| bearzdev wrote:
| Has anyone on staff been through a soc audit? Which trust
| criteria will be used?
|
| Does the app support data stores other than mongo?
| hardwaresofton wrote:
| 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.
| vmatsiiako wrote:
| 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?
| linuxdude314 wrote:
| 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.
| 9dev wrote:
| Oh, Mongo is a major turnoff. The only sensible data
| store to support in 2022 and beyond is Postgres, maybe
| SQLite IMO.
| vorpalhex wrote:
| 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 wrote:
| 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.
| NathanFlurry wrote:
| 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.
| vmatsiiako wrote:
| 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...
| DrBenCarson wrote:
| Do you mind sharing a bit more about Rivet? Never heard of it
| before. Thanks!
| turtledragonfly wrote:
| 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.
| vmatsiiako wrote:
| 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...
| eyakubovich wrote:
| 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.
| turtledragonfly wrote:
| 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.
| vmatsiiako wrote:
| 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.
| goodpoint wrote:
| meh.
| ahofmann wrote:
| "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".
| dang wrote:
| 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.
| jbotz wrote:
| 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.
| wryun wrote:
| I believe you can somewhat mitigate these concerns by reading
| and removing the secrets on startup, ideally whitelisting the
| entire env.
| vmatsiiako wrote:
| 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...
| eliaspro wrote:
| 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/
| vmatsiiako wrote:
| Thank you! We will take a look!
| gregwebs wrote:
| 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.
| syoc wrote:
| It's Linux specific, but I would look into the in-kernel key
| management https://man7.org/linux/man-
| pages/man7/keyrings.7.html
| dakiol wrote:
| And where do you store the key to decrypt the secret?
| jacobsenscott wrote:
| 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.
| idealmedtech wrote:
| Using which key?
| sofixa wrote:
| Ideally a single use one.
| simonw wrote:
| How do single use keys work? I had a quick search but
| couldn't find a pattern for them in Python.
| alexeldeib wrote:
| Check out vault's response wrapping with cubbyhole for
| one such case.
|
| Note this still takes a dependency on the service.
| idealmedtech wrote:
| 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.
| klabb3 wrote:
| 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.
| vmatsiiako wrote:
| 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.
___________________________________________________________________
(page generated 2022-12-19 23:00 UTC)