4 ms·

How do command line arguments or config files solve either problem?

yrro 6y ago
Command line arguments aren't inherited by child processes. Unfortunately they are visible to other users on the system, so they're no good for credentials. Config files (or an abstraction of them such as reading config data from a socket), after parsing, result in some credentials sitting in the memory of the process that needs them. They aren't in the environment block, so a quick and dirty "dump all my environment variables to stdout" procedure won't risk exposing them. And for the same reason, a child process that does the same won't inherit them in order to expose them. Note that talking about preventing accidental exposure of credentials. Config files alone can't protect credentials from a malicious process that deliberately goes looking for them to leak them; for that additional measures have to be taken... but environment variables aren't part of the solution!
- bopbeepboop 6y ago
  > Unfortunately they are visible to other users on the system, so they're no good for credentials. If you’re concerned about your own software logging credentials, command line arguments are negative in two regards: They’re highly visible when the process is running; they’re often automatically logged. > They aren't in the environment block, so a quick and dirty "dump all my environment variables to stdout" procedure won't risk exposing them. Okay — but the usual way that happens is “dump my config object in a log”, which parsed configs don’t help with. You also now have a config file: how is it stored? ...is it in the repo? ...what are the permissions? ...how do we deploy it? Environment variables don’t persist in repos and are designed to be integrated with hosting tools, like secrets managers. I’m not seeing how a config file beats Kubernetes injecting from the secret store, which is why we use environment variables: so our tools (secret stores) can configure the environment our software uses.
  - yrro 6y ago
    Good point about command line arguments being often automatically logged! So they bad for both reasons :) Now, if you're running in k8s then you can improve your setup by mounting your secret into your container, and have your code read the credentials from the file within the mount. This just looks like another kind of config file to me :)
    - PeterisP 6y ago
      Embedding secrets (which should be changeable and with limited access) into container images (which should be reproducible and perhaps stored in accessible locations) sounds like not a goood idea; IMHO you definitely need the capability to have the same container use different credentials so that, for example, you can run the same container in a development or testing environment as in production, but with different credentials.
      - bopbeepboop 6y ago
        I believe they meant mounting via Kubectrl as a file, from the secret manager. So runtime file injection.
      - yrro 6y ago
        I'm talking about doing this: https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod https://kubernetes.io/docs/concepts/configuration/secret/#us...
    - bopbeepboop 6y ago
      > And for the same reason, a child process that does the same won't inherit them in order to expose them. Wait, this is the crux of why you think it’s more secure — but actually I see the reverse problem: Dropping environmental variables is standard security practice, but dropping file access permissions is not. Most child processes read from the same set of files as the parents. How would having files rather than ENVs make my container more secure, where we’re concerned with developers making mistakes (passing ENV vs passing file permissions)? Similarly, the only proposed benefit of your idea is we don’t have them around post reading — but that’s true if you initialize a config object from ENV and then pass it around as well. (You ignored my point about how mistakes via logging happen.)
  - marcosdumay 6y ago
    > You also now have a config file: how is it stored? Hum... Your environment variables must be stored at some place too, so the server can be launched. You can store the files at the exact same place.
    - bopbeepboop 6y ago
      Sure — you throw them in the Kube secret manager. But now you have multiple config files (smart) or your entire config outside the repo (not smart). This isn’t always the wrong approach — SSH keys get loaded this way, for instance. ENV variables naturally provide a way to layer content from different sources in a way that files don’t, so if you have a relatively simple config from multiple providers (eg, getting AWS session token from the host plus your environment config from the launch ENVs) it’s easier to use the K-V store nature of ENV variables versus multiple files. Again, multiple config files isn’t always wrong — but using that to store single strings instead of ENV variables is a code smell, for sure.
- hajile 6y ago
  It's also easier to encrypt a config file and provide the decrypt key externally.
  - PeterisP 6y ago
    So then the real secret is the key, which is provided "externally" ... how? Through command line parameters, some other config file, or environment variables? :P
    - IMTDb 6y ago
      Another encrypted config file. Obviously.
      - snicker7 6y ago
        Encrypted files all the way down.
    - Someone 6y ago
      A file that’s protected appropriately or standard input.

yrro 6y ago

Command line arguments aren't inherited by child processes. Unfortunately they are visible to other users on the system, so they're no good for credentials. Config files (or an abstraction of them such as reading config data from a socket), after parsing, result in some credentials sitting in the memory of the process that needs them. They aren't in the environment block, so a quick and dirty "dump all my environment variables to stdout" procedure won't risk exposing them. And for the same reason, a child process that does the same won't inherit them in order to expose them. Note that talking about preventing accidental exposure of credentials. Config files alone can't protect credentials from a malicious process that deliberately goes looking for them to leak them; for that additional measures have to be taken... but environment variables aren't part of the solution!

bopbeepboop 6y ago
> Unfortunately they are visible to other users on the system, so they're no good for credentials. If you’re concerned about your own software logging credentials, command line arguments are negative in two regards: They’re highly visible when the process is running; they’re often automatically logged. > They aren't in the environment block, so a quick and dirty "dump all my environment variables to stdout" procedure won't risk exposing them. Okay — but the usual way that happens is “dump my config object in a log”, which parsed configs don’t help with. You also now have a config file: how is it stored? ...is it in the repo? ...what are the permissions? ...how do we deploy it? Environment variables don’t persist in repos and are designed to be integrated with hosting tools, like secrets managers. I’m not seeing how a config file beats Kubernetes injecting from the secret store, which is why we use environment variables: so our tools (secret stores) can configure the environment our software uses.
- yrro 6y ago
  Good point about command line arguments being often automatically logged! So they bad for both reasons :) Now, if you're running in k8s then you can improve your setup by mounting your secret into your container, and have your code read the credentials from the file within the mount. This just looks like another kind of config file to me :)
  - PeterisP 6y ago
    Embedding secrets (which should be changeable and with limited access) into container images (which should be reproducible and perhaps stored in accessible locations) sounds like not a goood idea; IMHO you definitely need the capability to have the same container use different credentials so that, for example, you can run the same container in a development or testing environment as in production, but with different credentials.
    - bopbeepboop 6y ago
      I believe they meant mounting via Kubectrl as a file, from the secret manager. So runtime file injection.
    - yrro 6y ago
      I'm talking about doing this: https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod https://kubernetes.io/docs/concepts/configuration/secret/#us...
  - bopbeepboop 6y ago
    > And for the same reason, a child process that does the same won't inherit them in order to expose them. Wait, this is the crux of why you think it’s more secure — but actually I see the reverse problem: Dropping environmental variables is standard security practice, but dropping file access permissions is not. Most child processes read from the same set of files as the parents. How would having files rather than ENVs make my container more secure, where we’re concerned with developers making mistakes (passing ENV vs passing file permissions)? Similarly, the only proposed benefit of your idea is we don’t have them around post reading — but that’s true if you initialize a config object from ENV and then pass it around as well. (You ignored my point about how mistakes via logging happen.)
- marcosdumay 6y ago
  > You also now have a config file: how is it stored? Hum... Your environment variables must be stored at some place too, so the server can be launched. You can store the files at the exact same place.
  - bopbeepboop 6y ago
    Sure — you throw them in the Kube secret manager. But now you have multiple config files (smart) or your entire config outside the repo (not smart). This isn’t always the wrong approach — SSH keys get loaded this way, for instance. ENV variables naturally provide a way to layer content from different sources in a way that files don’t, so if you have a relatively simple config from multiple providers (eg, getting AWS session token from the host plus your environment config from the launch ENVs) it’s easier to use the K-V store nature of ENV variables versus multiple files. Again, multiple config files isn’t always wrong — but using that to store single strings instead of ENV variables is a code smell, for sure.
hajile 6y ago
It's also easier to encrypt a config file and provide the decrypt key externally.
- PeterisP 6y ago
  So then the real secret is the key, which is provided "externally" ... how? Through command line parameters, some other config file, or environment variables? :P
  - IMTDb 6y ago
    Another encrypted config file. Obviously.
    - snicker7 6y ago
      Encrypted files all the way down.
  - Someone 6y ago
    A file that’s protected appropriately or standard input.