PVE(1)

A Proxmox VE user name consists of two parts: <userid>@<realm>. The login screen on the GUI shows them a separate items, but it is internally used as single string.

We store the following attribute for users (/etc/pve/user.cfg):

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.

Access permissions are assigned to objects, such as a virtual machines (/vms/{vmid}) or a storage (/storage/{storeid}) or a pool of resources (/pool/{poolname}). We use filesystem like paths to address those objects. Those paths form a natural tree, and permissions can be inherited down that hierarchy.

A privilege is the right to perform a specific action. To simplify management, lists of privileges are grouped into roles, which can then be uses to set permissions.

We currently use the following privileges:

A role is simply a list of privileges. Proxmox VE comes with a number of predefined roles which satisfies most needs.

You can see the whole set of predefined roles on the GUI.

Adding new roles using the CLI:

Permissions are the way we control access to objects. In technical terms they are simply a triple containing <path,user,role>. This concept is also known as access control lists. Each permission specifies a subject (user or group) and a role (set of privileges) on a specific path.

When a subject requests an action on an object, the framework looks up the roles assigned to that subject (using the object path). The set of roles defines the granted privileges.

Pools can be used to group a set of virtual machines and data stores. You can then simply set permissions on pools (/pool/{poolid}), which are inherited to all pool members. This is a great way simplify access control.

One of the most wanted features was the ability to define a group of users with full administartor rights (without using the root account).

Define the group:

Then add the permission:

You can finally add users to the new admin group:

You can give read only access to users by assigning the PVEAuditor role to users or groups.

Example1: Allow user joe@pve to see everything

Example1: Allow user joe@pve to see all virtual machines

If you want to delegate user managenent to user joe@pve you can do that with:

User joe@pve can now add and remove users, change passwords and other user attributes. This is a very powerful role, and you most likely want to limit that to selected realms and groups. The following example allows joe@pve to modify users within realm pve if they are members of group customers:

An enterprise is usually structured into several smaller departments, and it is common that you want to assign resources to them and delegate management tasks. A pool is simply a set of virtual machines and data stores. You can create pools on the GUI. After that you can add resources to the pool (VMs, Storage).

You can also assign permissions to the pool. Those permissions are inherited to all pool members.

Lets assume you have a software development department, so we first create a group

Now we create a new user which is a member of that group

I assume we already created a pool called dev-pool on the GUI. So we can now assign permission to that pool:

Our software developers can now administrate the resources assigned to that pool.