Proxmox VE allows granular access control through users, groups, and permissions. It supports multiple authentication sources and stores user information in /etc/pve/user.cfg. Users can be assigned roles that grant privileges for managing VMs, storage, and other system resources either directly or through pools and paths. This allows flexible administration of the Proxmox VE infrastructure.
Proxmox VE allows granular access control through users, groups, and permissions. It supports multiple authentication sources and stores user information in /etc/pve/user.cfg. Users can be assigned roles that grant privileges for managing VMs, storage, and other system resources either directly or through pools and paths. This allows flexible administration of the Proxmox VE infrastructure.
Proxmox VE supports multiple authentication sources: ◦ Linux PAM ◦ Integrated Proxmox VE authentication server ◦ LDAP ◦ Microsoft Active Directory. Granular access can be defined for: ◦ VMs ◦ Storages ◦ Nodes Proxmox VE stores user attributes in /etc/pve/user.cfg.
A user is internally often identified by its name and realm in the form <userid>@<realm>.
Each user entry in this file contains the following information:
◦ First name ◦ Last name ◦ E-mail address ◦ Group memberships ◦ An optional Expiration date ◦ A comment or note about this user ◦ Whether this user is enabled or disabled ◦ Optional two factor authentication keys The system’s root user can always log in via the Linux PAM realm and is an unconfined administrator. This user cannot be deleted, but attributes can still be changed and system mails will be sent to the email address assigned to this user. Each user can be member of several groups. Groups are the preferred way to organize access permissions. You should always grant permission to groups instead of using individual users. That way you will get a much shorter access control list which is easier to handle. The following realms (authentication methods) are available: ◦ (1) Linux PAM standard authentication In this case a system user has to exist (e.g. created via the adduser command) on all nodes The user is allowed to login, and the user authenticates with their usual system password. The following realms (authentication methods) are available: ◦ (2) Proxmox VE authentication server This is a unix like password store (/etc/pve/priv/shadow.cfg). Password are encrypted using the SHA-256 hash method. The following realms (authentication methods) are available: ◦ (3) LDAP It is possible to authenticate users via an LDAP server (e.g. openldap). The server and an optional fallback server can be configured and the connection can be encrypted via SSL. The following realms (authentication methods) are available: ◦ (4) Microsoft Active Directory A server and authentication domain need to be specified. Like with LDAP an optional fallback server, optional port, and SSL encryption can be configured. Each realm can optionally be secured additionally by two factor authentication. This can be done by selecting one of the available methods via the TFA dropdown box when adding or editing an Authentication Realm. Time-based One-time Password algorithm Time-based One-Time Password algorithm (TOTP) is an algorithm that computes a one-time password from a shared secret key and the current time. This uses the standard HMAC-SHA1 algorithm where the current time is hashed with the user’s configured key. The time step and password length parameters are configured. The YubiKey is a hardware authentication device manufactured by Yubico that supports: ◦ one-time passwords, ◦ public-key encryption and authentication, For authenticating via a YubiKey : ◦ a Yubico API ID, API KEY and validation server URL must be configured ◦ and users must have a YubiKey available. In order to get the key ID from a YubiKey, you can trigger the YubiKey once after connecting it to USB and copy the first 12 characters of the typed password into the user’s Key IDs field. In order for a user to perform an action (such as listing, modifying or deleting a parts of a VM configuration), the user needs to have the appropriate permissions. Administrator: has all privileges NoAccess: has no privileges (used to forbid access) PVEAdmin: can do most things, but miss rights to modify system settings (Sys.PowerMgmt, Sys.Modify, Realm.Allocate). PVEAuditor: read only access PVEDatastoreAdmin: create and allocate backup space and templates PVEDatastoreUser: allocate backup space and view storage PVEPoolAdmin: allocate pools PVESysAdmin: User ACLs, audit, system console and system logs PVETemplateUser: view and clone templates PVEUserAdmin: user administration PVEVMAdmin: fully administer VMs PVEVMUser: view, backup, config CDROM, VM console, VM power management Permissions.Modify: modify access permissions Sys.PowerMgmt: Node power management (start, stop, reset, shutdown, …) Sys.Console: console access to Node Sys.Syslog: view Syslog Sys.Audit: view node status/config, Corosync cluster config and HA config Sys.Modify: create/remove/modify node network parameters Group.Allocate: create/remove/modify groups Pool.Allocate: create/remove/modify a pool Realm.Allocate: create/remove/modify authentication realms Realm.AllocateUser: assign user to a realm User.Modify: create/remove/modify user access and details. VM.Allocate: create/remove new VM to server inventory VM.Migrate: migrate VM to alternate server on cluster VM.PowerMgmt: power management (start, stop, reset, shutdown, …) VM.Console: console access to VM VM.Monitor: access to VM monitor (kvm) VM.Backup: backup/restore VMs VM.Audit: view VM config VM.Clone: clone/copy a VM VM.Config.Disk: add/modify/delete Disks VM.Config.CDROM: eject/change CDROM VM.Config.CPU: modify CPU settings VM.Config.Memory: modify Memory settings VM.Config.Network: add/modify/delete Network devices VM.Config.HWType: modify emulated HW type VM.Config.Options: modify any other VM configuration VM.Snapshot: create/remove VM snapshots Datastore.Allocate: create/remove/modify a data store, delete volumes Datastore.AllocateSpace: allocate space on a datastore Datastore.AllocateTemplate: allocate/upload templates and iso images Datastore.Audit: view/browse a datastore Access permissions are assigned to objects, such as a virtual machines, storages or pools of resources. /nodes/{node}: Access to Proxmox VE server machines /vms: Covers all VMs /vms/{vmid}: Access to specific VMs /storage/{storeid}: Access to a storages /pool/{poolname}: Access to VMs part of a pool /access/groups: Group administration /access/realms/{realmid}: Administrative access to realms Pools can be used to group a set of virtual machines and data stores. You can then simply set permissions on pools (/pool/{poolid}), Now you must be able to: ◦ Manage Authentication Sources (Realms) ◦ Manage Users and Groups ◦ Manage Roles and Privileges ◦ Use paths and pools