dockercfg insecure #10318

Closed
rafaelhbarros opened this Issue Jan 23, 2015 · 61 comments

Projects

None yet
@rafaelhbarros

After a docker login, the CLI stores the password encoded in base64 in a file called dockercfg, and that is not entirely secure. I'd like to suggest changing that to keep either a token returned from the index, or another security mechanism to be implemented instead of saving passwords in plaintext.

This is particularly unsafe in case of open/shared workstations or in case the authentication happens against a custom index with higher security concerns about the password.

@tianon
Member
tianon commented Jan 23, 2015

So many +1s; this has bothered me for a while.

As I mentioned in #10151 (comment), I'd be +1 to removing this file entirely in favor of using the new ~/.docker directory appropriately instead, but if fixing this particular issue required some transition, switching to a new file at the same time would be perfect timing to kill two birds with one stone IMO.

@nathanleclaire
Contributor

Huge +1 to this issue and to @tianon comment.

@jessfraz
Contributor

+1 ugh base64

@dmp42 dmp42 added the Distribution label Jan 23, 2015
@zfogg
zfogg commented Jan 23, 2015

+1 wow, this should be top priority.

@daidoji
daidoji commented Jan 23, 2015

+1

@pfultz2
pfultz2 commented Jan 23, 2015

+1

This is a pretty big deal. HTTPS might make basic http auth secure for network communications, but its not secure when the basic auth token(which is USER:PASSWORD with base64 encoding) is stored on the machine.

@netroby
netroby commented Jan 24, 2015

And we should migrate the current dockercfg into new .docker file if we would like to made this change.

@SEJeff
SEJeff commented Jan 24, 2015

There isn't really a need for everyone to +1 this, just subscribe to this issue with the subscribe button to the right. That being said, clear text in the file is a very poor design.

For tokens, perhaps json web tokens would work? I'm also a HUGE fan of allowing passing the token in a custom Authorization header so that it doesn't make it's way into the logs server side.

The way django-rest-framework does json tokens it is pretty decent IMO. They require passing the token with a header like:

Authorization: Token {TOKEN_VALUE_HERE}
@shykes
Contributor
shykes commented Jan 24, 2015

Hi all, this is a known issue and the distribution maintainers are working on rolling out token-based auth. Meanwhile there is work underway to switch to keypair-based authentication and authorization for all components of Docker, including but not limited the registry.

Ping @dmp42 @dmcgowan @jlhawn

@shykes
Contributor
shykes commented Jan 24, 2015

I suppose a few haters are already busy writing another vitriolic blog post... Yes, storing user credentials in plaintext, even with proper permissions, is not ideal, and as explained above we are working on something better. But it's not unheard of, either: see for example .netrc from the standard gnu toolchain: http://www.gnu.org/software/inetutils/manual/html_node/The-_002enetrc-File.html

A reminder: one way or the other, you'll still need to store some private credential on your machine, and who can access them on the filesystem will still be crucially important. The reason passwords are worse than private keys in that regard is that they are more likely to be re-used across domains and tools, and can't be additionally protected by a passphrase.

@pfultz2
pfultz2 commented Jan 24, 2015

But it's not unheard of, either: see for example .netrc from the standard gnu toolchain

Thats not really the same thing. The .netrc file lets you optionally store the password in a file, plus, the password is for a protocol that is entirely insecure as well(ie it sends the password over the network in plaintext). Should we assume that docker is insecure like the telnet protocol?

@thaJeztah
Member

I hope this gets top priority to find a better alternative;

For the 1.5 release (I know it's in freeze, but to prevent negative reports); at least output a message that the password will be stored as (what I consider to be) plain text. As an example, this is what SVN will output;

ATTENTION! Your password for authentication realm:

http://domainname.com:80 “domainname.com”

can only be stored to disk unencrypted! You are advised to configure your system 
so that Subversion can store passwords encrypted, if possible. See the 
documentation for details. You can avoid future appearances of this warning by 
setting the value of the 'store-plaintext-passwords' option to either 'yes' 
or 'no' in '/root/.subversion/servers'.

Store password unencrypted (yes/no)? no

The warning should also mention where the password is stored, allowing people
to remove the stored password afterwards.

I'm also a HUGE fan of allowing passing the token in a custom Authorization header so that it doesn't make it's way into the logs server side.

I don't know if this is what's currently happening, but if these tokens are actually included in the logs on the registry, that's a serious issue. If a registry server gets compromised, all passwords are in the open. If possible, something should be put in place to scrub that data from the logs, also going back to existing logs (and backups).

For a future release, I really hope for a per-host token, including a way to revoke tokens from within the registry control-panel. That gives users control over each host that has access to the registry, eve if they don't have access to that host itself.

Once a new system is in place, people should be notified to reset their password, in case dockercfg are left behind on hosts where they have logged in in the past.

@sardaukar

No wonder people are jumping ship to other projects - the passive-aggressive is strong with @shykes in this thread :/

@thaJeztah
Member

@sardaukar I don't think it's fair to directly jump to conclusions here; also, you need to be logged in to a host in order to have access to that file. If you're logged in to the host, you'll also have access to all your private keys, and I don't think anyone has a problem with that?

The registry logging is something that I would like to have confirmed but until that becomes clear, please don't draw conclusions and start spreading rumours that have not been confirmed.

@thaJeztah
Member

I just had a short chat with @shykes on IRC; he's famously bad at responding to issues like this and decided to not respond further to prevent posting foolish comments 😄

He also thought that the distribution team (@dmp42 @stevvooe @dmcgowan @jlhawn) should be able to provide more information on progress on this issue and provide answers to some of the questions being raised here (wrt the registry, logging?).

I know a lot of work is currently going on with changes to the registry (V2) (see the distribution repository) including the way the docker daemon communicates with the registry (a complete new API), so chances are this is a thing of the past soon.

@dmcgowan
Member

@thaJeztah you are right, this will soon be a thing of the past. We cannot simply rip this out since many users are relying on it, but we are adding the building blocks to replace it in 1.5. This includes adding a public key identity to the client and a new authorization server for the registry which relies on token authentication and will soon be able to be authenticated using the public key identity. The initial version will continue to use basic auth credentials with added public key support once the authorization server has seen more use. PTAL at #9081 for the proposal of how authentication now works with the registry.

Another possible short term solution is now that we have the public key identity of the client, we can use the key pair to encrypt the dockercfg file. It is worthy of a proposal.

As for the logging mentioned, is this referring to adding a warning when storing the user's credentials in plain text? It is worth generating a PR to discuss, I think it sounds reasonable to address a real concern.

@sardaukar

@thaJeztah not jumping too much, just mirroring the mood from Reddit (www.reddit.com/r/programming/comments/2tga5a/docker_stores_usernamepasswords_in_essentially/) :/ comments like these are not cool

@thaJeztah
Member

@dmcgowan wrt the logging; concerns were raised if the authentication being sent the way they are now end up in log-files on the registry-servers. I don't think that's the case, but the possibility was raised here #10318 (comment).

@dmcgowan
Member

@thaJeztah basic authentication is not handled directly by registry. In the case of private registries it is handled by the proxy (nginx, haproxy) and the v1 public registry uses an index to issue tokens as described in #9081. I can confirm there is no possibility of the username/password getting logged in the new v2 registry, I am not as familiar with the v1 codebase but I can let @dmp42 confirm it is not.

@thaJeztah
Member

@dmcgowan thanks for the additional info. I'm interested to hear from @dmp42 for a final confirmation.

@thaJeztah
Member

@sardaukar thanks for that link, yes, that was to be expected.

It always makes me sad that, apparently, this is the world we live in. I understand that Solomon (being the "Steve Jobs" of Docker) will be watched closely and anything he says will be used both to praise Docker and to discredit Docker if people get the opportunity.

However, Docker is more than just Solomon (in fact, most of the time nowadays he's quite absent in this repository, probably because of other obligations). Most people working on the project are not even related to Docker (inc.) and a huge majority of the contributors is doing this in their spare time, just to "give back" to the project.

Over the (almost) two years I've been following this project, I've seen all kind of contributions, ranging from fixing typos to major changes in networking to support IPv6. I've seen people being really patient, trying to explain to absolute "Git newbies" how to clone a repository and do a rebase or amend a commit. At the same time, having to keep track of almost 900 open issues, feature requests and support questions, not to mention answering question on IRC and the mailing lists.

Does that make it right to have issues like this one? Nope, it shouldn't happen. It also shouldn't be taken out of proportion; like I mentioned in an earlier comment; SSH keys (as an example) are also accessible if you're logged in. That's not a problem, but people should be made aware that this is the case.

I also think that any developer will admit that looking at your TO-DO list, you'd rather pick working on "that new feature" than the less fun stuff. Replacing .dockercfg with something better has just been on the TO-DO list for too long.

Having said that; (see #10318 (comment)) People on the distribution team are actively working on this (regarded by many as) "un-cool" feature, and it will be replaced with something way better in the near future.

In the mean time, just take the regular precautions; don't give (untrusted) people access to your computer/account, change your (docker) passwords frequently, and monitor access.

Finally, to stop rumours up front; No, I am not affiliated with Docker, have not been asked or paid by docker to write this. I use Docker at work (and for fun), and contribute (where possible) in my spare time and during my daily travel to/from work (standing on the train, typing...).

Just wanted to get it off my chest 😄

@TheDong
TheDong commented Jan 25, 2015

@thaJeztah comparing this to ssh or netrc is disingenuous. If someone has physical access to my computer, they do not in fact have access to my ssh keys because they're encrypted and ssh understands to prompt me for a password for them. Someone can have root on my machine, and they still won't have my ssh credentials. I can temporarily decrypt them only in memory with ssh-agent + ssh-add for convenience of course. netrc is totally optional... with docker, even if you just "push" or "pull" a private repo, not explicitly type login, it still saves the credentials. There's no way to tell docker to encrypt them or not store them on disk. You still can't force a registry to be v2 only (they do that for the IndexServer, but for any other if someone MITM's the /v2/_ping, it'll fallback to plaintext). SSH allows pinning known hosts, setting allowed ciphers per server, etc etc etc... These things shouldn't be compared as even being in the same ballpark.

In your comment you say "It also shouldn't be taken out of proportion", and that's true, but saying that it's being taken out of proportion now shows a deep lack of understanding of how security works.

So yes, this issue should not be taken out of proportion and, imo, isn't. If anything, it's under proportioned. Hardly anyone is discussing how the keys are being sent as plaintext over the wire (thank gosh registries have to be https or --insecure-registry now), how little the daemon actually allows in terms of verification or security configuration, and how the v2 registry doesn't even solve most of these problems.

Perhaps part of the reason this happened is because docker is such a friendly project. Even for security sensitive things, early on, there was no need for a proposal or discussion, you just did it. I'm hopeful rocket, with their carefully made specifications, will cover this sort of critical scenario. I'm also hopeful that they'll not just say "it's not a big deal" when talking about severe security flaws.

@thaJeztah
Member

@TheDong I apologise for using SSH keys as an example, my main point was to illustrate "there's more that can be found when you are able to get (physical) access to ones computer/account".

I fully agree that more options should be provided wrt storing credentials (as stated in my earlier comments), and according to earlier statements, work is being done to accommodate that.

Wrt communication with privately hosted registries; I guess that really depends on how those are configured. I've seen many requests from people that saw "no need" to use TLS/SSL (or even authentication) for an in-house registry on their private network. Having said that, I'm really not an expert on setting up and configuring those.

I'm also hopeful that Mercedes Benz, with their expert design team will make their new model a lot safer and Eco-friendly than the current version. But I saw no reason to mention that in my earlier comment.

@dmp42
Member
dmp42 commented Jan 26, 2015

All,

Thanks a lot for the feedback on this.

A couple of words:

  • the current situation with dockercfg is not ideal, and we are well aware of that
  • we are currently working on it
  • using keys a-la-ssh is certainly something we are considering (and/or retrieving credentials from a keystore)
  • JWT are (already) used as part of the v2 protocol: https://github.com/docker/distribution/tree/fdea60af05c0b46026b81d8df49d53017661bd72/auth/token and will be the recommended workflow in the future
  • the discussions on authn/authz against the registry are being held in the open, on irc (weekly distribution meeting is monday morning 10AM) and on github. "distribution" maintainers definitely welcome feedback and constructive discussion
    • specifically the question of basic auth and the use of reverse proxies: docker/docker-registry#623
    • JWT based auth proposal: #9081
    • auth as part of the new registry protocol: #9015
  • a couple of things need to be set straight with regard to the discussion so far:
    • the registry does not dump plain text credentials into log files
    • the registry never sees plain text credentials (though an index or reverse proxy does)
    • tokens are sent in headers, not in urls

To sum this:

  • sure, things need to be fixed
  • there is an open effort in doing that (#distribution), and people are certainly welcome to join if they want - either way, the issue here is definitely something being worked on
  • we should aim for the right solution - not just "any solution as fast as possible" - this will take time and energy, but I'm confident we will get there

While this answer is not "a fix", I hope it will help.

@rafaelhbarros

@dmp42 I'm glad to see so much traction on this issue and that you're already working on it. Thanks for the clarification on all the issues raised and status update.

@mmdriley
Contributor

What are the threats we want to protect against here?

If you expect to be able to perform authenticated commands without entering a password then the Docker client is necessarily going to store something password-equivalent. The best you can do is get the OS file permissions correct and use this password only for Docker. (You're not sharing passwords, right?)

I see one interesting attack here: if I get access to your user account and can read your .dockercfg, I can take that password, authenticate to the Docker Hub, and change your password or take other actions that aren't allowed through the client. Then again, if you're logged into Docker Hub in your browser I can probably steal your cookies and accomplish the same thing.

The Gaim/Pidgin developers went through a similar discussion a decade ago. It's not exactly the same circumstance but it's still worth reading through their reasoning and conclusions.

Docker has made some security decisions I would call questionable (looking at you, tarsum) but this isn't one of them.

@pfultz2
pfultz2 commented Jan 26, 2015

If you expect to be able to perform authenticated commands without entering a password then the Docker client is necessarily going to store something password-equivalent.

Yes, but for security reasons, I would like to perform authenticated commands by entering a password everytime.(just like git and mercurial).

Also, storing session tokens instead of a password allows for stricter security policies whereas requiring users to change their passwords everyday is not feasible.

The best you can do is get the OS file permissions correct and use this password only for Docker. (You're not sharing passwords, right?)

For private repos, the account could give you more access to services other than docker. Token based authentication allows the session to be limited to certain services, and for a certain time.

if I get access to your user account and can read your .dockercfg, I can take that password, authenticate to the Docker Hub, and change your password or take other actions that aren't allowed through the client. Then again, if you're logged into Docker Hub in your browser I can probably steal your cookies and accomplish the same thing

Wow! That sounds like another security problem as well. You should only be able to change the password when you have the actual current password.

The Gaim/Pidgin developers went through a similar discussion a decade ago. It's not exactly the same circumstance but it's still worth reading through their reasoning and conclusions.

When you login with Pidgin they never store the password, unless you explicitly say so; unlike docker which always stores that password, with no option to opt-out.

@dmp42
Member
dmp42 commented Jan 26, 2015

Wow! That sounds like another security problem as well. You should only be able to change the password when you have the actual current password.

You DO NEED the old password to change password on the hub.

@tiborvass
Contributor

Also, in case anyone finds a security vulnerability, please be responsible and send an email to security@docker.com as explained here: https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-security-issues

@mmdriley
Contributor

I would like to perform authenticated commands by entering a password everytime

I agree this is a use case worth supporting. The initial auth could return a time-restricted, possibly-revocable token. (For example, it should be invalidated if your Docker Hub password changes.) The client will need fallback code for when that token expires or becomes invalid.

This seems like a much simpler response to a much more obvious threat than most of the discussion above.

You DO NEED the old password to change password on the hub.

Ack, yes, definitely. Sorry for my ambiguous wording before.

@rafaelhbarros

@mmdriley One issue that was raised before and it's bothering me is in the case of CI/CD servers.

It would nice to setup the servers to have read only access, instead of saving the account info in a text file. I want something analogous to the github deploy key. The solution to this would be to create a 3rd account with read-only access to a private repo and keeping that info on the deploy server, but that is not an ideal design.

@mgk
mgk commented Jan 26, 2015

Glad to see this is being taken seriously. The planned use of JWTs and SSH key pairs looks great.

we should aim for the right solution - not just "any solution as fast as possible" - this will take time and energy, but I'm confident we will get there

Makes good sense. In the meantime making sure users are aware of the risk is important. As a user I'm happy wait for the right solution and take steps to mitigate security weaknesses, but I need to know what they are to do that.

I second the suggestion by @thaJeztah: docker login v1 should inform the user that it is saving their unencrypted creds to ~/.dockercfg.

@thaJeztah
Member

I created a separate ticket for outputting a message / confirmation here; #10338 hoping that is possible to get into 1.5

@ewindisch
Contributor

Ideally we should store encrypted keys/tokens and have an agent manager ala gpg-agent and ssh-agent to manage these. I'd prefer it actually be one of those tools, actually, rather than inventing a new one that does less, worse.

I had already suggested to @dmp42 that we use Digest authentication and store the digest. It wouldn't prevent users from stealing the secret, but it would prevent theft of the password itself. I still think this would be appropriate, if only a marginal improvement for v1 while the v2 api settles in.

@dmp42
Member
dmp42 commented Jan 27, 2015

@ewindisch: storing a HA1 is almost as bad as storing a password (MD5(username:realm:password)) and only provides a false sense of security.

@ewindisch
Contributor

@dmp42 as I said, storing the MD5 is only a marginal improvement as it only prevents revelation of the password, but not revelation of a secret. Given that the Index API now allows password and email changes, which I believe is relatively new(??), I suppose it's moot.

One useful improvement here would be allow the password to be left blank, prompted for, and optionally cached in memory.

@jefflaporte

Big +1. As it currently operates users like us operating private registries can't integrate into LDAP without potentially compromising network-wide passwords.

@ludoch
ludoch commented Mar 3, 2015

Now, we are on March 3rd, and I still have my password stored in base64 text in my .dockercfg file...

WTF? In fact, my password has a character used to do a split (docker.py) which does not work at all, so that would be the second bug...

@t5unamie
t5unamie commented Mar 6, 2015

+1

@dmcgowan dmcgowan added the Trust label Apr 14, 2015
@arnauldvm

+1

@pkill
pkill commented Jun 2, 2015

👍

@jessfraz jessfraz added dist and removed Distribution labels Jul 10, 2015
@icecrime icecrime removed the dist/trust label Jul 17, 2015
@pfortuna

+1 on using revocable host tokens

@ewindisch
Contributor

Another important aspect here is that by using Digest auth, which specifies realms in the auth header, we can eliminate cross-registry attacks if the user/pass were the same on multiple registries and was somehow sniffed or stolen from an attacked registry.

@mmdriley
Contributor

Git has already solved this problem with credential helpers. Perhaps Docker can import that idea? (Ideally, even, allow shared implementations?)

@HuKeping
Contributor

One useful improvement here would be allow the password to be left blank, prompted for, and optionally cached in memory.

+1 for caching it in memory. The disadvantage is that you need to re-enter the password everytime Docker daemon restart.

@dmp42 dmp42 referenced this issue in docker/distribution Aug 10, 2015
Closed

Token caching, and credentials saving options #759

@HuKeping
Contributor

So what is the most possible solution that Docker prefer or is there anything that WIP? ping @thaJeztah @dmp42 @tiborvass @dmcgowan @stevvooe

@joozek78
joozek78 commented Oct 5, 2015

Did I miss something or are passwords still stored in cleartext after 10 months (from discovery)?

@rafaelhbarros

Still clear text.

@ewindisch
Contributor
@HuKeping
Contributor

We can use symmetric-key algorithm, like AES to encrypt it. But it'll still need to store some private credential on the machine say, the key. It doesn't make much sense.

@cheungpat

The problem seems to be that we need to use Docker Hub password to log in and this password has to be saved in dockercfg no matter plaintext or encrypted.

To solve this problem is not to find a secure way to store Docker Hub password, but for Docker Hub to accept some kind of deploy token that we can use to login instead of using Docker Hub password.

Supposedly the deploy token can only be used to pull images (or push as well), therefore the deploy token cannot do everything the Docker Hub password can do.

This will work similar to Google Account multi-factor authentication and app-specific password for those apps that don’t support it.

Sorry if solution like this was discussed before.

@dohnto dohnto referenced this issue in SUSE/Portus Oct 20, 2015
Closed

LDAP authentication #378

@superwanglin

Why can't docker simply provide an option to disable saving clear-text password before proper security is implemented?

@stevvooe
Contributor

@superwanglin Could you expand on your proposal? Do mean having a --no-save-password flag and having the user enter password for every push and pull?

@ewindisch
Contributor

I'll reiterate that I believe the right solution here is to support Digest Authentication in the registry and support to store the password as a digest (hash). This solves a number of security complaints. This would work similarly to a token and would be simple to implement.

@tianon
Member
tianon commented Oct 28, 2015
@JonathonReinhart

@mmdriley nailed it:

Git has already solved this problem with credential helpers. Perhaps Docker can import that idea? (Ideally, even, allow shared implementations?)

Look, if you don't want to re-type your password every time, something valuable has to be stored locally. I don't care if it's a hash or a token or what. This is why Linux has e.g. Gnome Keyring, so your secrets are only decrypted when you log in. It's the most convenient, and it's what should be decrypting your SSH private keys (they are encrypted, right?)

Docker should really consider following Git's lead here.

In the mean time, what @stevvooe suggested is what I wish existed. That, or an option I can specify in my docker config:

Do mean having a --no-save-password flag and having the user enter password for every push and pull?

There's no way I'm leaving my network's LDAP credentials in a base64-encoded file on disk. The fact that the JSON key is called auth instead of password frustrates me - like we're not even being honest about what's being saved.

Give me a way to prevent the creds from being saved to disk. I don't care if I have to re-type it. As a work-around, I've replaced my ~/.docker directory with a symlink to a directory in /dev/shm (mounted as tmpfs). Just add this to /etc/profile.d: docker_config_temp.sh.

...and I hope docker isn't planning on storing anything else there.

@TheDong
TheDong commented Oct 29, 2015

@ewindisch Storing a hash of the password and allowing it for auth during push/pull solves incredibly little.
The only thing it solves is that the settings in the webui would not be accessible, but frankly someone being able to push is scarier because that gives them arbitrary code execution in my application and any other users of my application... yeah.

As soon as you say "let them use the hash", you've turned the hash into a password and have the same problem all over again.

The only reason using a random token would make sense is if it can be scoped such that I can have a pull-only token or push-only token that is associated with one or more repositories or tags.

However, none of that helps with the "something that can do scary security-risky stuff is stored on my disk with no option to have encryption or have it stored only in memory" like the keychain on most modern OSs.

If you want the benefit that hashes traditionally give you, of not being able to gain privileges by compromising the server, a public-private key architecture would be better (similar to what modern yubikey auth does) and also solves that problem. You know, if I could plug in my yubikey to push to repositories, I'd be so happy. And the only reasonable way to end up with something specialized like that is to allow auth-helpers so that I can plugin my own option... and that should be baked into Docker so that other tools have any hope of jumping onto it.

It would also help the enterprise where people usually already have an auth solution and would want to be able to have the same level of security and consistency around their registry servers and clients for policy reasons and simplicity.

Its been the better part of a year since @shykes said "there is work underway to switch to keypair-based authentication", which was repeated by other maintainers, and I see zero evidence. It would have been quicker for me to produce a baby than to wait for this issue to be resolved.

Bonus points for not having the "group security" label and having the "exp/beginner" label still!

@stevvooe Having that flag would certainly be a step in the right direction, especially since it was proposed in January (see "Store password unencrypted (yes/no)? no") and a couple times since, but definitely not enough to close out this issue or claim anything approaching a reasonable security story.

@dbrgn
dbrgn commented Oct 29, 2015

Storing a hash of the password and allowing it for auth during push/pull solves incredibly little.

True.

The only reason using a random token would make sense is if it can be scoped such that I can have a pull-only token or push-only token that is associated with one or more repositories or tags.

That's one aspect. The other aspect is that you could generate a token for each service where you want to store the credentials, and then you can revoke the tokens if something goes wrong.

If you have a single password, changing that will break authentication on all places where you've stored the password (in either plaintext or as a hash).

I'd very much welcome pull-only scoped revokable tokens.

@calavera
Contributor
calavera commented Mar 3, 2016

#20107 fixes this problem. It will be release in 1.11.

@calavera calavera closed this Mar 3, 2016
@EugenMayer
EugenMayer commented Jun 26, 2016 edited

Having docker 1.11.2 this is still not fixed. In which release this is actually going to be in?

According to the changelog, it should have been part of 1.11.0: https://github.com/docker/docker/releases/tag/v1.11.0

But it is not working for me, still base64 encoding credentials.

@EugenMayer

Answering myself and leaving original comment for "google" - its just not really documented well yet, found

http://www.projectatomic.io/blog/2016/03/docker-credentials-store/

you need to add this into your $PATH https://github.com/docker/docker-credential-helpers/releases
and then add this to your config.json

cat ~/.docker/config.json                                                                                                                                1 ↵
{
    "credsStore": "osxkeychain"
}%

Also officially documented under https://docs.docker.com/engine/reference/commandline/login/ but this should be really promoted better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment