When running in single tenant mode, what is primary reason for also running with authentication beyond best practices. I’m struggling to understand what this buys me if every consumer of the loki service is in the same bucket already. I’d also love to know when it makes sense to break down a monolithic tenant into smaller ones, as that seems more likely the answer (authorization makes more sense in multi-tenant, and rarely are there true single tenant situations is my line of reasoning here).
There are a few things multi-tenancy addresses the most important is that limits can be applied differently between tenants. If running a single large single tenant cluster, one “client” can affect everything, potentially quite easily. Having some separation here may be valuable for some people.
Another example I’ve seen this be useful is AWS specific, which has per prefix rate limits on S3 buckets, as each tenant is in a sperate prefix this amoratizes the requests some to help with this (though this is in some ways a nice side effect and not really a solution to this problem)
Authentication is really left as an exercise outside of Loki, it only looks for the presence of the tenant header “X-Scope-OrgID” (I think that’s the correct header, going from memory) to chose how to tenant the requests.
It’s really left as an exercise to the operator what kind of authentication they want/need for Loki and what value it is for them.
@ewelch Thanks for your very clear explanation of what authentication is and isn’t for Loki.
I think I can probably better phrase my question as a question of what is the point at which most users say that they actually are multi-tenant. My group runs with the expectation that our cluster just has logging, and its a service that everyone gets “for free”. I’m trying to work out if this is a pattern I need to break and make each group within the cluster choose to send logs on their own, or if this is truly just a matter of opinion that each site has to make the call for themselves.
Gotcha, I can maybe offer a little guidance or share some of our experiences here, we run Loki internally as a very large single tenant cluster which is nice in many ways (e.g. querying over multiple loki clusters with one query is not available as an option yet). However there have been a handful of times where it’s also been a problem with one person writing some really aggressive queries and filling up the single tenants query queue in the frontend, or something logging a little too aggressively and hitting rate limits or stream limits which affect everything sending logs to that tenant.
But this model fits our company reasonable well, our engineers are also operators we tend to all want access to the same thing and don’t have any requirements for restricting access.
When we work with companies who setup Loki themselves, or use the hosted service and want multiple tenants, it’s typically use cases like separation of concerns for security or compliance reasons, or a more traditional operating infrastructure where teams are highly separated already and it seems to make more sense for them, a little bit of Conways law I guess.
Sometimes people also like having separate tenants for environments (dev,test,prod).
I’m trying to work out if this is a pattern I need to break and make each group within the cluster choose to send logs on their own, or if this is truly just a matter of opinion that each site has to make the call for themselves.
I would say it’s mostly a matter of opinion and I personally don’t have any strong opinions here. If/when Loki gets some better support for querying over multiple tenants/clusters we might decide to divide our infra up to separate tenants to have more granular limits, but honestly it’s not that often we have issues so I don’t think we would like decompose our big single tenant instance.
Not sure if this helps!?
2 Likes
This clears up a lot of my confusion. It sounds like the ultimate answer to my question is one that comes with time and after an engineering organization figures out how its units are organized, then how the technology that supports those units is organized alongside.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.