Outcome
By the end of this lesson, you will be able to describe the three system roles, match a job function to the right system role, and recognize when a system role does not fit and a custom role is warranted.
| Prerequisites | M4.1.L1: the policy table |
| Time | 9 minutes |
1. Concept
Three roles come with the product: Viewer, Editor and Admin. Between them they cover most of what people need, without anybody having to build a role.
You cannot edit them. They are defined in the product and changed only by ZopNight engineering, which is what makes them safe to reason about: an Admin means the same thing in your organisation as in anybody else’s. What you can do is assign them, or build your own roles alongside them.
ROLE POLICY ACTIONS COVERAGE──────────────────────────────────────────────────────────────────────Viewer view only, on every entity except billing read everything but billingEditor full view / create / update / delete on operate, not administer the operational entities; view-only on the administrative onesAdmin all policies, allResources: everything own the organisation Editor has, PLUS user, role, assignment, organisation, and the credential-connection surfaces (cloud-account, AI model)The progression is additive: Viewer ⊂ Editor ⊂ Admin. The line that matters is between Editor and Admin, and it is not “how much can you change” but “can you change who can change things, and can you connect a credential.” Promoting up the chain only adds capabilities; demoting only removes them.
Role boundaries
VIEWER Read everything except billing; modify nothing Sees: resources, schedules, costs, recommendations, audit log Cannot: start/stop a resource, create a schedule, apply a rec Use for: junior engineers, auditors, finance partners, executives
EDITOR Full CRUD on the operational entities: resources (start/stop), schedules, resource groups, overrides, recommendations (apply/dismiss = recommendation:update), budgets, dashboards, AI virtual keys View-only on the administrative entities: roles, users, organisation, assignments, cloud accounts, AI models, and also on teams and notifications Use for: platform engineers, FinOps analysts, SREs
ADMIN All policies, allResources. Everything Editor has, plus: - role:create / role:update / role:delete - user:create / user:update / user:delete - assignment (assign roles to users) - organisation:update - cloud-account:create/update/delete - ai-model:create/update/delete Use for: the org owner, security / compliance lead, platform ownersTwo rules explain most Editor/Admin boundaries you will meet:
- Connecting a credential is Admin. A cloud account and an AI model registration both accept a provider secret, so both are Admin-only to mutate and view-only for Editor. A budget-bounded consumption artifact over an already-connected provider (an AI virtual key) is not a credential connection, so Editor gets full CRUD on it.
- Changing who can change things is Admin. Role, user, assignment and organisation are Admin-only.
Why not just one role per person
These three roles handle most assignments because the cost-ops job ladder clusters into three tiers of need: read-only stakeholders (finance, exec, junior), operational practitioners (engineers, analysts), and administrative owners (leads, security). A role-per-person would explode into hundreds of policy combinations, half of them unused, none of them auditable.
The system-role design is a deliberate trade. You sacrifice some granularity (an analyst who should manage budgets but never touch schedules needs a custom role) in exchange for a clear, auditable default. The custom-role path remains open for the cases that need it (covered in L3).
Why Editor cannot manage RBAC
The Editor role intentionally excludes role management. Editors can change cost (apply recommendations, edit schedules) but not change who can change cost. That separation prevents a compromised Editor account from escalating itself to Admin. It also means RBAC drift cannot happen silently: every role change is an Admin action and is audit-logged.
This is a common point of confusion: customers ask “why can’t my Editor change a teammate’s role?” The answer is the privilege-escalation prevention. If the Editor truly needs that capability, the answer is Admin (with stronger account protection like SSO + MFA), not loosening Editor.
How system roles compose with team scoping
A user with the Editor system role can still be team-scoped so they only have Editor permissions within a specific team. The role defines what actions are possible; the team scope defines which subset of data those actions apply to. M4.1.L4 covers team scoping in depth. For now, remember: the system role and the team scope are independent dimensions.
Audit trail considerations
ROLE ASSIGNMENT CHANGES are logged like every other change: - Who made the change (the signed-in user) - What changed (method, path and request body, which names the assignee and the role) - TimestampThe log has no “old role” column and no reason field. To see the previous role, find the earlier assignment entry for the same user; record the reason in your own ticketing system.
Quarterly reviews typically pull this log to confirm: no surprise Admins, no demoted Editors who still have lingering access, no role changes by departed users.
How ZopNight uses the system roles
SYSTEM ROLE TYPICAL HEADCOUNT (mid-size customer, ~50 users)──────────────────────────────────────────────────────────────Viewer 15-20 (finance, exec, junior eng, auditors)Editor 25-30 (platform eng, FinOps analysts, SREs)Admin 2-5 (org lead, security lead, FinOps owner)Custom 2-5 (edge cases: compliance-only Auditor, FinOps Analyst with selective recommend)The 2-5 Admins is the most-watched number. More than 5 Admins in a mid-size org usually indicates a role-design problem; capabilities have leaked upward because Editor was too restrictive somewhere, and instead of fixing Editor or creating a custom role, the workaround was “just make them Admin.”
2. Demo
A mid-size customer’s role assignment after a clean review:
TEAM: 15 users─────────────────────────────────────────────────────8 engineers Editor1 senior engineer Admin1 SRE lead Admin3 PM / product Viewer1 finance partner Viewer1 security/compliance Custom (Viewer + audit-log:view + report:view extended)─────────────────────────────────────────────────────TOTAL 2 Admins · 8 Editors · 4 Viewers · 1 CustomThe customer started with 6 Admins (every engineer-lead was Admin “for convenience”). The review reduced to 2 by moving the leads who only applied recommendations and ran schedules down to Editor, which already allows both, and keeping Admin for the 2 people who manage roles + cloud accounts. No capability was lost; the blast radius of a compromised account dropped from 6 to 2.
3. Hands-on (6 min)
For your own team, map current role counts:
HEADCOUNT BY ROLE: Admin _____ (target: 2-5 for mid-size org) Editor _____ Viewer _____ Custom _____
For each Admin, write the one specific capability that requires Admin(not Editor + custom). If you cannot name one, that person is over-permissioned.
Admin #1 (name): __________ Required Admin capability: __________Admin #2 (name): __________ Required Admin capability: __________Admin #3 (name): __________ Required Admin capability: __________A clean output: every Admin has a specific reason. A messy output: Admins for whom no Admin-only capability is required.
4. Knowledge check
Q1
A FinOps Analyst needs to view recommendations and dismiss them, but NOT apply them (each apply is high-risk and goes through a separate approval). The right answer:
A. Editor: gives full access
B. A custom role with recommendation:dismiss but not recommendation:apply
C. Admin
D. RBAC cannot express this
Show answer
Correct: D. Applying and dismissing are both recommendation:update, so no role, system or custom, can grant one without the other. There is no recommendation:apply or recommendation:dismiss policy, which rules out B. Give them Editor (or Viewer + recommendation:update) and enforce the apply restriction in the remediation approval gate (M2.3.L3). This is the most common RBAC request that has a non-RBAC answer.
Q2
A new engineer joins. The right starting role is:
A. Admin so they can do anything during onboarding
B. Viewer: they need read-only first
C. Editor: most engineers need to create/modify resources
D. Random: pick one and adjust
Show answer
Correct: C. Promote to Admin only when there is a specific admin-tier need (managing roles, rotating cloud creds). Editor is the default for engineers. Admin is reserved for people who manage RBAC and cloud account credentials. The principle: start at the smallest role that lets the person do their job; promote on demonstrated need.
Q3
An organization has 8 Admins out of 20 users. The most likely explanation:
A. The org needs all of them
B. Normal for an organisation of that size
C. The product requires it
D. Role design has leaked upward
Show answer
Correct: D. Editor is probably too restrictive somewhere, so people got promoted to Admin as a workaround. 40% Admin density is a red flag. Audit the recent admin-tier actions: usually one or two missing capabilities explain it, and a focused custom role fixes it without blanket Admin grants.
5. Apply
Assign system roles in Settings → Organization, where the member list lives. The role picker shows a one-line summary of what each role grants.
A useful pre-save check: before saving, open the role in Settings → Roles and read its policy list. That list is exactly what the user will be able to do, before any team scope narrows it. If anything surprises you, the role is wrong or the team scope needs adjusting.
Related lessons
- L1: The policy table
- L3: Custom roles (next)
- L4: Team-scoped roles
- T4.M4.3.L1: What gets audit-logged