Does Jaeger include built-in authentication for the Query UI and collector endpoints?

Jaeger's all-in-one image and Operator-based deployments expose the Query UI on port 16686 and collector ingestion on ports 14268, 14250, and 4317/4318 (OTLP). As of Jaeger 1.x, these endpoints ship without integrated authentication or authorization, so anyone who can reach them can read traces — which often contain sensitive span tags such as URLs, user identifiers, and header values — or inject forged spans into storage.

On plain Kubernetes, Operator or Helm installs may also create an Ingress or LoadBalancer service for the Query service, and NetworkPolicies are not created by default. Documented guidance has historically been to place an OIDC-capable reverse proxy such as oauth2-proxy in front of Jaeger, because fine-grained, per-tenant access control is delegated to external layers rather than the server itself. Exact TLS and token flag names vary across 1.x releases, so behavior should be confirmed against the deployed version.

Before committing to a proxy-based design: does any Jaeger 1.x release provide native authentication or authorization for the query and collector endpoints, beyond TLS and bearer-token flags? Which endpoints must be treated as unauthenticated by design? And is a reverse proxy still the recommended mechanism for multi-tenant access control?