Support plaintext credentials as multi-call binary #5536
+197
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
- What I did
The problem
The Docker CLI supports storing/managing credentials without a credential-helper, in which case credentials are fetched from/saved to the CLI config file (
~/.docker/config.json
). This is all managed entirely by the CLI itself, without resort to a separate binary.There are a few issues with this approach – for one, saving the credentials together with all the configurations make it impossible to share one without the other, so one can't for example bind mount the config file into a container without also including all configured credentials.
Another issue is that this has made it so that any other clients accessing registry credentials (such as
https://github.com/google/go-containerregistry) all have to both:
config.json
, to check for credentials there, which also means they're dependent on this type and might break if the type changes/we need to be careful not to break other codebases parsing this file, and can't change the location where plaintext credentials are stored.This means that if we want to do something like support oauth credentials by having credential-helpers refresh oauth tokens before returning them, we have to both implement that in each credential-helper and in the CLI itself, and any client directly reading
config.json
will also need to implement this logic.The proposed solution
This commit turns the Docker CLI binary into a multicall binary, acting as a standalone credentials helper when invoked as
docker-credential-file
, while still storing/fetching credentials from the configuration file (~/.docker/config.json
), and without any further changes.This represents a first step into aligning the "no credhelper"/plaintext flow with the "credhelper" flow, meaning that instead of this being an exception where credentials must be read directly from the config file, credentials can now be accessed in the exact same way as with other credential helpers – by invoking
docker-credential-[credhelper name]
, such asdocker-credential-pass
,docker-credential-osxkeychain
ordocker-credential-wincred
.This would also make it possible for any other clients accessing credentials to untangle themselves from things like the location of the credentials, parsing credentials from
config.json
, etc. and instead simply support the credential-helper protocol, and call thedocker-credential-file
binary as they do others.Asides from addressing the aforementioned issues, the multi-call binary solution allows us to to do this while making minimal changes to packaging/delivery pipelines, as the CLI binary already has all the packaging setup required and we don't need to package or ship a separate binary. The only change required to use this is for existing packages to create a new symlink during installation, and this flow can be used. This also reduces overhead with managing a new repo, dependencies, etc.
- How I did it
Make the CLI binary multi-call, and act as a file credentials-helper when invoked as such.
- How to verify it
ln -s [docker CLI binary] [somewhere in your path/docker-credential-file]
docker-credential-file list
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)