Access management

Planeon separates two different questions: who can administer the platform (RBAC — users, groups, roles, permissions) and who can use a given desktop pool (entitlements). Both are managed from the same place — the Users & Access page (/users) — but they're independent: an end user can be entitled to several pools while holding no administrator permissions at all, and an administrator's permissions don't by themselves grant access to any pool's desktops.

The model: users, groups, roles, and permissions

Planeon has no local password store. Every user is a projection of an identity from your OIDC identity provider (see Identity providers) — there's nothing to provision manually before someone can sign in. Users & Access has four tabs:

• Users — read-only local projections of the people who have signed in through your identity provider.
• Groups — local groups you create, plus the built-in groups described below. Selecting Manage access on a group opens one dialog to set both its roles and its members at once. A group's effective members include both people you added directly and anyone synced in through an OIDC group binding — the latter show with disabled checkboxes, since their membership comes from the identity provider, not from this screen.
• Roles & permissions — custom roles you build from the built-in permission list below. Built-in roles are read-only product defaults.
• OIDC bindings — the mapping from your identity provider's group claims to local groups; see OIDC group bindings.

Planeon ships four built-in roles: platform_admin (full platform, authorization, and settings access), platform_operator (day-to-day operational access, without authorization or settings management), platform_viewer (read-only visibility across the platform), and end_user (no administrator permissions at all — access to desktops for this role comes entirely from pool entitlements, never from RBAC. A user with only end_user sees no administrator navigation and is taken straight to the user portal). It also ships three built-in groups — builtin:platform-admins, builtin:platform-operators, and builtin:platform-readers — each already bound to the matching built-in role.

Built-in permissions

These are the permission keys custom roles are built from, listed under Roles & permissions → System permissions:

Permission	Grants
platform:read	Read platform metadata and health state.
platform:admin	Administrative override for all platform capabilities — a global grant of this permission bypasses every other check.
auth:read	Read users, groups, roles, and bindings.
auth:manage	Manage users, groups, roles, and OIDC group bindings.
settings:read	Read platform settings.
settings:manage	Manage platform settings.
pve:read	Read Proxmox integration state.
pve:manage	Manage Proxmox integration settings and actions.
pools:read	Read desktop pools.
pools:manage	Manage desktop pools.
vms:read	Read virtual machines.
vms:manage	Manage virtual machines.
sessions:read	Read sessions.
sessions:manage	Manage sessions.
templates:read	Read templates.
templates:manage	Manage templates.
jobs:read	Read background jobs.
jobs:manage	Manage background jobs (for example, requeuing a failed one).
audit:read	Read the audit log.

Every role binding you create today applies platform-wide: assigning a role to a group or user grants that role's permissions globally. The authorization model is built with seams for scoping a grant down to a single cluster or pool, but those scoped grants are reserved for future releases — there is no way to create one from the console today.

OIDC group bindings

A group claim from your identity provider is not, by itself, authorization — it only grants access once you bind its value to a local group on the OIDC bindings tab. Each binding maps one claim value to one local group: for example, binding claim name groups, claim value corp-vdi-admins to the local group builtin:platform-admins means any user whose token carries corp-vdi-admins in its groups claim is treated as a member of builtin:platform-admins — and inherits that group's roles — from their next sign-in onward. Bindings are edited as a draft list with an explicit Save bindings action, since saving replaces the full binding set.

Membership synced this way is authoritative per sign-in: if a claim value is later removed from a user's token, their corresponding OIDC-managed group membership is cleared on their next authenticated request. Local memberships you assigned directly on the Groups tab are never affected by this sync.

Granting pool access to a group

Being able to administer the platform and being able to use a pool's desktops are separate grants. To let a group of end users request desktops from a pool, open Pools, select Entitlements on the pool's row, then Add entitlement and choose a user or group from your directory. Every member of an entitled group — including members synced in through an OIDC group binding — is entitled to request a desktop from that pool. This is exactly how the quickstart grants your first group access, and it's independent of any RBAC role: a group with no administrator permissions at all can still be entitled to a pool, which is the normal shape for your actual desktop users.

The first administrator

Before any of the above exists, someone has to be able to sign in and create it. That bootstrap step is covered in the installation guide's First login section — see it there rather than here, since it's part of the initial install walkthrough, not an ongoing access-management task.