65

Currently we im a running application on a single docker container, the application needs all sorts of sensitive data to be passed as environments variables,

Im putting those on the run command so they don't end up in the image and then on a repository, however i end up with a very non-secure run command,

Now, i understand that docker secrets exist, however, how can i use them without deploying a cluster? or is there any other way to secure this data?

Best Regards,

1

2 Answers 2

9

You can't... It does not support secrets without Swarm. Unless ''may be'' you ''Swarm'' using only one node.

The other solution would be, I think to use a third party vault software like this one:

https://www.vaultproject.io/

But then, to use the secrets in your containers from Vault, you would need to read the doc.

Hope this bring you to the right path to start.

6
  • Actually i just need to inject these secrets when creating the containers, they do not really need to remain "secret" inside the running containers, so i guess it would make sense for the host to be able to access and use the secrets when invoking the docker run command, i guess i can write a script with a bunch of replaces and calls to vault. Aug 29, 2017 at 19:41
  • @JuanSebastian you should check out Docker 'build-args' for that use case.
    – user23390
    Oct 11, 2017 at 15:08
  • @JuanSebastian I might be wrong, but getting the local ENV would give you what's inside thoses build-args.... Not sure .....
    – yield
    Oct 30, 2017 at 18:13
  • build-args are not included in the final image, but can only be accessed during image build time. A suitable solution is to write the secrets to files on the host (with appropriate permissions, of course) then volume mount them into your docker container. Your application inside the container can then read the secrets from those files
    – Brandon
    Sep 12, 2019 at 3:30
  • How would Vault help in this scenario?
    – Shōgun8
    Mar 6, 2020 at 19:35
78

Yes, you can use secrets if you use a compose file. (You don't need to run a swarm).

You use a compose file with docker-compose: there is documentation for "secrets" in a docker-compose.yml file.

I switched to docker-compose because I wanted to use secrets. I am happy I did, it seems much more clean. Each service maps to a container. And if you ever want to switch to running a swarm instead, you are basically already there.

Note: Secrets are not loaded into the container's environment, they are mounted to /run/secrets/

Here is a example:

1) Project Structure:

|
|---    docker-compose.yml
|---    super_duper_secret.txt

2) docker-compose.yml contents:

version: "3.6"

services:

  my_service:
    image: centos:7
    entrypoint: "cat /run/secrets/my_secret"
    secrets:
      - my_secret

secrets:
  my_secret:
    file: ./super_duper_secret.txt

3) super_duper_secret.txt contents:

Whatever you want to write for a secret really.

4) Run this command from the project's root to see that the container does have access to your secret, (Docker must be running and docker-compose installed):

docker-compose up --build my_service

You should see your container output your secret.

16
  • 1
    Can you show a working example of docker-compose using a secret? The documentation and my understanding of the implementation indicate that the secret will not be configured in the container.
    – BMitch
    Jan 31, 2019 at 13:56
  • 3
    Docker secrets are only available to swarm services, not to standalone containers. To use this feature, consider adapting your container to run as a service. Stateful containers can typically run with a scale of 1 without changing the container code. docker Feb 6, 2019 at 18:36
  • 9
    Just thought I'd link to the PR that added this to plain docker-compose (without swarm). github.com/docker/compose/pull/4368 It really is in there and from the code it looks like min version for compose file is 3.1 and API is 1.13.0. Code is still in current master ( github.com/dnephin/compose/blob/… ), so wouldn't expect a max version.
    – ssnobody
    Oct 23, 2019 at 0:39
  • 2
    I've created an example with mysql as a gist: gist.github.com/ronaldb/d4b3d3327a5f80bfd12d748ca0ae91ae - same idea as the cat, but using a more practical application.
    – RonaldB
    Nov 25, 2019 at 3:20
  • 2
    WHY would anyone do this, when without swarm, the effect is the same as a bind-mount but with (arguably) more complex config? The answer lies in compatibility, and predictability: Most of your service yaml will work the same (maybe you have modularized it) both for single-engine and swarm-mode. And software inside containers can make assumption about where to find secrets "/run/secrets" (read-only by default, btw) as opposed to each app coming up with its own "standard" mount points.
    – conny
    Jul 2, 2021 at 5:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.