Proxmox: «Permission Denied» у Datacenter — ролі й ACL налаштовано правильно

Повідомлення «Permission denied» у вигляді Datacenter Proxmox виглядає як дрібна незручність — поки воно не перекриє резервні копії, не зламає автоматизацію і не перетворить нічне чергування на інтерпретативний танець зі шляхами ACL.

Це не містична помилка. Права в Proxmox детерміновані. Біль виникає через людей: хибні припущення про спадкування ACL, плутанина між шляхами Datacenter vs node vs VM та визначення ролей, які ростуть як цвіль у підвалі.

Модель прав, яка насправді працює

Права Proxmox не складні. Вони просто багаторівневі. Якщо не відрізняти рівні, ви «полагодите» доступ, прикріпивши Administrator користувачу на / і вважатимете проблему вирішеною. Це працює так само, як можна вирішити текучий кран, відключивши воду всього міста.

Ось модель, яка вам потрібна:

• Ідентичність: користувач, група або API-токен. Зберігається в realm (PAM, PVE, LDAP/AD, OpenID тощо).
• Роль: іменований пакет привілеїв (наприклад, PVEVMAdmin, PVEAuditor).
• ACL: зв’язує identity → role на певному шляху, за потреби з propagation.
• Шлях: дерево ресурсів: /, /dc, /nodes/pve01, /vms/101, /storage/nvme-ssd, /pool/Dev тощо.
• Ефективні привілеї: Proxmox обчислює, що ви можете робити під час звернення, на основі всіх відповідних ACL.

«Permission denied у Datacenter» зазвичай означає: користувач може автентифікуватись, але не має одного чи кількох привілеїв, потрібних для відображення або операцій у масштабі /dc (або GUI звертався до API саме за цим шляхом).

Дві операційні істини:

1. Більшість сторінок GUI роблять кілька запитів. Ви можете мати дозвіл на перегляд VM, але бічна панель запитує кластерні ресурси, статус сховищ або метрики нод. Один заборонений виклик може зламати весь вигляд.
2. Шлях — це контракт. Якщо ACL на /nodes/pve01, а ви дивитесь щось під /dc, не чекайте дива.

Жарт №1: Дати всім Administrator на / — як вирішити черги звернень, вимкнувши телефон служби підтримки. Тиша буде, але і катастрофа теж.

Цікавинки й історичний контекст (те, що важливо)

Це не для вікторин. Пояснює, чому права Proxmox так виглядають і чому певні режими відмов повторюються.

1. Система прав Proxmox сильно впливалася unix-підходом: ідентичності й групи мапуються на дерево ресурсів. Тому шляхи відчуваються «як файлові системи».
2. Стандартні ролі кодують операційний намір: PVEVMAdmin — не «адмін усього», а «адмін віртуальних машин», і навмисно не надає всього на рівні Datacenter.
3. Конфігурація кластера розподілена: в кластері дані про права діляться через кластерну файлову систему. Нода, яка від’єднана, може показувати застарілі ACL і плутати діагностику.
4. Історично UI інфраструктурних продуктів часто робили over-fetch: ранні SPA-консолі адміністратора широко опитували ендпоінти для заповнення дашбордів. Поведінка GUI Proxmox у певній мірі успадкувала цю модель.
5. Дрібнозернисті права на сховище — відносно сучасне очікування: старі стеки віртуалізації вважали «адмін сховища = адмін гіпервізора». У Proxmox об’єкти сховища мають свої шляхи ACL — це добре, поки ви про це не забули.
6. API-токени відповідають на виклики автоматизації: довгоживучі паролі в скриптах — оперативний борг. Токени краще, але їх слід правильно скопати.
7. Принцип найменших привілеїв став мейнстримом через інциденти: розростання привілеїв — не естетична проблема; це множник інцидентів.
8. RBAC Proxmox розрахований на змішані команди: адміністратори віртуалізації, фахівці зі сховищ, аудитори і команди застосунків можуть співіснувати — якщо ви припините робити всіх «Administrator».
9. Propagation — класична пастка: успадковані дозволи зручні, але саме так «тимчасовий доступ» стає «вічним доступом».

Як Proxmox оцінює ролі і ACL (і чому ваш GUI мовчить про правду)

Ролі — це набори привілеїв

Роль — це іменований список привілеїв. Привілеї — атомарні одиниці, як-от VM.Audit, VM.PowerMgmt, Datastore.Allocate, Sys.Audit тощо.

Ключове: ви не надаєте привілеї безпосередньо користувачу. Ви надаєте роль через ACL. Роль — це «пакет», ACL — це «де», а користувач/група/токен — це «хто».

Шляхи ACL — це дерево ресурсів, а не рекомендація

Думайте в явних областях:

• /: усе, корінь усіх шляхів.
• /dc: об’єкти Datacenter (кластер, дозволи, пули, інвентар сховищ тощо).
• /nodes/<node>: об’єкти конкретної ноди (завдання, сервіси, syslog, локальне сховище на ноді).
• /vms/<vmid>: об’єкти конкретної VM/CT.
• /storage/<storageid>: права на об’єкт сховища.
• /pool/<poolname>: контроль доступу на основі пулів, корисний для делегування груп VM.

Повідомлення «permission denied» у вигляді Datacenter часто з’являється, коли ви надали користувачу права VM на /vms/101, але не надали можливості побачити певні об’єкти Datacenter, які GUI опитує. Ви отримуєте частковий доступ, що виглядає як зламаний доступ.

Propagation контролює спадкування вниз по дереву

ACL може мати propagation (застосовуватися до підшляхів) або ні. Propagation потужна. Це також спосіб випадково надати доступ до всіх VM, коли ви мали на увазі «тільки цей пул».

Операційна порада: вмикайте propagation тільки коли шлях вже є вузьким (наприклад, /pool/Dev) або коли це дійсно навмисно (наприклад, /vms для операторів VM). Уникайте propagation на /, якщо ви не створюєте суперкористувача свідомо.

Кілька ACL комбінуються

Користувач може бути членом груп, і групи можуть мати ACL. Користувач також може мати прямі ACL. Proxmox обчислює об’єднання привілеїв від всіх відповідних ACL.

Ось чому «видалити користувача з групи адміністраторів» іноді не допомагає: у них досі є прямий ACL десь, який ви забули.

GUI — клієнт, а не оракул істини

Proxmox UI відмінний, але це все ще веб-клієнт, що викликає API. Коли щось заборонено, він може показати узагальнене повідомлення. Ваша задача — знайти, який API-виклик був відхилений і якого привілею бракує.

У сумнівних випадках ставтеся до GUI як до генератора симптомів і використовуйте CLI для інспекції ACL та ролей.

Цитата (парафразована ідея): Gene Kranz підкреслював, що надійність приходить від дисципліни й чітких меж відповідальності, а не від героїзму.

Швидкий план діагностики

Це послідовність «не ускладнюй». Робіть у порядку. Зазвичай вона підкаже точну відсутню частину.

Перший крок: підтвердьте ідентичність і realm

• Користувач входить як user@pve чи user@pam чи user@ldap?
• Чи надали ви ACL не тому identity в realm (поширена помилка з AD/LDAP, де імена користувачів накладаються)?

Другий крок: перелічіть ACL, що застосовуються

• Перевірте прямі ACL користувача.
• Перевірте членство в групах і ACL груп.
• Перевірте, чи ввімкнено propagation і чи шлях ACL відповідає тій області, де виникає помилка.

Третій крок: перегляньте визначення ролі

• Чи містить роль фактично те привілеї, які ви вважаєте?
• Чи хтось «оптимізував» роль, прибравши «непотрібні» привілеї і зламав GUI?

Четвертий крок: відтворіть через API і знайдіть заборонений ендпоінт

• Спробуйте ту саму дію з pvesh від імені привілейованого користувача і порівняйте.
• Перегляньте журнали завдань і повідомлення про відмову з контекстом.

П’ятий крок: перевірте консистентність кластера, якщо поведінка відрізняється між нодами

• Якщо одна нода дозволяє, а інша відмовляє, можлива проблема з кластерною файловою системою або частково приєднаною нодою.

Шостий крок: лише потім змінюйте ACL

Не метушіться. Зробіть одну зміну, протестуйте, при потребі відкотіть. Зміни прав — це зміни в продакшені.

Практичні завдання: команди, вихідні дані, рішення (12+)

Усі завдання передбачають, що ви працюєте на ноді Proxmox як root або адміністратор. Команди реальні. Вихідні дані репрезентативні. Рішення — що робити далі.

Завдання 1: підтвердити ідентичність користувача (realm має значення)

cr0x@server:~$ pveum user list
USERID               ENABLED  EXPIRE
root@pam             1
alice@pve            1
alice@ldap           1
svc-terraform@pve     1

Що означає вивід: Є два користувача «alice» в різних realm. ACL прив’язуються до повного ID, включно з realm.

Рішення: Перевірте, хто саме входить. Якщо скарга від AD-логіну, необхідно надати alice@ldap, а не alice@pve.

Завдання 2: перелічити членство в групах (приховані привілеї живуть тут)

cr0x@server:~$ pveum user get alice@ldap
┌─────────┬───────────────────────────────┐
│ key     │ value                         │
╞═════════╪═══════════════════════════════╡
│ userid  │ alice@ldap                    │
├─────────┼───────────────────────────────┤
│ enable  │ 1                             │
├─────────┼───────────────────────────────┤
│ groups  │ DevOps,VM-Operators           │
└─────────┴───────────────────────────────┘

Що це означає: Alice успадковує ACL від DevOps і VM-Operators.

Рішення: Аудитуйте ACL цих груп перед змінами. Найшвидше виправлення часто — відсутній ACL на групі, а не додавання індивідуального ACL для користувача.

Завдання 3: вивантажити ACL і знайти користувача або групу

cr0x@server:~$ pveum acl list | egrep -i 'alice@ldap|DevOps|VM-Operators'
/pool/Dev -group VM-Operators -role PVEVMAdmin
/dc -group DevOps -role PVEAuditor

Що це означає: Оператори VM мають права VM admin в пулі Dev. DevOps має аудит на рівні datacenter.

Рішення: Якщо Alice не може відкрити Datacenter, бо GUI потребує більше ніж PVEAuditor, розширте роль аудитора обережно або додайте вузький ACL для відсутнього привілею.

Завдання 4: перевірити вміст ролі (не довіряйте припущенням)

cr0x@server:~$ pveum role show PVEAuditor
┌──────────────┬──────────────────────────────────────────────┐
│ key          │ value                                        │
╞══════════════╪══════════════════════════════════════════════╡
│ roleid       │ PVEAuditor                                   │
├──────────────┼──────────────────────────────────────────────┤
│ privileges   │ Datastore.Audit Group.Audit Mapping.Audit     │
│              │ Permissions.Modify Pool.Audit Realm.Allocate  │
│              │ SDN.Audit Sys.Audit VM.Audit                  │
└──────────────┴──────────────────────────────────────────────┘

Що це означає: Роль переважно для читання, але зверніть увагу, що в цьому прикладі вона включає Permissions.Modify (деякі середовища змінюють роль; за замовчуванням може бути інакше).

Рішення: Якщо ваш аудитор може змінювати права, ви створили мовчазний шлях ескалації привілеїв. Виправте визначення ролі відповідно до наміру.

Завдання 5: перелічити всі ролі й знайти відсутні привілеї

cr0x@server:~$ pveum role list
RoleID          Privileges
Administrator   *
NoAccess
PVEAdmin        Datastore.Allocate Datastore.AllocateSpace ...
PVEAuditor      Datastore.Audit Sys.Audit VM.Audit ...
PVEVMAdmin      VM.Allocate VM.Audit VM.Config.Disk VM.Config.CPU ...
PVEVMUser       VM.Audit VM.Console VM.Monitor VM.PowerMgmt

Що це означає: Ролі — це пакети; Administrator — wildcard.

Рішення: Якщо вас тягне надати Administrator, зупиніться. Визначте мінімальну роль і застосуйте її на правильному шляху.

Завдання 6: перевірити, чи користувач може перерахувати ресурси Datacenter через API (як адміністратор)

cr0x@server:~$ pvesh get /access/users --output-format=json-pretty | head
[
  {
    "comment": "",
    "email": "",
    "enable": 1,
    "expire": 0,
    "firstname": "",
    "groups": "DevOps;VM-Operators",
    "lastname": "",
    "userid": "alice@ldap"
  },
  ...

Що це означає: Як адміністратор, ви можете отримати інформацію про користувача. Це підтверджує, що API-ендпоінт існує й працює.

Рішення: Якщо користувач не може завантажити Datacenter, визначте, до якого ендпоінта йому відмовлено. Використовуйте інструменти розробника в браузері або відтворіть ймовірні виклики (див. наступні завдання).

Завдання 7: швидко перевірити, чи проблема в «не бачить ноди»

cr0x@server:~$ pvesh get /nodes
[
  {
    "cpu": 0.03,
    "maxcpu": 16,
    "maxmem": 68719476736,
    "mem": 12461883392,
    "node": "pve01",
    "status": "online",
    "uptime": 223948
  },
  {
    "cpu": 0.05,
    "maxcpu": 16,
    "maxmem": 68719476736,
    "mem": 18372743168,
    "node": "pve02",
    "status": "online",
    "uptime": 221402
  }
]

Що це означає: Ноди існують і доступні для адміністратора. Непривілейований користувач може отримувати відмову, якщо йому бракує Sys.Audit або еквівалентних привілеїв на /nodes або /.

Рішення: Якщо бокова панель Datacenter не працює, забезпечте користувачу принаймні права аудиту на /nodes або /dc, залежно від потрібної видимості.

Завдання 8: переглянути інвентар сховищ; відсутні ACL на сховищі спричиняють несподівані відмови

cr0x@server:~$ pvesh get /storage
[
  {
    "content": "images,rootdir,iso,vztmpl,backup",
    "enabled": 1,
    "shared": 1,
    "storage": "ceph-hdd"
  },
  {
    "content": "images,rootdir,backup",
    "enabled": 1,
    "shared": 0,
    "storage": "local-lvm"
  }
]

Що це означає: Об’єкти сховища існують; панелі GUI часто опитують їх.

Рішення: Якщо користувач може керувати VM, але не може приєднувати диски або переглядати ISO/backup, додайте ACL на /storage/<id> з роллю, яка містить потрібні привілеї datastore.

Завдання 9: показати поточні ACL у зручному вигляді (повний дамп)

cr0x@server:~$ pveum acl list
/dc -group DevOps -role PVEAuditor
/pool/Dev -group VM-Operators -role PVEVMAdmin
/storage/ceph-hdd -group VM-Operators -role PVEDatastoreUser

Що це означає: Права скупі й зрозумілі. Добрий знак.

Рішення: Якщо користувач скаржиться на відмову у вигляді Datacenter, перевірте, чи роль на /dc містить достатньо прав для тих розділів GUI, які йому потрібні.

Завдання 10: додати вузько спрямований ACL (приклад: дозволити лише моніторинг)

cr0x@server:~$ pveum acl modify /nodes -group VM-Operators -role PVEAuditor

cr0x@server:~$ pveum acl list | grep '/nodes'
/nodes -group VM-Operators -role PVEAuditor

Що це означає: Оператори VM можуть переглядати статус нод без прав адміністратора ноди.

Рішення: Якщо це виправляє видимість Datacenter, залиште. Якщо це відкриває більше, ніж потрібно, звузьте до /nodes/pve01 або натомість надайте лише /dc audit права плюс конкретні ендпоінти (складніше в управлінні).

Завдання 11: перевірити використання пулів; ACL на пулах — найчистіший механізм делегування

cr0x@server:~$ pvesh get /pools
[
  {
    "poolid": "Dev"
  },
  {
    "poolid": "Prod"
  }
]

Що це означає: Пули існують.

Рішення: Помістіть VM/CT команд у пули та призначайте ролі на /pool/<pool> з propagation. Це краще, ніж ставити ACL на кожну VM для порядку.

Завдання 12: підтвердити, що VM у очікуваному пулі (або ні)

cr0x@server:~$ pvesh get /pools/Dev --output-format=json-pretty | head -n 30
{
  "members": [
    {
      "id": "qemu/101",
      "node": "pve01",
      "type": "qemu",
      "vmid": 101
    },
    {
      "id": "lxc/120",
      "node": "pve02",
      "type": "lxc",
      "vmid": 120
    }
  ],
  "poolid": "Dev"
}

Що це означає: VM 101 у пулі Dev, тому застосовуються ACL /pool/Dev.

Рішення: Якщо користувач не може керувати «своєю» VM, спочатку перевірте, чи VM у правильному пулі, перед тим як редагувати ACL.

Завдання 13: виявити дрейф ролей (навіть благі наміри гублять)

cr0x@server:~$ pveum role show VMOperatorCustom
roleid: VMOperatorCustom
privileges: VM.Audit VM.Console VM.PowerMgmt VM.Snapshot

Що це означає: Користувацька роль не містить VM.Config.Disk і Datastore.AllocateSpace, тож операції з дисками можуть зазнати відмови.

Рішення: Вирішіть, чи оператори VM повинні керувати дисками. Якщо так — оновіть роль; якщо ні — задокументуйте обмеження і забезпечте шлях запиту змін для сховища.

Завдання 14: перевірити API-токени (вони часто переживають людей, що їх створили)

cr0x@server:~$ pveum user token list svc-terraform@pve
tokenid       expire  privsep
tf-ci         0       1
tf-prod       0       1

Що це означає: Токени існують і використовують privilege separation (privsep=1), що добре. Це означає, що привілеї токена відокремлені від прав користувача.

Рішення: Переконайтесь, що кожен токен має явні ACL на мінімальних шляхах, які йому потрібні. Не покладайтеся на широкі права користувача.

Завдання 15: перевірити здоров’я кластера, коли права поводяться непослідовно між нодами

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             corp-pve
Config Version:   27
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Dec 26 12:40:11 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          Yes

Що це означає: Кластер кворумний; конфіг (включно з правами) має бути консистентним.

Рішення: Якщо кластер у кворумі й все ще бачите різну поведінку, підозрюйте кешування в браузері, різні шляхи автентифікації realm або локальні проблеми на ноді, як-то зсув часу, що впливає на токени.

Проєктування ролей: що створювати, що забороняти і що тримати нудним

Дизайн RBAC — це місце, де Proxmox-майданчики або стають чистими, або — населені привидами. Мета не досконалість. Мета — передбачувані права, які ви зможете пояснити о 03:00.

Принцип 1: віддавайте перевагу груповим ACL перед індивідуальними

Індивідуальні ACL ростуть як чутка: швидко, брудно і важко відкликати. Використовуйте групи для людей. Токени для автоматизації. Прямі ACL для користувачів — лише для break-glass або тимчасового доступу з реально дотримуваним терміном закінчення.

Принцип 2: використовуйте пули для делегування

Якщо ви не використовуєте пули, ви робите ACL складніше. Пули дають стабільну ручку для «команда володіє цими VM/CT». Надавайте ролі на /pool/TeamX з propagation. Переміщуйте робочі навантаження між пулами при зміні власника. Це чистий шов делегації.

Принцип 3: відділяйте «може управляти VM» від «може змінювати інфраструктуру»

Оператори VM повинні мати можливість:

• вмикати/вимикати/перезавантажувати
• доступ до консолі
• перегляд конфігурації й метрик
• робити снапшоти (можливо)

Зазвичай їм не слід дозволяти:

• додавати нові бекенди сховищ
• редагувати кластерну мережу
• змінювати дозволи
• керувати нодами/сервісами

Звучить очевидно, поки ви не помітите, як часто люди дають привілеї ноди, лише щоб зупинити помилку у GUI.

Принцип 4: створюйте невелику кількість кастомних ролей і ставтесь до них як до коду

Стандартні ролі існують не дарма. Кастомні ролі — ок, але кожна повинна мати:

• одне-речення призначення («оператор VM з правом приєднувати диски в Dev лише»)
• чітко визначений шлях, де вона дозволена
• власника (команду), що відповідає за рев’ю раз на квартал

Принцип 5: не «вирішуйте» Permission denied розширенням області

Якщо користувач отримує відмову в Datacenter, виправлення рідко — «Administrator на /dc». Зазвичай це одне з:

• неправильна ідентичність realm
• ACL на неправильному шляху
• роль не містить одного привілею, потрібного GUI
• пул призначено неправильно
• відсутній ACL на сховищі

Жарт №2: Найшвидший спосіб закрити RBAC-запит — видалити RBAC. Команди безпеки називають це «кар’єрним розвитком».

Три корпоративні міні-історії з передової

Міні-історія 1: інцидент через хибне припущення

У них був акуратний кластер Proxmox для внутрішніх сервісів: CI-ранери, кеші збірки, кілька «тимчасових» середовищ, що стали постійними. Платформний інженер створив групу «VM Admin» і застосував PVEVMAdmin на /vms, припустивши, що цього вистачить для щоденних операцій.

Потім розробник подав тікет: «Datacenter view зламано, permission denied». Інженер відкрив GUI під акаунтом розробника і побачив помилку. Негайне припущення було, що роль неправильна, тож вони ескалували: додали PVEAdmin на /dc для групи. Помилка зникла. Тікет закрито. Всі щасливі.

Через тиждень резервні копії почали падати — не через те, що їх не можна було виконати, а тому, що хтось «допоміг» і під час відлагодження відредагував конфігурацію сховища бекапів. У них був доступ, бо PVEAdmin на /dc включає широкі права на datacenter. Конфіг виявився достатньо валідним, щоби зберегтися, але неправильним для відновлення. Помилка проявилась під час тесту відновлення.

Корінна причина не була зловмисною. Це було неправильне припущення: що Datacenter view вимагає прав адміністратора datacenter. Насправді потрібно було надати видимість аудиту для нод і сховищ, які GUI запитував. Правильним рішенням було б вузьке: надати PVEAuditor на /nodes і роль користувача datastore на конкретних шляхах сховища, або налаштувати кастомну роль з лише тими аудит-привілеями, що потрібні.

Відновлення було нудним: видалити широкий ACL, додати точні, і задокументувати «помилки GUI — це помилки ендпоінтів API, а не завжди проблеми ролей». Це негайно зменшило радіус ураження.

Міні-історія 2: оптимізація, що відбилася боком

Велика корпоративна команда вирішила, що в них «занадто багато ролей». Вони намагалися стандартизувати доступ між віртуалізацією, Kubernetes і bare metal. Хтось запропонував спрощення: створити одну кастомну роль Proxmox OpsStandard, що покривала б 95% потреб. Вони витягли привілеї з кількох ролей і прибрали все, що «виглядало ризиковано».

Спочатку все працювало. Менше імен ролей, менше рядків ACL. Потім почалися дивні речі: міграції VM падали для деяких користувачів, операції зі снапшотами періодично відмовляли, інтерфейс іноді показував пусті списки сховищ. Кожен симптом з’являвся в різних куточках продукту, тож це виглядало як баг Proxmox.

Реальна проблема — «оптимізація». Вони прибрали кілька привілеїв, що здавалися другорядними, але на які GUI і робочі процеси покладались. Роль дозволяла вмикати VM, тому люди вважали її достатньою. Насправді ні. Відмови були викликані браком допоміжних привілеїв, потрібних для супровідних запитів і оновлень стану.

Вони повернули зміни. Повернулися до невеликого набору ролей, вирівняних за відповідальністю, і обмежили область через пули та шляхи сховищ замість «однієї ролі, що править усім». Остаточний дизайн мав більше рядків ACL, але менше інцидентів.

Міні-історія 3: нудна, але правильна практика, що врятувала становище

Команда, близька до фінансів, керувала Proxmox для навантажень, чутливих до комплаєнсу. У них була звичка, над якою всі кепкували: квартальні рев’ю доступів. Не таблиця Excel для галочки — реальний перегляд груп, ролей і шляхів ACL з другою особою, що перевіряє.

Під час одного рев’ю вони помітили тонку річ: старий підрядник був відключений, але його API-токен досі існував. Токен мав власні ACL, бо privilege separation було ввімкнено. Він також мав доступ до /storage/backup-nfs з роллю, що дозволяла читати бекапи.

Нічого поганого ще не сталося. Ось у чому суть. Вони відкликали токен, видалили ACL і перемотали кілька секретів. Пізніше того року інша система була скомпрометована і зловмисники шукали внутрішні API. Proxmox-токен був би легким шляхом до викрадення бекапів, якби він досі існував.

Що їх врятувало — не якийсь хитрий інструмент. Це була нудна практика: поводитися з токенами як з продакшн-обліковими даними, рев’ювати їх і видаляти, коли сервіс або людина пішли.

Вони також тримали RBAC надзвичайно простим: пули для власності, окремі групи для аудиту й операцій, і жодних кастомних ролей без письмової вимоги. Завдяки цьому, коли з’являлись «permission denied», діагностика була швидкою, бо система була читабельною.

Типові помилки: симптом → корінна причина → виправлення

1) Симптом: «Permission denied» при кліку Datacenter, але консоль VM працює

Корінна причина: Користувач має права на рівні VM (/vms/<id> або /pool/<pool>), але не має прав аудиту для нод/сховищ, які GUI опитує.

Виправлення: Додайте роль аудиту на /nodes (або на /dc, якщо доречно) і роль datastore audit/user на потрібних /storage/<id>. Залишайте читанням, якщо не потрібні додаткові дії.

2) Симптом: Працює для alice@pve, але не для alice@ldap

Корінна причина: ACL надані неправильній ідентичності realm.

Виправлення: Надайте ACL потрібному user@realm. Розгляньте відключення локальних shadow-акаунтів, щоб зменшити плутанину.

3) Симптом: Користувач може запускати/зупиняти VM, але не може приєднати ISO

Корінна причина: Відсутні привілеї datastore на шляху ISO-сховища (/storage/<id>), а не проблема прав VM.

Виправлення: Додайте роль PVEDatastoreUser або аудиту на це сховище, або перемістіть ISO на сховище з потрібними ACL.

4) Симптом: Завдання резервного копіювання падає з помилками прав тільки при запуску автоматизацією

Корінна причина: API-токен має privilege separation увімкнено і не успадковує ACL користувача; токен не має власних ACL.

Виправлення: Додайте ACL для ідентичності токена на потрібних шляхах, або вимкніть privsep лише якщо ви приймаєте тісне зв’язування (звичайно не варто).

5) Симптом: Сторінка Datacenter → Permissions недоступна для «аудиторів»

Корінна причина: Роль аудитора не має відповідних привілеїв для об’єктів permission, або ви навмисно обмежили її і GUI правильно відмовляє.

Виправлення: Визначте намір. Якщо їм потрібно переглядати дозволи, додайте необхідний audit-привілей через оновлення ролі. Якщо ні — не обіцяйте доступ до цієї сторінки.

6) Симптом: Користувач бачить деякі VM, але не інші в тій самій команді

Корінна причина: VM не послідовно призначені в пул, або індивідуальні ACL різняться з часом.

Виправлення: Нормалізуйте через пули. Перемістіть VM у правильний пул; видаліть per-VM ACL, якщо немає документованого винятку.

7) Симптом: Права здаються правильними, але користувач все ще отримує відмову після змін

Корінна причина: Кешований сеанс/токен у браузері; користувач увійшов під іншим realm; ви змінили членство в групі, але сеанс не оновився.

Виправлення: Попросіть користувача вийти/увійти; перевірте realm у правому верхньому куті; перевірте CLI і переконайтесь, що ви змінили правильну ідентичність.

8) Симптом: Різні ноди поводяться по-різному для одного і того ж користувача

Корінна причина: Неконсистентність кластера (проблеми кворуму, нода неповністю приєднана) або відмінності в локальній інтеграції автентифікації.

Виправлення: Перевірте pvecm status, забезпечте кворум; перевірте конфіг realm на всіх нодах; виправте стан кластерної файлової системи перед змінами ACL.

Чеклісти / покроковий план

Чекліст A: Побудуйте RBAC правильно для команди (людські користувачі)

1. Створіть (або використайте) auth realm, що відповідає корпоративній ідентичності (LDAP/AD/OIDC). Не створюйте дубльованих локальних користувачів, якщо не маєте на те причин.
2. Створіть групи, що відображають відповідальність, а не оргструктуру: VM-Operators, VM-Auditors, Storage-Operators.
3. Створіть пули за командами або середовищами: Dev, Prod, Analytics.
4. Помістіть VM/CT у пули як джерело істини для власності.
5. Надавайте ролі на /pool/<pool> з propagation:
   • PVEVMUser або PVEVMAdmin залежно від здатності змінювати конфіг.
6. Надавайте PVEAuditor на /nodes, якщо потрібен перегляд статусу нод у GUI.
7. Надавайте ролі datastore на конкретних /storage/<id> для доступу до ISO/backup, якщо потрібно.
8. Задокументуйте, що вони не можуть робити (снапшоти? зміну розміру дисків? міграції?). Менше сюрпризів = менше запитів «просто зробіть їх адмінами».

Чекліст B: Виправити живий тікет «Datacenter permission denied», не погіршивши ситуацію

1. Підтвердіть realm і точний user ID (user@realm).
2. Перелічіть групи користувача і існуючі ACL.
3. Визначте сторінку/дію, що падає. Попросіть точний шлях кліку і час.
4. Перевірте, чи користувач може:
   • перерахувати ноди (аудит)
   • перерахувати сховища (аудит)
   • побачити пул і його членів
5. Якщо чогось бракує, додайте мінімальні audit-ACL на правильному шляху.
6. Повторно протестуйте з користувачем. Якщо виправлено — зупиніться. Не «поліпшуйте» далі на ходу.
7. Якщо не виправлено — знайдіть заборонений ендпоінт, переглянувши журнали завдань або відтворивши запити через API.
8. Як крайній захід, тимчасово дайте ширшу роль з часовим обмеженням і планом відкату.

Чекліст C: Автоматизація на токенах — безпечно

1. Створіть окремого сервісного користувача для домену автоматизації (наприклад, svc-terraform@pve).
2. Створюйте токени по середовищах (tf-dev, tf-prod), щоб можна було відкликати вибірково.
3. Тримайте privsep=1 і призначайте явні ACL токенам. Не покладайтеся на ACL користувача.
4. Надавайте доступ на рівні пулу і потрібних шляхів сховища, а не на /.
5. Рев’юйте токени щоквартально і видаляйте невикористані. Ротируйте облікові дані при зміні персоналу або власника пайплайнів.

FAQ (8+)

1) Чому Proxmox показує «permission denied» у Datacenter, коли я хочу лише доступ до VM?

Тому що GUI завантажує дані datacenter- і node-рівня для заповнення бічної панелі, дашбордів і панелей статусу. Прав VM не завжди покривають ті API-запити.

2) Чи не простіше дати PVEAuditor на /, щоб усі бачили все?

Ні. Надавайте права аудиту на /nodes і /dc лише за потреби й усвідомлюйте, що «бачити все» все ще означає доступ.

3) Який найбезпечніший спосіб дати команді доступ до «своїх» VM?

Використовуйте пули. Помістіть їхні VM/CT у /pool/Team і призначайте там VM-орієнтовану роль з propagation. Це чисто і відкатно.

4) Чому мій оператор VM не може приєднати диски або змонтувати ISO?

Операції з дисками/ISO часто зачіпають об’єкти сховища. Вам потрібні відповідні привілеї на /storage/<id> на додаток до прав VM.

5) Чи успадковують API-токени права користувача?

Ні, якщо для токена увімкнено privilege separation (privsep=1). У цьому випадку токени потребують власних ACL. Це зазвичай бажано для автоматизації.

6) Я надав правильну роль, але все ще бачу відмову. Що тепер?

Переконайтесь, що ви надали роль правильній ідентичності (user@realm), на правильному шляху, з propagation якщо потрібно. Потім попросіть користувача вийти/увійти для оновлення сесії.

7) Чи нормально кастомізувати стандартні ролі?

Можна, але ставтеся до цього як до зміни бібліотеки в продакшені: версіонуйте в голові, документуйте і готуйтеся до сюрпризів. Краще створювати нову кастомну роль, щоб дефолти лишалися передбачуваними.

8) Як зупинити розростання привілеїв з часом?

Використовуйте групові ACL, скопування через пули і квартальні рев’ю ACL і токенів. Видаляйте одноразові індивідуальні ACL, якщо немає письмового винятку.

9) Чому все працює на одній ноді, а на іншій — ні?

Або кластер не у консистентному стані (кворум/розподіл конфіг), або конфіг realm відрізняється на нодах, або користувач автентифікується по-іншому. Усуньте неконсистентність перш за все.

10) Де «правильно» призначати дозволи: /dc чи /?

Майже ніколи не на /. Використовуйте /dc для datacenter-широкої видимості (і лише для довірених ролей при записі). Для всього іншого використовуйте пули, ноди й шляхи сховищ.

Висновок: наступні кроки, які можна зробити вже сьогодні

Помилки «Permission denied» у Datacenter Proxmox не випадкові. Це система, що каже: ваша історія RBAC не відповідає тому, як GUI й API фактично звертаються до ресурсів.

Зробіть ці кроки:

1. Виберіть одного проблемного користувача і спроєктуйте його identity → groups → ACL-шляхи → roles. Запишіть у чотири рядки. Якщо не можете — ваш RBAC вже занадто хитромудрий.
2. Перемістіть командні робочі навантаження в пули і припиніть гру в whack-a-mole з per-VM ACL.
3. Додавайте мінімальний доступ аудиту для нод/сховищ лише коли потрібен для видимості. Не використовуйте «доступ Datacenter» як виправдання для admin-прав datacenter.
4. Проінвентаризуйте API-токени, підтвердіть privsep=1 і забезпечте, щоб кожен токен мав явні вузькі ACL.
5. Заплануйте квартальний рев’ю RBAC. Так, це нудно. Саме тому це працює.