Registry Auth Extensibility

[RichiCoder1]

What

In order to support registries that may have authentication models that make the traditional login model unideal, I propose adding an extensibility capability where support can be added for a registry provider's native authentication mechanism(s) via some extensibility point. This is becoming increasingly relevant in cases where managed cloud Kubernetes providers offer "managed identity" capabilities that ambiently provide the means to authenticate with that's providers registry. For tools that embedded Oras, they would have to build out their own duplicative means of turning these ambient credentials into something Oras can understand.

How

The specifics of this I'm not sure about, especially since I would assume we'd want a solution that works both for embedders and CLI users. The most straightforward and naive approach would be to bundle various well-known providers with the Oras module itself, with a configuration option to choose a preferred provider. Then the community could contribute and maintain adapters for various providers. This has the downside that many native go sdks for providers can be heavy weight and adding that weight by default to Oras may be untenable. Another option would be a plugin model where provider plugins are packaged separately and loaded dynamically. Then it'd be up to the embedder or Oras CLI to package these plugins along side their distribution.

Notes

At least right now this just is specific to Auth, but in theory I don't see why it couldn't be expanding to other concepts in the future. Trying to predict the future can be messy however, so I'm not trying to solve for that here.

API

type RegistryProvider interface {
	Authenticate(config map[string]interface{}) Credentials 
}

_{pardon my go, still novice}

[garethr]

As a consumer of Oras in Conftest, I think either model works in the short term, though the plugin model maybe works slightly better in the long term. If the plugin model is chosen having a discovery mechanism would be important. Given the small number of likely plugins a page in the documentation or a list in the repository would suffice.

[SteveLasker]

With the growth of new registries, GitHub (x2), Google (x2), solo wasm, on-prem instances, I don't think we can, or should try to include the every growing, or evolving registry models.
In a perfect world, we'd have a standard AUTH api - but, we know we don't live in a perfect world 😏
So, I'd propose an extensibility model that works with the ORAS libraries, added to the ORAS client, and I'm looking for golang helpers that want to add auth to regdoc. If regdoc gets useful, I'd PR here, or another repo alongside as a more robust example of a targeted cli.

[RichiCoder1]

Sounds like a plugin model with file system discovery model is the ideal path forward, with some example providers to get things rolling. Having done some research in plugin options, it looks like the go ecosystem's strongest plugin system is HashiCorp's go-plugin which also has the nice benefit of allowing non-Go plugins for providers who may have that preference.

The interface I propose would then be something like this:

syntax = "proto3";
package oras.v1alpha1;

message RegistryCredentials {
	string scheme = 1;
    string token  = 2;
}

message GetCredentialsRequest {
	string registry = 1;
}

message GetCredentialsResponse {
    RegistryCredentials credentials = 1;
}

service CredentialsProvider {
	rpc GetCredentials(GetCredentialsRequest) returns (GetCredentialsResponse);
}

If that makes sense? Then plugins could live in a location like $HOME/.config/oras/plugins with embedders potentially adding other locations. Naming scheme could be like oras-plugin-<vendor>. Idea shamelessly taken from a few other plugin implementations, namely Octant.

[SteveLasker]

Looking for 👀 from @shizhMSFT and @jdolitsky

[shizhMSFT]

Currently, oras CLI read docker CLI format config and can be configured to use existing docker credential helpers.