Stop Storing Secrets in Environment Variables

Or just overwrite the variables when you're done with them. Hell, you can wipe out the entirety of your __environ when you're done and it won't show up in /proc anymore. Sure, in docker world you can still see them with docker inspect but if someone has that level of access you're done anyway.

Environment variables are no ones favorite method of associating data with processes, but they're everyone's favorite.

The kernel keyring and secret files are "better" but they have an impedance mismatch which is that they're user/uid oriented rather than process oriented.

Here's an example in C. I'm a terrible C programmer but you get the picture. If you run this and then `ps eww` on the process it will be empty.

    #include <stdio.h>
    #include <string.h>
    #include <unistd.h>

    int main(int argc, char **argv, char **envp) {
        while (*envp) {
            printf("%s", *envp);
            int len = strlen(*envp);
            memset(*envp, 0, len);
            *envp++;
        }

        while (1) {
            sleep(10);
        }
   }

Is there any argument here besides "because something with permission to read them might copy them to somewhere public"? How does putting them in a tmpfs fix that?

Ultimately they must persist in memory to be useful. Beyond bootstrapping, sometimes API keys, etc must be read continuously. Env is as good a place as any if you need it continuously.

If you mount a tmpfs and copy it into the container env at runtime, is this much worse than mounting a secret object in the k8s Deployment/pod definition in api server?

You could argue that the k8s API server wouldn’t learn it if it was runtime discovered, but this increases complexity. Are ephemeral secret mounts that much better than the built k8s secret objects? I would say no.

Or you could store them in your cloud provider’s secrets manager. aws.amazon.com/secrets-manager cloud.google.com/secret-manager