docker / cli

The Docker CLI
Apache License 2.0
4.84k stars 1.91k forks source link

Proposal: deprecate base64 credentials in config.json #559

Open n4ss opened 6 years ago

n4ss commented 6 years ago

We think w/ @tych0 that storing the credentials directly in a config file in home directory is not safe at all and we should remove this option as the credential management has improved a lot on every platform since then.

@tych0 has implemented a new (and lightweight) backend for credential-helpers on Linux based on pass so now users can easily store credentials on Linux, Windows and MacOS. His docker/cli PR also got merged: https://github.com/docker/cli/pull/451 so we should be good to go on removing plaintext password. (having pass credential store by default is on the way)

/cc @vdemeester @thaJeztah

tych0 commented 6 years ago

I guess we'll need to deprecate it and print a big warning and such, per the deprecation policy. I'm happy to send a patch that does this if we decide we want it.

thaJeztah commented 6 years ago

Deprecating it would finally address https://github.com/moby/moby/issues/10318 :tada: - this would require a longer deprecation period though, because this has been supported for a really long time. Perhaps we may even have to consider having an environment variable that allows keeping the old storage after it's been deprecated (but happy to hear if that's taking it too far) 😅

vdemeester commented 6 years ago

this would require a longer deprecation period though, because this has been supported for a really long time.

So let's try to deprecate it as soon as possible :stuck_out_tongue: :angel: :pray:

cc @dnephin @vieux @tiborvass @cpuguy83

tiborvass commented 6 years ago

@tych0 @n4ss does this mean the docker-ce deb/rpm package would have a dependency on pass ? Do we care about behavior of static builds used on more esoteric platforms?

I don't think we can completely remove the insecure option: where there is no pass, and when docker pull is called in scripts (not a tty). We just have to inform very explicitly that it is insecure, and do our best to have secure defaults on the most platforms.

tych0 commented 6 years ago

On Tue, Sep 26, 2017 at 05:31:25PM +0000, Tibor Vass wrote:

@n4ss does this mean the docker-ce deb/rpm package would have a dependency on pass ? Do we care about behavior of static builds used on more esoteric platforms?

It depends, but yes, I think it should. There's nothing that links against pass binaries or anything, so you could install it, and the pass helper would just try to exec the binary and fail, and default to secretservice.

I don't think we can completely remove the insecure option: where there is no pass, and when docker pull is called in scripts (not a tty). We just have to inform very explicitly that it is insecure, and do our best to have secure defaults on the most platforms.

What's the problem with docker pull? As far as I can tell, it just says "run docker login":

$ docker pull tycho/private Using default tag: latest Error response from daemon: pull access denied for tycho/private, repository does not exist or may require 'docker login'

eubnara commented 5 years ago

Is there any plan not to store password credentials? I just want to use one-time docker login. If I use the same machine with my teammates, it is hard to secure my password. Even though I use pass, the person who makes gpg id with passphrase is able to know passwords on the same machine using docker-credential-pass like this:

$ docker-credential-pass get
(type registry address)
(type passphrase for gpg id)

When someone share a machine, I think it is safe to login only one-time and not to save one's password like git. git with default settings does not save password.

thaJeztah commented 5 years ago

@eubnara perhaps better to open a new ticket / enhancement request for that. That said; I think all existing credential-stores are per-user, so even though the machine could be shared between colleagues; if colleagues use their own user-account on the machine, they would not have access to other colleague's credentials (from the client perspective; if the daemon is running on the same host, and they have access to the API, they effectively have root access on the machine)