SDK for oras login

[shizhMSFT]

The package docker of the oras-go v1 is removed from v2 in order to decouple oras-go with docker SDKs. Besides, not all oras-go adopters depends on docker for authentication credentials, especially in Kubernetes.

However, we do notice that CLIs like oras and notation still rely on docker config files for credentials since it is convenient. Both CLIs re-invent the wheels at some levels, and I guess more CLIs like Helm will do the same. In addition, the issue oras-project/oras#414 points out there might be potential bugs when sharing the same docker config with various tools with different docker CLI library versions.

Therefore, I propose that we can implement for oras-go v2 with something equivalent to the package docker of oras-go v1 in a new repository so that we can do oras login and oras logout using the shared docker config in a securer manner.

The name of the new repository could be oras-project/oras-credentials-go with package name credentials. Any name suggestions are welcome.

FAQ

Q: Why use docker config and docker credential helpers?
A: There are lots of existing credential helpers designed for docker by many cloud providers. Why not reuse them?

Q: Why not integrate the login SDK into oras-go v2?
A: oras-go v2 is designed to be generic, vendor neutral, and stable. Having the dependency on docker CLI means the oras-go library needs to be upgraded very frequently once there is an update on docker CLI although those updates are not related to auth.

Q: How can the new implementation be more secure?
A: It can be done by having an option to only allow native credential stores on writing so that no plaintext credentials are written to the disk.

[FeynmanZhou]

This authentication seems critical when ORAS-go dependents/users upgrade to ORAS-go v2 and still rely on package docker. They will need to implement it on their side. So I hope this can be designed as a generic SDK solution that is applicable to any projects who depend on docker for authentication credentials.

@sabre1041 ORAS-go v2.0.0 will be released soon. We thought Helm might have this kind of challenge when it upgrades to ORAS-go v2.0.0 from v1. Do you think this separate SDK solution will be beneficial to Helm? Any other concerns about upgrading it in Helm?

[sabre1041]

@FeynmanZhou Yes, I will be able to look into this later in the week week of (Jan 19-20)

[vsoch]

This might be of interest / eventually help with this issue. opencontainers/tob#119. Perhaps an oras maintainer should comment on that thread to support it / participate in the WG?

[shizhMSFT]

Thank @vsoch for pointing this out. The issue 119 is mainly for the auth protocol, which is covered by the package oras.land/oras-go/v2/regsitry/auth in oras-go v2.

The new repository in this discussion is mainly about obtaining the credentials used for auth.

[vsoch]

You don't think credentials for auth would become part of some new auth spec? I don't think we can rule that out.

[shizhMSFT]

From my own understanding, the PR opencontainers/tob#119 proposes a new WG for specs of Authentication (AuthN) and Authorization (AuthZ) for the interactions between servers and clients. However, accessing credentials used for authentication is in the scope of Key Management.

Here's a simple scenario showing the differences of the concepts:

1. Type username and password memorized in my brain --> Key Management. Since there are lots of username and password pairs, I may store those credentials directly on the disk (insecure way) or use a Key Management Service (more secure way).
2. The remote registry recognizes me as identified by the username after verifying the password --> Authentication.
3. The remote registry denies my push artifact request since I'm only authorized to pull artifacts by looking up the access control list of the identity identified by my username --> Authorization.

[vsoch]

Thank you yes I’m aware of the the difference :)

The credential files are often the first step in a registry interaction and thus could be determined to be in scope, as determined by the working group. It cannot be ruled out until they decide it is or is not in scope.

[AaronFriel]

Will this SDK be compatible with credential helpers as already are used by Docker compatible registries?

Thinking about registries such as the major cloud providers', and their tools. They aren't configured to provide credentials to oras and the result could be impaired UX.

For users of the SDK or CLI, will a compatibility mode be an option to attempt to use Docker's configured credential providers?

[shizhMSFT]

Will this SDK be compatible with credential helpers as already are used by Docker compatible registries?

Yes! That's one of the goals.