Разграничение доступа в Proxmox для команды

MAATRIX

Кластер Proxmox завели один человек, но пользуются им уже пятеро: два разработчика перезапускают свои VM, админ занимается бэкапами, а джуниор иногда заходит «посмотреть, всё ли работает». Если у всех логин-пароль от одного root-аккаунта — это не временное неудобство, а вопрос времени, когда кто-то случайно удалит чужую VM или снесёт настройки хранилища. У Proxmox есть встроенная система прав, которая решает это без сторонних инструментов — нужно один раз разобраться, как она устроена, и потратить час на настройку.

Из чего состоит модель прав Proxmox

Система доступа Proxmox VE строится на четырёх независимых сущностях, и путаница обычно возникает именно потому, что их пытаются свести в одну.

Пользователи (Users) — учётные записи, которые заходят в веб-интерфейс или дёргают API. Пользователь всегда привязан к realm (области аутентификации): pve — локальная база самого Proxmox, pam — системные пользователи хоста, либо внешний realm через LDAP или Active Directory. Имя пользователя всегда пишется с суффиксом realm: ivan@pve, maria@ldap.

Группы (Groups) — простое объединение пользователей для массовой выдачи прав. Права можно назначать и напрямую пользователю, но на команде из трёх и более человек группы почти всегда удобнее — вы не выдаёте права каждому новому разработчику отдельно, а просто добавляете его в существующую группу.

Роли (Roles) — именованные наборы конкретных разрешений (privileges). Разрешение — это атомарное действие вида VM.PowerMgmt (запуск/остановка/перезагрузка), VM.Console (доступ к консоли), VM.Allocate (создание VM), VM.Config.Disk (изменение дисков), Datastore.Allocate (управление хранилищем), Sys.Modify (изменение настроек узла) и так далее — полный список выводится командой pveum right list. Proxmox поставляется с готовыми ролями (PVEAdmin, PVEVMAdmin, PVEVMUser, PVEAuditor и другие), но их набор жёстко зашит под усреднённый сценарий — в реальной команде почти всегда нужны свои роли под конкретные задачи.

Области действия (Paths) — к каким именно объектам применяется связка «пользователь/группа + роль». Путь может указывать на конкретный узел кластера (/nodes/pve2), конкретную VM (/vms/105), хранилище (/storage/local-zfs) или пул ресурсов (/pool/project-alpha). Одна и та же роль, назначенная на разные пути, даёт совершенно разный доступ.

Право в Proxmox — это всегда четвёрка: кто (пользователь/группа) получает какую роль (набор разрешений) на какой путь (объект). Именно эта связка называется ACL (Access Control List), и вся настройка доступа сводится к тому, чтобы собрать нужный набор таких четвёрок.

Почему всем-администратор — плохой старт

Самый частый сценарий на старте: завели Proxmox, создали по локальному пользователю на каждого члена команды, всем выдали роль Administrator (или добавили в группу с этой ролью) на путь / — то есть безусловный root-доступ ко всему кластеру. Работает мгновенно, никаких конфликтов прав, все всё видят и всё могут.

Проблема вскрывается не сразу, а когда:

• Разработчик, тестируя автоматизацию, случайно удаляет VM соседнего проекта — у него были на неё те же права, что и на свою.
• Нужно разобраться, кто выключил production-VM в 3 часа ночи — в логе /var/log/pve/tasks/ виден вызов от конкретного пользователя, но если у всех root, это ничего не объясняет: root мог сделать кто угодно.
• Увольняется человек — и вместо отзыва одной записи приходится вычищать пароль/ключ, которым, возможно, пользовались и другие («он же говорил всем свой пароль от общего аккаунта»).
• Нужно дать временный доступ подрядчику «только на одну VM» — а технически он либо ничего не может, либо может всё.

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

Создание кастомной роли: пример «разработчик проекта»

Разберём типичный запрос: разработчик должен иметь возможность перезапускать VM своего проекта, заходить в консоль и смотреть состояние — но не должен иметь права удалять VM, менять диски или трогать настройки хранилища и сети.

Через веб-интерфейс: Datacenter → Permissions → Roles → Create, указываете имя (например DevRestart) и отмечаете нужные privileges. Тот же результат через CLI:

pveum role add DevRestart -privs "VM.PowerMgmt,VM.Console,VM.Monitor,VM.Audit"

Разбор набора:

• VM.PowerMgmt — старт/стоп/ребут/сброс VM;
• VM.Console — доступ к noVNC/SPICE консоли;
• VM.Monitor — просмотр графиков нагрузки и статуса;
• VM.Audit — просмотр конфигурации VM (без права её менять).

Сознательно не включены VM.Allocate (создание/удаление), VM.Config.Disk, VM.Config.HWType, Datastore.Allocate — с этой ролью разработчик физически не может снести диск или прибить чужую VM, даже случайно.

Сравнение с готовыми ролями Proxmox — почему они обычно не подходят как есть:

Дальше создаём группу и назначаем роль на конкретный путь:

pveum group add dev-alpha -comment "Разработчики проекта Alpha"
pveum user add ivan@pve --groups dev-alpha
pveum acl modify /pool/project-alpha --group dev-alpha --role DevRestart

Обратите внимание: право назначено не на отдельные VM, а на пул ресурсов /pool/project-alpha — про пулы отдельно ниже.

Пулы ресурсов: права на проект, а не на список VM

Если в проекте пять VM и завтра появится шестая, назначать роль на каждую по отдельности — это лишняя ручная работа и источник ошибок (забыли добавить право на новую VM — разработчик написал в саппорт, почему не видит свой сервер). Resource Pool в Proxmox решает это: вы группируете VM/CT (и опционально хранилища) в один объект, а права выдаёте на пул целиком.

Создание пула и добавление в него VM:

pvesh create /pools --poolid project-alpha --comment "Проект Alpha"
pvesh set /pools/project-alpha -vms 101,102,103

Или через интерфейс: Datacenter → Permissions → Pools → Create, затем на вкладке пула — Add → VM/CT и выбор нужных машин. Когда VM 104 создаётся под этот же проект, её достаточно добавить в пул — право автоматически распространяется, ничего в ACL менять не нужно:

pvesh set /pools/project-alpha -vms 101,102,103,104

Практическая схема для команды из нескольких проектов — один пул на проект, одна группа на проект, права назначены один раз на связку пул-группа:

/pool/project-alpha  →  group dev-alpha    →  role DevRestart
/pool/project-beta   →  group dev-beta     →  role DevRestart
/pool/shared-infra   →  group devops       →  role PVEVMAdmin

Пулы также помогают с биллингом и отчётностью — на вкладке пула виден суммарный расход ресурсов (CPU, RAM, диск) по всем входящим в него VM, что удобно, если инфраструктуру делят между проектами с разными бюджетами.

Отдельно стоит право Pool.Audit (или соответствующее в составе роли) — оно даёт видеть сам факт существования пула и список входящих в него объектов, без чего пользователь может не увидеть свои VM в интерфейсе вообще, даже имея права на действия с ними.

Проверка и отладка прав

После настройки полезно убедиться, что права работают именно так, как задумано, а не подобрать это методом «попросил коллегу проверить».

Посмотреть все назначенные ACL:

pveum acl list

Вывод покажет путь, пользователя/группу, роль и флаг propagate (наследуются ли права на вложенные объекты — по умолчанию да). Проверить эффективные права конкретного пользователя:

pveum user permissions ivan@pve

Команда покажет итоговый набор разрешений с учётом всех групп и путей — это самый быстрый способ понять, почему пользователь видит (или не видит) что-то в интерфейсе, вместо того чтобы вручную складывать права из разных мест.

Частая грабля: права, назначенные на путь верхнего уровня (/ или /vms), перекрывают и расширяют то, что вы точечно ограничили ниже — если у пользователя где-то по группе есть Administrator на /, локальная узкая роль на пул ничего не даст, потому что действует объединение (OR) всех применимых прав, а не пересечение. Прежде чем разбираться, почему кастомная роль «не работает», проверьте pveum user permissions целиком, а не только запись про нужный пул.

Интеграция с LDAP/Active Directory для крупной команды

Пока в команде три-пять человек, локальные пользователи Proxmox (realm pve) — рабочий вариант. Когда счёт идёт на десятки, у локальных аккаунтов всплывает системная проблема: увольнение сотрудника означает поход в Proxmox (а если у вас несколько кластеров — в каждый) и ручное отключение или удаление его аккаунта. Если это забыли сделать — доступ остаётся действующим неограниченно долго.

Если в организации уже есть корпоративный LDAP или Active Directory, подключение Proxmox к нему как внешнего realm снимает эту проблему: единая точка правды об учётных записях, единая точка отзыва доступа (заблокировали пользователя в AD при увольнении — он не может зайти ни в Proxmox, ни в остальные интегрированные системы).

Добавление LDAP-realm через CLI:

pveum realm add company-ldap --type ldap \
  --server1 ldap.company.local \
  --port 389 \
  --base-dn "OU=Users,DC=company,DC=local" \
  --user-attr sAMAccountName \
  --bind-dn "CN=svc-proxmox,OU=ServiceAccounts,DC=company,DC=local" \
  --password 'пароль-сервисной-учётки'

Для Active Directory с шифрованием соединения добавьте --mode ldaps --port 636 (или --mode gssapi при настроенной интеграции с Kerberos) — открытый LDAP на 389 порту без TLS передаёт bind-пароль сервисной учётки в открытом виде, это стоит закрыть отдельно на уровне сети или сразу использовать ldaps.

После добавления realm пользователи из AD синхронизируются командой:

pveum realm sync company-ldap --enable-new 0

Флаг --enable-new 0 важен: он создаёт учётные записи Proxmox для найденных в AD пользователей, но не активирует их автоматически — активацию и назначение ролей вы делаете осознанно, а не получаете доступ «по умолчанию» для всех, кто есть в корпоративном каталоге. Дальше для новых пользователей ivan.petrov@company-ldap работает та же схема групп и ролей, что описана выше — realm меняет только источник аутентификации, модель прав внутри Proxmox остаётся той же.

Важный нюанс: группы Proxmox и группы AD — разные сущности, автоматического маппинга по умолчанию нет (кроме отдельно настраиваемой синхронизации групп в новых версиях PVE). Практичнее всего добавлять синхронизированных LDAP-пользователей в группы Proxmox вручную или скриптом при онбординге, а не полагаться на то, что членство в AD-группе само транслируется в права.

С чего начинать: маленькой команде тоже нужна схема с первого дня

Соблазн на старте — не тратить время на роли и пулы, потому что «нас всего трое, и так понятно, кто что делает». Это ровно тот момент, когда схему проще всего настроить правильно: пока VM пять, а не пятьдесят, и пользователей трое, а не двадцать. Разбирать задним числом, у кого какие права накопились за два года «выдал по-быстрому, потом разберёмся» — заметно дороже, чем один раз в начале описать роли и создать под них ACL. Те же принципы (доступ по ролям, а не по факту знакомства с администратором, точка отзыва при увольнении) справедливы для любой инфраструктуры, а не только для Proxmox — на общем уровне «сотрудник и продакшн» это разобрано в статье про оформление доступа сотрудников к продакшену; здесь мы разбирали именно механику встроенной ролевой системы гипервизора.

Минимальный чек-лист для старта даже на команде из 2-3 человек:

• Завести хотя бы одну кастомную роль под реальную задачу, а не выдавать Administrator всем.
• Сгруппировать VM в пулы по проектам с первого дня — переносить VM в пул задним числом дольше, чем сразу создать её внутри пула.
• Заводить пользователей группами, даже если группа пока состоит из одного человека — добавить второго станет тривиально.
• Проверять pveum user permissions <user> после любого изменения ACL, а не полагаться, что всё настроилось «как задумано».
• Если команда растёт быстрее, чем успеваете вручную отключать уволенных в локальной базе — переходить на LDAP/AD раньше, чем это станет проблемой безопасности.

Для дальнейшей настройки самой виртуализации пригодятся смежные материалы — про кластер Proxmox из двух узлов и про типы хранилищ в Proxmox, если права нужно развести ещё и по разным датасторам, а не только по VM.

Частые вопросы