51–60 of 99 posts
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.
You lost me at - just enter username and password.
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.
This way, you can stay updated about when it's ready. Thank you!
Earlier quoted context omitted.
Using which key?
Ideally a single use one.
Earlier 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?
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.
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.
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!
Earlier quoted context omitted.
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.
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.
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.
Earlier quoted context omitted.
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.
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.