Skip to main content

​
Overview

Polystack Extended RBAC is the per-action access control layer of the Polystack Platform. It builds on the platform’s existing identity and policy stack (Polystack Identity tokens, project scoping, service-level role policy) and adds a privilege catalog so cloud operators can construct custom roles that grant or deny specific Dashboard actions. Each grant can optionally be scoped to a tag condition — for example, “this role can act on instances tagged env=staging only”.
Prerequisites
  • An administrator account on the Polystack Dashboard with the rbac_admin privilege (or the built-in admin role)
  • The Polystack Platform identity layer enabled (default on every cluster)
  • The RBAC gateway enabled in the deployment console → Configuration for cluster-wide enforcement on every direct platform service API call

​
What Fine-Grained RBAC Lets You Express

Extended RBAC was designed to express the access patterns customers expect from mature private cloud platforms. Concrete examples:

​
Levels of Access Control

Extended RBAC is one layer in a five-layer access stack: A typical production setup uses all five.

​
Enabling the RBAC Gateway

Extended RBAC’s management surface is always active — privileges, custom roles, tag conditions, and the audit log are available from the Dashboard out of the box. The RBAC gateway is the additional switch that decides whether Extended RBAC enforces every direct platform service API call cluster-wide, or only the calls that go through the Dashboard extension APIs. The gateway is enabled through the deployment console — there is no other supported configuration path.

Open the deployment console → Configuration

From the deployment console, navigate to Configuration.

Enable the RBAC gateway

Locate the Enable RBAC Authorization Gateway toggle and switch it on. Save the configuration.

Run reconfigure

From the deployment console → Operations, run a reconfigure for the Dashboard service. The reverse proxy is regenerated with the gateway active and reloaded without downtime.

Verify

Open the Dashboard. From this point forward, every direct platform service API call passes through Extended RBAC’s enforce layer before reaching the backend service.
The cluster now enforces Extended RBAC on every direct API call.
Rolling back is symmetrical — flip the toggle off and reconfigure. No database changes are needed; privilege grants and audit history persist regardless of whether the gateway is on.

​
What You Can Control Per Service

Extended RBAC privileges map one-to-one to the action menus the Dashboard exposes. The lists below are the actual GUI actions available per service — every entry is independently grantable to a custom role, and most can be tag-conditioned.
Primary action: Create Instance.Row actions (organized into submenus in the More dropdown):
  • Instance Status: Start, Stop, Lock, Unlock, Reboot, Soft Reboot, Suspend, Resume, Pause, Unpause, Shelve, Unshelve
  • Related Resources: Attach Interface, Detach Interface, Attach Volume, Detach Volume, Associate Floating IP, Disassociate Floating IP, Manage Security Group
  • Backups and Snapshots: Create Snapshot
  • Clone and Template: Clone, Convert to Template
  • Configuration Update: Resize, Confirm Resize or Migrate, Revert Resize or Migrate, Adjust Resources (live resize — vCPU / RAM / device hot-add), Change Password, Rebuild Instance
  • Other row actions: Console, Edit Instance, Modify Instance Tags, Delete
  • Batch actions: Start, Stop, Reboot, Soft Reboot, Delete
  • Admin-view extras: Migrate, Live Migrate, Bulk Live Migrate
Each item is independently grantable. Console, Create Instance, and Delete are three separate privileges — they are not bundled.Script execution endpoints — Polystack has no general “exec arbitrary command on a running VM” endpoint. Script execution flows through two distinct Compute API endpoints, each gated by its own privilege:Implications: a role can be granted Create Instance while User Data attachment is independently allowed or denied; a role with Start / Stop / Reboot / Resize does not automatically get changePassword. Both privileges can be tag-conditioned (for example, allow changePassword on env=staging instances only).
  • Instance Snapshots: Edit, Browse Files (file-level recovery), Rollback, Create Instance, Create Volume, Delete
  • Images: Create, Edit, Browse Files, Create Instance, Create Volume, Delete; admin extras — Manage Access, Manage Metadata
  • Flavors: Create, Manage Access, Delete (read-only catalog access is itself a separate privilege)
  • Keypairs: Create, Delete
  • Server Groups: Create, Delete, Create Instance into the group
  • VM Templates: Create Template, Edit, Deploy, Delete; admin — Manage Access
  • Hypervisors (admin): Host Management
  • Bare Metal Nodes (admin): Create, Manage State, Edit, Power On, Power Off, Inspect, Set Maintenance, Clear Maintenance, Set Boot Device, Create Port, Create Port Group, Delete
Volumes:
  • Primary actions: Create, Accept Volume Transfer
  • Row first action: Edit
  • Submenu Data Protection: Create Snapshot, Create Backup, Create Image, Clone Volume, Restore
  • Submenu Instance Related: Bootable, Create Instance, Attach, Detach
  • Submenu Capacity and Type: Extend Volume, Change Type
  • Other row actions: Create Transfer, Cancel Transfer, Delete
  • Admin extras: Update Status, Migrate, Live Retype
Snapshots: Create, Edit, Restore, Create Volume, DeleteBackups: Create, Edit, Browse Files (file-level recovery), Create Volume, DeleteVolume Types (admin): Create, Manage QoS, Set Provisioning, Manage Access, Create Encryption, Delete Encryption, Edit, Delete
  • Networks: Create Network, Edit, Create Subnet, Delete
  • Routers: Create, Edit, Connect Subnet, Disconnect Subnet, Set Gateway, Close Gateway, Enable SNAT, Disable SNAT, Delete
  • Floating IPs: Allocate, Edit, Associate, Disassociate, Create Port Forwarding, Release
  • Security Groups: Create, Edit, Create Rule, Delete
  • Ports: Create, Edit, Attach Instance, Associate FIP, Disassociate FIP, Detach, Modify QoS, Manage Security Group, Delete
  • Load Balancers: Create, Edit, Associate FIP, Disassociate FIP, Delete
  • DNS Zones: Create, Update, Create Records, Delete
  • Projects: Create, Edit, Delete, Manage Quota, Manage User, Manage User Group, Enable, Forbidden, Modify Tags
  • Users: Create, Edit, System Role, Set Default Project, Password, Reset MFA (admin escape hatch), Enable, Forbidden, Delete
  • Roles: Create, Edit, Delete
  • Domains: Create, Edit, Enable, Forbidden, Delete
  • User Groups: Create, Edit, Manage User, Delete
  • Secrets: Create, Delete
  • Containers: Create, Delete
  • Certificates (under Network → Certificate): Create, Delete
  • Stacks: Create, Edit, Abandon, Delete
  • Audits: Create, Delete
  • Audit Templates: Create, Delete
  • Action Plans: Start (execute the plan), Delete
Goals and Strategies are read-only catalogues with no actions to gate.
  • Segments: Create, Update, Add Host, Delete
  • Hosts: Update, Delete
  • Notifications: Create, Delete
  • Clusters: Create, Delete, Get Cluster Config, Show Certificate, Sign Certificate, Resize, Upgrade, Launch Dashboard
  • Cluster Templates: Create, Edit, Create Cluster, Delete
Some Polystack-developed actions (Clone, Convert to Template, Adjust Resources, Browse Files, Rollback, Reset MFA, Sign Certificate, Bulk Live Migrate) are gated only by Extended RBAC. For these actions Extended RBAC is the sole enforcement layer, even when the cluster gateway is off.

​
Manage RBAC from the Dashboard

Extended RBAC is managed from three pages under Identity in the admin view of the Dashboard. The pages have separate responsibilities — managing roles is intentionally distinct from editing what a role can do, and from reviewing what changed.

​
Roles — Identity → Roles

The existing Roles list is enhanced with Extended RBAC awareness. It remains the single place where roles are created, deleted, and assigned to users.

​
RBAC Permissions — Identity → RBAC Permissions

The dedicated permissions editor — its single responsibility is “given a custom role, edit what privileges it has.” No role create / delete / assignment lives here.

Pick a Custom role

The role selector at the top of the page lists every Custom role. System roles do not appear because they cannot be edited.

Toggle privileges in the matrix

Privileges are grouped by service (Compute, Storage, Network, Identity, Key Manager, Orchestration, Optimization, Instance HA, Container Infrastructure) and by category within each service (for example, Instance Lifecycle, Instance Actions, Backups and Snapshots). Each row has:
  • A checkbox to grant or revoke the privilege
  • A hover tooltip showing the privilege description, prerequisite chain, and any associated service-level policy rule
  • A condition chip if a tag condition is attached to this grant

Add a tag condition

Click + Add Tag Condition on any granted privilege to scope it. The tag condition modal lets you pick a tag key, an operator (equals, not_equals, contains, starts_with, any_of), and a value. Conditions are reusable — one “env=prod” condition can be referenced by many grants.

Preview Effective Rules

Before saving, click Preview Effective Rules to simulate what a real user holding this role would be allowed to do against representative resources. The simulator runs the same enforcement engine the live request path uses.

Save

On Save, the backend validates that prerequisite chains are intact. If a privilege you toggled requires a prerequisite that is not yet granted, a Missing Prerequisites modal lists them and offers to enable them automatically. The grant batch is written atomically with an audit log entry and a cross-node invalidation event — every Dashboard and apiserver node sees the change within 5 seconds.
Your changes are live within 5 seconds across the entire cluster.

​
RBAC Audit Log — Identity → RBAC Audit Log

Every change made through Extended RBAC is recorded in an append-only log, queryable from the Audit Log page. Each row shows actor, action, target, source IP, request ID, and an old → new diff. Expand a row to see the full JSON diff.
The Audit Log page is also reachable as View History from any Custom row on the Roles page and as Audit Log from the header of the RBAC Permissions page.

​
Examples — Common Role Designs

These are example role designs you can build using the privilege matrix and tag conditions described above.
Grant instance.start, instance.stop, instance.reboot, instance.suspend, instance.resume, instance.pause, and instance.unpause. Withhold instance.resize, instance.adjust_resources (live resize), and instance.edit. Operators keep workloads alive without changing their shape.
A role scoped to project prod that grants instance management privileges only when the target VM carries the tag team=db. The user holds zero privileges on instances tagged team=web or team=api.
Grant volume.attach, volume.detach, volume.read. Withhold volume.create and volume.delete. The operator wires existing storage but cannot add or remove volumes.
Grant only *.list and *.read privileges. Even when the user calls aggregator endpoints, Extended RBAC filters the response rows so the auditor sees only resources their tag conditions permit.
Grant instance.delete and volume.delete, nothing else. Useful for end-of-life automation.
The admin role remains a deliberate platform bypass. Patterns of the form “admin has zero privileges on project X if denied” are not expressible — the only ways to constrain admin are disable_admin_bypass (cluster-wide) or require_system_scope_for_admin (force system-scope tokens for admin actions).

​
Tag Conditions

Tag conditions let one privilege grant target only resources matching a tag — without creating multiple roles. They are evaluated against the resource being acted on (instance tags, volume metadata, network tags, etc.). Build conditions in the + Add Tag Condition modal on the RBAC Permissions page. Conditions are reusable across roles — one “env=prod” condition can be referenced by many grants.

​
Enforcement Model

When Extended RBAC evaluates whether a request is allowed:

Anonymous check

Requests with no user context are denied.

Admin bypass

The built-in admin role passes through unless disable_admin_bypass is set. An emergency override is available for incident response.

Privilege lookup

Resolve the request to a privilege code. Unknown URLs fall through to allow (compatibility mode) by default; switch to fail-closed in strict deployments.

Prerequisite walk

Walk the prerequisite chain (max depth 8). A grant with a tag condition does not satisfy an unconditional prerequisite — this prevents bypass.

Rule resolution

Collect every grant the caller’s roles produce, sort by priority descending, and return the first rule whose tag condition matches the target.

Audit

Role and grant changes are recorded unconditionally. Allow / deny decisions are recorded when audit-deny logging is enabled.

​
Cross-Node Invalidation

Multi-node deployments stay coherent through a transactional invalidation log. Every role mutation, privilege grant, or condition change is appended to the log in the same database transaction as the underlying change. Other nodes poll the log every couple of seconds and refresh their local caches when they see a new event — privilege changes propagate to every node within ~5 seconds without restarting any service.

​
Best Practices

The built-in roles cover most cases. Reach for a Custom role when you have a specific exception — “this team needs to resize but not delete” — rather than rebuilding from scratch.
Tag every resource with env=prod, env=staging, or env=dev, and create one Custom role per privilege scope, scoped to the relevant tag. Avoids combinatorial role explosion.
Use Preview Effective Rules on the RBAC Permissions page to simulate a role change against representative users and resources before applying it.
Disabling admin bypass globally is rarely worth the operational risk. Audit the bypass log and tighten via require_system_scope_for_admin if your compliance framework requires project-scoped admin separation.
The audit log retention defaults to one year. Forward to your SIEM or long-term object storage for longer compliance windows.

Roles

Manage Polystack Identity roles — create, assign, implied-roles

Policy Management

Service-level policy YAML hardening

Multi-Factor Auth

Strengthen sign-in with TOTP MFA