If you are decrypting things remotely , that means you need to pass the private key to the remote host, at least temporarily. An advantage is that you don’t need to worry about production secrets being open locally, or having to remove them after the deploy. But the disadvantage is that your private key has to (at least momentarily) be present on all remote hosts you are deploying to.

Finally, you can decide that you want to keep secrets encrypted everywhere, including remote hosts, and make your application automatically decrypt the secrets upon reading them. For this you would need to pass the private key to all remote hosts, perhaps as environment variable, and add some code to reading in your settings, that decrypts it on the fly. This method is the most secure of the above, because the decrypted secrets only exist in RAM, which means that merely having access to the disk of the server is not enough to compromise your app.



An attacker has to have a full login access to your remote server, or a Docker container. And let’s face it — if the attacker gains login access to your server, all bets are off at this point. They can probably fireup irb or a remote debugger, and connect to your app’s ruby runtime to fetch the secrets. They can also quickly figure out how the app is getting its encryption key by examining the code and the environment variables. So we won’t focus much on the case when the remote server is completely compromised, but focus on the cases where may just partial access — such as disk access — is available to the attacker. In these situation you really don’t want to have unencrypted secrets lying around the filesystem.