Add Secret store #6075

alexlarsson · 2014-05-28T08:20:53Z

This is a continuation of #5836, and the discussions about it we had on last weeks irc meeting. It implements a secret store that you can access via:

docker secret list
docker secret add a-name a-file
docker secret rm a-name

You can then grant access to a specific secret by using docker run --grant-secret a-name image.
The granted secrets are stored (by name) in the hostconfig, and will be re-granted on restarting the container (assuming the secret is still in the store). Additionally any files stored in /etc/docker/secrets are considered "host based" secrets and will be granted to all containers on the host.

On container start the secrets are copied into a tmpfs in /run/secrets, so they will not ever be part of any image based on the container.

There are no docs yet, I'll be working on that next.

timthelion · 2014-05-28T08:27:40Z

api/client/commands.go

@@ -72,6 +73,7 @@ func (cli *DockerCli) CmdHelp(args ...string) error {
 		{"run", "Run a command in a new container"},
 		{"save", "Save an image to a tar archive"},
 		{"search", "Search for an image in the docker index"},
+		{"secret", "Maintain secrets database"},


"Maintain a secrets database" or "Maintain a database of secrets"

alexlarsson · 2014-05-28T19:14:51Z

Update fixes the doc misspelling

cyphar · 2014-05-29T10:22:39Z

+1 for secrets which are added to a container's fs during run-time. This would be invaluable for ssh keys and other secrets. This is a feature which would make a project I'm working on much simpler.

alexlarsson · 2014-06-02T07:42:24Z

Updated to latest master

proppy · 2014-06-02T07:49:32Z

daemon/container.go

+		return err
+	}
+	for _, s := range data {
+		container.command.CreateFiles[filepath.Join("/run/secrets", s.Name)] = s.Data


did you consider /var/run or /var/tmp instead?

/var/run is typically a symlink to /run in "modern" distros. See e.g. https://wiki.debian.org/ReleaseGoals/RunDirectory
I don't think /var/tmp makes sense, its semantically less like a temporary file, more like a runtime transient file.

timthelion · 2014-06-02T08:51:05Z

@alexlarsson would you mind answering this: https://groups.google.com/forum/#!topic/docker-user/aWStVPCwq6w ?

cyphar · 2014-06-02T10:10:38Z

Out of interest, why --grant-secret and not just --secret or --secrets?

alexlarsson · 2014-06-02T14:23:24Z

@cyphar It grants access to a predefined secret rather than define a secret, so it felt right. I'm open to changing that of course, if we want it to be shorter then --secret would be better.

timthelion · 2014-06-02T18:03:24Z

--grant-secret is better, less ambiguos.

shykes · 2014-06-04T00:23:09Z

+1 on --grant-secret

crosbymichael · 2014-06-04T00:34:45Z

@alexlarsson why can these files not be bind mounted?

vieux · 2014-06-04T00:35:42Z

api/client/commands.go

+		} else {
+			hostBased := ""
+			if out.GetBool("HostBased") {
+				hostBased = "*"


can we use [OK] instead of * like in docker search ?

/cc @crosbymichael @shykes

Well, that signifies "trusted" to which "ok" seems to make sense. Here it is a bit more generic boolean. Maybe [x] ?

Maybe [HOST] or just [H]?

alexlarsson · 2014-06-04T07:08:32Z

@crosbymichael We want to copy the files for real into the container so that later changes to the secret store does not affect running containers. For instance, it should be possible to remove a secret from the store once a container is started with it. Furthermore, we might have secrets that are not necessarily stored as regular files in the filesystem in the future (in an earlier patch the secrets were never on the host fs at all for instance).

That said, we could perhaps use bind mounts at a higher level. I.e. mount the tmpfs on the host, copy files to it, then bind mount it into the container and unmount the host version. I'll have a look at that.

alexlarsson · 2014-06-04T08:25:40Z

@crosbymichael Here is the alternative implementation using a tmpfs from the host bind-mounted in:
alexlarsson@d92b083

If you prefer that approach we can drop a bunch of the libcontainer commits when this is squashed in.

If you implent CmdFoo with an extra boolean first arg, and CmdFooList and CmdFooAdd as usual the code will make this just work. Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)

The secrets store keeps track of a set of named secrets, such as API keys or ssh keys that you can later access from containers. There are two types of secrets, the host based ones, which are stored in /etc/docker/secrets, and are automatically applied to all containers, and user secrets which you can add via "docker secret add <name> <file>" and which can be granted permission to by name. You can also list secrets with "docker secret list" and remove them with "docker secret rm". Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)

If you run something like docker run --grant-secret foo image Then the "foo" secret will be copied into a /run/secrets tmpfs in the container. Additionally, all host-based secrets will be copied into all containers running on a specific host. Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)

This is useful if you want to use secrets during docker build which will not be recorded in the final image. Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)

Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)

alexlarsson · 2014-06-16T13:41:23Z

I rebased on master with the alternative approach from above.
Note, this depends on this PR for libcontainer to avoid a race condition: docker-archive/libcontainer#22

SvenDowideit · 2014-06-16T23:47:48Z

docs/sources/reference/commandline/cli.md

+
+Lists the names and details of all the secrets that are installed in
+the docker daemon secret store. Access to these secrets can be granted
+to containers at user disgression.


I presume you mean discretion :)

vbatts · 2014-06-24T19:51:40Z

@SvenDowideit how about the commit I've added here https://github.com/vbatts/docker/compare/alexlarsson-secrets

SvenDowideit · 2014-06-24T23:05:29Z

@vbatts @alexlarsson better, but still i don't think its enough. I would suggest adding a mention to the --grant-secrets cli summary; something like the selected secret file will be added in /run/secrets, and the docker build and docker run cli.md and man pages really do need to talk about what a secret is (it seems you've hinted that a secret is actually a single file, and that it will go into /run/secret, but you've not actually explicitly said so.

now to the harder part....

Does this mean /run/secret is now special, and any base image with that dir will lose access, or are you just inserting a file? Also... can I have more than one secret?

these questions should be answered for the reader in the cli documentation - otherwise they're left not knowing - and obviously, if its documented, there should be tests for that.

timthelion · 2014-06-24T23:10:04Z

/etc/docker/secrets is also completely undocumented.

vbatts · 2014-06-25T20:41:33Z

@SvenDowideit @timthelion k. I'll work on this.

vbatts · 2014-06-26T14:57:21Z

@SvenDowideit @timthelion see #6697

vbatts · 2014-06-26T17:52:46Z

As a note, I've identified a couple of items regarding this feature that I will either fix or get clarity on.

docker secret add can not handle adding directories, but the /etc/docker/secrets handles directories fine
duplicate file names can not be added through docker secret add, but can exist if a duplicate is added to /etc/docker/secrets/ after the first is added through the cli
despite /run/secrets being create as 0700, once mounted tmpfs it's sticky world readable 1777 inside the container

Also, i'm not sure how to handle the uniqueness of file names, and having them appear in the container in a consistent way. Perhaps to have a markup, similar to --volume, so there could be --grant-secret=:content.pem to have the uniquely named file from the host/store, be available in the container as "content.pem".

timthelion · 2014-06-26T19:12:38Z

@vbatts I think that the existence of /etc/docker/secrets should really be reconsidered. When this was discussed at the a contributers IRC meeting which lead to this PR the idea of having /etc/docker/secrets was not really agreed upon. The whole point of this PR was supposed to be "to have something simple that can make it into 1.0". That is obviously a mute point now. It would be much better to have a docker secret set-group global command or something like that.

SvenDowideit · 2014-06-30T04:50:05Z

are we moving to #6697, and thus should close this to avoid losing info due to split conversation?

vbatts · 2014-06-30T15:41:13Z

@SvenDowideit I'm not opposed to moving the conversation. Most of the meat of the design is on this issue.

@timthelion I can't disagree with you. I've only gotten involved on this request recently. Perhaps having a syntax like docker secret add --global foo.cert would be simpler and more understandable. Also, gating everything at add helps with the duplicate/conflicted name bug in the current implementation. And docker secret rm ... would still work the same. The issue becomes that "host secrets" implies an ACL that docker does not currently have full support of. Even adding a flag like --globabl so that the secret file is in all new containers, means that any user that is in the 'docker' group can add/rm with global secrets. Where as, as a sysadmin of the host I could ensure that this file is in all new containers, and a user in the 'docker' group could not remove that secret. This is a use case that is not easily done just-in-docker.

erikh · 2014-08-01T18:05:37Z

The changes here in server/buildfile.go conflict with recent changes to this functionality. Can you rebase?

timthelion · 2014-08-01T20:15:06Z

@SvenDowideit Yes, please close this in favor of #6697, this is getting confusing :(

tiborvass · 2014-08-01T20:17:28Z

Closing in favor of #6697 (which is carrying this PR)

alexlarsson mentioned this pull request May 28, 2014

Add private files support #5836

Closed

timthelion reviewed May 28, 2014
View reviewed changes

alexlarsson added the /project/doc label May 29, 2014

proppy reviewed Jun 2, 2014
View reviewed changes

alexlarsson mentioned this pull request Jun 2, 2014

New implementation of /run support #5991

Closed

vieux reviewed Jun 4, 2014
View reviewed changes

alexlarsson added 6 commits June 16, 2014 15:39

Add --grant-secret support to docker build

78cb8f5

This is useful if you want to use secrets during docker build which will not be recorded in the final image. Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)

API docs: add the new secret based requests

103c898

Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)

docs: Add cli docs for the secret store

d6a4427

Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)

SvenDowideit reviewed Jun 16, 2014
View reviewed changes

SvenDowideit mentioned this pull request Jun 17, 2014

Forward ssh key agent into container #6396

Open

vbatts mentioned this pull request Jun 26, 2014

Continuation of the docker secret storage feature #6697

Closed

oxypwn mentioned this pull request Jul 22, 2014

How to keep the created user directory permanent ? boot2docker/boot2docker#438

Open

tiborvass closed this Aug 1, 2014

cyphar mentioned this pull request Jan 23, 2015

Proposal: The Docker Vault #10310

Closed

thaJeztah mentioned this pull request May 26, 2015

Secrets: write-up best practices, do's and don'ts, roadmap #13490

Open

parthaa mentioned this pull request Aug 22, 2016

Need a way to specify custom directories for rhsm configuration projectatomic/docker#186

Open

Atchuu mentioned this pull request Jun 21, 2018

Can microdnf use rhui for yum package installations? rpm-software-management/microdnf#32

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Secret store #6075

Add Secret store #6075

alexlarsson commented May 28, 2014

timthelion May 28, 2014

alexlarsson commented May 28, 2014

cyphar commented May 29, 2014

alexlarsson commented Jun 2, 2014

proppy Jun 2, 2014

alexlarsson Jun 2, 2014

timthelion commented Jun 2, 2014

cyphar commented Jun 2, 2014

alexlarsson commented Jun 2, 2014

timthelion commented Jun 2, 2014

shykes commented Jun 4, 2014

crosbymichael commented Jun 4, 2014

vieux Jun 4, 2014

alexlarsson Jun 4, 2014

cyphar Jun 4, 2014

alexlarsson commented Jun 4, 2014

alexlarsson commented Jun 4, 2014

alexlarsson commented Jun 16, 2014

SvenDowideit Jun 16, 2014

vbatts commented Jun 24, 2014

SvenDowideit commented Jun 24, 2014

timthelion commented Jun 24, 2014

vbatts commented Jun 25, 2014

vbatts commented Jun 26, 2014

vbatts commented Jun 26, 2014

timthelion commented Jun 26, 2014

SvenDowideit commented Jun 30, 2014

vbatts commented Jun 30, 2014

erikh commented Aug 1, 2014

timthelion commented Aug 1, 2014

tiborvass commented Aug 1, 2014

Add Secret store #6075

Add Secret store #6075

Conversation

alexlarsson commented May 28, 2014

timthelion May 28, 2014

Choose a reason for hiding this comment

alexlarsson commented May 28, 2014

cyphar commented May 29, 2014

alexlarsson commented Jun 2, 2014

proppy Jun 2, 2014

Choose a reason for hiding this comment

alexlarsson Jun 2, 2014

Choose a reason for hiding this comment

timthelion commented Jun 2, 2014

cyphar commented Jun 2, 2014

alexlarsson commented Jun 2, 2014

timthelion commented Jun 2, 2014

shykes commented Jun 4, 2014

crosbymichael commented Jun 4, 2014

vieux Jun 4, 2014

Choose a reason for hiding this comment

alexlarsson Jun 4, 2014

Choose a reason for hiding this comment

cyphar Jun 4, 2014

Choose a reason for hiding this comment

alexlarsson commented Jun 4, 2014

alexlarsson commented Jun 4, 2014

alexlarsson commented Jun 16, 2014

SvenDowideit Jun 16, 2014

Choose a reason for hiding this comment

vbatts commented Jun 24, 2014

SvenDowideit commented Jun 24, 2014

timthelion commented Jun 24, 2014

vbatts commented Jun 25, 2014

vbatts commented Jun 26, 2014

vbatts commented Jun 26, 2014

timthelion commented Jun 26, 2014

SvenDowideit commented Jun 30, 2014

vbatts commented Jun 30, 2014

erikh commented Aug 1, 2014

timthelion commented Aug 1, 2014

tiborvass commented Aug 1, 2014