Access Control
Members, groups, roles, invites, and service accounts for client orgs
Manage who can access your client organization at /organization/members.
Tabs:
| Tab | Purpose |
|---|---|
| Users | Members and their roles |
| Groups | Group membership for bulk role assignment |
| Invites | Pending and sent invitations |
| Roles | Custom roles and permissions |
| Service accounts | Programmatic API access for automation |
Roles and permissions
NodeRings uses RBAC: permissions are grouped into roles, and roles are assigned to users, groups, or service accounts.
Client orgs use client-scoped permissions (virtual machines, billing, firewall, SSH keys, tickets, etc.). Provider-only permissions (agents, nodes, plans, preflight) are hidden when your active org is a client.
Each organization starts with these built-in roles:
| Role | Access |
|---|---|
| Owner | Full access, including organization delete and billing. Keep at least one Owner. |
| Administrator | Manage users, roles, and resources. Cannot delete the organization or change billing (billing remains read-only). |
| Billing | Subscriptions, payment methods, and invoices. Organization profile is read-only. |
| Operator | Day-to-day runtime: VMs, firewalls, backups, snapshots, SSH keys, Instant Apps, tickets. No IAM admin or billing write. |
| Viewer | Read-only across resources. |
Least privilege: Give members the minimum role they need. Prefer Operator for engineers who run VMs, Billing for finance, and reserve Owner for org identity and irreversible actions. Use groups when several people share the same access pattern.
Invites
Send an invite
Invites tab → enter email → choose a role → send.
Recipient accepts
They click the email link while signed in, or accept from Profile → Invites after signing up.
More detail: Organization → Invites.
Service accounts
Service accounts are for API and CI automation, not interactive login.
- Create a service account under Service accounts.
- Assign roles (same RBAC as users).
- Generate token: copy once; store securely.
- Call the API with
Authorization: Bearer <token>.
For provider-side automation patterns, see Provider Guides → Access control. Client orgs use the same token mechanism against client API endpoints their roles allow.