RBAC в Kubernetes — это механизм управления доступом, который отвечает на вопрос: кто, что и где может делать в кластере. Если настроить его по принципу минимальных привилегий, можно резко снизить риск случайных ошибок, утечек и эскалации прав.
Что такое RBAC в Kubernetes
- Role — набор разрешений в рамках одного namespace
- ClusterRole — набор разрешений на уровне всего кластера или для ресурсов без namespace
- RoleBinding — привязывает Role к пользователю, группе или ServiceAccount
- ClusterRoleBinding — привязывает ClusterRole на уровне всего кластера
Принцип минимальных привилегий
Суть простая: субъекту выдаются только те права, которые нужны для конкретной задачи, и ничего лишнего.
Например, если приложению нужно только читать ConfigMap, не стоит давать доступ к Secret, Pod или Deployment.
Типичные ошибки
- ❌ Выдача `cluster-admin` “на всякий случай”
- ❌ Использование `*` в `verbs`, `resources`, `apiGroups`
- ❌ Один ServiceAccount для разных приложений
- ❌ Доступ к Secret без реальной необходимости
- ❌ Широкие ClusterRole там, где хватит обычной Role
Как настроить безопасно
- Создавайте отдельный ServiceAccount для каждого приложения
- Ограничивайте доступ namespace-уровнем, если нет причины выходить на кластерный уровень
- Разрешайте только нужные verbs: `get`, `list`, `watch`, `create`, `update`, `patch`, `delete`
- Избегайте wildcard-прав
- Регулярно проверяйте, кто и какие права имеет
Пример Role с минимальными правами
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: app-prod
name: configmap-reader
rules:
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get", "list"]
Пример привязки
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-configmaps
namespace: app-prod
subjects:
- kind: ServiceAccount
name: app-sa
namespace: app-prod
roleRef:
kind: Role
name: configmap-reader
apiGroup: rbac.authorization.k8s.io
Как проверить права
Полезная команда для аудита доступа:
kubectl auth can-i get secrets --as=system:serviceaccount:app-prod:app-sa -n app-prod
Практические рекомендации
- 🛡️ Не давайте доступ к Secret, если нужен только ConfigMap
- 🛡️ Для CI/CD создавайте отдельные роли под деплой, а не полный админский доступ
- 🛡️ Используйте `ClusterRole` только когда действительно нужен доступ к ресурсам всего кластера
- 🛡️ Периодически пересматривайте RoleBinding и ClusterRoleBinding
- 🛡️ Документируйте, зачем выдано каждое право
Итог
RBAC в Kubernetes — не формальность, а базовый слой безопасности. Грамотная настройка минимальных привилегий помогает сократить поверхность атаки, упростить аудит и сделать кластер предсказуемее в эксплуатации. Чем уже права, тем ниже цена ошибки. ⚙️
За полезными материалами — загляните в подборку каналов про IT 📚