RBAC в Kubernetes: роли, привязки и минимальные права

Прямой ответ

RBAC (Role-Based Access Control) — механизм авторизации в Kubernetes. Он отвечает на вопрос «разрешено ли этому субъекту выполнить это действие с этим ресурсом». По умолчанию доступ запрещён: без явной привязки субъект не может сделать ничего.

Модель состоит из двух пар объектов:

Правило состоит из трёх частей: группа API, ресурсы и глаголы.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: billing
  name: deploy-runner
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "patch"]
  - apiGroups: [""]                       # пустая строка — core-группа
    resources: ["pods", "pods/log"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: billing
  name: ci-deploy
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: deploy-runner
subjects:
  - kind: ServiceAccount
    name: ci-runner
    namespace: billing

Глаголы: get, list, watch, create, update, patch, delete, deletecollection. Полезная деталь — ClusterRole можно привязать внутри одного namespace через RoleBinding: правила берутся из ClusterRole, а область действия ограничивается привязкой. Это позволяет описать набор прав один раз и выдавать его по namespace.

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

kubectl auth can-i patch deployments -n billing --as=system:serviceaccount:billing:ci-runner
kubectl auth can-i --list -n billing

Практика: минимальные права и типовые ошибки

1. Запрещено по умолчанию. Если действие не разрешено явно, оно отклоняется. Это упрощает аудит: достаточно перечислить разрешённое.

2. Различайте глаголы чтения и записи. list часто дают «на всякий случай», но список секретов — это уже утечка. Правило resources: ["secrets"], verbs: ["list"] выдаёт содержимое всех секретов namespace.

3. Защита от повышения привилегий. Пользователь может выдать права, только если сам ими обладает. Нельзя создать Role с доступом к секретам, не имея такого доступа.

4. ClusterRoleBinding — крайняя мера. Привязка cluster-admin сервисному аккаунту даёт полный контроль над кластером, включая чтение всех секретов. Такое решение требует обоснования.

5. Встроенные роли. view — чтение без секретов, edit — изменение ресурсов namespace, admin — плюс управление ролями внутри namespace, cluster-admin — всё.

6. Токены сервисных аккаунтов. Постоянные токены в секретах создаются только при явном указании аннотации; обычный механизм — проекция токена в под с ограниченным сроком жизни. Токен, найденный в скомпрометированном поде, действует ограниченное время.

7. Доступ к секретам — это доступ ко всему. Сервисный аккаунт с правом читать секреты может получить учётные данные облачного провайдера и выйти за пределы кластера.

8. Права на поды включают выполнение команд. Право pods/exec позволяет получить оболочку в любом поде namespace и использовать его сервисный аккаунт — см. статью про security context.

Рекомендации:

1. Выдавайте права на уровне namespace. Role и RoleBinding покрывают большинство задач; ClusterRoleBinding нужен редко.
2. Отдельный сервисный аккаунт на каждую задачу. Общий аккаунт «для CI» накапливает права и делает инциденты неконтролируемыми.
3. Проверяйте фактические права, а не манифесты. kubectl auth can-i --list показывает итоговую картину с учётом всех привязок.
4. Версионируйте роли в репозитории. Изменение прав через kubectl не оставляет следов и не проходит ревью.
5. Учитывайте агрегацию. ClusterRole может включать другие роли через метки, поэтому итоговые права не всегда видны из одного объекта.
6. Храните учётные данные вне секретов кластера там, где это возможно — см. статью про управление секретами.

Практический сценарий: пайплайн не мог обновить Deployment

Контекст: CI выполнял kubectl set image, получал ошибку deployments.apps "api" is forbidden, хотя сервисный аккаунт существовал.

1. Диагностика. kubectl auth can-i patch deployments -n billing --as=system:serviceaccount:billing:ci-runner вернул no. Значит, проблема в правах, а не в контексте kubeconfig.
2. Проверка привязок. kubectl get rolebinding -n billing показал привязку к роли view, то есть только чтение.
3. Причина. Роль выдали по шаблону «для CI», не уточнив, какие действия нужны. Дополнительно в Role отсутствовала группа apps, а deployments относятся именно к ней: правило с apiGroups: [""] не сработало бы.
4. Действия. (а) Создали роль deploy-runner с глаголами get, list, patch для deployments в группе apps и get, list для pods/log; (б) привязали её к ci-runner через RoleBinding в namespace billing; (в) явно отказались от доступа к секретам и pods/exec; (г) добавили проверку kubectl auth can-i в пайплайн перед деплоем, чтобы ошибка прав обнаруживалась до попытки изменения; (д) завели отдельный сервисный аккаунт для задачи отката с правом только на patch.
5. Результат. Деплой прошёл; права ограничены четырьмя глаголами вместо полного доступа, а проверка в пайплайне исключила повторение ситуации.

Вывод: ошибка прав в Kubernetes почти всегда объясняется отсутствием привязки либо неверной группой API. Проверка через auth can-i снимает догадки, а минимальный набор глаголов сокращает последствия компрометации.

FAQ

Как узнать, какие права у сервисного аккаунта? kubectl auth can-i --list --as=system:serviceaccount:<namespace>:<имя> -n <namespace>. Команда выводит итоговый перечень разрешённых действий с учётом всех привязок.

Можно ли запретить действие явно? Нет. RBAC работает по принципу «разрешено только то, что указано»; механизма запрета нет. Чтобы отменить доступ, удаляют привязку.

Чем Role отличается от ClusterRole по содержимому? Структура правил одинакова. Разница в области: Role существует внутри namespace, ClusterRole — в масштабе кластера и может описывать ресурсы, не привязанные к namespace, например узлы.

Нужны ли права на чтение секретов для обычного приложения? Обычно нет: секрет монтируется в под автоматически, и приложению не нужен API-доступ. Право get secrets требуется только контроллерам, которые управляют секретами.

Источники: Kubernetes docs (RBAC, authorization, service accounts) — ссылки в шапке.