Open jawnsy opened 2 years ago
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?
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.
SystemContext
to point at them, which is functional but awkward. Is the goal to do significantly better than that?
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.
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
ordocker-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