RBAC в Kubernetes
Тема дорожной карты · Prometheus
Role-Based Access Control (RBAC) в Kubernetes необходим для предоставления Prometheus разрешений на обнаружение сервисов и сбор метрик с подов, сервисов и узлов кластера. Prometheus требует ServiceAccount, ClusterRole с разрешениями get, list и watch для ресурсов nodes, pods, services, endpoints и ingresses, а также ClusterRoleBinding, связывающего роль с сервисным аккаунтом Prometheus. Без должной конфигурации RBAC обнаружение сервисов Kubernetes в Prometheus не сможет перечислить цели, что приведёт к отсутствию метрик и деградации мониторинга. При использовании Prometheus Operator сам оператор управляет необходимыми ресурсами RBAC для экземпляров Prometheus, которые он разворачивает. Аудит и минимизация разрешений RBAC Prometheus до только необходимых являются лучшей практикой безопасности в производственных средах Kubernetes.
Как это работает
RBAC в Kubernetes: у Prometheus нет встроенной auth (предполагается доверенная сеть). В production — за reverse proxy (Caddy, nginx) с auth (OAuth2 proxy, basic auth, mTLS). Scrape-таргеты с auth: basic_auth, bearer_token, tls_config. Шифруйте remote_write/read трафик через TLS. Ограничьте /metrics-эндпойнты от публичности (auth или network ACL). Скрейп-секреты — из secrets:-файла с правильными правами.
Когда применять
Всегда фронт Prometheus + Alertmanager с auth в production — даже "внутренние" тулы утекают бизнес-данными. mTLS или OAuth2-proxy спереди. Ротация scrape-credentials периодически. Prometheus под non-root. Для multi-tenant — Mimir или VictoriaMetrics (с tenancy); один Prometheus не изолирует тенантов.
Типичные ошибки
Ловушки RBAC в Kubernetes: экспозиция UI / API Prometheus публично (мгновенный info leak — каждая метрика, каждый job); plain HTTP между Prometheus и exporters (cred + метрики на проводе); не ротируют service-account токены для k8s-scrape; общий Prometheus между security-границами (нет tenancy-изоляции).