Skip to content

Default opentelemetry_insecure to None so OTEL_EXPORTER_OTLP_INSECURE takes effect #322

Closed

Description

@lesnik512

opentelemetry_insecure defaults to True (lite_bootstrap/instruments/opentelemetry_instrument.py:77) and is always passed to the gRPC span and metric exporters (:260-263, :287-290). The HTTP exporters do not receive it (:271, :298). The gRPC exporters read OTEL_EXPORTER_OTLP_TRACES_INSECURE, OTEL_EXPORTER_OTLP_METRICS_INSECURE and OTEL_EXPORTER_OTLP_INSECURE only when insecure is None (opentelemetry/exporter/otlp/proto/grpc/trace_exporter/__init__.py:97-99, metric_exporter/__init__.py:112-114, and the generic variable in exporter.py:318-323, all in 1.44), so today those variables do nothing.

With insecure=None and no variable set, the exporter decides from the endpoint: an https scheme means TLS, and otherwise the connection is insecure only when the scheme is http (exporter.py:316-323). An https scheme forces TLS even when insecure=True is passed. A schemeless endpoint such as collector:4317, which connects in plaintext today, would switch to TLS. The 1.28 floor resolves the same way, written differently (trace :97-100, metric :107-110, exporter.py:208-218 at 1.28.0).

Work

  • Test first: with OTEL_EXPORTER_OTLP_TRACES_INSECURE=false and a default config with a gRPC endpoint, the span exporter is secure. It fails today.
  • Change the field to bool | None = None and pass it through unchanged; None leaves the decision to the exporter.
  • _parse_remote_insecure_host (:103-120) tests not self.opentelemetry_insecure. Resolve the effective value first (the field, then the variables, then the scheme) so the "sending telemetry unencrypted" warning still fires exactly when the connection is plaintext. The https false positive that exists today is An https:// OTLP gRPC endpoint gets the "sending telemetry unencrypted" warning #333; land it first.
  • Docs: the bullet at docs/introduction/configuration.md:134, with the schemeless-endpoint change and the advice to write http://collector:4317 for a plaintext local collector.

Verify: the new test passes, the existing insecure-warning tests (tests/instruments/test_opentelemetry_instrument.py:216-272, tests/test_config.py:100-109, tests/test_fastapi_bootstrap.py:206-214) still pass, and an http:// endpoint connects in plaintext with no setting.

Breaking for gRPC users with a schemeless endpoint who never set opentelemetry_insecure: the exporter starts using TLS and fails against a plaintext collector until they add http:// or set opentelemetry_insecure=True.

Activity

  1. added this to the 2.0.0 milestone on Oct 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestneeds-triageMaintainer needs to evaluate this issue

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions