https://www.yubico.com/products/services-software/yubicloud/[YubiCloud] or
https://developers.yubico.com/Software_Projects/Yubico_OTP/YubiCloud_Validation_Servers/[host your own verification server].
+[[pveum_tfa_lockout]]
+Limits and Lockout of Two-Factor Authentication
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A second factor is meant to protect users if their password is somehow leaked
+or guessed. However, some factors could still be broken by brute force. For
+this reason, users will be locked out after too many failed 2nd factor login
+attempts.
+
+For TOTP, 8 failed attempts will disable the user's TOTP factors. They are
+unlocked when logging in with a recovery key. If TOTP was the only available
+factor, admin intervention is required, and it is highly recommended to require
+the user to change their password immediately.
+
+Since FIDO2/Webauthn and recovery keys are less susceptible to brute force
+attacks, the limit there is higher (100 tries), but all second factors are
+blocked for an hour when exceeded.
+
+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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* `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
* `PVEPoolAdmin`: allocate pools
-* `PVESysAdmin`: User ACLs, audit, system console and system logs
+* `PVESysAdmin`: audit, system console and system logs
* `PVETemplateUser`: view and clone templates
* `PVEUserAdmin`: manage users
* `PVEVMAdmin`: fully administer VMs
* `PVEVMUser`: view, backup, configure CD-ROM, VM console, VM power management
+* `PVESDNAdmin`: manage SDN configuration
+* `PVESDNUser`: access to bridges/vnets
You can see the whole set of predefined roles in the GUI.
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
~~~~~~~~~~
* `Realm.Allocate`: create/modify/remove authentication realms
* `Realm.AllocateUser`: assign user to a realm
* `User.Modify`: create/modify/remove user access and details.
+* `SDN.Allocate`: manage SDN configuration
+* `SDN.Audit`: view SDN configuration
Virtual machine related privileges::
* `VM.Config.Options`: modify any other VM configuration
* `VM.Config.Cloudinit`: modify Cloud-init parameters
* `VM.Snapshot`: create/delete VM snapshots
+* `SDN.Use`: access SDN vnets and local network bridges
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
~~~~~~~~~~~~~~~~~
* 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.
* `/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
-----------------
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
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
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
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
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`.
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
~~~~~~~~~~~~~~
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.
projects / pve-docs.git / blobdiff