Docker swarm secrets - stop gaining access to decrypted secret mounted in an in-memory filesystem

[muthumani-prabhu]

When a newly-created service is granted with access to a secret, the decrypted secret is mounted into the container in an in-memory filesystem. The location of the mount point within the container defaults to /run/secrets/<secret_name>. This still doesn't stop anyone to gain access to the secrets by running

1. "docker exec" command
2. Creating new service by granting access to a secret

Is this a valid case? Are any other approach available to plug this gap?

If the intention of the docker swarm secrets and lock is to secure user secrets, then without plugging the gap of gaining access through the above means will seem to to be uncompleted. Please let me know your thoughts and suggestion on possible approaches.

[thaJeztah]

Being able to run docker exec requires access to the docker API on the host where the container runs; having API access is equivalent to having root access on the host. If someone is able to get that, your node, and any information on that host is compromised.

Creating new service by granting access to a secret

Doing so requires API access on a manager node. Having API access means you have full control over the cluster, including all information in the cluster.

(Assuming Docker Community Edition; Docker Enterprise Edition has role-based access control, which can limit the actions a user can perform on the API).

You’re correct that both situations allow access to secrets, but only in a situation where your system was compromised (someone was able to obtain root access, or equivalent on the machine)