How many of the auth plugins had been supported before? With this change, we go back to only supporting bearer creds as auth mechanism, don't we?

as far as I understand, this would drop mtls authentication, since azure
managed identity is not supported for OCI. Or is tls even covered
by constructing the tls config? Is this maybe also an issue on redirect?

Personally, I would add another auth type that maps closely to the options
provides by containerd.docker package. Registry protocols are kind of
specific, and I don't think you can cover it with some more simple, generic
auth plugin.

So either we need to make the auth plugins alot more complex for all users,
or we just create a registry specific one, that can deal with the quirky,
protocols.

This is where @DerGut introduced the feature. It also mentions s3_signing for talking to AWS.

I'd like to avoid throwing the baby out with the bathwater 😉

this github ui terrible. I don't know understand what all the
buttons are suppossed to do. I keep deleting my comments
by accident, sorry.

Hi all, as @bluebrown mentioned the registry protocols are quite specific so maybe keeping it simple makes more sense. The addition of the plugins seems to have complicated the behavior of the OCI downloader and is currently causing issues with some registries (AWS and Azure ) because of the underlying redirect mechanism.

Would changing the plugin authorizer used in the OCI downloader to not attach the authorization header on a redirect make sense in this scenario ?

@carabasdaniel, to my understanding, this should solve the problem.

Based on my research, there is nothing in the HTTP spec that says if/when
credentials should be sent during redirect.

However, there is the www-authenticate header, that is used by some
implementations, including containerd.

They maintain a handler map, to know what endpoints should get auth
header. One criterion for adding a URL to the map, is www-authenticate.

You can see this roughly here:
https://github.com/containerd/containerd/blob/88bf19b2105c8b17560993bee28a01ddc2f97182/remotes/docker/authorizer.go#L114

And here: https://github.com/containerd/containerd/blob/2c042ae0de7b9d69df8df8e370e2d802f10f9ee5/core/remotes/docker/auth/parse.go#L98

Hi @bluebrown, @srenatus sorry for the late reply I grabbed this change on top of latest main and I was testing this change with different OCI registries.

Public registries seem to work as expected, however when testing against some private registries I seem to hit the same problem that the CI shows. Basically the client created by rest.DefaultRoundTripperClient(tc, *config.ResponseHeaderTimeoutSeconds) doesn't have the necessary credentials and it fails to get the manifest of a private image returning a 401.

You can use docker to spin up a local private registry to repro this issue or rely on the tests to easily debug. Please let me know if you need more details about this.

In the CNCF policy CLI project used to build and push policy images to different OCI registries we use the oci package from here to solve this issue https://github.com/opcr-io/policy/blob/main/oci/oci.go

Ah sorry, I meant this as answer to your question:

Would changing the plugin authorizer used in the OCI downloader to not attach the authorization header on a redirect make sense in this scenario ?

We also found some code that would not add the headers on redirect if the hostname changes.