Как спроектировать RBAC-модель для крупной организации с множеством команд и кластеров (multi-tenancy), и какие здесь компромиссы?

Короткий ответ

Единого правильного шаблона нет: модель обычно строится вокруг пространства имён на команду/продукт с переиспользуемыми ClusterRole и RoleBinding в каждом namespace, но конкретная степень изоляции (shared-кластер с namespace-мультиарендностью vs отдельные кластеры на команду) зависит от требований к безопасности, зрелости команд и готовности нести операционные издержки.

Как это работает подробнее

типовой подход — определить небольшой набор переиспользуемых ClusterRole ("viewer", "developer", "admin-namespace") с чётко описанными правами, затем привязывать их к конкретным группам пользователей через RoleBinding в namespace каждой команды, избегая создания уникальных ролей под каждую команду. Группы пользователей обычно синхронизируются из внешней IdP (через OIDC), а не управляются вручную внутри Kubernetes, чтобы избежать рассинхронизации при увольнениях/переходах сотрудников между командами.

• Компромисс. решение зависит от зрелости платформенной команды (способна ли она поддерживать десятки кластеров на одном уровне качества) и требований безопасности конкретных workload (например, PCI DSS или работа с особо чувствительными данными могут требовать физической изоляции кластера); разумный средний путь — несколько кластеров по уровню доверия/критичности (например, prod/non-prod отдельно), а не один кластер на каждую команду и не один кластер на всю организацию.

Пример кода

manifest.yamlКопировать

kind: ClusterRole
metadata: { name: namespace-developer }
rules:
  - apiGroups: ["apps", ""]
    resources: ["deployments", "services", "configmaps", "pods"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]

Что использовать на практике

• Практика. namespace-мультиарендность в общем кластере дешевле в эксплуатации и быстрее в развёртывании, но требует дисциплины в NetworkPolicy, ResourceQuota, Pod Security Admission и RBAC, чтобы одна команда не могла случайно или намеренно повлиять на другую; она также несёт риск "шумного соседа" и более широкий blast radius при компрометации control plane. Отдельные кластеры на команду/окружение дают более сильную изоляцию и меньший blast radius, но кратно увеличивают операционную нагрузку (patching, upgrade, мониторинг каждого кластера) и могут приводить к дублированию инфраструктуры.

Подводные камни

• Риски. частая ошибка — создавать уникальную Role под каждую команду вместо переиспользуемых ClusterRole, что приводит к разрастанию прав и усложняет аудит; также кандидаты иногда путают namespace-уровневый RoleBinding с ClusterRoleBinding (действующим на весь кластер) или забывают упомянуть синхронизацию групп доступа с внешним IdP.