Hierarchy under test

1. Clients
2. Clusters
3. Nodes
4. VMs / CTs
5. Templates
6. Storage
7. Networks

Permissions cascade down this tree. Every level is checked for what each account can see and what it can change.

Four dimensions

• GUI

  Real interface

  The suite drives the real controls — menus, tabs, buttons and context menus — exactly as each user would, and records what is shown, hidden or disabled.

• API

  Direct calls

  The same operations are sent straight to the API. Used where the product has no GUI control or the account's permissions hide it from the interface — always flagged in the report.

• Isolation

  Leak sweeps

  Every read — lists, dashboards, searches, maps and topology — is checked to return only the account's own resources. Any foreign client, cluster, node, VM or CT counts as a leak.

• Security

  Write-isolation probes

  Management actions — create, edit, delete, power, migrate, clone — are attempted outside the account's entitlements and must be refused. API rate limiting and account lockout are tested too.

Accounts tested

15 accounts cover every permission scope: global (super-admin, admin and read-only), client, cluster, node and individual VM/CT, each with Admin, Operator or Viewer roles — plus an account with no permissions at all, which must see and do nothing.

How to read the results

• PASSThe account behaved exactly as expected: allowed where entitled, blocked where not.
• FAILThe result differs from what the permission model requires.
• SKIPThe check does not apply to that account or environment, so it counts neither as pass nor fail.
• LEAKSThe account reached data outside its assignment. The target is always zero.
• CORRECT BLOCKSForbidden actions that were denied exactly as they should be.