Add Support for generating / refreshing Auth Header in auto instrumentation

Is your feature request related to a problem?

In order to authenticate to some Google APIs, we need the Authorization header to be added and then periodically refreshed in the OTLP exporter.

This is possibly by injecting ChannelCredentials (for grpc) or Session (for HTTP) into the OTLP exporters

Currently for auto instrumentation there's no way to inject these objects.

Describe the solution you'd like

Add new environment variables (OTEL_EXPORTER_OTLP_CREDENTIAL_PROVIDER, OTEL_EXPORTER_OTLP_LOGS_CREDENTIAL_PROVIDER, OTEL_EXPORTER_OTLP_METRICS_CREDENTIAL_PROVIDER,
OTEL_EXPORTER_OTLP_TRACES_CREDENTIAL_PROVIDER) to the sdk.
Alternatively add 2 new environment variables OTEL_EXPORTER_OTLP_GRPC_CREDENTIAL_PROVIDER for the GRPC OTLP exporters, and OTEL_EXPORTER_OTLP_HTTP_CREDENTIAL_PROVIDER for the HTTP OTLP exporters. These should actually be named OTEL_PYTHON_... according to https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/#language-specific-environment-variables because they aren't part of the official environment variable spec.

This environment variable will be set to an entry point that when loaded and initialized returns a ChannelCredentials (for grpc) or Session (for HTTP) object, auto instrumentation code will then pass that into the OTLP exporter(s). The OTLP exporters already accept these objects in their constructors. We could load these in the OTLP exporter classes OR in the configurator class. The exporters currently don’t use the entry_points API at all, which is needed for this approach to work.

I prototyped this solution here.

ChannelCredentials and Session handle automatically setting and refreshing the Authorization header.

It’s already standard in the auto instrumentation code to use environment variables to configure the OTLP exporters, so I think this is the most straightforward option.

Describe alternatives you've considered

An alternative is to use the existing environment variables (OTEL_METRICS_EXPORTER, OTEL_TRACES_EXPORTER, OTEL_LOGS_EXPORTER) that inject metrics, traces, and log exporters. An initialized exporter with ChannelCredentials / Session could be passed to them. The code would have to be updated to accept class instance objects, instead of only Class objects.

This solution is fine, but it requires users to set multiple environment variables instead of only 1 in cases where they want to send multiple kinds of telemetry to google's API.

It also could be confusing for users that they need to specify an exporter that isn't the default OTLP exporter, when it is technically the default OTLP exporter that is being used under the hood.

Another alternative solution is to add a new environment variable (OTEL_EXPORTER_OTLP_CUSTOMIZER, and log/metric/trace equivalents) to the sdk. I prototyped this at https://github.com/open-telemetry/opentelemetry-python/pull/4452.

This environment variable will be set to an entry point that when loaded and initialized returns an ExporterCustomizer class which has a single configure_exporter function, that takes an OtlpExporter class, initializes it with whatever arguments it wants to (ex: passing in the Session or ChannelCredentials etc.), and returns the class instance.

This would allow vendors to customize the OTLP exporters for users instead of asking users to set 5 or 6 environment variables.

I'm fine with this approach too, but again it could be unclear to users what exactly the customizer is doing to their exporters.

Additional Context

How Java code does it: 1, 2.

Would you like to implement a fix?

Yes

Start with opentelemetry-sdk/src/opentelemetry/sdk/environment_variables/init.py and the OTLP gRPC and HTTP exporter files linked in the issue. Review the configurator and exporter entry-point options, then compare them with the referenced prototype. Done means auto instrumentation can configure credential providers for the relevant OTLP exporters and credentials can refresh authentication headers.