Глава 42. Пользователи и их права
PVE поддерживает несколько источников аутентификации, например, Linux PAM, интегрированный сервер аутентификации PVE, LDAP, Active Directory и OpenID Connect:
Используя основанное на ролях управление пользователями и разрешениями для всех объектов (ВМ, хранилищ, узлов и т. д.), можно определить многоуровневый доступ.
PVE хранит данные пользователей в файле
/etc/pve/user.cfg:
# cat /etc/pve/user.cfg
user:root@pam:1:0::::::
user:test@pve:1:0::::::
user:testuser@pve:1:0::::Just a test::
user:user@pam:1:0::::::
group:admin:user@pam::
group:testgroup:test@pve::
Каждая запись о пользователе в этом файле содержит следующую информацию: имя, фамилия, адрес электронной почты, членство в группах, дата истечения срока действия, комментарий, включен или отключен этот пользователь, отметка о включении двухфакторной аутентификации.
Пользователя часто внутренне идентифицируют по его имени и области аутентификации в форме <user>@<realm>.
После установки PVE существует один пользователь root@pam, который соответствует суперпользователю ОС. Этого пользователя нельзя удалить, все системные письма будут отправляться на адрес электронной почты, назначенный этому пользователю. Суперпользователь имеет неограниченные права, поэтому рекомендуется добавить других пользователей с меньшими правами.
Каждый пользователь может быть членом нескольких групп. Группы являются предпочтительным способом организации прав доступа. Всегда следует предоставлять права доступа группам, а не отдельным пользователям.
API-токены позволяют получить доступ без сохранения состояния к REST API из другой системы. Токены могут быть сгенерированы для отдельных пользователей. Токенам, для ограничения объема и продолжительности доступа, могут быть предоставлены отдельные разрешения и даты истечения срока действия. Если API-токен скомпрометирован, его можно отозвать, не отключая самого пользователя.
API-токены бывают двух основных типов:
токен с раздельными привилегиями — токену необходимо предоставить явный доступ с помощью ACL. Эффективные разрешения токена вычисляются путем пересечения разрешений пользователя и токена;
токен с полными привилегиями — разрешения токена идентичны разрешениям связанного с ним пользователя.
API-токен состоит из двух частей:
Для генерации API-токена в веб-интерфейсе необходимо в окне → → нажать кнопку Добавить. В открывшемся окне следует выбрать пользователя и указать ID-токена:
Отметку
Разделение привилегий следует снять, в противном случае токену необходимо назначить явные права. Подробнее см.
Управление доступом.
После нажатия кнопки Добавить будет сгенерирован API-токен:
Отображаемое секретное значение необходимо сохранить.
Значение токена отображается/возвращается только один раз при создании токена. Его нельзя будет снова получить через API позже!
Если был создан токен с раздельными привилегиями, токену необходимо предоставить разрешения:
В окне → нажать кнопку → :
В открывшемся окне выбрать путь, токен и роль и нажать кнопку Добавить:
Для создания API-токена в консоли используется команда:
# pveum user token add <userid> <tokenid> [ОПЦИИ]
Возможные опции:
--comment <строка> — комментарий к токену;
--expire <целое число> — дата истечения срока действия API-токена в секундах с начала эпохи (по умолчанию срок действия API-токена совпадает со сроком действия пользователя). Значение 0 указывает, что срок действия токена не ограничен;
--privsep <логическое значение> — ограничить привилегии API-токена с помощью отдельных списков контроля доступа (по умолчанию) или предоставить полные привилегии соответствующего пользователя (значение 0).
Примеры команд для работы с токенами:
создать токен t2 для пользователя user@pam с полными привилегиями:
# pveum user token add user@pam t2 --privsep 0
┌──────────────┬──────────────────────────────────────┐
│ key │ value │
╞══════════════╪══════════════════════════════════════╡
│ full-tokenid │ user@pam!t2 │
├──────────────┼──────────────────────────────────────┤
│ info │ {"privsep":"0"} │
├──────────────┼──────────────────────────────────────┤
│ value │ 3c749375-e189-493d-8037-a1179317c406 │
└──────────────┴──────────────────────────────────────┘
вывести список токенов пользователя:
# pveum user token list user@pam
┌─────────────┬─────────┬────────┬─────────┐
│ tokenid │ comment │ expire │ privsep │
╞═════════════╪═════════╪════════╪═════════╡
│ monitoring │ │ 0 │ 1 │
├─────────────┼─────────┼────────┼─────────┤
│ t2 │ │ 0 │ 0 │
└─────────────┴─────────┴────────┴─────────┘
вывести эффективные разрешения для токена:
# pveum user token permissions user@pam t2
Можно использовать опцию
--path, чтобы вывести разрешения для этого пути, а не всё дерево:
# pveum user token permissions user@pam t2 --path /storage
добавить разрешения для токена с раздельными привилегиями:
# pveum acl modify /vms --tokens 'user@pam!monitoring' --roles PVEAdmin,PVEAuditor
удалить токен пользователя:
# pveum user token remove user@pam t2
Разрешения на API-токены всегда являются подмножеством разрешений соответствующего пользователя. То есть API-токен не может использоваться для выполнения задачи, на которую у пользователя владельца токена нет разрешения.
Пример:
Предоставить пользователю test@pve роль PVEVMAdmin на всех ВМ:
# pveum acl modify /vms --users test@pve --roles PVEVMAdmin
Создать API-токен с раздельными привилегиями с правами только на просмотр информации о ВМ:
# pveum user token add test@pve monitoring --privsep 1
# pveum acl modify /vms --tokens 'test@pve!monitoring' --roles PVEAuditor
Проверить разрешения пользователя и токена:
# pveum user permissions test@pve
# pveum user token permissions test@pve monitoring
Чтобы использовать API-токен при выполнении API-запросов, следует установить заголовок HTTP Authorization в значение PVEAPIToken=USER@REALM!TOKENID=UUID.
