[OTLPHTTP Exporter] OAuth2 Client Credentials Authorization support for Exporters using HTTP Clients

[pavankrish123]

Description:

1. Added support for exporters that use HTTP Clients to use OAuth2 Client credentials workflow (2-legged/machine-to-machine).
2. When enabled as a part of HTTP Client Configuration, an HTTP Client with OAuth2 supported authorization transport is returned.
3. The underneath Go OAuth2 library does the token auto-refresh as necessary.

Example

exporters:
  otlphttp:
    endpoint: http://localhost:9000
    oauth2:
      client_id: someclientidentifier
      client_secret: someclientsecret
      token_url: https://autz.server/oauth2/default/v1/token
      scopes: ["some.resource.read"]

Link to tracking Issue:
#2785

Testing: : Added unit tests/functional tests.

Documentation: Added README for the config

[codecov]

Codecov Report

Merging #2464 (af0ba4c) into main (73b55f0) will decrease coverage by 0.38%.
The diff coverage is 100.00%.

❗ Current head af0ba4c differs from pull request most recent head 883ac54. Consider uploading reports for the commit 883ac54 to get more accurate results

@@            Coverage Diff             @@
##             main    #2464      +/-   ##
==========================================
- Coverage   92.06%   91.68%   -0.39%     
==========================================
  Files         313      313              
  Lines       15439    15344      -95     
==========================================
- Hits        14214    14068     -146     
- Misses        817      870      +53     
+ Partials      408      406       -2     

Impacted Files	Coverage Δ
config/configclientauth/bearer_token.go	100.00% <ø> (ø)
config/configclientauth/configoauth2.go	100.00% <100.00%> (ø)
config/configgrpc/configgrpc.go	98.76% <100.00%> (ø)
config/confighttp/confighttp.go	100.00% <100.00%> (ø)
service/zpages.go	0.00% <0.00%> (-80.00%)	⬇️
internal/version/version.go	80.00% <0.00%> (-20.00%)	⬇️
extension/zpagesextension/zpagesextension.go	78.57% <0.00%> (-14.29%)	⬇️
internal/collector/telemetry/telemetry.go	94.44% <0.00%> (-5.56%)	⬇️
translator/trace/protospan_translation.go	92.41% <0.00%> (-4.96%)	⬇️
exporter/prometheusremotewriteexporter/exporter.go	89.33% <0.00%> (-1.21%)	⬇️
... and 70 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1d40a12...883ac54. Read the comment docs.

[pavankrish123]

Note: I understand that we are chasing GA. But since OTLPHTTP exporter features is present in the roadmap, for the sake of feature completeness, I am putting up this PR. If it is bit late please let me know, happy to move the PR to draft and will resubmit it when it is a good time. 🙏

[jpkrohling]

We have two places with related code:

• https://github.com/open-telemetry/opentelemetry-collector/tree/main/config/configauth
• https://github.com/open-telemetry/opentelemetry-collector/blob/main/config/configgrpc/bearer_token.go

This second seems to be closely related to this but won't perform token refreshes. They should really be made consistent among each other, either by having this here only taking care of sending the token that was previously configured, or by making that one to refresh tokens (and possibly use the same configuration as this here). The use case that the gRPC one covers is for Kubernetes deployments, where a token file is available locally in a file.

[pavankrish123]

Thank you @jpkrohling.

Agreed, let me refresh this PR after making the modules consistent. I will move bearer_token.go into configclientauth package which has both RoundTripper for OAuth2 (HTTP Clients), OAuth2PerRPCCredentials (grpc) and tokenRPCCredentials(grpc) existing code.

I was only planning to add OAuth2 for HTTP Clients but will add for grpc too.

Thanks for looking into this!

[pavankrish123]

Hi @jpkrohling couple of thoughts here.

This second seems to be closely related to this but won't perform token refreshes. They should really be made consistent among each other, either by having this here only taking care of sending the token that was previously configured, or by making that one to refresh tokens (and possibly use the same configuration as this here).

So as I understand we are looking into two completely different ways for authorization.

1. "bearer token" : As I understand, we are directly taking the token through the configuration file and plugging in to headers. This might be a viable option for long lived tokens in some use cases where security is not a concern. Clients in this scenario are directly dealing with tokens. To support this flow

   • for grpc clients bearer_token.go is handling it by creating PerRPCCredentials to plug in the authorization header into grpc calls.
   • for http clients: we can plug in the authorization: Bearer <token> via headers option in HTTPClientSettings in confighttp.go - so no additional support is needed.

2. OAuth2 Client Credential Flow: in this flow there is no token directly configured or entered into configuration file. The client (collector) authenticates server using client credentials grant and the tokens are received and refreshed as needed. Clients only deal with <client-id , client-secret, token-url > as opposed to token directly in this flow. Token is derived indirectly and always lives in memory and need not be entered into files. The use cases for this scenario are

1. we do not want to enter the access token directly into configuration file for safety reasons
2. access tokens are usually short lived and constant manual recycling is not an option.

This is the flow the PR is aiming to support and so OAuth2RoundTripper and OAuth2ClientCredentialsPerRPCCredentials is provided for http and grpc clients respectivey which gets and auto refreshes the tokens as needed.

IMHO there is a validity in both the flows and the support should be kept as it is. Kindly let me know if I have misunderstood your suggestion completely or assumed something wrong.

Notes:

• I have moved bearer_token.go to configauthclient module from configgrpc to make it live with related files that deal with client side authorization.
• I have not enabled "client credentials" flow in configgrpc. Plan to do it in another PR. I would want to limit the scope for http clients in this one. Kindly let me know if this is alright. Happy to open an issue.

Thanks for the review

[jpkrohling]

Your assessment is correct, there's one aspect that is missing from the current bearer token auth though: I originally proposed reading the token from a file, like the ones Kubernetes injects into pods. When those tokens are changed, the collector would reload them. Reading values from files were deemed as a feature that the collector should support more generically, so, I removed this from the original PR.

In that case, the OAuth dance would be done by an external process, and the current token to be used would be made ready to the collector.

I'll take another look at your PR soon.

[jpkrohling]

Looks nice! As a follow-up PR, we might want to create a doc somewhere with the auth information for both receivers and exporters.

[pavankrish123]

Thanks for all the suggestions @jpkrohling - I will add the warnings suggestions and refresh the PR and will open issues to document the auth receivers and exporters

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[pavankrish123]

@jpkrohling Think the PR is auto closed despite it is a draft. Shall I reissue a fresh PR after #2603 - I do not know how to reopen this one :(

[jpkrohling]

@tigrannajaryan, @bogdandrutu please reopen this one, as this was closed despite being in draft mode.

[tigrannajaryan]

Github doesn't let me reopen, no idea why.

[bogdandrutu]

It says that there is already an open PR from the same branch

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[pavankrish123]

Hello @bogdandrutu @jpkrohling Is there any chance we could get this thing reviewed now that @jpkrohling's #2603 is almost done. This PR is sort of independent to the work going on there but still belongs to Auth bucket we are tracking - This PR is to expose OAuth2 configuration for clients (oltp http exporter) authentication to OAuth2 servers. This is different from 2603 which handles server (receiver) side Auth.

I believe @gramidt is also looking for this something like this PR but on gRPC side #2500. If we can get this through in upcoming release, we can start messaging OT collector to our customers (internal and external) - Thank you!

[jpkrohling]

This PR is to expose OAuth2 configuration for clients (oltp http exporter) authentication to OAuth2 servers

Should this follow the same pattern as the server-side mechanism, where the clients would determine what to do based on a config option and performed by an extension?