Kubernetes RBAC — включение и настройка

Логотип Kubernetes

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

Enabling RBAC in Kubernetes
Kubernetes RBAC Objects
Creating a Service Account
Adding a Role
Binding Roles to Users and Service Accounts
Testing Your RBAC Rule
Summary

Что такое RBAC в Kubernetes

RBAC — это механизм управления доступом, который определяет, какие действия могут выполнять пользователи и сервисные аккаунты в кластере. Ключевая идея: принцип наименьших привилегий — выдавайте только те права, которые действительно нужны.

Определения в одну строку:

Role: набор правил доступа в пределах пространства имён (namespace).
RoleBinding: связывает Role с субъектами (users, groups, serviceaccounts) в том же namespace.
ClusterRole: набор правил, применимый к ресурсам уровня кластера (например, Nodes, Namespaces) или для использования в любом namespace.
ClusterRoleBinding: связывает ClusterRole с субъектами на уровне всего кластера.

Important: большинство дистрибутивов Kubernetes поставляются с RBAC включённым. Если он выключен — включите флаг на kube-apiserver.

Enabling RBAC in Kubernetes

Проверьте, включён ли RBAC в вашем кластере командой:

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

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

rbac.authorization.k8s.io/v1

Если команда ничего не возвращает, RBAC не включён. Включается через параметр запуска API-сервера:

$ kube-apiserver --authorization-mode=RBAC

Примечание: в управляемых облаках (GKE, EKS, AKS и др.) RBAC обычно включён по умолчанию и управление параметрами запуска API-сервера может быть недоступно напрямую. Обратитесь к документации провайдера.

Kubernetes RBAC Objects

RBAC опирается на четыре основных типа объектов:

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

Ключевые различия:

Namespaced (Role/RoleBinding) ограничены отдельным namespace.
Cluster-scoped (ClusterRole/ClusterRoleBinding) применяются к ресурсам уровня кластера и могут применяться в любом namespace.

Принцип: используйте Role/RoleBinding для действия в пределах namespace; используйте ClusterRole/ClusterRoleBinding для глобальных полномочий или для шаблонов прав, которые повторно назначаются в разных пространствах имён.

Creating a Service Account

SerciceAccount — специальный вид пользователя, управляемый Kubernetes. Для практики мы создадим сервисный аккаунт и подключимся к кластеру под его токеном.

Создаём аккаунт:

$ kubectl create serviceaccount demo

Проверьте детали и найдите связанную секрект-токен:

$ kubectl describe serviceaccount demo

В выводе ищите поле “Tokens” или “Mountable secrets”. Имя секрета выглядит как demo-token-xxxxx.

Получение токена в shell (пример):

$ 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

Попробуйте выполнить команду, например, получить список Pod’ов:

$ kubectl get pods

Если вы получаете Forbidden — это означает, что у аккаунта нет роли, разрешающей доступ к ресурсам Pods.

Notes: в новых версиях Kubernetes токены сервисных аккаунтов могут быть проекциями (projected tokens) с TTL; также возможны механизмы External Token Review.

Adding a Role

Роли описываются обычным YAML-манифестом. Пример роли, разрешающей просмотр и перечисление Pod’ов в namespace default:

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

Пояснения к полям коротко:

apiGroups: список API-групп; пустая строка означает core API (pods, services и т.д.).
resources: ресурсы, к которым применимо правило.
verbs: действия: get, list, watch, create, update, patch, delete, deletecollection.

После написания роли примените её под админским контекстом:

$ kubectl config use-context default
$ kubectl apply -f role.yaml

Проверьте, что role создана:

$ kubectl get role demo-role -n default -o yaml

Совет: при добавлении новых прав учитывайте, что verbs должны включать только нужные операции — например, добавление create даст возможность создавать ресурсы.

Binding Roles to Users and Service Accounts

RoleBinding связывает Role с субъектами. Пример RoleBinding для сервисного аккаунта demo:

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

Ключевые правила:

subjects описывают того, кому назначается роль: ServiceAccount, User, Group.
roleRef указывает на Role или ClusterRole; при указании Role роль и binding должны находиться в одном namespace.

Применение:

$ kubectl apply -f role-binding.yaml

Проверка:

$ kubectl get rolebinding demo-role-binding -n default -o yaml

Binding ClusterRole для namespace-ограниченных сценариев

Если вы хотите дать права на чтение подов во всех namespace, используйте ClusterRole и назначьте ClusterRoleBinding:

Пример ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pods-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

ClusterRoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: demo-pods-reader-binding
subjects:
- kind: ServiceAccount
  name: demo
  namespace: default
roleRef:
  kind: ClusterRole
  name: pods-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRole позволяет охватывать сразу все namespace; будьте осторожны — это более широкие полномочия.

Testing Your RBAC Rule

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

$ kubectl config use-context demo
$ kubectl get pods

Ожидаемый результат при корректно назначенных правах:

No resources found in default namespace.

Если вы пробуете создать Pod и получаете Forbidden — это нормально, если роль не содержит create. Пример ошибки:

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

Добавьте 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

Методология проектирования RBAC (мини-метод)

Сбор требований: для каждой команды/сервиса опишите минимальные операции и ресурсы.
Группировка: объедините похожие требования в роли (по функциональности, не по пользователям).
Назначение: связывайте роли с субъектами через binding; предпочитайте serviceaccounts для машинных задач.
Проверка: тестируйте в изолированной среде и используйте sandbox-контексты для проверки прав.
Аудит и ревизия: регулярно проверяйте назначенные роли и убирайте лишние права.

Heuristic: 1 роль ≈ 1 набор действий в пределах ответственности (например, “viewing pods” или “deploying apps”).

Чек-лист: создание безопасной RBAC-конфигурации

Используется принцип наименьших привилегий.
Role/ClusterRole минимальны по набору verbs.
RoleBinding ограничены namespace, если нет необходимости в глобальном доступе.
Избегаете ClusterRoleBinding для human users без крайней нужды.
Токены сервисных аккаунтов не храните в публичных репозиториях.
Включён аудит (Audit Logs) для отслеживания изменений прав и запросов API.
Регулярный ревью ролей (например, ежеквартально).

Критерии приёмки для ролей

Роль разрешает только необходимые verbs для нужных ресурсов.
Binding назначен правильному субъекту (user/serviceaccount/group) и в правильном namespace.
Протестировано переключением контекста и выполнением всех ожидаемых операций.
Логи аудита показывают ожидаемые операции без неожиданных ошибок доступа.

Распространённые ошибки и способы устранения

Ошибка: “User … cannot list resource …” — причина: отсутствует подходящая RoleBinding. Решение: создайте Role/ClusterRole и привяжите.
Ошибка: RoleBinding не действует — причина: roleRef.apiGroup указано неверно или role находится в другом namespace. Решение: проверьте namespace и apiGroup.
Секрет с токеном не отображается — причина: возможно, используется projected token или Kubernetes версия с автоматической ротацией токенов. Решение: проверьте Secret типа “kubernetes.io/service-account-token” и механизм projected token.
Чрезмерные права — причина: использование ClusterRoleBinding для human users. Решение: замените на узкоограниченные роли и отдельные bindings.

Примеры использования (шаблоны и сниппеты)

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

role.yaml:

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

role-binding.yaml:

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

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

$ kubectl apply -f role.yaml
$ kubectl apply -f role-binding.yaml
$ kubectl config use-context demo
$ kubectl get pods

Decision tree: Role или ClusterRole (Mermaid)

flowchart TD
  A[Нужны права только в одном namespace?] -->|Да| B[Role + RoleBinding]
  A -->|Нет| C[Права на ресурсы уровня кластера или в нескольких namespace]
  C --> D[ClusterRole]
  D --> E[ClusterRoleBinding 'если нужен доступ всем' / RoleBinding с roleRef: ClusterRole 'если нужен доступ в конкретном namespace']
  B --> F[Создайте минимальные rules]

Security hardening и рекомендации

Минимизируйте использование ClusterRoleBinding для пользователей: давайте глобальные привилегии только сервисам или доверенным администраторам.
Ограничьте сервисные аккаунты по namespace и используйте отдельные аккаунты для разных приложений.
Включите аудит API-сервера (Audit Logs) для мониторинга вызовов и изменений RBAC-объектов.
Ротация и контроль секретов: используйте внешние хранилища секретов (HashiCorp Vault, AWS Secrets Manager) для долгоживущих токенов и учёта их ротации.
Политики NetworkPolicy и PodSecurityPolicy (или их замены) дополняют RBAC, но не заменяют его.
Отключите избыточные привилегии: особенно verbs [““] и resources: [““] в ClusterRole.

Тесты и приёмка (test cases / acceptance criteria)

Негативный тест: под аккаунтом без прав выполнить get pods — ожидаемо Forbidden.
Позитивный тест: после назначения RoleBinding выполнить get pods и получить список (или No resources found).
Проверка создания: если role содержит create, попытка создать Pod должна succeed; если нет — Forbidden.
Логирование: соответствующие операции должны быть видны в audit logs.

Модель зрелости RBAC (уровни)

Уровень 0 — нет RBAC, доступ по общему админ-учётному запису.
Уровень 1 — базовые роли и bindings для нескольких сервисов.
Уровень 2 — централизованный контроль ролей, аудит и регулярный ревью.
Уровень 3 — автоматизированное управление ролями, GitOps для RBAC-манифестов, интеграция с внешними системами управления секретами и SSO.

Edge-case gallery

Включённость внешней авторизации (WebHook) совместно с RBAC — убедитесь, что вы понимаете приоритеты authN/authZ.
Использование групп (groups) зависит от провайдера идентификации (OIDC, LDAP) — группы приходят в токене и должны соответствовать записям в subjects.
ServiceAccount токены с TTL: не используйте долгоживущие токены, если можно применять краткоживущие JWT с ротацией.

Privacy и соответствие требованиям (коротко)

RBAC помогает снизить риск утечки данных за счёт ограничения доступа. Для соответствия требованиям защиты данных (например, GDPR) следует:

Разграничивать права доступа к данным и журналам.
Ограничивать и контролировать доступ к секретам и логам.
Поддерживать журнал действий (audit) для расследования инцидентов.

Заключение

RBAC — ключевой компонент безопасности Kubernetes. Правильная модель ролей и bindings позволяет ограничить действие пользователей и сервисов и снизить риск злоупотребления правами. Планируйте роли заранее, применяйте принцип наименьших привилегий, включайте аудит и регулярно ревьюте назначения.

Important: выделяйте роли по функциям, тестируйте в отдельном контексте, ограничивайте ClusterRoleBinding и храните RBAC-манифесты в системе контроля версий.

Summary:

Включите RBAC, если он ещё не включён.
Создавайте роли минимальными и назначайте через bindings.
Используйте ClusterRole только там, где нужны глобальные права.
Тестируйте и ведите аудит.

Дополнительно: используйте предложенные шаблоны и чек-листы для быстрого старта и безопасной эксплуатации.