Grafana Tempo has no built-in authentication layer

Grafana Tempo is a tracing backend, and its security posture depends heavily on what sits in front of it. The official documentation states that Tempo does not include an authentication layer and recommends an authenticating reverse proxy in every deployment mode. A small public footprint is still worth reviewing because a tracing endpoint can contain request paths, service names, error details, and cross-service relationships.

The measured footprint

On 2026-11-11 at 23:48 UTC, title="Grafana Tempo" returned 10 matches with sub_type=all, page 1, and page size 1. The same collection recorded 0 for app="Grafana Tempo", 1,538 for http.body="Grafana Tempo", 3 for app="Tempo", and 15,437 for title="Tempo".

The exact product title is the strongest selected signal in this set. Ten matches are a small observation and may include documentation, demos, or internal services with public DNS. The broader Tempo title count is not suitable as a product census because the word has many unrelated uses. The body count is broader still.

Authentication and tenancy

Tempo's authentication guide says the service relies on a reverse proxy to prevent unauthorized access. When multi-tenancy is enabled, the X-Scope-OrgID header identifies the tenant, and Tempo assumes that trusted clients populate the value. The proxy should authenticate the caller, derive the tenant from the authenticated identity, strip any client-supplied value, and reject requests that do not belong to that identity.

The tracing data model creates a specific exposure risk. A trace can include service names, span attributes, HTTP routes, database statements, error messages, and links to other traces. A public read API can disclose architecture and application behavior even when it does not expose credentials. A public write API can inject misleading traces, consume storage, or create high-cardinality data.

Deployment review

Map every Tempo listener and the reverse proxy in front of it. Include the HTTP query API, the OTLP HTTP and gRPC endpoints, the Jaeger-compatible paths, and any metrics or health endpoints. Confirm which paths require authentication and which are intentionally public. Apply network policy so only trusted collectors can write and only approved query services can read.

Test tenant isolation with two identities. A user for tenant A should receive a denial for tenant B, even when the request includes a forged header. Test the write path with a collector that does not set the header and with one that sets the wrong tenant. Confirm that the proxy adds the trusted value after authentication rather than forwarding the client's value.

Review retention and deletion because tracing stores can retain sensitive data longer than the application logs that generated it. Define which span attributes must be removed or hashed. A trace can expose a bearer token or query parameter if the instrumentation records full headers or URLs.

From count to action

Use the 10 exact-title matches as a lead, not as a vulnerability count. Verify each asset against certificate ownership, DNS delegation, and the organization's approved observability domains. If an asset is a Tempo API, check whether it is behind the documented proxy and whether the tenant header can be chosen by the caller.

The important number is not the public population. It is the number of Tempo endpoints that accept query or write traffic without an identity-aware proxy. That number comes from owned infrastructure and query tests, not from a search-engine total alone.

References

• Grafana Labs, Manage authentication for Grafana Tempo
• Grafana Labs, Enable multi-tenancy
• Grafana Labs, Tempo HTTP API
• ZoomEye query: title="Grafana Tempo"