67

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,

Juan Sebastian
  • 1,233
  • 3
  • 10
  • 13

3 Answers3

82

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.

Lindsay-Needs-Sleep
  • 921
  • 6
  • 5
  • 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 '19 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](https://docs.docker.com/engine/swarm/secrets/) – Alwin Kesler Feb 06 '19 at 18:36
  • 1
    @BMitch Added an example. Hope it helps you! (It has been awhile since I have worked with docker and my environment has quite a bit more going on... but I think this should work. Please let me know if I missed something!) – Lindsay-Needs-Sleep Feb 18 '19 at 11:42
  • I cannot replicate this on my services _without a swarm_ (`docker-compose.yml` on a single node); when I start the container `/run` only contains an `nginx.pid` and there are no `Mounts` shown by `docker inspect $container`. – giorgiosironi Apr 17 '19 at 07:48
  • I can replicate it with the original images used here however; going to find out what is the difference. – giorgiosironi Apr 17 '19 at 07:53
  • My problem was that the container needed to be recreated after `secrets` is added to the service configuration. `docker-compose down` should be run before applying the change, so that a new container is created with the `Mounts`. – giorgiosironi Apr 17 '19 at 12:38
  • 1
    This is awesome! After reading how secrets have been an issue for years and the problem has recently become solvable only via starting a swarm according to the official docs I'm so happy that it works via plain docker-compose now :D – Tobias Uhmann Apr 25 '19 at 17:17
  • What is the owner and permission for the `super_duper_secret.txt` file? – lonix Oct 07 '19 at 16:52
  • It has been very long since I have used docker, but I **believe** non-root owner-ship is fine. If it is root read-only, than you might need to run docker compose as root. Let us know how it goes! – Lindsay-Needs-Sleep Oct 10 '19 at 22:43
  • 1
    For me, it's not working, latest docker-compose says the `secrets` key is unknown for it. Could you add what docker-compose versions do you use and can you confirm it works on a plain new VM without Docker Swarm? – Gabor Garami Oct 11 '19 at 06:13
  • 1
    I don't have access to the VM I was using anymore. I can definitely confirm it was without swarm. I never touched it. My docker-compose.yml is version 3.6. According to this, v3.6 works with docker engine 18.02.0+ and v3.7 works with 18.06.0+. v3.6 was the newest when I was working on this. I think it is safe to guess that my version was between 18.02.0 and 18.06.0. I think it was probably 18.03.0. Is your's above 18.06.0? If so, would you be able to try a lower version? If that works, I will update the answer with a max version. Thanks! – Lindsay-Needs-Sleep Oct 19 '19 at 15:59
  • 9
    Just thought I'd link to the PR that added this to plain docker-compose (without swarm). https://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 ( https://github.com/dnephin/compose/blob/8c4fc4bc2ed82648f7a6ab7e14a492368f997415/compose/config/config.py#L234 ), so wouldn't expect a max version. – ThatOneDude Oct 23 '19 at 00:39
  • 2
    I've created an example with mysql as a gist: https://gist.github.com/ronaldb/d4b3d3327a5f80bfd12d748ca0ae91ae - same idea as the cat, but using a more practical application. – RonaldB Nov 25 '19 at 03:20
  • 1
    This is helpful, but it doesn't use `docker secret`, which I believe the question is about. – reinierpost Jan 09 '20 at 13:04
  • Major caveats exist: docker-compose will only set the secrets on the local docker engine. Secrets will not be passed when docker-compose is talking to a remote daemon. Given we talk about the merits of swarm vs. docker-compose, it assumes the target is a multi-node set. And with that docker-compose becomes a mute point. – barbazoo Feb 07 '21 at 00:24
  • 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](https://docs.docker.com/compose/reference/#specifying-multiple-compose-files) 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 02 '21 at 05:19
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.

yield
  • 771
  • 1
  • 9
  • 24
  • 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. – Juan Sebastian Aug 29 '17 at 19:41
  • @JuanSebastian you should check out Docker 'build-args' for that use case. – user23390 Oct 11 '17 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 '17 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 '19 at 03:30
  • How would Vault help in this scenario? – Shōgun8 Mar 06 '20 at 19:35
  • @Octavian it would server as a secure storage that handles who gets access to which secret, and (im thinking what i was doing 3 years ago) you would then code your stuff so every secret had to be negotiated and accessed through vault, every time it needed to be used. – Juan Sebastian Jun 18 '20 at 20:25
  • The docker documentation states that buildArgs should not be used for secrets since they are visible in docker history. Vault is a better way to go. – Mathias Mamsch Jan 28 '23 at 20:42
2

Yes (but actually No)

No Currently Docker doesn't support config & secrets if you're not in a swarm

But the docker compose specs have configs & secrets compose specs

So How does it works ?

It actually create a docker volume to make you believe the functionality is here, more concretely it's a Bind mount

enter image description here

That's a big difference with swarm if you want to deploy your app remotely!

example

services:
  test:
    image: alpine
    secrets:
      - source: my_secret
secrets:
  my_secret:
    file: $PWD/secret

is relatively identical to this

services:
  test:
    image: alpine
    volumes:
      - $PWD/secret:/run/secrets/my_secret:ro

If you're looking at your volumes with docker inspect <container> if and you're using secret you will see that your secrets are just local bind volumes

Fl_ori4n
  • 121
  • 3
  • 2
    I wondered if this were the case. Because I was seeing the mentions of secrets in the compose file spec and there are no caveats given there about requiring to be in the context of a swarm. but others were saying you need to be in a swarm... thanks. – pooley1994 Feb 16 '23 at 18:35