
Introducing Docker Secrets Management - ferrantim
https://blog.docker.com/2017/02/docker-secrets-management/
======
diogomonicapt
I think with this release things have come full circle for me. I was part of
the team that 5 years ago built Keywhiz at Square, starting the whole "secrets
should be files exposed as an in-memory filesystem" thing.

Building it a second time was interesting. One of the biggest reasons why
Keywhiz didn't go anywhere was the fact that it is incredibly hard to setup,
and requires you to bring your own PKI. This time we didn't make that mistake
and integrated directly into Swarm, which is the right place for it to live,
and turns setting up your own PKI into a one-liner.

Anyway, AMA.

Disclosure: I work on the Docker Security team

~~~
himanshuy
Is Docker PCI compliant? My application deals with a lot of PII data. There
was a lot of concern in my team over SOC-2 and PCI compliance when I suggested
using Docker. We also talked to one of the solution architects from Amazon and
he wasn't sure if Docker is ready for PII data.

~~~
Diederich
> solution architects from Amazon and he wasn't sure if Docker is ready for
> PII data.

I'm curious if you can relate what his reasoning was?

Docker is, among other things, a wrapper around a bunch of Linux kernel
functions, the likes of which have been used for many, many years by companies
like Google to facilitate all kinds of useful isolation.

~~~
paulddraper
I think it's pretty well agreed that multi-tenant Docker isn't a good security
solution.

Use it for for operational isolation, not for critical security isolation.

~~~
Diederich
That's what I've heard as well, and I agree with that assessment, given that
the requirement is to separate untrusted code execution.

At the same time, going back to the initial quote:

> solution architects from Amazon and he wasn't sure if Docker is ready for
> PII data

A lot of companies are using containers to execute code that manages all kinds
of regulated data right now, ya?

The security limitations of Linux namespaces and friends are mostly related to
the execution of untrusted code.

------
unpythonic
This looks amazing. Solving secret distribution across containers will be very
useful. Being able to see via `docker secret` exactly which services are using
which secrets is an unexpected treat.

I'm a little worried about two aspects of what has been shown. From the
article it shows:

    
    
        $ docker exec $(docker ps --filter name=redis -q) ls -l /run/secrets
        total 4
        -r--r--r--    1 root     root            17 Dec 13 22:48 my_secret_data
    

From this we can tell exactly how long the secret is. If the secret service
didn't do it for us, I'd like for the secrets to be null-padded to a uniform
2-4K of bytes.

I'm also a bit worried that the default protection on the file has it set to
world-readable. Since it appears that secret distribution is independent of
the container setup itself, there doesn't appear to be any way of setting
ownership and permissions on this file. That is, if one were able to
chmod/chown the file in the Dockerfile, running a `docker service update
--secret-rm` and `docker service update --secret-add` would reset such
'fixes'.

A great start, and I can't wait to start using it.

~~~
cyli
You can specify the UID, GID, and mode of the secret from within the
container:
[https://docs.docker.com/engine/reference/commandline/service...](https://docs.docker.com/engine/reference/commandline/service_create/#/create-
a-service-with-secrets), and pass the same configuration to the service update
command as well.

~~~
unpythonic
Oh, that's great to know. That coupled with filling out the size to an
uninteresting length with nulls (or another delimiter) covers my concerns. For
example:

    
    
        $ echo "my secret" | dd bs=512 conv=sync | docker secret create my_secret_data -

------
heroprotagonist
This is interesting, but in my opinion, it's not quite as universally useful
as some of the secret management in other security tools because you have to
explicitly manage the secret within your application by reading that in-memory
filesystem.

I'd much prefer passing a secret as an environment variable if that can be
done securely. It's possible with some tools, but not out of the box with
Docker itself.

eg, with one tool, you can do:

# docker run --rm -e PASSWORD={supersecret_password} someimage:latest program

Then '{supersecret_password}' gets replaced in the container at runtime with
the value stored in the tool or from an integration with a separate dedicated
secret management tool like HashiCorp Vault, and value gets masked external to
the container such as when running 'docker inspect' command.

The benefit is that you don't need to modify or maintain a lot of pre-packaged
applications that read environment variables instead of looking to the
contents of a file on the disk, so it just works out the box.

However, under ordinary circumstances, you may not want to pass secrets as
environment variables in docker (or at least be careful about it). A 'docker
inspect' command can show any docker user the environment variable and its
value, if you don't have a tool to encrypt the contents.

~~~
justincormack
Linux does not hide process environments, you can cat /proc/[pid]/environ to
read them. It is not a good way to pass secrets.

~~~
heroprotagonist
True, but people do it anyway and a large number of applications are
preconfigured to use them. But to the point, the same tool that hides the
secret and encrypts the variable in 'docker inspect' will also show it as
encrypted in /proc/[pid]/environ as well.

~~~
justincormack
That would be a kernel patch then. Good luck getting that upstream.

------
doublerebel
Comparing this to Vault (with which I have been very satisfied):

The article mentions a single master key for cluster encryption. Are there any
plans to split this as in Shamir's Secret Sharing?

How do secrets and secret authorizations renew and expire?

Any plans for limited-use tokens/secrets?

------
justincormack
Comparison of this with other secretes management frameworks here
[https://medium.com/on-docker/secrets-and-lie-abilities-
the-s...](https://medium.com/on-docker/secrets-and-lie-abilities-the-state-of-
modern-secret-management-2017-c82ec9136a3d#.ur0pnuirw)

~~~
tonyhb
wrote this as a comment when that article was posted to YC:

tl;dr: author looks at secret management services and reviews them

KeyWhiz: Provides everything you need but with complex PKI management, meaning
setup and maintenance is a pain. Secure.

Vault: A+ would test again. Awesome rotation policies, on-demand secret
generation via backends, master key sharing. Legit and secure, everything you
need but has to be configured on top of your cluster.

Docker: Super easy to use, and it's built in. 10/10 would use again. Keys
encrypted at rest, keys encrypted over the wire, and shared with only nodes
who need them. Secure all round

Kube: Totally insecure. Plaintext at rest, plaintext over the network, shared
everywhere. Basically a plaintext POC

~~~
Leon
Vault is really wonderful to work with, and its integration with consul makes
it phenomenally powerful.

~~~
jsfitzsimmons
What kind of stuff do you get from the integration? I mean, aside from the
obvious stuff like a clustered storage backend and leader election?

------
simplehuman
This is really nice. What is the equivalent in the kubernetes world?

~~~
eicnix
Kubernetes supported secrets for nearly 2 years:
[https://kubernetes.io/docs/user-
guide/secrets/](https://kubernetes.io/docs/user-guide/secrets/)

They currently debate over pluggable secret stores:
[https://github.com/kubernetes/kubernetes/issues/10439](https://github.com/kubernetes/kubernetes/issues/10439)

You can use Hashicorp Vault as a third party resource to store your secrets:
[https://github.com/Boostport/kubernetes-
vault](https://github.com/Boostport/kubernetes-vault)

Kubernetes also supports RBAC to control access to secrets:
[https://kubernetes.io/docs/admin/authorization/](https://kubernetes.io/docs/admin/authorization/)

~~~
tonyhb
Secrets as in passwords and keys stored at rest in plain text. So not really
secrets.

~~~
benth
It's not so much the plain text part that bothers me, it's the access control.

Quoting the docs at [https://kubernetes.io/docs/user-guide/secrets/#security-
prop...](https://kubernetes.io/docs/user-guide/secrets/#security-properties):

"Currently, anyone with root on any node can read any secret from the
apiserver, by impersonating the kubelet. It is a planned feature to only send
secrets to nodes that actually require them, to restrict the impact of a root
exploit on a single node."

As your cluster grows, your risk grows.

------
mnm1
Is there a way to manage secrets during the build process itself without
specifying them on the command line / docker compose files?

------
tlrobinson
It would be neat if you could inject secrets as environment variables.
Something like:

    
    
        --secret="my_secret:MY_SECRET"
    

Obviously you could have a script that does

    
    
        MY_SECRET=$(cat /run/secrets/my_secret) ./whatever
    

but a lot of existing containers can be configured via environment variables.

~~~
diogomonicapt
We explicitly chose not to support secrets as ENV variables, since they are
prone to being leaked (child processes inhering parent's env; easy to leak ps
-e; bug reports usually include ENV of the application; core dumps include ENV
of the application, etc etc)

~~~
tlrobinson
Makes sense, but how do child processes not have access to the secrets files?

~~~
diogomonicapt
My unstated assumption was that when calling something like imagetragick you
would be doing the appropriate privilege dropping using setuid and setgid.
This is obviously not necessarily the case, but it's at least _a lot_ more
common than people cleaning up the ENV before creating a child process.

------
daveguy
Not sure if anyone from docker is watching, but the images are cut off at the
side on mobile.

~~~
ManoMarks
Yes, someone from Docker is watching :-). I've alerted the blog team. Thanks
for letting us know.

------
lyschoening
Will we be able to use this on Docker Cloud soon?

~~~
justincormack
I believe it is coming soon yes.

