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

Prototype change adding a Authorization Header Setter to OTLP exporters #4432

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

DylanRussell
Copy link

@DylanRussell DylanRussell commented Feb 14, 2025

This is an an alternative approach to #4431.

In order to dynamically set the authorization header a new environment variable (OTEL_AUTH_HEADER_EXTENSION) is added. The value of the variable must point to a Class provided via entry points that implements this interface:

class BaseAuthHeaderSetter(ABC):

    @abstractmethod
    def get_auth_header(self) -> Tuple[str, str]:
        pass

For example for Google we'd do something like:

class GCPAuthHeaderSetter(BaseAuthHeaderSetter):
    def __init__(self):
        self._credentials, _ = google.auth.default() # type: ignore
        self._request = requests.Request()

    def get_auth_header(self) -> Tuple[str, str]:
        if self._credentials.expired: # type: ignore
            self._credentials.refresh(self._request) # type: ignore
        return ("Authorization", f"Bearer: {self._credentials.token}") # type: ignore

The advantage to this approach over this one is that the user would only have to specify one auth header extension and it'd automatically get loaded in to all their OTLP exporters, versus having to specify a bunch of custom exporters.

@Kludex
Copy link
Contributor

Kludex commented Feb 20, 2025

I don't think either this or #4431 need to get in to achieve what you want.

For grpc exporters, you have the credentials parameter that can be used. See this.

For HTTP exporters, you can use the Session parameter, and pass to the exporter. You can use this.


@aabmass brought the argument that we shouldn't rely on coupling with requests.Session because it may be replaced by urllib3, but people already rely on that parameter, and it seems a pretty sensible option. Also, this is currently already achievable without changing anything...

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

Successfully merging this pull request may close these issues.

2 participants