Correct me if I misunderstood you, but you don't want _engineers_ who write your code to have access to private TLS keys which are _used_ in production
If you compromise a process, you can potentially exfiltrate its memory. You'd need to also compromise the operating system to exfiltrate memory from other processes.
So, keys being in nginx means you can only get the keys by breaking nginx (or the OS), not by breaking the in-house application.
From engineers sure.
But a separate process helps for other threats, like heartbleed.
Also, try to avoid passing in keys as command line arguments. If you can, avoid using environment variables, too. You can pass thet data in using standard in, so the data is never exposed.
Example of leaky environment variables:
https://gist.github.com/amorphid/db037f03246962959b6a034b2ca...
TBH, though, if they are sniffing env variables from processes there's not reason not to sniff that process's memory directly.
https://gist.github.com/amorphid/4a65741d14db38b96341d7e1f2d...
The short version is I'm passing a variable in via the pid's standard in, reading the line, and then declaring the variable. This is a very contrived example :) But you can write a wrapper script that would handle all of the line reading for you.
This originally came up when I was asking someone how to pass sensitive information (API keys, passwords, etc.). I did some research, and found this approach.
In most programming languages, for basic system calls, you basically just call a command, that command runs, and then exits. But sometimes you want a script that can take information from standard in, or send it to you from standard out. Like you may write a script that runs for a few minutes, then says "OK, I'm ready for the password!", and then you pass it in at the time it's needed (but honestly, don't do it unless you need to, because it's one more thing that can break.
Erlang/Elixir land have a library called erlexec that does this => http://saleyn.github.io/erlexec/
Another Elixir library is Porcelain => https://github.com/alco/porcelain
The unix permissions model is designed to isolate one user's data from another.
For one thing, a malicious or disgruntled engineer could sneak in code that exposes your private key material in some fashion.
Secondly, and more likely, your engineers may make a mistake that inadvertently exposes process memory, which would include your private key material.
In simpler terms, it often pays to have a firewall between important company secrets and the guy/gal who happens to be working on your web app this month.
Assuming you would answer the question "Do your engineers have root access to production machines?" in the negative, you probably also don't want your engineers writing code that has access to the things that the root user has access to.
One other way to put this is, are you comfortable running your Go process as root (in order to bind to port 443)?
You do not need to run as root to bind an application to a low port, instead use setcap (it works for everything not just Go): https://stackoverflow.com/questions/14537045/how-i-should-ru...