rbac support for exporter-toolkit
63 views
Skip to first unread message
Jesús Samitier
Nov 22, 2022, 4:30:32 PM11/22/22
to Prometheus Developers
Hi,
It was great to see all of you in Munich!
After our talk about securing Prometheus in K8s, we received a message in Mastodon suggesting us that it'd be a good idea to add rbac support to the exporter-toolkit. I'm not sure because you don't always deploy your exporters in Kubernetes, so wanted to ask to the community.
If someone thinks that this could be useful for the project, we'd be glad to contribute.
Thanks!
After our talk about securing Prometheus in K8s, we received a message in Mastodon suggesting us that it'd be a good idea to add rbac support to the exporter-toolkit. I'm not sure because you don't always deploy your exporters in Kubernetes, so wanted to ask to the community.
If someone thinks that this could be useful for the project, we'd be glad to contribute.
Thanks!
Julien Pivotto
Nov 25, 2022, 7:01:32 AM11/25/22
to Jesús Samitier, Prometheus Developers
I am surprised by this, it looks a huge maintenance burden and
potentially would add a lot of disk space to all the exporters that is
shared between all if you use a sidecar.
We also, as you point out, have many users just not deploying to kube.
On 10 Nov 05:44, Jesús Samitier wrote:
> Hi,
>
> It was great to see all of you in Munich!
>
> After our talk about securing Prometheus in K8s, we received a message in
> Mastodon suggesting us that it'd be a good idea to add rbac support to the
> exporter-toolkit <https://github.com/prometheus/exporter-toolkit>. I'm not
> You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/edc5b581-edc7-49ea-8906-1e81281e4209n%40googlegroups.com.
--
Julien Pivotto
@roidelapluie
potentially would add a lot of disk space to all the exporters that is
shared between all if you use a sidecar.
We also, as you point out, have many users just not deploying to kube.
On 10 Nov 05:44, Jesús Samitier wrote:
> Hi,
>
> It was great to see all of you in Munich!
>
> After our talk about securing Prometheus in K8s, we received a message in
> Mastodon suggesting us that it'd be a good idea to add rbac support to the
> sure because you don't always deploy your exporters in Kubernetes, so
> wanted to ask to the community.
>
> If someone thinks that this could be useful for the project, we'd be glad
> to contribute.
>
> Thanks!
>
> --
> wanted to ask to the community.
>
> If someone thinks that this could be useful for the project, we'd be glad
> to contribute.
>
> Thanks!
>
> You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/edc5b581-edc7-49ea-8906-1e81281e4209n%40googlegroups.com.
--
Julien Pivotto
@roidelapluie
Bryan Boreham
Nov 28, 2022, 5:39:46 AM11/28/22
to Prometheus Developers
What is meant by "add rbac support to the exporter-toolkit" ?
I have been using Kubernetes and Prometheus for many years; I know what RBAC is but cannot immediately see how an exporter would want to write code that references it.
Bryan
Jesús Samitier
Nov 28, 2022, 5:56:50 AM11/28/22
to Bryan Boreham, Prometheus Developers
Hi
The idea is to integrate kube-rbac-proxy to add an extra (and optional) security feature in a new exporter, so the final user can rely on RBAC to assure that only Prometheus can scrape its metrics. This is something you get when you install Prometheus in K8s using the official helm chart - only Prometheus can scrape the Prometheus metrics exposed by the K8s internals. The idea is to have something similar but for any exporter.
Any developer can integrate it in its exporter (as shown here https://www.brancz.com/2018/02/27/using-kube-rbac-proxy-to-secure-kubernetes-workloads), but someone pointed out on Mastodon that we could also integrate in in the exporter toolkit so it's even easier.
The idea is to integrate kube-rbac-proxy to add an extra (and optional) security feature in a new exporter, so the final user can rely on RBAC to assure that only Prometheus can scrape its metrics. This is something you get when you install Prometheus in K8s using the official helm chart - only Prometheus can scrape the Prometheus metrics exposed by the K8s internals. The idea is to have something similar but for any exporter.
Any developer can integrate it in its exporter (as shown here https://www.brancz.com/2018/02/27/using-kube-rbac-proxy-to-secure-kubernetes-workloads), but someone pointed out on Mastodon that we could also integrate in in the exporter toolkit so it's even easier.
You received this message because you are subscribed to a topic in the Google Groups "Prometheus Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/prometheus-developers/q7M_dDLU0nY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to prometheus-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/c4d87f55-d74f-4d48-bd59-2c42eadec169n%40googlegroups.com.
Stuart Clark
Nov 28, 2022, 5:59:07 AM11/28/22
to Jesús Samitier, Bryan Boreham, Prometheus Developers
On 2022-11-28 10:56, Jesús Samitier wrote:
> Hi
>
> The idea is to integrate kube-rbac-proxy to add an extra (and
> optional) security feature in a new exporter, so the final user can
> rely on RBAC to assure that only Prometheus can scrape its metrics.
> This is something you get when you install Prometheus in K8s using the
> official helm chart - only Prometheus can scrape the Prometheus
> metrics exposed by the K8s internals. The idea is to have something
> similar but for any exporter.
>
> Any developer can integrate it in its exporter (as shown here
> https://www.brancz.com/2018/02/27/using-kube-rbac-proxy-to-secure-kubernetes-workloads),
> but someone pointed out on Mastodon that we could also integrate in in
> the exporter toolkit so it's even easier.
>
What would actually be needed in the toolkit though? Is it just some
> Hi
>
> The idea is to integrate kube-rbac-proxy to add an extra (and
> optional) security feature in a new exporter, so the final user can
> rely on RBAC to assure that only Prometheus can scrape its metrics.
> This is something you get when you install Prometheus in K8s using the
> official helm chart - only Prometheus can scrape the Prometheus
> metrics exposed by the K8s internals. The idea is to have something
> similar but for any exporter.
>
> Any developer can integrate it in its exporter (as shown here
> https://www.brancz.com/2018/02/27/using-kube-rbac-proxy-to-secure-kubernetes-workloads),
> but someone pointed out on Mastodon that we could also integrate in in
> the exporter toolkit so it's even easier.
>
docs explaining how to deploy the sidecar with the exporter, or actual
code changes?
--
Stuart Clark
Jesús Samitier
Nov 28, 2022, 6:01:50 AM11/28/22
to Stuart Clark, Bryan Boreham, Prometheus Developers
Yeah, maybe add some documentation with example configurations.
Stuart Clark
Nov 28, 2022, 6:10:05 AM11/28/22
to Jesús Samitier, Bryan Boreham, Prometheus Developers
On 2022-11-28 11:01, Jesús Samitier wrote:
> Yeah, maybe add some documentation with example configurations.
>
If it just some docs I don't see any issue?
> Yeah, maybe add some documentation with example configurations.
>
--
Stuart Clark
Ben Kochie
Nov 28, 2022, 6:40:25 AM11/28/22
to Stuart Clark, Jesús Samitier, Bryan Boreham, Prometheus Developers
It depends on if the sidecar is with Prometheus or with the target.
If it's with Prometheus, that's probably just a docs update.
If it's with every exporter, that's probably something we would want in the exporter-toolkit.
But, my understanding was that the typical thing here was to use mTLS for securing and authorizing Prometheus.
If it's with Prometheus, that's probably just a docs update.
If it's with every exporter, that's probably something we would want in the exporter-toolkit.
But, my understanding was that the typical thing here was to use mTLS for securing and authorizing Prometheus.
If it's something we need to integrate into every exporter to do some kind of token auth, we might want to consider this.
On Mon, Nov 28, 2022 at 11:59 AM Stuart Clark <stuart...@jahingo.com> wrote:
--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/3883faab86ed1a93de7ad2d8f8598ea5%40Jahingo.com.
Stuart Clark
Nov 28, 2022, 6:43:07 AM11/28/22
to Ben Kochie, Jesús Samitier, Bryan Boreham, Prometheus Developers
On 2022-11-28 11:40, Ben Kochie wrote:
> It depends on if the sidecar is with Prometheus or with the target.
>
> If it's with Prometheus, that's probably just a docs update.
>
> If it's with every exporter, that's probably something we would want
> in the exporter-toolkit.
>
> But, my understanding was that the typical thing here was to use mTLS
> for securing and authorizing Prometheus.
>
> If it's something we need to integrate into every exporter to do some
> kind of token auth, we might want to consider this.
>
Do you mean building in the functionality directly into the exporter
> It depends on if the sidecar is with Prometheus or with the target.
>
> If it's with Prometheus, that's probably just a docs update.
>
> If it's with every exporter, that's probably something we would want
> in the exporter-toolkit.
>
> But, my understanding was that the typical thing here was to use mTLS
> for securing and authorizing Prometheus.
>
> If it's something we need to integrate into every exporter to do some
> kind of token auth, we might want to consider this.
>
instead of using a sidecar?
--
Stuart Clark
Ben Kochie
Nov 28, 2022, 6:45:45 AM11/28/22
to Stuart Clark, Jesús Samitier, Bryan Boreham, Prometheus Developers
Yes, build it in. We don't want to require sidecars for every exporter.
Jesús Samitier
Nov 28, 2022, 7:43:35 AM11/28/22
to Ben Kochie, Stuart Clark, Bryan Boreham, Prometheus Developers
instead of adding kube-rbac-proxy as a sidecar, integrating with Kubernetes ServiceAccount + RBAC could be done directly using the Kube api.
Julien Pivotto
Nov 28, 2022, 7:53:08 AM11/28/22
to Ben Kochie, Stuart Clark, Jesús Samitier, Bryan Boreham, Prometheus Developers
On 28 Nov 12:45, Ben Kochie wrote:
> Yes, build it in. We don't want to require sidecars for every exporter.
I disagree with this, as this sidecar is only required in kubernetes
> Yes, build it in. We don't want to require sidecars for every exporter.
environments. Baking it into the exporter toolkit would be a huge
maintenance challenge:
- from users - which version of the exporter matches my kube version?
(it includes k8s libraries)
- from admins - every exporter is larger now
- from maintainers - everyone would have to keep the toolkit up to date
to match k8s versions and fix potentially critical bugs
On the contrary, I find the sidecar pattern great here - first, this is
designed exclusively for kube. Second, the same code only needs to be
downloaded once per machine, even if you have 10 containers. Then, you
manage the version and the config as you wish. You do not depend on your
exporter to include the rbac proxy that you need or have a mix of those
versions included.
> --
> You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CABbyFmrmeBX5fxbiPzDV%2BYpePy4UqYz%3DQsHJRwtPkob%2BGZ_w5Q%40mail.gmail.com.
> You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
--
Julien Pivotto
@roidelapluie
Bryan Boreham
Nov 28, 2022, 10:27:01 AM11/28/22
to Prometheus Developers
I see that kube-rbac-proxy both authenticates the caller and performs an authorization request to check whether that caller is allowed.
Given divided opinions, how about a separate library which implements the feature, and a hook in prometheus/exporter-toolkit so that any similar library can be added at the choice of the exporter.
Bryan
Julien Pivotto
Nov 28, 2022, 10:29:01 AM11/28/22
to Bryan Boreham, Prometheus Developers
On 28 Nov 07:27, Bryan Boreham wrote:
> I see that kube-rbac-proxy both authenticates the caller and performs an
> authorization request to check whether that caller is allowed.
>
> Given divided opinions, how about a separate library which implements the
> feature, and a hook in prometheus/exporter-toolkit so that any similar
> library can be added at the choice of the exporter.
it looks like this could then be added to the kube-rbac-proxy, but in
> I see that kube-rbac-proxy both authenticates the caller and performs an
> authorization request to check whether that caller is allowed.
>
> Given divided opinions, how about a separate library which implements the
> feature, and a hook in prometheus/exporter-toolkit so that any similar
> library can be added at the choice of the exporter.
general if official exporters do not use it, it does not make sense to
have it on the exporter toolkit.
--
Julien Pivotto
@roidelapluie
Reply all
Reply to author
Forward
0 new messages