Is there a way to hook oneself into the request generation when a registry is being accessed?

[rjschwei]

When a user runs podman pull somewhere along the line an http(s) request to a registry is generated. Is there a way to add additional header data to such a request via some kind of plugin mechanism?

Thanks

[vrothberg]

Thanks for reaching out, @rjschwei. At the present, there is no such mechanism to extend the http headers.

Can you elaborate a bit more on your use case? Maybe /etc/containers/registries.conf can be extended for your needs. Do you need the headers for all or specific registries?

[rjschwei]

@vrothberg, in the Enterprise model, i.e. customers being charged for access to containers which include support, there is a need to verify the client. In a Public Cloud use case this verification would happen via the instance metadata. The desire would be to send that instance metadata along as part of the request header.

[vrothberg]

@mtrmac WDYT?

[mtrmac]

• We really don’t want to expose the HTTP stack internals, that’s an unbounded ABI. (And I don’t know how we would implement in-process plugins for Go code; maybe that’s possible but everything I’ve seen ends up using an out-of-process RPC. We are certainly not going to build one to wrap the HTTP stack.)
• Adding specifically HTTP headers is a bit more palatable, and a tracked RFE ( https://github.com/containers/image/issues/1391 ). But, really, most of the proposed uses at the very least dubious, if not outright nonsensical (Support custom header in registry image#1781 ).
• … and the proposed one here, at a first glance, seems like one of such cases. If you want to charge customers, why not do that based on ordinary authentication to the registry, and then charging the user account? There already is an authentication mechanism, and a mechanism (not ideal, arguably, but one) for managing the authentication secrets. And I suppose there is some mechanism for distributing credentials to cloud instances, purely on cloud identity. Putting identity/authentication into a completely unprotected config file, and building all of this from scratch separately in something which is not obviously targeted at protecting credentials, is at the very least not better, AFAICT.