This page documents the existing security mechanisms in Jaeger, organized by the pairwise connections between Jaeger components. We ask for community help with implementing additional security measures (see issue-1718).

Client to Agent

Deployments that involve jaeger-agent are meant for trusted environments where the agent is run as a sidecar within the container’s network namespace, or as a host agent. Therefore, there is currently no support for traffic encryption between clients and agents.

• ❌ Sending trace data over UDP - no TLS/authentication.
• ❌ Retrieving sampling configuration via HTTP - no TLS/authentication.

Client to Collector

Clients can be configured to communicate directly with jaeger-collector via HTTP. Unfortunately, at this time the Jaeger backend does not provide means of configuring TLS for its HTTP servers. The connections can be secured by using a reverse proxy placed in front of jaeger-collectors.

• ❌ HTTP - no TLS/authentication.
  • Some Jaeger clients support passing auth-tokens or basic auth.
  • Blog post: Protecting the collection of spans (using Keycloak).
  • Blog post: Secure architecture for Jaeger with Apache httpd reverse proxy on OpenShift.

Agent to Collector

• ✅ gRPC - TLS with client cert authentication supported.

Collector/Query to Storage

• ✅ Cassandra - TLS with mTLS supported.
• ✅ Elasticsearch - TLS with mTLS supported; bearer token propagation.
• ✅ Kafka - TLS with various authentication mechanisms supported (mTLS, Kerberos, plaintext).

Browser to UI

• ❌ HTTP - no TLS/authentication.
  • Blog post: Protecting Jaeger UI with an OAuth sidecar Proxy.

Consumers to Query Service

• ✅ HTTP - TLS with client cert authentication supported.
• ✅ gRPC - TLS with client cert authentication supported.