41–50 of 99 posts
Earlier quoted context omitted.
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
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.
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...
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.
Earlier quoted context omitted.
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?
Currently, we only support Mongo, although we received requests for some other ones. Which one are you interested in?
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...
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 f…
Earlier quoted context omitted.
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/
Earlier quoted context omitted.
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?
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.
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.
Earlier quoted context omitted.
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 opaq…
Certifications are definitely important, and we're actively thinking of that.