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

Простыми словами: RoleBinding связывает «кто» (субъект) с «что можно делать» (роль).

Ключевые понятия

1. Role (Роль): Набор правил, определяющих, какие действия (verbs: get, list, create, delete) разрешены над какими ресурсами (pods, services, deployments). Role действует только в рамках одного namespace.
2. ClusterRole (Кластерная роль): Аналогична Role, но действует на уровне всего кластера. Используется для:
   • Ресурсов, не привязанных к namespace (например, nodes, persistentvolumes).
   • Разрешения доступа к эндпоинтам API (например, /healthz).
   • Предоставления одинаковых прав во всех namespace сразу (если привязать через RoleBinding).
3. RoleBinding (Привязка роли): Связывает Role с субъектами внутри одного namespace.
4. ClusterRoleBinding (Кластерная привязка роли): Связывает ClusterRole с субъектами на уровне всего кластера.

Примеры использования

1. RoleBinding для Role (внутри namespace)

Создадим Role, которая даёт права на чтение Pod’ов в namespace development, и RoleBinding, которая даёт эти права сервисному аккаунту my-sa.

Role (reader-role.yaml):

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: pod-reader
rules:
- apiGroups: [""] # "" указывает на core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

RoleBinding (reader-binding.yaml):

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: development
subjects:
# Можно указать несколько типов субъектов
- kind: ServiceAccount
  name: my-sa # Имя сервисного аккаунта
  namespace: development
roleRef:
  kind: Role # Должна быть "Role" или "ClusterRole"
  name: pod-reader # Имя роли, на которую ссылаемся
  apiGroup: rbac.authorization.k8s.io

Результат: Сервисный аккаунт my-sa в namespace development может выполнять get, watch, list для Pod’ов только в этом namespace.

2. RoleBinding для ClusterRole (доступ к ресурсам кластера внутри namespace)

Это очень распространённый паттерн. Вы создаёте одну ClusterRole (например, для просмотра Pod’ов), а затем используете RoleBinding в каждом namespace, чтобы дать доступ разным пользователям/сервисным аккаунтам.

ClusterRole (cluster-pod-viewer.yaml):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-pod-viewer
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

RoleBinding в namespace development:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-view-pods
  namespace: development
subjects:
- kind: User
  name: dev-user@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-pod-viewer
  apiGroup: rbac.authorization.k8s.io

Результат: Пользователь dev-user@example.com может просматривать Pod’ы только в namespace development.

3. ClusterRoleBinding (глобальный доступ)

Если нужно дать права на уровне всего кластера (например, администратору кластера или сервисному аккаунту для мониторинга всех нод).

ClusterRoleBinding (cluster-admin-binding.yaml):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: global-admin
subjects:
- kind: User
  name: admin@company.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin # Встроенная роль, дающая полный доступ
  apiGroup: rbac.authorization.k8s.io

Результат: Пользователь admin@company.com получает права администратора на весь кластер (все namespace, все ноды, все CRD).

Важные нюансы и правила

1. RoleBinding не может ссылаться на Role из другого namespace.
   • Если Role создана в namespace-a, а RoleBinding в namespace-b — это ошибка. RoleBinding может ссылаться только на Role из того же namespace или на ClusterRole.
2. ClusterRoleBinding не может ссылаться на Role.
   • ClusterRoleBinding работает только с ClusterRole.
3. Субъекты (Subjects):
   • User: Обычный пользователь (создается через сертификаты или внешний IdP).
   • Group: Группа пользователей (например, из LDAP или Azure AD).
   • ServiceAccount: Учетная запись для приложений (Pod’ов). Это самый частый случай в автоматизации.
4. Принцип наименьших привилегий (PoLP):
   • Всегда начинайте с минимально необходимых прав.
   • Используйте Role + RoleBinding, если доступ нужен только в одном namespace.
   • Используйте ClusterRole + RoleBinding, если нужен одинаковый шаблон прав в нескольких namespace.
   • Используйте ClusterRole + ClusterRoleBinding только для глобальных задач (мониторинг, администрирование).

Практический пример: CI/CD пайплайн

Предположим, у вас есть Jenkins или GitLab Runner, который должен деплоить приложения в namespace production. Ему не нужен доступ к другим namespace или к нодам.

Создаем ClusterRole (шаблон деплоера):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployer-role
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["services", "configmaps", "secrets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Создаем RoleBinding в namespace production:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jenkins-deployer
  namespace: production
subjects:
- kind: ServiceAccount
  name: jenkins-sa
  namespace: ci-cd # Сервисный аккаунт живет в другом namespace!
roleRef:
  kind: ClusterRole
  name: deployer-role
  apiGroup: rbac.authorization.k8s.io

Результат: Сервисный аккаунт jenkins-sa из namespace ci-cd может управлять Deployment’ами, Service’ами, ConfigMap’ами и Secret’ами только в namespace production.

Как проверить, что RoleBinding работает?

Используйте команду kubectl auth can-i:

# Проверить, может ли пользователь dev-user создать Pod в namespace development
kubectl auth can-i create pods --as dev-user@example.com -n development

# Проверить, может ли сервисный аккаунт my-sa удалять Deployment в namespace production
kubectl auth can-i delete deployments --as system:serviceaccount:ci-cd:jenkins-sa -n production

# Проверить, может ли пользователь выполнять любые действия на уровне кластера
kubectl auth can-i '*' '*' --as admin@company.com
# Просмотреть, какие права фактически есть у текущего пользователя
kubectl auth can-i --list

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: prometheus-operator-access
  namespace: monitoring
rules:
- apiGroups: ["monitoring.coreos.com"]
  resources: ["servicemonitors", "podmonitors"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-team-prometheus
  namespace: monitoring
subjects:
- kind: User
  name: dev-team@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: prometheus-operator-access
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-log-reader
  namespace: development
rules:
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-view-logs
  namespace: development
subjects:
- kind: User
  name: dev-user@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-log-reader
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: super-reader
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-super-reader: "true"
rules: [] # Правила будут собраны автоматически

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pods-reader
  labels:
    rbac.example.com/aggregate-to-super-reader: "true"
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]