I do not need multi-tenant mode. All I want to do is add a protection layer over the ability for my remote promtail agents to reach the Loki endpoint.
I’m happy enough to just use basic_auth on my Nginx reverse proxy that sits in front of Loki. But if so, I don’t understand the point of the auth options for the Data Source. Do I need both (and make sure Loki recognizes the same password as the one I configure in Nginx’s basic auth file), or just one or the other?
What is the conflict?
Loki allows you to put what you want in front of Loki for auth, e.g. you are familiar with nginx basic auth, so nginx can be your auth layer. More advanced users use OAuth for authentication and authorization, so they will deploy some OAuth proxy.
Every of these users want to have just copy&paste example in the doc, so it’s there. Use example for your use case.
Thanks jangaraj. What I am confused about is, what is the purpose of setting auth (basic or OAuth) at the Loki ‘data source’ layer, if you’ve already set the auth at the Nginx layer?
If “Grafana Loki does not come with any included authentication layer”, why are there authentication options when configuring the Data Source?
Is it just for when the Grafana interface would need to traverse the Nginx proxy to reach the Loki endpoint, as opposed to via localhost?
Because Grafana is connecting to Loki and if Loki has some auth layer, you must be able to set that auth in the Grafana Loki datasource configuration. Otherwise, Grafana won’t receive any suitable response from Loki.
So in my case, Grafana and Loki are on the same network defined in the same Docker Compose file. This means that for a Loki Data source, I can leave it as ‘No authentication’ and have it connect to http://loki:3100 (bypassing the Nginx reverse proxy altogether).
Meanwhile, my remote Promtail agents will traverse the Nginx reverse proxy and so will use the basic auth.
