4 ms·

If you use Golang, check out their newly introduced "embed" using which you can embed all your files into a single binary. I used to use Docker (and Kuernetes f

If you use Golang, check out their newly introduced "embed" using which you can embed all your files into a single binary. I used to use Docker (and Kuernetes for a short while), got frustrated and switched to Buildah/Podman for quite some time, and then now have switched to using embed. I have a Golang server with Flutter frontend interacting using GRPCWeb. Now I'm able to embed the Go server code, all the Flutter generated web code, generated Protobuf code, TLS certs, all the other resources, EVERYTHING into a SINGLE statically linked binary with no external dependences. I.e., you just run the executable and it just works. Of course it interacts with an external Redis binary but by itself it's just a single executable that can just be deployed with an scp to cloud, how much easier can you get? You do need your own orchestration mechanisms, but packaging wise it seems great. Anyone else tried this?

GauntletWizard 5y ago
You had me until you said TLS certs. As a SRE, I'm fully onboard with single executable deployments, but you should treat your binary as public information - don't include private material, inject it into the environment at runtime. Part of that is about the possibility of leaking your key, but the other half is that you should be running exactly the same binary in production and staging, and you should have different keys for each. Recompiling can introduce behavioral changes (even in a well managed build environment like Golang's where dependencies are versioned through version control tags and cryptographic hashes of those tags)
- herdcall 5y ago
  I have a local encryption mechanism that hides these keys from view in the binaries (say using grep or strings). And I'm not comfortable with the alternative of the certs being on the server in plain view as files; I feel having them inside the binary in an encrypted form is safer. I keep the keys and certs away from GitHub of course, so only I have them as files locally. Am I missing something?
  - n_u_l_l 5y ago
    Aside from improvements with organization and environment separation when you separate the configuration from the code (and also not having to roll your own solution), one of the security risks is that you accidentally mix up binaries. You will think that will never happen until it happens. A bigger security threat, I think, is that you have the private key both on your server and on your computer. It adds another location where you could mix up, hackers now have 2 possible attack targets, and it's more likely that your PC gets infected than your server. Either way, now, if your PC gets infected or your server gets hacked they will have the private key, while if you only have it on your server they won't necessarily have it when your PC gets infected. The safest solution if you don't want to store the private key unencrypted is to generate an encrypted private key with openssl. You would however need to provide the encryption key every time you start the server. You will still have the unencrypted private key in RAM, but that's inevitable and also the case with your current method. The private key (even encrypted) should never leave the server.
    - herdcall 5y ago
      Thanks for your response, much appreciated. I'm actually not planning to place the private key (or anything really) on the server other than the executable. I was in fact also thinking about using a password like you suggested (it's still under development). You're correct about the vulnerability of my personal computer and the need to take special care to protect the private key.
      - GauntletWizard 5y ago
        You are putting the private key on the server, it just happens to be encoded as data in the binary. It would not take an attacker long, looking at your executable in a sandbox, to figure out where it is - not matter how it is that you've obfuscated it. From a threat modeling perspective, nothing you do will prevent an attacker that is able to run as your application user (or root) on your server. That's fine; The level of obfuscation you've put into place will (possibly) keep some of the script-kiddies who aren't targeting you directly from realizing they've stolen your key. The attack you should be concerned about is on your distribution side: You can't copy that binary anywhere else without revealing your key. You can't put it in a docker image repository or a java package repository or even a s3 bucket - Because those become places that your key can be revealed. And you want to do those things. You want a copy of precisely the binary you deployed.

GauntletWizard 5y ago

You had me until you said TLS certs. As a SRE, I'm fully onboard with single executable deployments, but you should treat your binary as public information - don't include private material, inject it into the environment at runtime. Part of that is about the possibility of leaking your key, but the other half is that you should be running exactly the same binary in production and staging, and you should have different keys for each. Recompiling can introduce behavioral changes (even in a well managed build environment like Golang's where dependencies are versioned through version control tags and cryptographic hashes of those tags)

herdcall 5y ago
I have a local encryption mechanism that hides these keys from view in the binaries (say using grep or strings). And I'm not comfortable with the alternative of the certs being on the server in plain view as files; I feel having them inside the binary in an encrypted form is safer. I keep the keys and certs away from GitHub of course, so only I have them as files locally. Am I missing something?
- n_u_l_l 5y ago
  Aside from improvements with organization and environment separation when you separate the configuration from the code (and also not having to roll your own solution), one of the security risks is that you accidentally mix up binaries. You will think that will never happen until it happens. A bigger security threat, I think, is that you have the private key both on your server and on your computer. It adds another location where you could mix up, hackers now have 2 possible attack targets, and it's more likely that your PC gets infected than your server. Either way, now, if your PC gets infected or your server gets hacked they will have the private key, while if you only have it on your server they won't necessarily have it when your PC gets infected. The safest solution if you don't want to store the private key unencrypted is to generate an encrypted private key with openssl. You would however need to provide the encryption key every time you start the server. You will still have the unencrypted private key in RAM, but that's inevitable and also the case with your current method. The private key (even encrypted) should never leave the server.
  - herdcall 5y ago
    Thanks for your response, much appreciated. I'm actually not planning to place the private key (or anything really) on the server other than the executable. I was in fact also thinking about using a password like you suggested (it's still under development). You're correct about the vulnerability of my personal computer and the need to take special care to protect the private key.
    - GauntletWizard 5y ago
      You are putting the private key on the server, it just happens to be encoded as data in the binary. It would not take an attacker long, looking at your executable in a sandbox, to figure out where it is - not matter how it is that you've obfuscated it. From a threat modeling perspective, nothing you do will prevent an attacker that is able to run as your application user (or root) on your server. That's fine; The level of obfuscation you've put into place will (possibly) keep some of the script-kiddies who aren't targeting you directly from realizing they've stolen your key. The attack you should be concerned about is on your distribution side: You can't copy that binary anywhere else without revealing your key. You can't put it in a docker image repository or a java package repository or even a s3 bucket - Because those become places that your key can be revealed. And you want to do those things. You want a copy of precisely the binary you deployed.