Skip to content

Roles & permissions

Cloud Digit uses role-based access control (RBAC) at two scopes: organization roles and project roles. A user's effective permissions are the union of their org role and their per-project role.

The two scopes

graph LR
    User[User identity]
    User --> O[Organization role<br/>Owner / Admin / Billing / Member / Read-only]
    User --> P1[Project role · arctic<br/>Project Admin / Member / Read-only]
    User --> P2[Project role · polar<br/>Project Admin / Member / Read-only]
    O -.applies across org.-> Apply1
    P1 -.applies inside one project.-> Apply2
    Apply1[Org-level permissions]
    Apply2[Project-level permissions]

A user might be Member of the org (so they can sign in and read org-level metadata) and Project Admin of one specific project (so they can do anything inside that project, but not touch other projects).

Built-in organization roles

Role Can sign in Manage members Manage billing Create projects Resources
Owner ✓ ✓ ✓ ✓ Full, all projects
Admin ✓ ✓ — ✓ Full, all projects
Billing ✓ — ✓ — — (read-only on metadata)
Member ✓ — — — Per-project assignment required
Read-only ✓ — — — View-only across assigned projects

What "Owner" means in practice

  • The only role that can:
    • Reassign the Owner role to someone else (you must always have at least one Owner)
    • Change billing identity (TIN / BIN / RJSC) — requires KYC re-verification
    • Suspend or close the organization
  • Can do everything Admins can do, plus the above

What "Admin" means

  • Can do everything Owner can do except billing-identity changes and org closure
  • Typical for the day-to-day platform / cloud admin who doesn't sign cheques

"Billing"

  • Sees invoices, balance, transactions, payment methods
  • Can top up via MFS / bank transfer
  • Cannot create or modify resources
  • Good for finance teams that need to pay bills but shouldn't be touching infrastructure

"Member"

  • Default for engineering staff
  • Sees only the projects they're assigned to (see project roles below)
  • Cannot manage org members or billing

"Read-only"

  • View across every project they're assigned to, edit nothing
  • Use for: NOC operators on watch, internal auditors, junior staff in training

Built-in project roles

Project roles apply only to a single project.

Role Create / modify resources Manage project members Manage project settings Quota changes View only
Project Admin ✓ ✓ ✓ ✓ n/a
Member ✓ — — — —
Read-only — — — — ✓

"Project Admin"

  • Full control inside the project: create / delete any resource, manage members, configure quotas, change project settings
  • Cannot create new projects (that's an org-level Admin / Owner action)
  • Cannot see other projects unless separately assigned to them

"Member"

  • Day-to-day operator: create VMs, mount volumes, manage networks
  • Cannot manage project members or change project-level settings
  • Cannot approve quota increases (those require Project Admin)

"Read-only"

  • See everything but click nothing that mutates
  • Combine with ACCOUNT → Financial → Read permissions for project-level cost visibility without write access

Assigning roles

Org role

Org settings → Members → edit a member → change role.

Project role

Open project → sidebar Access → +Add member, or edit an existing entry.

Project Access page Project-level Access. Members here are a subset of the org members.

You can only add to a project someone who is already a member of the parent organization. If you need to grant project access to someone external, invite them to the org first (with role Member), then add them to the project.

Role-change rules

Rule Why
You can grant a role you hold yourself Cleanest delegation; prevents privilege escalation
You cannot remove yourself from your own last Owner role The org must always have an Owner
Project Admin can change project roles for users already in the project Self-service operation
Project Admin cannot invite new org members Org-level concern

Custom roles (preview)

In addition to the built-ins, Cloud Digit supports custom roles with finer-grained permissions, in preview. A custom role bundles individual service:action permissions and can be scoped to a specific tag selector.

```yaml

Example: an "ML team" role that can only touch GPU resources

name: ml-team scope: project permissions: - compute.servers.create - compute.servers.read - compute.servers.delete - compute.images.read - ai-gpu.notebooks.create - ai-gpu.notebooks.delete - ai-gpu.inference.read - storage.volumes.create - storage.volumes.read selector: tags: team: ml ```

Custom roles are available on request (open a ticket) and visible in Project Settings → Custom roles.

Permission cheatsheet — service × role

The matrix below summarises what each built-in role can do per major service area. A = full, W = limited write, R = read-only, — = no access.

Service Org Owner Org Admin Org Member + Project Admin Org Member + Project Member Project Read-only
Servers (VMs) A A A A R
Volumes A A A A R
Networking A A A A R
Kubernetes A A A A R
Object Storage A A A A R
Orchestration A A A A R
Key Manager A A A W (read & use, not destroy) R
Project Access (IAM) A A A — —
Project Quota A A A — R
Project Settings A A A — R
Financial — project A A A R R
Org Settings A A — — —
Org Members A A — — —
Org Billing A — — — —

Combining with API tokens

API tokens are also scoped to a role and a project (or org). See API tokens & service accounts. A token can never grant more than the user who issued it.

Audit trail

Every role assignment and revocation is logged with:

  • Actor (who made the change)
  • Subject (whose role changed)
  • Before / after values
  • Scope (which org or project)
  • Timestamp + source IP

Available in the audit log and exported in audit packs.