Loki needs identity in front of the tenant header
Grafana Loki stores and queries logs, and its multi-tenant mode depends on the X-Scope-OrgID header to identify a tenant. Grafana's documentation states that Loki does not include an authentication layer and that an authenticating reverse proxy or a deployment-specific access layer is needed in front of the services. That makes the proxy, the tenant header, and the network boundary part of the security model.
A ZoomEye query for title="Grafana Loki" returned 12 matches on 28 October 2026, using sub_type=all and a page size of one. An app="Grafana Loki" query returned zero. The small result is useful for a bounded review, not evidence that the product is rare or safe. Loki deployments often hide behind a Grafana, gateway, or Kubernetes service name that does not contain the product title.
Authentication and tenancy are separate
The documentation explains that in multi-tenant mode, every request needs X-Scope-OrgID; a request without it receives a 401 response with no org id. A reverse proxy can authenticate a caller and set the tenant header. If a client can reach Loki directly and send its own header, it may bypass the proxy's tenant decision.
Loki also supports mutual TLS on its HTTP and gRPC servers. The documentation notes that mTLS authenticates the client at transport level but does not populate the tenant header. A deployment therefore still needs a trusted component to choose the tenant, or a client design that safely maps a certificate identity to one tenant.
Build a request path diagram for every ingestion and query route. Identify the proxy, the service account or client certificate, the tenant selection rule, and the backend authorization that consumes the logs. A shared administrator token can defeat the distinction between tenant routing and tenant authorization. Rotate it if the proxy or operator boundary is unclear.
Review exposure and data sensitivity
Use the Loki measurement as a starting query, then compare the host inventory with the expected external services. From an unauthenticated network, confirm that Loki's HTTP and gRPC endpoints are not reachable. From an authorized network, check that requests without a tenant header fail and that a request with a tenant selected by a low-privilege caller cannot read another tenant's labels or entries.
Check retention and deletion separately. A tenant header controls logical query scope; it does not prove that storage, backups, or maintenance jobs keep organizations separate. Review retention periods and access to the object store. If tenants share a storage backend, document how the storage policy prevents one tenant's operator from reading another's data.
The practical control is straightforward to test. Rotate a proxy credential, remove a tenant binding, and verify the old client fails. Then try a direct request to the Loki port. If the first test passes but the second succeeds, the front-door policy is not complete.
Top comments (0)