Proxmox Users Setup
To secure the Proxmox node or cluster we need to set some user things on the OS level (Debian) and some more then in Proxmox. Having servers in a Data Center also needs some more security measures to be in place. Servers are key targets for hackers, gain access to thousands accounts in one go.
First task is to create a new Administrator account to do what ROOT usually is doing and then we will inactivate ROOT from the Debian OS as from the Proxmox app.
We will also create some other needed users.
We can not just takeout the ROOT as we normally do in Debian. First we install SUDO on Debian and create the new Debian user.
To understand the two realms PAM (Linux PAM standard authentication) an PVE (Proxmox VE authentication server) its easier to say that PAM users have Shell access and PVE users doesn't. PAM user need to exist in the Debian OS to be able to control the Proxmox as a root user.
We will also discuss the API users. An API user is needed for things like Zabbix or other auditing apps. They don't use password, they utilize the token architecture for authorization.
User Management
Proxmox VE supports multiple authentication sources, for example Linux PAM, an integrated Proxmox VE authentication server, LDAP, Microsoft Active Directory and OpenID Connect.
By using role-based user and permission management for all objects (VMs, Storage, nodes, etc.), granular access can be defined.
Proxmox VE stores user attributes in /etc/pve/user.cfg
What can Proxmox Permissions Do
Restrict user access or control over: nodes, VM's, disks, pools, creation of users and their permissions.
But you can't control the use of NIC's (use the firewalls) or set quotas.
Authentication Realms
As Proxmox VE users are just counterparts for users existing on some external realm, the realms have to be configured in /etc/pve/domains.cfg
. The following realms (authentication methods) are available:
- Linux PAM
- Linux PAM is a framework for system-wide user authentication
- Proxmox VE Authentication
- This is a Unix-like password store, which stores hashed passwords in
/etc/pve/priv/shadow.cfg
.
- This is a Unix-like password store, which stores hashed passwords in
- LDAP
- LDAP (Lightweight Directory Access Protocol) is an open, cross-platform protocol for authentication using directory services. OpenLDAP is a popular open-source implementations of the LDAP protocol.
- Microsoft Active Director
- Microsoft Active Directory (AD) is a directory service for Windows domain networks and is supported as an authentication realm for Proxmox VE. It supports LDAP (originated from LDAP) as an authentication protocol.
- OpenID Connect
- OpenID Connect is implemented as an identity layer on top of the OATH 2.0 protocol. It allows clients to verify the identity of the user, based on authentication performed by an external authorization server.
Adding user to OpenID or LDAP need to be done at the source first
Realm Enforced 2FA Elevated security for Remote Servers
You can set up multiple second factors, in order to avoid a situation in which losing your smartphone or security key locks you out of your account permanently.
The following two-factor authentication methods are available User configured and realm-enforced TOTP (Time-based One-Time Password) and YubiKey OTP, WebAuthn (Web Authentication) is a general standard for authentication and Single use Recovery Keys which is a list of keys which should either be printed out and locked in a secure place or saved digitally in an electronic vault.
Other very good to use things are 2FA or OpenID authentication. If you absolutely need to have access to the GUI over the web like to servers in Data Centers. They are needed but you also need tunneling apps and Reverse Proxies.
The thing with hypervisor security is that you are not securing just your PC or Laptop but 100's or 1.000's of servers running in that cluster and all the users.
Create an Administrator Account
The Administrator account shall exist on the OS level and then also on the application level as a Proxmox PAM user.
I use "admin" only as an example, use your imagination.
For security reasons do not use admin as your superuser
- PAM users are local to the a node,
to have access to the Shell you need to first create them in Debian - PVE users are local to the cluster, the whole cluster
PAM is not synchronized across the cluster
PVE is synchronized across the cluster
Create the new Superuser
Go to the Debian Shell add adduser admin
and then in Datacenter -> Permissions -> Users
add that user as a PAM user.
This user will be our new root account, you may like to use groups.
In Datacenter -> Permissions
set the users permissions to /
and Administrator
.
Logout and login as the new user. Test the new user thoroughly and if all tests are successful go to the Shell and:
- Set the root password as expired.
- Add the admin-users public key to Debian for SSH login.
- Make SSH root login with password as not allowed
- and login with keys to allowed.
- Then in the GUI make root not active.
You can't delete the root account but we can make it unusable.
Other users
You can now add your users as single users, in groups or using pools.
The Built-in types are:
- NoAccess, Administrator,
- PVEAdmin, PVEAuditor, PVEUserAdmin, PVESysAdmin, PVETemplateUser,
- PVEDatastoreAdmin, PVEDatastoreUser,
- PVEMappingAdmin, PVEMappingUser,
- PVEPoolAdmin, PVEPoolUser,
- PVESDNAdmin, PVESDNUser,
- PVEVMAdmin, PVEVMUser.
You can create more fine graded types by hitting [Create]. All depending on you organizations segregation of duties.
API users for Tokens
APIusers will be with Permissions to either the /
or any other and as PVEAuditor
or any local Role you created. Use a toke and no password.
Create a token and store that token (it will show one time only).
References
Proxmox User Management [1]
Pve User Management wiki, Proxmox VE Administration Guide documentation ↩︎