Update http_config to support cfaccess

[jaymzh]

Adds a new auth type cf-access which allows using this tool with
Cloudflare Access. Defines the new auth type, create a new RoundTripper
to handle the login / token fetch flow, and set it as the client
transport if enabled.

I originally planned to add this in prometheus/prometheus for
promtool, but (1) The implementation is cleaner doing it here and (2)
I want to do it for amtool as well, so implementing it in common
means not doing it twice.

If you were curious what it looks like to put directly in prometheus/prometheus,
there's a commit here for comparison: jaymzh/prometheus@6ea12c1

Signed-off-by: Phil Dibowitz phil@ipom.com

[roidelapluie]

Thank you. This seems to drag a lot of dependencies to this project, which is broadly used.

Do you think it could fit in its own repo/module? We have a precedent: https://github.com/prometheus/sigv4/ . Happy to have that under prometheus/ if you think it's useful

[jaymzh]

Thanks for the reply!

Yes, since this is implemented as a RoundTripper, extracting it into a separate module should be straightforward.

I originally put it in common to avoid requiring each consumer to interpret authorization.type: cf-access and install an additional RoundTripper. However, a standalone module could keep that integration small while preventing common from inheriting cloudflareds dependency tree.

I envision the module providing a helper such as:

cfg, cfAccessEnabled, err := cfaccess.PrepareHTTPClientConfig(cfg)
if err != nil {
    return err
}

This would detect and validate the cf-access configuration and return a copy with the authorization entry removed, preventing common from treating cf-access as a literal HTTP authorization scheme.

The consumer would then construct its normal transport and conditionally wrap it:

rt, err := commonconfig.NewRoundTripperFromConfig(cfg, "promtool")
if err != nil {
    return err
}
if cfAccessEnabled {
    rt = cfaccess.NewRoundTripper(rt)
}

amtool would do the equivalent around the transport returned by NewClientFromConfig.

Before doing the extraction, I'd like to confirm that this is the intended architecture and that follow-up integrations for promtool and amtool would be welcome. The standalone module would not provide user-facing functionality until consumers adopt it.

If so, wanna create that repo and I'll make modify this a bit and PR over there?