• slider image 168
:::
條列式新聞
新聞載入中,請稍後...

2-2-5-2

  

https://pve.proxmox.com/wiki/User_Management

 

 

 

 
 

 

Authentication Realms

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.

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. This is the most convenient method for small (or even medium) installations where users do not need access to anything outside of Proxmox VE. In this case users are fully managed by Proxmox VE and are able to change their own passwords via the GUI.

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.

Users are searched under a Base Domain Name (base_dn), with the user name found in the attribute specified in the User Attribute Name (user_attr) field.

The Base Domain Name would be ou=People,dc=ldap-test,dc=com and the user attribute would be uid.

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.

Permission Management

Proxmox VE uses a role and path based permission management system. An entry in the permissions table allows a user or group to take on a specific role when accessing an object or path. This means an such an access rule can be represented as a triple of (path, user, role) or (path, group, role), with the role containing a set of allowed actions, and the path representing the target of these actions.

Roles

Privileges

Node / System related privileges
Virtual machine related privileges
Storage related privileges

Objects and Paths

Pools

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.

What permission do I need?

["and", <subtests>...] and ["or", <subtests>...]

Each(and) or any(or) further element in the current list has to be true.

["perm", <path>, [ <privileges>... ], <options>...]

The path is a templated parameter (see Objects and Paths). All (or , if the any option is used, any) of the listed privileges must be allowed on the specified path. If a require-param option is specified, then its specified parameter is required even if the API call’s schema otherwise lists it as being optional.

["userid-group", [ <privileges>... ], <options>...]

The caller must have any of the listed privileges on /access/groups. In addition there are two possible checks depending on whether the groups_param option is set:

  • groups_param is set: The API call has a non-optional groups parameter and the caller must have any of the listed privileges on all of the listed groups.

  • groups_param is not set: The user passed via the userid parameter must exist and be part of a group on which the caller has any of the listed privileges (via the /access/groups/<group> path).

["userid-param", "self"]

The value provided for the API call’s userid parameter must refer to the user performing the action. (Usually in conjunction with or, to allow users to perform an action on themselves even if they don’t have elevated privileges.)

["userid-param", "Realm.AllocateUser"]

The user needs Realm.AllocateUser access to /access/realm/<realm>, with <realm> referring to the realm of the user passed via the userid parameter. Note that the user does not need to exist in order to be associated with a realm, since user IDs are passed in the form of <username>@<realm>.

["perm-modify", <path>]

The path is a templated parameter (see Objects and Paths). The user needs either the Permissions.Modify privilege, or, depending on the path, the following privileges as a possible substitute:

Real World Examples

Delegate User Management

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:

 

 

 
:::
展開 | 闔起

文章類別

書籍目錄

展開 | 闔起

線上使用者

6人線上 (6人在瀏覽線上書籍)

會員: 0

訪客: 6

更多…