I’m preparing to deploy an app to production, using Docker Swarm.
Secret-management being an important part of securing a deployment, I want to know how much additional effort an attacker needs to apply in order to extract secrets, after gaining access to a manager node?
The documentation states that docker secrets encrypts the data at rest, but I have yet to find a clear statement of how. The closest I’ve found is a reference to base64-encoding, which is barely even obfuscation, let alone encryption. So my questions are:
What encryption algorithm does docker secrets use?
How is the decryption key protected, given that no user interaction is required at startup?
What additional steps can/should we take to make life even harder for the red team?
The secrets are stored in the raft log, which is replicated amongst the manager nodes. Though, there is no documentation about how the secrets are encrypted. I guess a good look at the moby sources should shed some light about what is actually used.
Make sure you use docker secret create rather than declaring it in a compose file, as the latter requires the secret to exist as plaintext file on the host…
When a swarm service is created, the secret will be decrypted in memory and mounted as read-only tmpfs file system into the container. To state the obvious: a secret will not persist in the container file system or in a volume, unless something (an entry point script, a user?) inside the container copies it from the mounted location to a different location.
The only way to protect access to the mounted plaintext secret file inside the container, is to use the long syntax to set owner uid/gid and permission mask. From my experience, the target can be an arbitrary absolute path inside the container (even though the documentation says something else ). But, if you put into account that your entry point script or application needs to have permissions to read the plaintext secret file itself, you will notice that it’s not realy feasible to protect access to the secret plaintext file inside the container.
The best way to protect secrets is to restrict access to the docker engine. Everyone able to execute docker commands will be able to easily get the value of the secrets. Either don’t grant access to untrusted parties, or use Protect the Docker daemon socket | Docker Documentation in combination with Open Policy Agent | Docker to establish a fine-grained access control.
). But, if you put into account that your entry point script or application needs to have permissions to read the plaintext secret file itself, you will notice that it’s not realy feasible to protect access to the secret plaintext file inside the container.