>we didn't want code that we wrote to have access to our private TLS keys in production.
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
As clarified by some sibling comments, having your own engineers writing code that has access to your private keys is potentially problematic.
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)?
A separate process is overkill for protection from engineers, just have the private keys read from disk, and only have them on production disks.
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.
Or don't have the keys on the server at all. Anyone who gets root access can walk right up to the key file and yoink it. Obviously keys have to be stored somewhere. But it doesn't have to be on every server's disk.
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.
Those env vars should only be exposed to the same user. The same user can also usually attach a debugger and read the secrets from memory. (Of course, this is harder, so you may not want secrets in env vars anyway.)
The unix permissions model is designed to isolate one user's data from another.
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.
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