RBAC в Kubernetes: настройка и проверка

Логотип Kubernetes

Быстрые ссылки

Включение RBAC в Kubernetes
Объекты RBAC в Kubernetes
Создание сервисного аккаунта
Добавление Role
Привязка ролей к пользователям и сервисным аккаунтам
Тестирование правила RBAC
Резюме

Что такое RBAC и зачем он нужен

Role-based access control (RBAC) — это механизм для определения действий, которые учётные записи могут выполнять в кластере Kubernetes. RBAC снижает риск при компрометации учётных данных и предотвращает эскалацию привилегий: каждому пользователю выдавайте минимум разрешений, необходимых для работы.

По умолчанию многие дистрибутивы Kubernetes стартуют с суперпользовательской учётной записи. Аутентификация под такой учётной записью даёт возможность совершать любые действия, но это повышает риск — компрометация такой учётной записи даёт полный контроль над кластером.

В этой статье мы покажем, как включить и настроить RBAC, чтобы чётко определить возможности разных пользователей. Часто часть пользователей должна лишь создавать и просматривать Pods, а администраторы — удалять и модифицировать ресурсы. RBAC позволяет задать такие политики и применять их централизованно.

Включение RBAC в Kubernetes

RBAC — опциональная функция Kubernetes, но большинство популярных дистрибутивов поставляются с ней по умолчанию, включая управляемые облачные сервисы. Проверить, включён ли RBAC в кластере, можно с помощью Kubectl:

$ kubectl api-versions | grep rbac.authorization.k8s

Ожидаемый вывод при включённом RBAC:

rbac.authorization.k8s.io/v1

Если команда не возвращает никакого вывода, RBAC отключён. В большинстве случаев его включают запуском kube-apiserver с флагом –authorization-mode=RBAC:

$ kube-apiserver --authorization-mode=RBAC

Если вы используете управляемый кластер (GKE, EKS, AKS и т. п.), настройка параметров запуска API-сервера может быть недоступна. Обратитесь к документации поставщика.

Важно: перед изменением конфигурации API-сервера сохраните текущие манифесты и протестируйте изменения в тестовом окружении.

Основные объекты RBAC в Kubernetes

Kubernetes RBAC включает четыре типа объектов:

Role — набор правил доступа внутри namespace. Определяет, какие действия разрешены над какими ресурсами.
RoleBinding — связывает Role с одним или несколькими субъектами (пользователями, группами, сервисными аккаунтами) внутри namespace.
ClusterRole — тот же набор правил доступа, но для кластера в целом или для ресурсов без namespace (например, Nodes, Namespaces).
ClusterRoleBinding — привязка ClusterRole к субъектам на уровне всего кластера.

Role и RoleBinding являются namespaced-объектами: они действуют только внутри конкретного namespace. ClusterRole/ClusterRoleBinding применяются к ресурсам уровня кластера.

Краткое определение терминов:

Субъект (subject) — пользователь, группа или сервисный аккаунт, которому назначаются права.
Verb — действие (get, list, watch, create, update, delete и т. д.).
Resource — тип ресурса Kubernetes (pods, deployments, configmaps и т. п.).

Создание сервисного аккаунта

Сервисный аккаунт — это «пользователь», управляемый Kubernetes API. Каждому сервисному аккаунту соответствует токен, который используется для аутентификации.

Поскольку обычных пользователей нельзя напрямую создавать через Kubernetes API (аутентификация реализуется внешними провайдерами), в примерах мы будем использовать сервисный аккаунт.

Создайте сервисный аккаунт командой:

$ kubectl create serviceaccount demo

Эта команда создаст аккаунт demo в текущем namespace (обычно default). Чтобы получить токен, сначала найдите секрет, где он хранится:

$ kubectl describe serviceaccount demo

Пример вывода (сокращённый):

Name:                demo
Namespace:           default
Mountable secrets:   demo-token-w543b
Tokens:              demo-token-w543b

Токен хранится в секрете demo-token-w543b. Извлечём значение токена в переменную окружения:

$ TOKEN=$(kubectl describe secret demo-token-w543b | grep token: | awk '{print $2}')

Добавьте новые учётные данные в kubectl и создайте контекст для сервисного аккаунта:

$ kubectl config set-credentials demo --token=$TOKEN

$ kubectl config set-context demo --cluster=default --user=demo

Замените значение –cluster на имя вашего активного подключения к кластеру. Текущее имя контекста можно проверить командой:

$ kubectl config current-context

Переключитесь на контекст demo, предварительно отметив имя своего текущего контекста, чтобы вернуться к нему позже:

$ kubectl config use-context demo

После переключения kubectl будет аутентифицироваться как сервисный аккаунт demo. Попробуйте получить список Pods:

$ kubectl get pods

Если у аккаунта нет роли, разрешающей просмотр Pods, вы увидите ошибку:

Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:demo" cannot list resource "pods" in API group "" in the namespace "default"

Это нормально: сейчас сервисный аккаунт не имеет прав.

Добавление Role

Role создают как обычный Kubernetes-объект. В Role указывают один или несколько правил, которые допускают конкретные операции над ресурсами.

Ниже — пример Role, разрешающей просмотр списка Pods и получение их описания:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: demo-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

Пояснение: verbs get и list для ресурса pods позволяют выполнять команды kubectl get pod и kubectl describe pod. Операции create и delete не включены — ими пользоваться будет запрещено.

Примените Role, вернувшись в контекст администратора:

$ kubectl config use-context default

$ kubectl apply -f role.yaml

Ожидаемый вывод:

role.rbac.authorization.k8s.io/demo-role created

Привязка ролей к пользователям и сервисным аккаунтам

Чтобы связать Role с сервисным аккаунтом demo, создайте RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: demo-role-binding
subjects:
- kind: ServiceAccount
  name: demo
  namespace: default
roleRef:
  kind: Role
  name: demo-role
  apiGroup: rbac.authorization.k8s.io

Важно: в subject для сервисного аккаунта указывайте namespace, где создан аккаунт. RoleBinding и Role должны существовать в одном namespace.

Примените binding:

$ kubectl apply -f role-binding.yaml

Ожидаемый вывод:

rolebinding.rbac.authorization.k8s.io/demo-role-binding created

Тестирование правила RBAC

Переключитесь обратно на контекст demo и выполните те же команды:

$ kubectl config use-context demo

$ kubectl get pods

Теперь команда должна выполниться корректно:

No resources found in default namespace.

Если вы попробуете создать Pod, операция всё ещё будет запрещена, так как у роли нет verb create:

$ kubectl run nginx --image=nginx

Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:demo" cannot create resource "pods" in API group "" in the namespace "default"

Чтобы разрешить создание Pod, добавьте verb create в Role и примените обновлённый манифест:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: demo-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create", "get", "list"]

Примените изменения:

$ kubectl apply -f role.yaml

Теперь у сервисного аккаунта будет право создавать Pods.

Практическая методика проектирования ролей

Мини-методология по проектированию RBAC для команды или проекта:

Соберите требования. Проанализируйте, какие команды и операции выполняют пользователи и автоматизированные системы.
Группируйте по обязанностям. Выделите шаблоны: просмотр ресурсов, управление workload-ами, администрирование сетей и т. д.
Создайте минимальные роли. Для каждого шаблона создайте Role/ClusterRole с наименьшим набором verbs.
Назначьте роли субъектам через RoleBinding/ClusterRoleBinding.
Тестируйте в тестовом namespace, используйте отдельные контексты kubectl.
Аудитируйте. Регулярно проверяйте, не появились ли лишние привилегии.
Документируйте. Фиксируйте назначенные роли и причины на уровне команды.

Чек-лист для внедрения RBAC

Определены функции и обязанности пользователей
Создано минимальное количество ролей для повторного использования
Используются ClusterRole только при необходимости
Все сервисные аккаунты имеют ограниченные права
Выполнено тестирование в отдельном контексте
Внедрён процесс аудита и удаления неиспользуемых ролей
Документация и карта ролей доступны команде

Критерии приёмки

Сервисный аккаунт может выполнять только те operations, что указаны в Role.
Попытка выполнить запрещённую операцию возвращает Forbidden.
Все роль/байндинги задокументированы и покрыты тестами.
Аудит ролей проходит автоматически или по расписанию.

Когда RBAC может не сработать (ограничения и исключения)

В управляемых кластерах часть настроек API-сервера недоступна — вы не сможете включать RBAC программно, если провайдер выключил эту возможность на своём уровне.
Если используются внешние механизмы аутентификации (OIDC, LDAP), корректная интеграция пользователей и групп обязательна — некорректно настроенные identity-мэппинги приведут к тому, что RoleBinding не найдёт субъект.
RBAC не контролирует поведение приложений внутри Pod (например, доступ к хранилищу или внешним API). Для этого нужны дополнительные механизмы (NetworkPolicy, Pod Security).

Альтернативы и дополнения к RBAC

ABAC (Attribute-Based Access Control) — устаревший и менее гибкий подход в Kubernetes, на практике встречается редко.
Webhook авторизация — позволяет интегрировать внешние сервисы для принятия решений об авторизации в реальном времени.
PodSecurity (раньше PodSecurityPolicy) — контролирует безопасность Pod на уровне спецификаций контейнеров.
NetworkPolicy и ограничение на уровне инфраструктуры — дополняют RBAC, закрывая доступ между компонентами.

Примеры тестов и сценариев проверки

Тестовые сценарии, которые стоит автоматизировать:

Попытка выполнить get/list для ресурса — должна пройти, если роль это разрешает.
Попытка выполнить create/update/delete — должна вернуть Forbidden, если verb отсутствует.
Привязка роли к ошибочному субъекту (неправильный namespace) — привязка не действует.
Переключение контекста kubectl на сервисный аккаунт — проверка, что токен действительно используется.

Пример автоматизированного теста (bash):

# переключаемся на demo-контекст
kubectl config use-context demo
# проверяем, что get pods успешен
kubectl get pods >/dev/null 2>&1 && echo "OK" || echo "GET_FAILED"
# проверяем, что create запрещён
if kubectl run nginx --image=nginx >/dev/null 2>&1; then
  echo "CREATE_ALLOWED"
else
  echo "CREATE_FORBIDDEN"
fi

Безопасное внедрение: шаги и роллбек

Подготовьте роли в тестовом namespace и тщательно тестируйте.
Примените роли и binding в staging перед production.
Перед массовым внедрением сохраните текущие манифесты API-сервера.
При ошибках откатите изменения, удалив или скорректировав Role/RoleBinding и переключившись на административный контекст.

Безопасность и лучшие практики

Принцип наименьших привилегий. Оформляйте роли с минимумом verbs.
Избегайте выдачи ClusterRoleBinding пользователям, если можно обойтись RoleBinding.
Используйте отдельные сервисные аккаунты для автоматизации и CI/CD-пайплайнов.
Регулярно ревизуйте роли и binding-ы: удаляйте неиспользуемые.
Логируйте события авторизации и используйте SIEM для анализа подозрительной активности.

Миграция и совместимость

При переходе с ABAC на RBAC убедитесь, что все существующие политики перенесены в Role/ClusterRole.
Тестируйте на копии кластера перед переносом в production.
Обратите внимание на изменения в поле apiGroup и namespacing при конвертации правил.

Краткий справочник: однострочные определения

Role — правила доступа в пределах namespace.
RoleBinding — привязывает Role к субъектам в namespace.
ClusterRole — правила доступа на уровне кластера.
ClusterRoleBinding — связывает ClusterRole с субъектами по всему кластеру.

Факт-бокс

Количество ключевых RBAC-объектов: 4 (Role, RoleBinding, ClusterRole, ClusterRoleBinding).
Чаще всего для обычных приложений достаточно Role/RoleBinding; ClusterRole применяйте только при необходимости.

Примеры распространённых ошибок и как их исправлять

Ошибка: RoleBinding создан в другом namespace. Исправление: перенесите RoleBinding в тот же namespace, где Role и сервисный аккаунт.
Ошибка: указан неверный apiGroup в roleRef. Исправление: используйте apiGroup: rbac.authorization.k8s.io для roleRef у Role/ClusterRole.
Ошибка: забыли указать namespace в subject для ServiceAccount. Исправление: добавьте поле namespace в subject.

Резюме

RBAC в Kubernetes даёт мощный и гибкий инструмент контроля доступа, позволяя минимизировать привилегии и снизить риски. Процесс внедрения включает включение RBAC (если требуется), проектирование ролей, создание Role/ClusterRole и соответствующих привязок, тестирование контекстов и регулярный аудит. Следуйте принципу наименьших привилегий, документируйте назначения и автоматизируйте тесты.

Важно: RBAC — не единственный уровень защиты. Дополняйте его сетевыми ограничениями, политиками безопасности Pod и мониторингом.

Краткие рекомендации для старта:

Начните с инвентаризации действий пользователей.
Создайте минимальные роли и тестируйте в отдельном namespace.
Автоматизируйте проверку Forbidden/Allowed для критичных операций.