A config store like Vault. Of course, that needs credentials too, which are typically a file on the file system.
IMO, people are overly sensitive about environment vars. They are really no worse than files on the file system - both can be accessed if you're a privileged user on that machine.
You could, but then you’ll have replaced a universal and standardized abstraction with a hard commitment to one very specific approach. That doesn’t come cheap.
One thing that I like, which this approach allows for, is live configuration. For things like databases and such which allow for the regular rolling of credentials.
It's not simple by itself, but it simplifies other things.
Via either program config files, an inline subshell calling cat, or ssh-agent in that specific case, to keep credentials both out of the environment, and off of the command-line where it can be read by inspecting the resulting process for it's invocation.
SSH agent is a good example. It’s effectively an environment var which is why this works fine:
sudo SSH_AUTH_SOCK=$SSH_AUTH_SOCK git clone ...
Edit:
The reason I think it’s silly to make a blanket statement environment vars are bad is because too many containers have credentials baked into the image when they should be passed in another way.
You can disable access the possibility to read the memory of other processes and you can do it for environment variables. Storing access tokens in memory is more obscure than environment variables, that is true though.
Store a path to the top secret file in an environment variable, and have the program read the credentials out of the file. Put the file somewhere far away from the repo, on the deployed filesystem.
