Что такое ClusterRole?

ClusterRole — это объект Kubernetes, который определяет набор прав доступа (permissions) для работы с кластерными ресурсами или ресурсами во всех namespace’ах. В отличие от обычного Role, который действует в пределах одного namespace, ClusterRole имеет глобальную область видимости.

Основные отличия ClusterRole от Role

Аспект	Role	ClusterRole
Область действия	Один namespace	Весь кластер
Доступ к ресурсам	Только resources в namespace	Cluster-scoped resources + все namespaces
Привязка	RoleBinding	ClusterRoleBinding
Использование	Локальные права	Глобальные права

Синтаксис ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin  # Имеет глобальное действие
rules:
- apiGroups: [""]  # Core API group
  resources: ["pods", "services", "nodes", "namespaces"]
  verbs: ["get", "list", "watch", "create", "update", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments", "daemonsets", "statefulsets"]
  verbs: ["*"]  # Все операции
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles", "clusterrolebindings"]
  verbs: ["get", "list"]

Типичные use cases для ClusterRole

1. Административные роли

# Полные права на кластер
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: super-admin
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
- nonResourceURLs: ["*"]
  verbs: ["*"]

2. Мониторинг и наблюдение

# Права для систем мониторинга (Prometheus)
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-role
rules:
- apiGroups: [""]
  resources: ["nodes", "services", "endpoints", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["extensions"]
  resources: ["ingresses"]
  verbs: ["get", "list", "watch"]

3. Доступ к узлам (nodes)

# Просмотр информации об узлах
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

4. Управление Persistent Volumes

# Управление постоянными томами
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pv-admin
rules:
- apiGroups: [""]
  resources: ["persistentvolumes"]
  verbs: ["get", "list", "watch", "create", "update", "delete"]

Привязка ClusterRole через ClusterRoleBinding

Глобальная привязка пользователю

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-binding
subjects:
- kind: User
  name: "alice@company.com"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

Привязка к ServiceAccount

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus-binding
subjects:
- kind: ServiceAccount
  name: prometheus-service-account
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: monitoring-role
  apiGroup: rbac.authorization.k8s.io

Использование ClusterRole в пределах namespace

ClusterRole можно использовать с обычным RoleBinding для предоставления прав в конкретном namespace:

# RoleBinding с ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: limited-admin-binding
  namespace: development  # Только в этом namespace
subjects:
- kind: User
  name: "developer@company.com"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole  # Используем ClusterRole!
  name: cluster-admin  # Но применяем только к namespace development
  apiGroup: rbac.authorization.k8s.io

Встроенные ClusterRole в Kubernetes

Kubernetes поставляется с предопределенными ClusterRole:

1. cluster-admin

kubectl describe clusterrole cluster-admin

• Полные права на весь кластер
• Может управлять любыми ресурсами

2. admin

• Права администратора в пределах namespace
• Не может управлять ресурсами кластера

3. edit

• Права на редактирование ресурсов
• Не может управлять RBAC

4. view

• Права только на чтение
• Не может просматривать secrets

Практические примеры

Создание custom ClusterRole

# Создание через kubectl
kubectl create clusterrole pod-reader \
  --verb=get,list,watch \
  --resource=pods

# С привязкой ко всем namespaces
kubectl create clusterrolebinding pod-reader-binding \
  --clusterrole=pod-reader \
  --user=reader-user

Проверка прав

# Проверка прав для пользователя
kubectl auth can-i create deployments --as=developer@company.com

# Проверка прав в конкретном namespace
kubectl auth can-i delete pods --namespace=production

Best Practices

1. Принцип минимальных привилегий

# Вместо полных прав
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]  # Только необходимые операции

2. Использование групп вместо отдельных пользователей

subjects:
- kind: Group
  name: "developers@company.com"
  apiGroup: rbac.authorization.k8s.io

3. Регулярный аудит

# Просмотр всех ClusterRoleBindings
kubectl get clusterrolebindings -o wide

# Детальная информация о конкретной роли
kubectl describe clusterrole <role-name>

4. Использование агрегации

# Агрегированная роль для мониторинга
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-aggregated
  labels:
    rbac.authorization.k8s.io/aggregate-to-monitoring: "true"
rules:
- apiGroups: [""]
  resources: ["services", "endpoints", "pods"]
  verbs: ["get", "list", "watch"]

Безопасность

Опасные паттерны

# НЕ ДЕЛАЙТЕ ТАК! Опасные права:
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["*"]  # Полный доступ к secrets!

Защита от эскалации привилегий

# Ограничение на создание RBAC-ресурсов
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles", "clusterrolebindings"]
  verbs: ["get", "list"]  # Только чтение, не создание

Отладка проблем с правами

Команды для диагностики

# Проверка прав текущего пользователя
kubectl auth can-i --list

# Проверка прав конкретного пользователя
kubectl auth can-i create pods --as=system:serviceaccount:default:my-sa

# Просмотр событий RBAC
kubectl get events --field-selector involvedObject.kind=ClusterRole

Common issues

1. Неправильный apiGroup: Убедитесь, что указали правильный apiGroup для ресурса
2. Опечатка в verbs: get, list, watch, create, update, patch, delete
3. Отсутствие привязки: ClusterRole без ClusterRoleBinding бесполезен

ClusterRole — мощный инструмент управления доступом в Kubernetes, который следует использовать с осторожностью. Всегда применяйте принцип минимальных привилегий и регулярно проводите аудит прав доступа в кластере.

Ключевые моменты:

• Используйте ClusterRole для кластерных ресурсов и глобальных прав
• Привязывайте через ClusterRoleBinding для глобального доступа
• Используйте с RoleBinding для ограничения прав namespace’ом
• Следуйте принципу минимальных привилегий
• Регулярно аудитируйте и пересматривайте права доступа