Add support for alternate credential stores

[flungo]

It would seem that in the latest versions of Docker, there may be a shift from Docker handling the storage of registry credentials in it's ~/.docker/config.json to using 3rd-party or OS provided credential managers. See the docker login reference and docker-crenetial-helpers project for more details on this and the implementation.

This is certainly, the default configuration as it stands for Windows as running docker login will not add the older format of an auths with server objects that have an auth token (as happens with docker on Linux right now).

From what I can see, and I could be mistaken having only had a quick browse of the source online, but the current implementation relies on either a username/password pair in the config.json or an auth token. Implementation would require the checking of the credsStore field with dispatch the appropriate implementation as well as concrete implementations being provided for osxkeychain, secretservice and wincred.

I will reproduce and add the log output for the error when trying to pull or push from a windows system where it will use "credsStore": "win" when I get a chance.

There has been some discussion on this with the #532 PR.

[rhuss]

For this we probably have to reach out for some external helper tool, which shouldn't be a problem (if optional). Of course, a pure Java solution would be awesome, but I'm afraid thats not possible.

Currently we also have support for docker-machine where we call an external command, so we already have the 'machinery'.

So the idea would be to reach out to ~/.docker/config.json, extract the credential store and then call the helper with the appropriate options described in the docker login documentation ?

[hwellmann]

I can confirm the issue on MacOS. I'm working with a private registry, and I can no longer transparently log in with the credentials stored in ~/docker/config.json. As far as I can recall, this used to work with earlier versions of Docker and/or d-m-p.

What's worse, trying to start a container for an image which needs to be pulled from the registry, I'm getting the following stack trace:

[ERROR] Failed to execute goal io.fabric8:docker-maven-plugin:0.20.0:start (default-cli) on project sabio-docker-foo: Execution default-cli of goal io.fabric8:docker-maven-plugin:0.20.0:start failed: JSONObject["auth"] not found. -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal io.fabric8:docker-maven-plugin:0.20.0:start (default-cli) on project sabio-docker-foo: Execution default-cli of goal io.fabric8:docker-maven-plugin:0.20.0:start failed: JSONObject["auth"] not found.
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal io.fabric8:docker-maven-plugin:0.20.0:start failed: JSONObject["auth"] not found.
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
	... 20 more
Caused by: org.json.JSONException: JSONObject["auth"] not found.
	at org.json.JSONObject.get(JSONObject.java:473)
	at org.json.JSONObject.getString(JSONObject.java:654)
	at io.fabric8.maven.docker.util.AuthConfigFactory.getAuthConfigFromDockerConfig(AuthConfigFactory.java:320)
	at io.fabric8.maven.docker.util.AuthConfigFactory.createAuthConfig(AuthConfigFactory.java:120)
	at io.fabric8.maven.docker.service.RegistryService.createAuthConfig(RegistryService.java:96)
	at io.fabric8.maven.docker.service.RegistryService.checkImageWithAutoPull(RegistryService.java:81)
	at io.fabric8.maven.docker.StartMojo.prepareStart(StartMojo.java:321)
	at io.fabric8.maven.docker.StartMojo.executeInternal(StartMojo.java:149)
	at io.fabric8.maven.docker.AbstractDockerMojo.execute(AbstractDockerMojo.java:223)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
	... 21 more

Even if it's not feasible to access the osxkeychain from d-m-p, it would be helpful to check if an auth object exists and provide a meaningful error message to the end user.

As a workaround, I added a <server> definition to my ~/.m2/settings.xml.

Docker version 17.03.0-ce

[rhuss]

agree that we should be more polite here.

[anirudhsr]

What server tag did you add ? I'm sorry how was this issue fixed it's not clear to me.

[robtayl0r]

Putting my repo credentials in a server block in my settings.xml, with the registry name as the id, worked for me:

<server>
      <id>my-docker.jfrog.io</id>
      <username>foo</username>
      <password>bar</password>
</server>

Then in the pom:

<build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>io.fabric8</groupId>
                    <artifactId>docker-maven-plugin</artifactId>
                    <version>0.21.0</version>
                    <configuration>
                        <registry>my-docker.jfrog.io</registry>

[rodlogic]

It seems that the workaround above will not work nicely with AWS ECR since it generates a temporary user/password.

Is there a work around for AWS ECR?

[jghankins]

I'm running into same issue, OSX Docker for Mac with AWS ECR. Has anyone figured out a work around for this combination?

[jghankins]

@rodlogic For ECR I just sorted a way to get this working again. I set the property docker.skip.extendedAuth to true like: mvn -Ddocker.skip.extendedAuth=true clean package docker:build I have a script that calls the ecr get-login --no-include-email bit to get the temp credentials. Using the property bypasses the logic that trys to use it's own logic using API credentials. I wasn't able to get it to work using the settings.xml and API keys. I was able to get it to work using the section but I obviously didn't want to include API creds in the pom. Setting the property above property via POM didn't work, I had to pass via the maven command line. Back in business with that.

As an Update!! That worked for a build request but then died when I tried to do a Docker:Push. When I stopped bypassing the extended Auth using the above property, the push worked. I suspect it's a cached entry in the keychain which I've dealt with before using CodeCommit on MacOS. I used an AppleScript for that, so I've just created another script to clear the cached credential. Here is the link to the script I wrote. That might deal with this issue. :)

https://gist.github.com/jghankins/650fecfa333f5d53419593bcf4a0284f

[dominicdsouza]

This issue is resolved here: #731

[rhuss]

Credential helper support has been added and a serious bug fixed in 0.25.2 (soon to be released) for a login to index.docker.io.

Please reopen a new issue if there is anything left to do.