Пользователи, роли и ACL в Proxmox VE: разграничение доступа

Модель авторизации Proxmox VE: пользователи, роли и пути

Доступ в Proxmox VE строится на трёх понятиях: пользователь, роль и путь. Пользователь — это учётная запись, роль — набор конкретных разрешений вроде «создать VM» или «просмотреть журнал», а путь — объект, к которому эта роль применяется: датацентр целиком, конкретный узел, пул ресурсов или одна виртуальная машина.

Связка «пользователь + роль + путь» называется ACL-записью. Пока для пользователя не создана ни одна такая запись, у него нет прав ни на что, даже если учётная запись существует и пароль верный. Это защищает от случайного расширения доступа новых сотрудников.

Источники аутентификации: pve, PAM, LDAP и AD

Proxmox VE поддерживает несколько источников проверки пароля. Realm pve хранит пользователей во внутренней базе кластера, PAM использует системных пользователей Linux на узле, а LDAP и Active Directory позволяют подключить корпоративный каталог и не заводить локальные пароли для каждого администратора.

Для большинства небольших команд достаточно realm pve: пользователи создаются прямо в веб-интерфейсе и не зависят от операционной системы узла. Для крупной инфраструктуры с десятками администраторов LDAP удобнее — отзыв доступа при увольнении сотрудника происходит в одном месте.

Как создать пользователя и назначить пароль

Пользователь создаётся в разделе Datacenter → Permissions → Users или командой в консоли узла.

pveum user add ivan@pve --password
pveum passwd ivan@pve

Сразу после создания у пользователя ivan@pve нет ни одного права. Следующий шаг — назначить ему роль на нужном пути, иначе вход в панель будет возможен, но список ресурсов останется пустым. Учётную запись стоит сразу защитить двухфакторной аутентификацией.

Встроенные роли и создание собственной роли

В Proxmox VE есть готовый набор ролей для типовых сценариев.

Если готовые роли не подходят, можно собрать свою из отдельных привилегий в разделе Datacenter → Permissions → Roles, например разрешить только «VM.Console» и «VM.Monitor» для службы поддержки первой линии.

Как назначить ACL на путь: датацентр, пул, VM

ACL назначается в разделе Datacenter → Permissions → Add. Указываются путь, пользователь или группа и роль.

• Путь / — права распространяются на весь кластер.
• Путь /pool/webteam — права только на ресурсы конкретного пула.
• Путь /vms/101 — права только на одну виртуальную машину.

Правило наследования простое: разрешение на верхнем уровне пути действует на все вложенные объекты, если на них явно не задано другое правило. Такой подход удобно сочетать с пулами ресурсов при создании виртуальных машин для разных клиентов или отделов.

API-токены для автоматизации без пароля

Для скриптов и внешних систем вместо пароля пользователя используют API-токен — отдельный секрет, привязанный к учётной записи, с собственным набором прав.

pveum user token add ivan@pve automation --privsep 1
pveum acl modify /vms/101 --tokens 'ivan@pve!automation' --roles PVEVMUser

Флаг --privsep 1 означает, что токен не наследует права пользователя автоматически, а получает только то, что явно назначено отдельной ACL-записью. Это снижает ущерб, если токен утечёт: он не даст доступ ко всему кластеру. Подробности работы с токенами через скрипты — в статье про REST API и автоматизацию.

Чек-лист безопасного разграничения доступа

• Каждому пользователю назначена ACL на конкретный путь, а не на весь кластер без необходимости.
• Используются готовые роли или собственная роль с минимальным набором прав.
• API-токены выданы с privsep 1 и отдельными правами.
• Учётные записи администраторов защищены двухфакторной аутентификацией.
• Список пользователей и ролей регулярно пересматривается при изменении команды.

Такая структура прав делает аудит доступа предсказуемым: видно, кто и на каком основании может управлять конкретной VM или пулом ресурсов.