Introducing Docker Secrets Management

Re:Introducing Docker Secrets Management by mikegerwitz on Thursday February 09, 2017 @02:10PM (#13609869)

The docs explicitly state "You cannot remove a secret that a running service is using". I'm not comfortable with sensitive secrets remaining plaintext in memory after the running service possibly does not need it anymore (e.g. maybe the service only needs it on startup). It seems like you could rotate the key with something else, but that doesn't seem ideal. Or can the container itself remove the secret "file"?

Consequently, because it's mounted as a filesytem, what if the service is compromised and vulnerable to arbitrary code execution, directory traversal, etc? The secret could then be leaked.

Am I misinterpreting something? How would others here handle this?

Edit: To clarify: rotating a secret will cause the service to restart. So I guess by "doesn't seem ideal", I mean it doesn't seem like an option.

[ Parent | on HN ]

Re:Introducing Docker Secrets Management by cpuguy83 on Thursday February 09, 2017 @02:20PM (#13609954)

You can update a service to not use a secret once it's not needed. Of course this will restart the task(s) I think. Definitely worth thinking about. Maybe a single-read secret or something.

If a service is compromised, you should always assume the secret is compromised.

[ Parent | on HN ]

Re:Introducing Docker Secrets Management by mikegerwitz on Thursday February 09, 2017 @02:23PM (#13609987)

> Maybe a single-read secret or something.

I like this idea. As a benefit, you wouldn't have to rely on developers of individual services to make sure the secret is cleared. This would also have the benefit of causing an error if something else happened to read the secret before the intended service, indicating a possible compromise (or maybe just a misconfiguration).

(I use a similar concept with `xclip -l' to allow reading passwords from the clipboard a single time before it quits.)

[ Parent | on HN ]