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.

Using which key?

Ideally a single use one.

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.

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.

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.

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

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

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