Enterprises using Prometheus

[an...@signoz.io]

Hey Everyone,

How does enterprise implement RBAC to Prometheus Data? I think this is important from data security point of view.

[Ben Kochie]

Typically Prometheus doesn't contain any sensitive data, so no fine-grained access controls are necessary.

Prometheus is also designed to be distributed, so in a large organization, there may be hundreds of individual Prometheus servers. Deployment is automated, managed by tools, allowing teams to operate their own instances without any effort.

There are some multi-tenant tools for example: https://github.com/prometheus-community/prom-label-proxy

Systems like Cortex can provide multi-tenancy as well: https://github.com/cortexproject/cortex

On Sat, Mar 20, 2021 at 8:28 AM an...@signoz.io <an...@signoz.io> wrote:

Hey Everyone,

How does enterprise implement RBAC to Prometheus Data? I think this is important from data security point of view.

--
You received this message because you are subscribed to the Google Groups "Prometheus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/30960e35-472b-4954-99b2-7e538eb65f23n%40googlegroups.com.

[an...@signoz.io]

Got it.. and does each team manage their own data and don't share it with other teams? Or each team has a prom instance running with a central data storage? 

[Stuart Clark]

On 20/03/2021 12:52, an...@signoz.io wrote:
> Got it.. and does each team manage their own data and don't share it
> with other teams? Or each team has a prom instance running with a
> central data storage?

It very much depends on what you want, team capabilities and
security/performance/maintenance concerns.

In general the decentralised nature of Prometheus allows each
team/application/environment to have its own set of servers, which
prevents a single central failure from stopping everyone. If the metrics
are only useful to a single team then it might not be more widely
available, but similarly it could be shared if multiple teams need
visibility - this could be using federation or a remote write system.

Ultimately it is down to who should control what (ideally you don't want
another team controlling a system you depend upon if you could do it
yourself) and who should be able to access what (there might be some
systems which are "secret" or some business level metrics you want to be
more careful about who can access).

You could send everything to a single central remote write system, but
you'd need to be careful about creating a single point of failure and
how maintenance outages of that system are handled. Also, that single
central system may need to have a single "lowest common denominator"
setup to allow all teams to do what they want, while also having to live
within and constraints (e.g. storage) that might apply. Personally I try
to keep things more separated, so using different storage for each team,
which makes maintenance easier and allows each team to control their own
configuration, at the cost of a bit more complexity/infrastructure.

--
Stuart Clark

[Evelyn Pereira Souza]

On 20.03.21 14:45, Stuart Clark wrote:
> Personally I try to keep things more separated, so using different
> storage for each team, which makes maintenance easier and allows each
> team to control their own configuration, at the cost of a bit more
> complexity/infrastructure.

We do the same here. But we have some "big data" layer that takes data
from individual instances (for big picture of all services).

kind regards
Evelyn

[Abhinav Khushraj]

Many deployments use an external storage to deal with the various problems cited above e.g. storage constraints, complex queries, analytics etc. There are several external storage options available 

https://prometheus.io/docs/operating/integrations/ 

Cheers!

Abhinav

--
You received this message because you are subscribed to the Google Groups "Prometheus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/75fe2965-7292-4af9-7411-a949b49608c0%40disroot.org.