5 ms·

I agree completely. Storing secrets in environment variables is wrong: https://blog.forcesunseen.com/stop-storing-secrets-in-environment-variables https://blog.

I agree completely. Storing secrets in environment variables is wrong: https://blog.forcesunseen.com/stop-storing-secrets-in-environment-variables https://blog.forcesunseen.com/stop-storing-secrets-in-enviro... Even unsetting environment variables leaves them in /proc/self/environ. There isn't a thread-safe way to unset environment variables in POSIX, so even if you `unset TOP_SECRET` from within a program the contents of /proc/self/environ will remain unchanged and available.

josephcsible 4y ago
But /proc/*/environ is only readable by the user the process is running as and root, so if you can read it, you're already on the other side of the airtight hatchway.
- eriner_ 4y ago
  Arbitrary file read vulnerabilities are extremely common.
  - josephcsible 4y ago
    Sure, but if you have one of them, then you can read the secret files out of /vault or whatever too.
    - hedora 4y ago
      Or, if you only have access to proc, from the process's heap.
    - eriner_ 4y ago
      Correct! This is why I explicitly said the following in the blog post I linked above: > Once the application hits “readiness” status (as determined by health endpoints or the load balancer), the secrets volume should be unmounted and made inaccessible.
      - metadat 4y ago
        Then I'll just pull it from the processes memory directly. It's security through obscurity at best.
        mumblemumble 4y ago
        It seems to me in line with the comment that the post quoted: > Ultimately, secrets need to live somewhere and need to be accessed as plain text. Just make sure that the access as small window is as [sic] possible, and try to obliterate it after use, if possible. This is not an all-or-nothing situation; it's a game of mitigation. If the process needs to retain the secret in memory, true, there's not much you can do about that. But I don't think that minimizing where else you're storing it is just security through obscurity. Fewer possible attack vectors is still fewer possible attack vectors.
        metadat 4y ago
        Now, if you encrypt them in memory, or even better obtain the creds in an audited fashion, use them and clear the memory promptly, it's slightly better.
        Rapzid 4y ago
        Just an arbitrary file read vulnerability away at /proc/$pid/mem
      - mrslave 4y ago
        I really like my applications to at least try to reestablish dropped connections though. But I do appreciate the minimization mindset with respect to secrets. The last time I was responsible for the scaffolding of a new software service it supported reading secrets from a file. It confused the operations team and I was just told to include support for an environment variable. Oh well, I tried.
CameronNemo 4y ago
How do you actually unmount the volume with kubernetes once the secrets are read and the process is ready? I've never heard of a feature like that.
- aliswe 4y ago
  you dont ... you remove the mapping and restart the pod.
- thinkmassive 4y ago
  From my comment farther below: > If your app can’t interface directly w/k8s, but it can read secrets from a file, you can use a small init program to fetch the k8s secret and write it to a named pipe. This is advantageous compared to mounting as a volume, because the pipe disappears after both ends close their connection to it.

josephcsible 4y ago

But /proc/*/environ is only readable by the user the process is running as and root, so if you can read it, you're already on the other side of the airtight hatchway.

eriner_ 4y ago
Arbitrary file read vulnerabilities are extremely common.
- josephcsible 4y ago
  Sure, but if you have one of them, then you can read the secret files out of /vault or whatever too.
  - hedora 4y ago
    Or, if you only have access to proc, from the process's heap.
  - eriner_ 4y ago
    Correct! This is why I explicitly said the following in the blog post I linked above: > Once the application hits “readiness” status (as determined by health endpoints or the load balancer), the secrets volume should be unmounted and made inaccessible.
    - metadat 4y ago
      Then I'll just pull it from the processes memory directly. It's security through obscurity at best.
      - mumblemumble 4y ago
        It seems to me in line with the comment that the post quoted: > Ultimately, secrets need to live somewhere and need to be accessed as plain text. Just make sure that the access as small window is as [sic] possible, and try to obliterate it after use, if possible. This is not an all-or-nothing situation; it's a game of mitigation. If the process needs to retain the secret in memory, true, there's not much you can do about that. But I don't think that minimizing where else you're storing it is just security through obscurity. Fewer possible attack vectors is still fewer possible attack vectors.
        metadat 4y ago
        Now, if you encrypt them in memory, or even better obtain the creds in an audited fashion, use them and clear the memory promptly, it's slightly better.
      - Rapzid 4y ago
        Just an arbitrary file read vulnerability away at /proc/$pid/mem
    - mrslave 4y ago
      I really like my applications to at least try to reestablish dropped connections though. But I do appreciate the minimization mindset with respect to secrets. The last time I was responsible for the scaffolding of a new software service it supported reading secrets from a file. It confused the operations team and I was just told to include support for an environment variable. Oh well, I tried.

CameronNemo 4y ago

How do you actually unmount the volume with kubernetes once the secrets are read and the process is ready? I've never heard of a feature like that.

aliswe 4y ago
you dont ... you remove the mapping and restart the pod.
thinkmassive 4y ago
From my comment farther below: > If your app can’t interface directly w/k8s, but it can read secrets from a file, you can use a small init program to fetch the k8s secret and write it to a named pipe. This is advantageous compared to mounting as a volume, because the pipe disappears after both ends close their connection to it.