Облако
Роли и права доступа к ресурсам кластера Managed Kubernetes
В Managed Kubernetes EdgeCloud каждому токену назначается роль, которая определяет, что он может делать с ресурсами кластера через Kubernetes API.
Система построена на стандартном механизме Kubernetes RBAC. В кластере предустановлены три роли — они создаются автоматически при развёртывании кластера и привязаны к группам пользователей через ClusterRoleBinding.
| Роль Managed Kubernetes | ClusterRole в K8s | Группа | Что может делать |
| mkaas admin | cluster-admin | Administrators | Всё без ограничений |
| mkaas editor | edit | Engineers | Создавать, изменять и удалять рабочие нагрузки |
| mkaas viewer | view | Users | Только просматривать ресурсы |
Как это работает технически: при создании API-ключа пользователь выбирает одну из групп (Administrators, Engineers, Users). Эта группа указывается в токене. Когда пользователь обращается к Kubernetes API, Webhook-авторизация проверяет группу и применяет соответствующую ClusterRole.
Как работает авторизация: ec-plugin и Webhook
Доступ к Kubernetes API в Managed Kubernetes EdgeCloud обеспечивается через ec-plugin — exec-плагин для kubectl, разработанный EdgeCloud и размещённый на GitHub. Для доступа к кластеру необходимо скачать и установить этот плагин.
Доступ реализован на основе Webhook-авторизации. Каждый раз, когда пользователь выполняет команду через kubectl, запускается ec-plugin, который формирует специальный токен на основе API-ключа и отправляет его в сервис авторизации EdgeCloud. Сервис авторизации проверяет роли пользователя в IAM и предоставляет или отказывает в доступе к кластеру.
Пошаговая цепочка при каждой команде:
- Пользователь вызывает kubectl (например, kubectl get pods).
- kubectl видит в kubeconfig блок users.user.exec и вызывает ec-plugin get-token.
- ec-plugin обращается к сервису авторизации EdgeCloud (IAM_BASE_URL) с API-ключом пользователя (API_KEY) и формирует токен в формате ExecCredential.
- kubectl передаёт полученный токен в заголовке запроса к Kubernetes API-серверу.
- API-сервер отправляет токен на Webhook-авторизацию, которая проверяет его в IAM и возвращает группу пользователя (Administrators, Engineers или Users).
- Kubernetes RBAC применяет ClusterRoleBinding для этой группы и определяет, разрешена ли запрошенная операция.
Kubeconfig — это конфигурационный файл, который скачивается из личного кабинета, является шаблоном. Он содержит адрес API-сервера кластера и настройки подключения, но не содержит API-ключ пользователя. Пользователь должен самостоятельно вставить свой API-ключ в поле API_KEY:
users:
- name: my-cluster-user
user:
exec:
apiVersion: client.authentication.k8s.io/v1beta1
command: ec-plugin
args:
- get-token
env:
- name: IAM_BASE_URL
value: "https://api.edgecenter.ru/iam"
- name: API_KEY
value: "<сюда вставить свой API-ключ>"
Каждый пользователь работает со своим личным API-ключом. Ключ определяет группу (Administrators, Engineers, Users), а группа определяет права в кластере. Пользователь обладает в кластере только теми правами, которые соответствуют его роли — ни больше, ни меньше.
Кэширование и логи. ec-plugin кеширует токен на диске (~/.kube/cache/exec_plugin) и автоматически обновляет его при истечении TTL. Повторные команды kubectl используют кеш без обращения к IAM. Логи самого плагина пишутся в директорию $XDG_CACHE_HOME/ec_plugin (обычно это ~/.cache/exec_plugin). При возникновении проблем с подключением эти логи необходимы для диагностики.
Блокировка учётной записи. API-ключ привязан к учётной записи пользователя в IAM EdgeCloud. Если учётная запись пользователя заблокирована со стороны IAM (деактивирована, удалена, приостановлена), его API-ключ автоматически перестаёт работать. Пользователь получит ошибку Unauthorized при попытке подключиться к любому кластеру, к которому у него был доступ. Отзыв (revoke) отдельного API-ключа работает аналогично — ключ блокируется, доступ прекращается.
Установка и настройка. Плагин ec-plugin разработан EdgeCloud и доступен на GitHub. Подробная инструкция по установке и подключению к кластеру приведена в статье Подключиться к кластеру Managed Kubernetes.
Какие роли действуют в сервисе
Ниже показаны все роли Managed Kubernetes EdgeCloud и как они наследуют разрешения друг друга. Например, mkaas admin включает все разрешения mkaas editor, а mkaas editor — все разрешения mkaas viewer.
Роли разделены на две группы:
Роли для Kubernetes API — определяют, что пользователь может делать внутри кластера через kubectl. Каждая вышестоящая роль включает все разрешения нижестоящей.
Роли EdgeCloud — определяют, что пользователь может делать в личном кабинете. Наследование работает аналогично: Владелец аккаунта включает все права Администратора проекта, и так далее.
Важно: для работы с кластером нужны обе роли одновременно. Роль EdgeCloud без роли MKaaS не даёт доступа к Kubernetes API. Роль MKaaS без роли EdgeCloud не позволяет увидеть кластер в личном кабинете.
Что может каждая роль
mkaas admin
Полный доступ. Нет ограничений ни по ресурсам, ни по операциям. Эквивалент встроенной роли Kubernetes cluster-admin.
Что доступно помимо editor:
- управление узлами (Nodes) и постоянными томами (PersistentVolumes);
- создание и редактирование ролей и привязок (RBAC);
- управление пространствами имён (Namespaces);
- доступ к системным URL: /healthz, /metrics, /logs.
Рекомендация: назначайте эту роль только тем, кому нужно администрировать сам кластер. Для повседневной работы с приложениями достаточно роли editor.
mkaas editor
Рабочая роль для инженеров и разработчиков. Позволяет полноценно работать с приложениями, но не даёт доступа к инфраструктуре кластера и RBAC.
Что может:
- создавать, изменять, удалять и масштабировать Deployments, StatefulSets, DaemonSets, ReplicaSets;
- управлять Pods, включая exec, attach, port-forward;
- работать с Services, Ingresses, NetworkPolicies;
- управлять ConfigMaps, Secrets, PVC;
- создавать и удалять CronJobs, Jobs, HPA, PodDisruptionBudgets;
- просматривать метрики, события, логи.
Чего не может:
управлять Nodes, PersistentVolumes (PVC управлять может), Namespaces;
создавать или изменять роли RBAC;
обращаться к системным URL (/healthz, /metrics).
mkaas viewer
Только чтение. Подходит для мониторинга и аудита — пользователь видит состояние ресурсов, но не может ничего менять.
Что может: просматривать (get, list, watch) Pods, Deployments, Services, Ingresses, ConfigMaps, PVC, HPA, CronJobs, Events, Namespaces, метрики.
Чего не может:
- создавать, изменять или удалять любые ресурсы;
- просматривать Secrets (в отличие от editor);
- выполнять exec, attach, port-forward в Pods;
- просматривать Nodes, PV, роли RBAC.
Связь с ролями EdgeCloud
Для работы с кластером нужны две роли одновременно: роль в платформе EdgeCloud (доступ к личному кабинету) и роль MKaaS (доступ к Kubernetes API). Это разные системы, они не заменяют друг друга.
| Роль EdgeCloud | Что даёт в ЛК | Рекомендуемая роль MKaaS | Что даёт в K8s API |
| Владелец аккаунта | Полный доступ ко всему | mkaas admin | cluster-admin |
| Администратор проекта | Полный доступ в проекте | mkaas admin | cluster-admin |
| Пользователь | Управление ресурсами | mkaas editor | edit |
| Наблюдатель | Только чтение | mkaas viewer | view |
Важно: у пользователя должна быть минимум роль Наблюдатель в EdgeCloud — без неё он не увидит кластер в личном кабинете и не сможет скачать kubeconfig. Роль EdgeCloud определяет, что можно делать в ЛК (создавать/удалять кластеры). Роль MKaaS определяет, что можно делать внутри кластера через kubectl.
Особенности и ограничения
Не изменяйте базовые роли. Роли cluster-admin, edit и view — системные. Их изменение может нарушить работу кластера. Если стандартных ролей недостаточно — создайте собственную роль.
Как назначить роль
Роль EdgeCloud (доступ к проекту)
- Откройте Управление доступом в личном кабинете EdgeCloud.
- Выберите проект.
- Нажмите Добавить пользователя, укажите email.
- Выберите роль (Администратор проекта / Пользователь / Наблюдатель).
- Подтвердите.
Роль MKaaS (доступ к Kubernetes API) — первое подключение
Когда пользователь впервые подключается к кластеру, он проходит следующий путь:
- Создать личный API-ключ. В личном кабинете EdgeCloud перейдите в Профиль → API-токены и создайте новый ключ. При создании выберите группу, определяющую вашу роль в кластере: Administrators (admin), Engineers (editor) или Users (viewer).
- Установить ec-plugin. Скачайте плагин с GitHub EdgeCloud и поместите в системный PATH. Проверьте установку: ec-plugin --help
- Скачать kubeconfig. В личном кабинете перейдите на страницу кластера и скачайте конфигурационный файл. Этот файл — шаблон: он содержит адрес API-сервера, но не содержит ваш ключ.
- Вставить свой API-ключ в kubeconfig. Откройте скачанный файл и найдите поле API_KEY в секции env. Замените значение-заглушку на свой реальный API-ключ:
env:
- name: IAM_BASE_URL
value: "https://api.edgecenter.ru/iam"
- name: API_KEY
value: "<вставьте сюда свой API-ключ>"
5. Разместить kubeconfig. Переименуйте файл в config (без расширения) и поместите в ~/.kube/config.
6. Проверить подключение:
kubectl get pods
kubectl auth whoami # покажет вашу группу и роль
После этого пользователь работает с кластером в рамках своей роли. Группа в API-ключе определяет, какие операции разрешены (см. раздел 2).
Каждый пользователь — свой ключ. Не используйте чужие API-ключи. Каждый участник команды должен создать свой собственный ключ с подходящей ролью. Это обеспечивает аудит действий и корректную блокировку при необходимости.
Блокировка учётной записи = блокировка доступа к кластеру. Если учётная запись пользователя заблокирована в IAM EdgeCloud (или отозван его API-ключ), доступ к кластеру через kubectl прекращается немедленно. Пользователь получит ошибку Unauthorized. Создать новый ключ заблокированный пользователь не сможет.
Группы Administrators, Engineers и Users привязаны к ClusterRoleBinding автоматически при создании кластера. Вручную настраивать RBAC не нужно.