ACL v2: Fine-grained access control in Xen Orchestra

florent

@Andrew the NBD warning is probably doable.
the other solution is not : NBD is mandaotry to use CBT ( the fallback with export can't work without a real snapshot )

florent

@flakpyro yes this one : https://github.com/vatesfr/xen-orchestra/pull/9635

fixed this morning in our work branch, and merged this after noon . We also explicited some edge cases here : https://github.com/vatesfr/xen-orchestra/blob/master/%40xen-orchestra/backups/docs/VM backups/incrementalReplication.md (that will probably be ported to the main doc shortly )

thank you for your input

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed feat(backups): improve incremental replication #9635

MathieuRA

@acebmxer Thanks. We will do our best to merge the fix tomorow

florent

yes, the last changes are released in latest ( 6.3) tomorrow if everything proceed as intended

mostly : https://github.com/vatesfr/xen-orchestra/pull/9622
https://github.com/vatesfr/xen-orchestra/pull/9557

and this one was in 6.2 :
https://github.com/vatesfr/xen-orchestra/commit/e36e1012e20c9678efa15148179941cb284c39a6

that's nice to hear

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed feat(xo-server): use index for getAllUnhealthyVdiChainsLength #9622

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed fix(backups): better handling of generator cleanup #9557

0

fbeauchamp committed to vatesfr/xen-orchestra

fix(xo-web): reducing polling for patches and license

MathieuRA

Hi @acebmxer.
Can you test on the branch mra-fix-vm-dashboard?

MathieuRA

ACL v2: Fine-grained access control in Xen Orchestra

With the v2 of the ACL system, Xen Orchestra takes a new step forward in permission management. Where v1 offered basic per-object access control, v2 introduces a full RBAC (Role-Based Access Control) model, with effects, selectors, and an action hierarchy.

What changes

The old approach allowed granting access to an object (a VM, an SR…). Simple, but limited: there was no way to say "this user can shutdown only VM with tag: foo".

Another major limitation of v1: it only covered XAPI objects — VMs, hosts, SRs, networks, so user, groups, backups, schedules, jobs,... was out of scope.

ACL v2: REST API exclusive

ACL v2 is available through the REST API only. The JSON-RPC API (used by XO5) stays on ACL v1, and conversely: ACL v1 is not available on the REST API.

Key concepts

Roles and privileges

A role is a named set of privileges. Each privilege defines:

a resource type (vm, sr, network, backup-job…)
an action (read, start, shutdown:clean, delete…)
an effect: allow or deny
an optional selector to target specific objects (complex-matcher format)

Actions are hierarchical. Granting shutdown covers both shutdown:clean and shutdown:hard. But granting shutdown:clean does not cover shutdown as a whole. deny always takes precedence over allow.

Built-in roles

Actually, 4 template roles are provided out of the box:

Read only — full read-only access to the infrastructure
VMs read only — read-only access to VMs only
VMs power state manager — manage VM power state (start, stop, reboot, pause…)
VMs creator — create VMs from templates

These roles are immutable and automatically updated on startup — they cannot be assigned directly. To use them, copy the template into a new role and assign that copy to your users or groups. This ensures the built-in templates always stay up to date without affecting your custom configurations.

Selectors: object-level precision

A selector restricts a privilege to objects matching certain properties. For example:tags:qa
This allows add a privilege only on VMs tagged qa.

What makes this mechanism powerful is its dynamic nature. Selectors are evaluated in real time.
In case the users subscribed to VMs changes, if the qa tag is added to an existing VM, and the user have a read privilege, he will see that VM appear as a new object — the user will receive an add event, not an update. Conversely, if the tag is removed, he will receive a remove event: the VM disappears from his scope.

Events are always from the user's perspective, not XOA's. For XOA, it is a simple tag update. For the ACL user, it is an object entering or leaving their scope.

This enables very practical use cases: a single tag is enough to grant or revoke access to a resource, without touching roles or privileges at all.

Assigning Roles to Users and Groups

A role can be attached to a user or a group. A user's effective roles are the union of their direct roles and those of their groups.

REST API integration

All endpoints are exposed through the REST API:

GET/POST /acl-roles — list and create roles
PUT/DELETE /acl-roles/{id}/users/{userId} — attach/detach a role to a user
PUT/DELETE /acl-roles/{id}/groups/{groupId} — attach/detach a role to a group
GET/POST /acl-privileges — list and create role's privileges
POST /acl-roles/{id}/actions/copy — copy a role

Each REST API endpoint declares the required privileges to access it via the swagger UI. If an endpoint declares none, it is admin-only.

A concrete example

Alice is a member of the QA team. She needs to be able to start and stop VMs in her test environment, but must not touch anything in production.

With ACL v2:

Create a QA Operator role with following privileges:
- {resource: 'vm', action: 'read', effect: 'allow', selector: 'tags:qa'}
- {resource: 'vm', action: 'start', effect: 'allow', selector: 'tags:qa'}
- {resource: 'vm', action: 'stop', effect: 'allow', selector: 'tags:qa'}
Attach this role to Alice (or her group)

That's it. Alice cannot touch production VMs, and any attempt is blocked with an explicit error.

Another concrete example

Bob is allowed to rename VMs, but only while they are running — to prevent renaming VMs that are off and might be part of an automated process.

With ACL v2:

Create a Running VM Renamer role with following privilege:
- {resource: 'vm', action: 'read', effect: 'allow', selector: 'power_state:Running'
- {resource: 'vm', action: 'update:name_label', effect: 'allow', selector: 'power_state:Running'
Attach this role to Bob

Bob can rename and see any running VM.

One last example

Carol can see all VMs in the infrastructure, except those tagged prod.

With ACL v2:

Create a Non-Prod VM Reader role with two privileges:
- {resource: 'vm', action: 'read', effect: 'allow'} no selector, grants read access to all VMs
- {resource: 'vm', action: 'read', effect: 'deny', selector: 'tags:prod' explicitly denies access to production VMs
Attach this role to Carol

Since deny always takes precedence over allow, Carol can browse the full VM list — except production VMs, which are completely invisible to her.

ETA on master: early April
Already testable on mra-acl-v2 branch, but not yet finished
List of possible actions (by resource)

{
  update: {
    name_label:true,
    name_description:true,
    ...
  }
}

is translated into -> update:name_label, update:name_description, ...

Please note that ACL v2 is currently only accessible via the REST API. Support in the XO6 user interface will be available later.

MathieuRA

@acebmxer Yes, thanks.
The error unable to read properties of undefined is clearly unexpected. I will investigate.

You probably have a more detailed error log on the xo server side. Can you paste it here?

MathieuRA

@acebmxer

Sorry, I may not have been clear.

/rest/v0/vms/:id/dashboard is an endpoint on the XO REST API.

Therefore, you need to make an HTTP GET request to <xo-url>/rest/v0/vms/<your-vm-id>/dashboard.

You can do this directly with your browser, or from Swagger if you prefer.
(<xo-url>/rest/v0/docs)

MathieuRA

Hello.

Could you please run the request GET /rest/v0/vms/<your-vm-id>/dashboard and check if the endpoint is working?

Team - XO Backend

Posts

closed feat(backups): improve incremental replication #9635

closed feat(xo-server): use index for getAllUnhealthyVdiChainsLength #9622

closed fix(backups): better handling of generator cleanup #9557

ACL v2: Fine-grained access control in Xen Orchestra

What changes

ACL v2: REST API exclusive

Key concepts

Roles and privileges

Built-in roles

Selectors: object-level precision

Assigning Roles to Users and Groups

REST API integration

A concrete example

Another concrete example

One last example

Member List