Сообщить об ошибкеКороткий ответ
Role и RoleBinding ограничены одним namespace и дают права только на ресурсы внутри него; ClusterRole определяет права, применимые на уровне всего кластера (включая кластерные ресурсы вроде Node), но может быть связан как ClusterRoleBinding (права во всём кластере), так и RoleBinding (права только в конкретном namespace, хотя сам набор прав переиспользуемый).
Как это работает подробнее
RBAC в Kubernetes состоит из двух частей — определение прав (Role/ClusterRole, набор правил "что можно делать с какими ресурсами") и привязка этих прав к субъекту (RoleBinding/ClusterRoleBinding, "кому выданы эти права и где"). ClusterRole часто используют для переиспользуемых наборов прав (например, "read-only доступ к Pod и Service"), которые затем привязываются к разным namespace через отдельные RoleBinding, чтобы не дублировать одинаковые правила.
Пример кода
kubectl auth can-i delete pods --as=system:serviceaccount:prod:ci-deployer -n prodЧто использовать на практике
- Практика. для прав, которые должны действовать везде одинаково и затрагивают кластерные ресурсы (Node, PersistentVolume, сами CRD), используют ClusterRole + ClusterRoleBinding; для ограничения команды только её собственным namespace — Role + RoleBinding (или переиспользуемый ClusterRole + RoleBinding именно в этом namespace). Принцип наименьших привилегий означает выдачу максимально узких прав, необходимых для задачи, и регулярный аудит через
kubectl auth can-i.
Подводные камни
- Риски. выдавать ClusterRoleBinding там, где достаточно RoleBinding в одном namespace, расширяя права на весь кластер без необходимости; путать "ClusterRole можно привязать через RoleBinding" с "ClusterRole всегда даёт права на весь кластер" — область действия определяется типом binding, а не только типом role.