Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Custom Exporter Authenticators as Extensions #3115

Closed
pavankrish123 opened this issue May 6, 2021 · 5 comments
Closed

Support for Custom Exporter Authenticators as Extensions #3115

pavankrish123 opened this issue May 6, 2021 · 5 comments

Comments

@pavankrish123
Copy link
Contributor

pavankrish123 commented May 6, 2021

Is your feature request related to a problem? Please describe.
We recently added framework to add server (receiver) side authentication via extensions. This is very convenient to extend and add custom authentication seamlessly. In similar fashion clients (exporters) should be able to utilize any custom authentication defined as extension.

Describe the solution you'd like

something like this (similar to extension/authoidcextension) for receivers

extensions:
  oauth2:
      client_id: someclientidentifier
      client_secret: someclientsecret
      token_url: https://autz.server/oauth2/default/v1/token
      scopes: ["some.resource.read"]

exporter:
  otlphttp/withauth:
    authentication:
      authenticator: oauth2

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [oltphttp/withoauth]

Describe alternatives you've considered
Implemented PR #2464 where ConfigHttp client directly implements one form of Auth (Oauth2)

@pavankrish123
Copy link
Contributor Author

cc: @jpkrohling @bogdandrutu

@bogdandrutu
Copy link
Member

@jpkrohling would let you drive this, but feels reasonable

@jpkrohling
Copy link
Member

Looks good, just not 100% about the property name. We use authenticators on the receivers' side as well, which would make this consistent but might confuse users. Do you think we can solve this with documentation by ensuring that all authenticators clearly state whether they are meant to be used on the server/receiver side vs. client/exporter?

@rakyll
Copy link
Contributor

rakyll commented May 6, 2021

If this happens, we may consider having SigV4 as an extension.

cc @alolita @Aneurysm9 @anuraaga

@pavankrish123
Copy link
Contributor Author

pavankrish123 commented May 6, 2021

This is great!

@jpkrohling I was pondering on the same. The right place to get this information would be in the extension config definition. Not sure what is the best way.

In any case, I think we need to refine the interface here https://github.com/open-telemetry/opentelemetry-collector/blob/main/config/configauth/authenticator.go#L36 to more specific cases. like HTTPServerAuthenticator, GRPCServerAuthenticator, HTTPClientAuthenticator, GRPCClientAuthenticator WDYT.?

tigrannajaryan pushed a commit that referenced this issue May 20, 2021
This PR adds support to add client side (exporter) authenticators for HTTP and gRPC clients through extension based authenticators. This is built of top of what was added  for receiver (server) side authenticators via extensions in #2603 

**Link to tracking Issue:** #3115

**Testing:** 
- Did a manual testing for static bearer token.
- Added unit tests
dashpole pushed a commit to dashpole/opentelemetry-collector that referenced this issue Jun 14, 2021
…try#3128)

This PR adds support to add client side (exporter) authenticators for HTTP and gRPC clients through extension based authenticators. This is built of top of what was added  for receiver (server) side authenticators via extensions in open-telemetry#2603 

**Link to tracking Issue:** open-telemetry#3115

**Testing:** 
- Did a manual testing for static bearer token.
- Added unit tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants