- 
                Notifications
    
You must be signed in to change notification settings  - Fork 509
 
Description
Feature or enhancement request details
Docker and other compatible CLIs support credential helpers, which are separate CLIs to dynamically provide credentials for configured repos.
https://docs.docker.com/reference/cli/docker/login/#credential-helper-protocol
In ~/.docker/config.json these are configured like so:
{
  "credHelpers": {
    "cgr.dev": "cgr",
    "us-east4-docker.pkg.dev": "gcloud",
    ...  
},
When configured this way, when docker pull needs to get creds for cgr.dev, it executes docker-credential-cgr (i.e., docker-credential-<helper-name>), passing the host on stdin, and parsing the JSON output of the program to receive credentials.
For example:
$ echo cgr.dev | docker-credential-cgr get | head -c 60
{"ServerURL":"cgr.dev","Username":"_token","Secret":"eyxxxxx
This mechanism lets registry host providers implement their own auth schemes by providing cred helper binaries to produce auth tokens, which are typically short-lived.
It seems that container pull etc do not support invoking configured cred helpers in the same way, instead expecting users to run container login to store long-lived credentials in the keychain.
This essentially means that, in order for container pull to pull from private registries, long-lived credentials are required, and registries that don't prefer long-lived tokens (like cgr.dev) are not well supported by container pull etc.
Is this something that's on the roadmap? Or if not, is there an explanation for why this should not be supported? The keychain is a trusted place to store long-lived credentials, but short-lived credentials dynamically provided in a standard way should also be supported IMO.
Code of Conduct
- I agree to follow this project's Code of Conduct