Allow login credentials for specific repo/scope

Inizia da cli/config/types/authconfig.go e traccia come le credenziali AuthConfig vengono memorizzate e interrogate per le richieste al registry. Confronta il formato della chiave repository/scope con il modello strutturato delle credenziali proposto, inclusa la compatibilità con credential-helper. Il lavoro sarà considerato completato quando il progetto avrà un design concordato per selezionare le credenziali più specifiche e un percorso di migrazione o retrocompatibilità definito.

Description

Currently, it is only possible to store one set of credentials/token for a registry domain. Defined in AuthConfig https://github.com/docker/cli/blob/v29.1.2/cli/config/types/authconfig.go#L4 .

The request is to expand this so that separate credentials can be set for a specific repository and token scope.

Use-cases

• Some registries support credentials that are scoped to specific repositories. This is better for security and should be encouraged. In build, it is currently impossible to use such credentials when build can pull multiple repositories. In docker push (or build —push) same issue appears when using cross-repo mount. If the push token was only scoped to the target repository, it does not have access to the source repository from which the layer was originally pulled. Additionally, you would always need to reset the credentials between each command.
• Registry can have rate limiting based on credentials. Currently, when push credentials are presented to push the build result, these credentials are also used for the pull requests for the same registry. This may change the rate-limiting calculation and make builds fail. For example, in GitHub Actions, the default credentials for public read-only access have high rate limits, but when a user switches them to their own credentials in order to make push work, they may get much lower limits.

Option 1:

Switch the definition of string key for AuthConfig map from domain name to:

domain[/repo/path][:scope1,scope2]

When querying credentials, the library would filter out all the matching ones and then pick the most specific match (first by repo, then by scope).

While microformat is somewhat hacky, this method would allow at least some of the credential helpers to continue working without modification. The cloud provider credential helpers (GCP, Azure) probably do parse the domain name from the key.

Option 2:

As the credentials are defined in a map, it makes avoiding the microformat tricky. We can add Repository []string, Scope []string to the AuthConfig struct, but we would also need to change the container from a map to an array. For backwards compatibility and upgrades, updating the type might be beneficial, though. We could also not replace the map but add smth like repoAuths []AuthConfig that is only used when repo or scope are specified.

This would still mean that credential helpers wouldn’t work by default. Or if we still use the microformat for the registry helper key, then maybe some will work, but it is hard to be sure. We would probably need to redefine the credential helper interface, and at least some of the credential helpers would need to be updated.

This is not strictly related to the request above, but if this work results in a major refactoring of the credentials system, it probably makes sense to find a new home for this code where the Docker credential support can be easily imported into other projects, rather than needing to import the docker/cli repository.