RBAC (Role-Based Access Control) в Kubernetes даёт гибкий контроль доступа, но легко превращается в лабиринт Role, ClusterRole, RoleBinding и ServiceAccount. Разберём простые схемы, типичные ошибки и как держать права прозрачными.
Базовые понятия
Role – права в рамках одного namespace. ClusterRole – права на уровне кластера или переиспользуемая роль для нескольких namespace. RoleBinding связывает роль с пользователем или ServiceAccount. Для приложений внутри кластера используйте ServiceAccount – не личные учётки.
Частые ошибки
- Слишком широкие права – cluster-admin «на всякий случай». Лучше начинать с минимальных прав и расширять по мере необходимости.
- Забытый ServiceAccount – под запускается с default SA, у которого нет нужных прав. Создайте отдельный SA и укажите его в spec.serviceAccountName.
- RoleBinding в другом namespace – Role привязана к namespace A, а Binding создали в B. Проверяйте, что subject и role совпадают по контексту.
Практические схемы
Для dev-команды: Role с get/list/watch на Deployment, Pod, Service в своём namespace. Для CI/CD: ServiceAccount с правами на create/update в нужных namespace. Для мониторинга: ClusterRole с get/list на метрики и события. Платформы вроде Opsy AI помогают управлять RBAC через единый интерфейс и дают рекомендации по минимальным правам.
Вывод
RBAC не обязан быть сложным. Начните с чёткой схемы: кто что должен делать, создайте роли под эти сценарии, привяжите к ServiceAccount или пользователям. Регулярно ревьюйте права – со временем накапливается лишнее. См. также: что такое GitOps и Kubernetes без Helm.