Securing Prometheus Endpoints with RBAC

Apply Kubernetes RBAC policies to restrict access to Prometheus metrics and sensitive configuration endpoints within your cluster.

In this lesson, you will learn how to leverage Kubernetes RBAC to ensure only authorized users and services can query your Prometheus metrics endpoints.

Why Secure Prometheus Metrics?

By default, the /metrics endpoint on Prometheus and its associated exporters (like Node Exporter or cAdvisor) are often exposed via HTTP. While these metrics don't contain passwords or private keys, they provide a blueprint of your cluster’s internal state, including infrastructure load, specific application performance, and internal service naming. If left unrestricted, an attacker could use this data to perform reconnaissance before launching an exploit.

Implementing RBAC Protection

In a Kubernetes-native environment, Prometheus usually runs inside a cluster, and we secure access by controlling who—or what—can perform a GET request against the Prometheus service.

Instead of relying on basic network access, we use Kubernetes RBAC to define Roles or ClusterRoles that permit access to specific subresources. For example, if you are using the Prometheus Operator, you can restrict access to the Prometheus custom resource using a RoleBinding.

To prevent unauthorized access to the web interface or API, you should avoid exposing the Prometheus service as a NodePort or LoadBalancer without an authentication layer. Instead, use an Ingress controller with an OIDC (OpenID Connect) provider or a sidecar proxy that validates requests against the Kubernetes TokenReview API.

Here is how you might define a restricted Role that limits which ServiceAccounts can even "look" at your monitoring namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: monitoring
  name: prometheus-read-only
rules:
- apiGroups: [""]
  resources: ["services/proxy"]
  verbs: ["get"]
  resourceNames: ["prometheus-operated"]

By binding this Role only to trusted users or CI/CD pipelines, you ensure that even if someone manages to hit the cluster IP, the API server will reject the request unless the requester carries the proper RBAC permissions to access the services/proxy subresource. This prevents unauthorized discovery of your telemetry data.

Key Takeaway: Use Kubernetes RBAC to gate access to the services/proxy subresource, ensuring that only authenticated identities can query your Prometheus metrics endpoints.