RBAC: Roles и ClusterRoles

RBAC (Role-Based Access Control) в Kubernetes — механизм авторизации, управляющий тем, какие пользователи, группы и сервисные аккаунты могут выполнять какие API-операции над какими ресурсами Kubernetes в кластере. RBAC включён по умолчанию в современном Kubernetes и использует четыре основных объекта API в группе rbac.authorization.k8s.io: Role и ClusterRole определяют наборы разрешённых глаголов (get, list, watch, create, update, patch, delete) для типов ресурсов, а RoleBinding и ClusterRoleBinding предоставляют эти роли субъектам. Role и RoleBinding ограничены пространством имён и управляют доступом в рамках одного пространства имён, тогда как ClusterRole и ClusterRoleBinding имеют область кластера и могут предоставлять доступ к ресурсам без пространства имён: nodes, persistentvolumes и clusterroles. RBAC Kubernetes настраивается через kubectl create role, kubectl create clusterrole и kubectl create rolebinding и проверяется с помощью kubectl auth can-i <verb> <resource> --as <user>. Строго ограниченный RBAC — основа безопасности Kubernetes; дополняется политиками OPA Gatekeeper, Kyverno и проекцией токенов сервисных аккаунтов для минимизации радиуса поражения при компрометации учётных данных.

Как это работает

RBAC: Roles и ClusterRoles в Kubernetes слоится через несколько контролей: RBAC (кто может делать что на каких ресурсах), Network Policies (какие pods могут общаться с какими), Pod Security Standards (ограничения privileged-операций), admission controllers (валидируют/мутируют ресурсы до persistence), underlying container runtime sandbox. Defence-in-depth: предполагайте, что любой single control будет обойдён, и проектируйте несколько слоёв.

Когда применять

Внедряйте RBAC: Roles и ClusterRoles с создания кластера, не retrofit-ом позже — добавление RBAC в permissive кластер ломает десятки нагрузок. Начните с restrictive defaults и давайте доступ по нужде (least-privilege); применяйте NetworkPolicies в default-deny режиме; включайте PSS на уровне namespace. Регулируемые отрасли (банки, медицина) требуют это с дня 1; consumer-приложения выигрывают от этого до первого production-инцидента.

Типичные ошибки

Security-ловушки: cluster-admin role выдан разработчикам (полная власть; одна плохая команда сносит prod); image pull из ненадёжных registries без верификации подписи; serviceaccount tokens auto-mount в каждом pod (network access к API = lateral movement); пропуск CIS Kubernetes Benchmark-аудитов. Регулярный pentest находит реальные проблемы до того, как их найдут атакующие.

Связанные понятия

• Безопасность
• ServiceAccount
• Pod Security Standards
• OPA Gatekeeper