6 ms·

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

by jbotz 4y ago

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-use-env-variables-for-secret-data/ 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.

gregwebs 4y ago
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.
- idealmedtech 4y ago
  Using which key?
  - sofixa 4y ago
    Ideally a single use one.
    - simonw 4y ago
      How do single use keys work? I had a quick search but couldn't find a pattern for them in Python.
      - alexeldeib 4y ago
        Check out vault’s response wrapping with cubbyhole for one such case. Note this still takes a dependency on the service.
    - idealmedtech 4y ago
      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.
      - IncRnd 4y ago
        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.
        idealmedtech 4y ago
        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.
        IncRnd 4y ago
        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.
- syoc 4y ago
  It's Linux specific, but I would look into the in-kernel key management https://man7.org/linux/man-pages/man7/keyrings.7.html https://man7.org/linux/man-pages/man7/keyrings.7.html
- dakiol 4y ago
  And where do you store the key to decrypt the secret?
  - jacobsenscott 4y ago
    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.
vmatsiiako 4y ago
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-1kdbk07ro-RtoyEt_9E~fyzGo_xQYP6g https://join.slack.com/t/infisical-users/shared_invite/zt-1k...
- eliaspro 4y ago
  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/ https://systemd.io/CREDENTIALS/
  - vmatsiiako 4y ago
    Thank you! We will take a look!
- POPOSYS 4y ago
  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.
  - segudev 4y ago
    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-maturity-model https://www.gitguardian.com/files/secrets-management-maturit...
wryun 4y ago
I believe you can somewhat mitigate these concerns by reading and removing the secrets on startup, ideally whitelisting the entire env.
klabb3 4y ago
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 4y ago
  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.
  - Terretta 4y ago
    > 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?
- 3np 4y ago
  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?
encryptluks2 4y ago
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.
- vmatsiiako 4y ago
  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 :)
  - encryptluks2 4y ago
    There is vaultwarden, gopass, Vault, SOPS, Conjur, dotenv, etc.
    - vmatsiiako 4y ago
      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 :)
      - encryptluks2 4y ago
        > 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.
benatkin 4y ago
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.WasiCtxBuilder.html 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.WasiCtx.html#method.new https://docs.rs/wasmtime-wasi/0.21.0/wasmtime_wasi/struct.Wa...

by jbotz 4y ago

gregwebs 4y ago

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.

idealmedtech 4y ago
Using which key?
- sofixa 4y ago
  Ideally a single use one.
  - simonw 4y ago
    How do single use keys work? I had a quick search but couldn't find a pattern for them in Python.
    - alexeldeib 4y ago
      Check out vault’s response wrapping with cubbyhole for one such case. Note this still takes a dependency on the service.
  - idealmedtech 4y ago
    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.
    - IncRnd 4y ago
      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.
      - idealmedtech 4y ago
        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.
        IncRnd 4y ago
        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.
syoc 4y ago
It's Linux specific, but I would look into the in-kernel key management https://man7.org/linux/man-pages/man7/keyrings.7.html https://man7.org/linux/man-pages/man7/keyrings.7.html
dakiol 4y ago
And where do you store the key to decrypt the secret?
- jacobsenscott 4y ago
  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.

vmatsiiako 4y ago

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-1kdbk07ro-RtoyEt_9E~fyzGo_xQYP6g https://join.slack.com/t/infisical-users/shared_invite/zt-1k...

eliaspro 4y ago
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/ https://systemd.io/CREDENTIALS/
- vmatsiiako 4y ago
  Thank you! We will take a look!
POPOSYS 4y ago
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.
- segudev 4y ago
  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-maturity-model https://www.gitguardian.com/files/secrets-management-maturit...

wryun 4y ago

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

klabb3 4y ago

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 4y ago
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.
- Terretta 4y ago
  > 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?
3np 4y ago
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?

encryptluks2 4y ago

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.

vmatsiiako 4y ago
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 :)
- encryptluks2 4y ago
  There is vaultwarden, gopass, Vault, SOPS, Conjur, dotenv, etc.
  - vmatsiiako 4y ago
    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 :)
    - encryptluks2 4y ago
      > 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.

benatkin 4y ago

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.WasiCtxBuilder.html 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.WasiCtx.html#method.new https://docs.rs/wasmtime-wasi/0.21.0/wasmtime_wasi/struct.Wa...