Користувачі, ролі і 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 або пулом ресурсів.