[Feature] Add support for built-in credential helpers

[jawnsy]

This library currently supports the Docker Credential Helper protocol, which integrate with the various clouds to exchange service account credentials for appropriate registry credentials. For example, this feature allows users logged in with gcloud or docker-credential-gcr to push images to Google Container Registry using their Google Cloud credentials.

go-containerregistry allows users to build binaries with support for these registries by embedding credential helpers for Amazon ECR, Azure ACR, and Google GCR. This feature may simply be a documentation exercise, or it may involve the addition of APIs to support injecting the code for credential helpers, as go-containerregistry does.

I'd be happy to contribute this, but would need some pointers as I'm not too familiar with this codebase.

Open questions

• How should this feature interact with external credential helpers?
• Is it possible to add this feature to containers/image in a way that does not affect existing tools like skopeo/podman/buildah? These should probably behave the same as before, executing credential helpers as defined in the containers-auth.json file

[vrothberg]

Thanks for reaching out, @jawnsy!

At the time of writing, containers/image supports credential helpers only by executing the respective binaries. You can find the code here: https://github.com/containers/image/blob/main/pkg/docker/config/config.go

go-containerregistry implements the following interface for passing such helpers in the Go code: https://pkg.go.dev/github.com/docker/docker-credential-helpers/credentials#Helper

I am open to the idea. I don't have a strong opinion on how to extend the API as long as the existing one remains stable.

@mtrmac WDYT?

[mtrmac]

It’s easy enough to imagine an implementation of the immediate proposal — in those places, where we call helperclient.NewShellProgramFunc, consult a map of built-in credential implementations; separately, allow some way of registering an implementation there — presumably a global per-process one, something like c/image/transports (or would that be per-request? I can’t see my it should).

That would allow adding support for this in an API-invisible way, and users would “just” have to use appropriate registries.conf/auth.json configuration pointing at the credential helpers.

I’m wondering more about those higher-level parts.

• Presumably Podman/Buildah/Skopeo would not use this (short term), and it would be an API only for other consumers? That’s fine, I just want to be explicit about it.
• Is the implied intent to have an API similar to Go-containerregistry one, where the client doesn’t use the global config files at all, and instead chooses to use a specific helper / interface, for a single request? We, kind of, can do it right now, by creating temporary files and using SystemContext to point at them, which is functional but awkward. Is the goal to do significantly better than that?
  • It’s possible, of course (e.g. by providing a DockerCredentialHelper member beside SystemContext.DockerAuthConfig), it’s just somewhat more worrisome WRT designing a good stable API. (We would be committing to the Helper interface’s stability, and possibly better documenting the semantics, either way — but interactions of the new helper interface vs. DockerAuthConfig vs. AuthFilePath etc. might be a bit tricky.)

---

One immediate concern that needs to be resolved in the first version is defining the semantics of namespaced credentials (like “a separate credential for quay.io/{vendor1,vendor2}”). Currently we support that for config files, but not for credential helpers (because the credential helpers follow Docker semantics, and the Helper interface is very vague about the semantics of keys). Any new API would need to deal with this and explicitly document the semantics. That might well be the current registry-scope-only semantics for helpers, as long as we have a path to adding some kind of namespaced support later. So it’s not a huge issue, it’s just something we need to keep in mind — also WRT the possible interactions with other SystemContext options.