Access Control
Members, roles, groups, and service accounts in your provider org
Access control
Access control covers who can act in your provider organization:
| Area | Typical use |
|---|---|
| Members | Human users invited to your org |
| Roles | Permission bundles (RBAC) |
| Groups | Collections of users that inherit roles |
| Service accounts | Machine identities for CI/CD and nr CLI |
Roles and permissions
NodeRings uses role-based access control (RBAC). Each organization starts with five built-in roles. You can also create custom roles and assign any combination of permissions.
| Role | Access |
|---|---|
| Owner | Full access, including organization delete and billing/payouts. Keep at least one Owner. |
| Administrator | Manage users, roles, and resources. Cannot delete the organization or change billing/payouts (billing remains read-only). |
| Billing | Subscriptions, payment methods, invoices, Connect, and payouts. Organization profile is read-only. |
| Operator | Day-to-day infrastructure: agents, nodes, platforms, IPAM, templates, network, tickets. No IAM admin or billing write. |
| Viewer | Read-only across resources. |
Reserve Owner for people who manage billing and organization identity. Use Administrator for operational admins, Billing for finance, and Operator for infra on-call.
| Permission | Owner | Administrator | Billing | Operator | Viewer |
|---|---|---|---|---|---|
| Addon | |||||
| Agent | |||||
| Cloudinittemplate | |||||
| Cpucore | |||||
| Domain | |||||
| Environmentvariable | |||||
| Exchangerate | |||||
| Group | |||||
| Invite | |||||
| Invoice | |||||
| Ipam | |||||
| Livevalidation | |||||
| Manualpayout | |||||
| Metadata | |||||
| Metric | |||||
| Node | |||||
| Nodeplacement | |||||
| Notificationsetting | |||||
| Notificationtemplate | |||||
| Oauth2 | |||||
| Organization | |||||
| Payment | |||||
| Paymentmethod | |||||
| Payoutconfiguration | |||||
| Payoutinvoice | |||||
| Permission | |||||
| Plan | |||||
| Platform | |||||
| Preflight | |||||
| Providerconnect | |||||
| Providercustomer | |||||
| Providerdashboard | |||||
| Providerdashboardplanstab | |||||
| Providerplan | |||||
| Providerreview | |||||
| Refund | |||||
| Region | |||||
| Role | |||||
| Secret | |||||
| Serviceaccount | |||||
| Sshkey | |||||
| Subscription | |||||
| Usagereport | |||||
| User | |||||
| Vmtemplate |
Service accounts
Service accounts are machine identities for the nr CLI, CI/CD, and API automation.
Create the service account
A human admin creates the service account in the organization.
Generate a token
Generate an API token. It is shown once: store it in your secret manager immediately.
Assign a role
Grant the service account a role scoped to exactly what the automation needs.
Optional allowed IPs restrict which source networks may use a token, a good safeguard for CI runners with stable egress addresses.