]> git.proxmox.com Git - pve-docs.git/blobdiff - pveum.adoc
fix #5429: network: override device names: include Type=ether
[pve-docs.git] / pveum.adoc
index a24598dfa6cbd77aecbd47a956c9a870d894c290..a549810965ef2c8a51f21cb764ff8907fa544fee 100644 (file)
@@ -282,6 +282,13 @@ The main configuration settings for Microsoft Active Directory are:
 
 * `Port` (`port`): The port that the Microsoft AD server listens on
 
+
+NOTE: Microsoft AD normally checks values like usernames without case
+sensitivity. To make {pve} do the same, you can disable the default
+`case-sensitive` option by editing the realm in the web UI, or using the CLI
+(change the `ID` with the realm ID):
+`pveum realm modify ID --case-sensitive 0`
+
 [[pveum_ldap_sync]]
 Syncing LDAP-Based Realms
 ~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -564,7 +571,7 @@ can be specified in Base32 (RFC3548) or hexadecimal notation.
 +
 {pve} provides a key generation tool (`oathkeygen`) which prints out a random
 key in Base32 notation, that can be used directly with various OTP tools, such
-as the `oathtool` command line tool, or on Android Google Authenticator,
+as the `oathtool` command-line tool, or on Android Google Authenticator,
 FreeOTP, andOTP or similar applications.
 
 YubiKey OTP::
@@ -601,7 +608,9 @@ An admin can unlock a user's Two-Factor Authentication at any time via the user
 list in the UI or the command line:
 
 [source,bash]
+----
  pveum user tfa unlock joe@pve
+----
 
 [[pveum_user_configured_totp]]
 User Configured TOTP Authentication
@@ -634,7 +643,7 @@ field and pressing the 'Apply' button.
 
 There is no server setup required. Simply install a TOTP app on your
 smartphone (for example, https://freeotp.github.io/[FreeOTP]) and use
-the Proxmox Backup Server web-interface to add a TOTP factor.
+the Proxmox Backup Server web interface to add a TOTP factor.
 
 [[user_tfa_setup_webauthn]]
 === WebAuthn
@@ -706,7 +715,7 @@ This is done via `/etc/pve/datacenter.cfg`. For instance:
 u2f: appid=https://mypve.example.com:8006
 ----
 
-For a single node, the 'AppId' can simply be the address of the web-interface,
+For a single node, the 'AppId' can simply be the address of the web interface,
 exactly as it is used in the browser, including the 'https://' and the port, as
 shown above. Please note that some browsers may be more strict than others when
 matching 'AppIds'.
@@ -764,12 +773,19 @@ of predefined roles, which satisfy most requirements.
 
 * `Administrator`: has full privileges
 * `NoAccess`: has no privileges (used to forbid access)
-* `PVEAdmin`: can do most tasks, but has no rights to modify system settings (`Sys.PowerMgmt`, `Sys.Modify`, `Realm.Allocate`)
+* `PVEAdmin`: can do most tasks, but has no rights to modify system settings
+  (`Sys.PowerMgmt`, `Sys.Modify`, `Realm.Allocate`) or permissions
+  (`Permissions.Modify`)
 * `PVEAuditor`: has read only access
 * `PVEDatastoreAdmin`: create and allocate backup space and templates
 * `PVEDatastoreUser`: allocate backup space and view storage
+* `PVEMappingAdmin`: manage resource mappings
+* `PVEMappingUser`: view and use resource mappings
 * `PVEPoolAdmin`: allocate pools
-* `PVESysAdmin`: User ACLs, audit, system console and system logs
+* `PVEPoolUser`: view pools
+* `PVESDNAdmin`: manage SDN configuration
+* `PVESDNUser`: access to bridges/vnets
+* `PVESysAdmin`: audit, system console and system logs
 * `PVETemplateUser`: view and clone templates
 * `PVEUserAdmin`: manage users
 * `PVEVMAdmin`: fully administer VMs
@@ -788,10 +804,12 @@ To add a role through the command line, you can use the 'pveum' CLI tool, for
 example:
 [source,bash]
 ----
-pveum role add PVE_Power-only --privs "VM.PowerMgmt VM.Console"
+pveum role add VM_Power-only --privs "VM.PowerMgmt VM.Console"
 pveum role add Sys_Power-only --privs "Sys.PowerMgmt Sys.Console"
 ----
 
+NOTE: Roles starting with `PVE` are always builtin, custom roles are not
+allowed use this reserved prefix.
 
 Privileges
 ~~~~~~~~~~
@@ -805,38 +823,45 @@ We currently support the following privileges:
 
 Node / System related privileges::
 
-* `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/modify/remove node network parameters
-* `Sys.Incoming`: allow incoming data streams from other clusters (experimental)
 * `Group.Allocate`: create/modify/remove groups
+* `Mapping.Audit`: view resource mappings
+* `Mapping.Modify`: manage resource mappings
+* `Mapping.Use`: use resource mappings
+* `Permissions.Modify`: modify access permissions
 * `Pool.Allocate`: create/modify/remove a pool
 * `Pool.Audit`: view a pool
-* `Realm.Allocate`: create/modify/remove authentication realms
 * `Realm.AllocateUser`: assign user to a realm
+* `Realm.Allocate`: create/modify/remove authentication realms
+* `SDN.Allocate`: manage SDN configuration
+* `SDN.Audit`: view SDN configuration
+* `Sys.Audit`: view node status/config, Corosync cluster config, and HA config
+* `Sys.Console`: console access to node
+* `Sys.Incoming`: allow incoming data streams from other clusters (experimental)
+* `Sys.Modify`: create/modify/remove node network parameters
+* `Sys.PowerMgmt`: node power management (start, stop, reset, shutdown, ...)
+* `Sys.Syslog`: view syslog
 * `User.Modify`: create/modify/remove user access and details.
 
 Virtual machine related privileges::
 
+* `SDN.Use`: access SDN vnets and local network bridges
 * `VM.Allocate`: create/remove VM on a server
-* `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.Backup`: backup/restore VMs
 * `VM.Clone`: clone/copy a VM
-* `VM.Config.Disk`: add/modify/remove disks
 * `VM.Config.CDROM`: eject/change CD-ROM
 * `VM.Config.CPU`: modify CPU settings
+* `VM.Config.Cloudinit`: modify Cloud-init parameters
+* `VM.Config.Disk`: add/modify/remove disks
+* `VM.Config.HWType`: modify emulated hardware types
 * `VM.Config.Memory`: modify memory settings
 * `VM.Config.Network`: add/modify/remove network devices
-* `VM.Config.HWType`: modify emulated hardware types
 * `VM.Config.Options`: modify any other VM configuration
-* `VM.Config.Cloudinit`: modify Cloud-init parameters
+* `VM.Console`: console access to VM
+* `VM.Migrate`: migrate VM to alternate server on cluster
+* `VM.Monitor`: access to VM monitor (kvm)
+* `VM.PowerMgmt`: power management (start, stop, reset, shutdown, ...)
+* `VM.Snapshot.Rollback`: rollback VM to one of its snapshots
 * `VM.Snapshot`: create/delete VM snapshots
 
 Storage related privileges::
@@ -846,6 +871,12 @@ Storage related privileges::
 * `Datastore.AllocateTemplate`: allocate/upload templates and ISO images
 * `Datastore.Audit`: view/browse a datastore
 
+WARNING: Both `Permissions.Modify` and `Sys.Modify` should be handled with
+care, as they allow modifying aspects of the system and its configuration that
+are dangerous or sensitive.
+
+WARNING: Carefully read the section about inheritance below to understand how
+assigned roles (and their privileges) are propagated along the ACL tree.
 
 Objects and Paths
 ~~~~~~~~~~~~~~~~~
@@ -886,6 +917,7 @@ set by default). We use the following inheritance rules:
 * Permissions for individual users always replace group permissions.
 * Permissions for groups apply when the user is member of that group.
 * Permissions on deeper levels replace those inherited from an upper level.
+* `NoAccess` cancels all other roles on a given path.
 
 Additionally, privilege separated tokens can never have permissions on any
 given path that their associated user does not have.
@@ -954,51 +986,69 @@ depending on the path, the following privileges as a possible substitute:
 * `/vms/...`: requires 'VM.Allocate`
 * `/pool/...`: requires 'Pool.Allocate`
 +
-If the path is empty, `Permission.Modify` on `/access` is required.
+If the path is empty, `Permissions.Modify` on `/access` is required.
++
+If the user does not have the `Permissions.Modify` privilege, they can only
+delegate subsets of their own privileges on the given path (e.g., a user with
+`PVEVMAdmin` could assign `PVEVMUser`, but not `PVEAdmin`).
 
-Command Line Tool
+Command-line Tool
 -----------------
 
 Most users will simply use the GUI to manage users. But there is also
-a fully featured command line tool called `pveum` (short for ``**P**roxmox
-**VE** **U**ser **M**anager''). Please note that all Proxmox VE command
-line tools are wrappers around the API, so you can also access those
+a fully featured command-line tool called `pveum` (short for ``**P**roxmox
+**VE** **U**ser **M**anager''). Please note that all Proxmox VE command-line
+tools are wrappers around the API, so you can also access those
 functions through the REST API.
 
 Here are some simple usage examples. To show help, type:
 
 [source,bash]
+----
  pveum
+----
 
 or (to show detailed help about a specific command)
 
 [source,bash]
+----
  pveum help user add
+----
 
 Create a new user:
 
 [source,bash]
+----
  pveum user add testuser@pve -comment "Just a test"
+----
 
 Set or change the password (not all realms support this):
 
 [source,bash]
+----
  pveum passwd testuser@pve
+----
 
 Disable a user:
 
 [source,bash]
+----
  pveum user modify testuser@pve -enable 0
+----
 
 Create a new group:
 
 [source,bash]
+----
  pveum group add testgroup
+----
 
 Create a new role:
 
 [source,bash]
+----
  pveum role add PVE_Power-only -privs "VM.PowerMgmt VM.Console"
+----
 
 
 Real World Examples
@@ -1014,17 +1064,23 @@ full administrator rights (without using the root account).
 To do this, first define the group:
 
 [source,bash]
+----
  pveum group add admin -comment "System Administrators"
+----
 
 Then assign the role:
 
 [source,bash]
+----
  pveum acl modify / -group admin -role Administrator
+----
 
 Finally, you can add users to the new 'admin' group:
 
 [source,bash]
+----
  pveum user modify testuser@pve -group admin
+----
 
 
 Auditors
@@ -1036,12 +1092,16 @@ role to users or groups.
 Example 1: Allow user `joe@pve` to see everything
 
 [source,bash]
+----
  pveum acl modify / -user joe@pve -role PVEAuditor
+----
 
 Example 2: Allow user `joe@pve` to see all virtual machines
 
 [source,bash]
+----
  pveum acl modify /vms -user joe@pve -role PVEAuditor
+----
 
 
 Delegate User Management
@@ -1051,7 +1111,9 @@ If you want to delegate user management to user `joe@pve`, you can do
 that with:
 
 [source,bash]
+----
  pveum acl modify /access -user joe@pve -role PVEUserAdmin
+----
 
 User `joe@pve` can now add and remove users, and change other user attributes,
 such as passwords. This is a very powerful role, and you most
@@ -1060,8 +1122,10 @@ example allows `joe@pve` to modify users within the realm `pve`, if they
 are members of group `customers`:
 
 [source,bash]
+----
  pveum acl modify /access/realm/pve -user joe@pve -role PVEUserAdmin
  pveum acl modify /access/groups/customers -user joe@pve -role PVEUserAdmin
+----
 
 NOTE: The user is able to add other users, but only if they are
 members of the group `customers` and within the realm `pve`.
@@ -1078,20 +1142,26 @@ permissions further.
 Give the user `joe@pve` the role PVEVMAdmin on all VMs:
 
 [source,bash]
+----
  pveum acl modify /vms -user joe@pve -role PVEVMAdmin
+----
 
 Add a new API token with separate privileges, which is only allowed to view VM
 information (for example, for monitoring purposes):
 
 [source,bash]
+----
  pveum user token add joe@pve monitoring -privsep 1
  pveum acl modify /vms -token 'joe@pve!monitoring' -role PVEAuditor
+----
 
 Verify the permissions of the user and token:
 
 [source,bash]
+----
  pveum user permissions joe@pve
  pveum user token permissions joe@pve monitoring
+----
 
 Resource Pools
 ~~~~~~~~~~~~~~
@@ -1102,24 +1172,32 @@ of these. Let's assume that you want to set up a pool for a software development
 department. First, create a group:
 
 [source,bash]
+----
  pveum group add developers -comment "Our software developers"
+----
 
 Now we create a new user which is a member of that group:
 
 [source,bash]
+----
  pveum user add developer1@pve -group developers -password
+----
 
 NOTE: The "-password" parameter will prompt you for a password
 
 Then we create a resource pool for our development department to use:
 
 [source,bash]
+----
  pveum pool add dev-pool --comment "IT development pool"
+----
 
 Finally, we can assign permissions to that pool:
 
 [source,bash]
+----
  pveum acl modify /pool/dev-pool/ -group developers -role PVEAdmin
+----
 
 Our software developers can now administer the resources assigned to
 that pool.