-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Comments
@jpkrohling would let you drive this, but feels reasonable |
Looks good, just not 100% about the property name. We use |
If this happens, we may consider having SigV4 as an extension. |
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.? |
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
…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
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
Describe alternatives you've considered
Implemented PR #2464 where ConfigHttp client directly implements one form of Auth (Oauth2)
The text was updated successfully, but these errors were encountered: