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.
| Tier | Architect |
| JTBD | ”Assign every user to the smallest role that lets them do their job.” |
| Personas | Platform Engineer · Security/Compliance · FinOps Lead |
| Prerequisites | M3.1.L1: the policy table |
| Time | 9 minutes |
| Bloom verb | Describe (Understand), Match (Apply), Recognize (Analyze) |
1. Concept
Three roles come with the product: Viewer, Editor and Admin. Between them they cover about 80% of what anyone needs, 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 read everythingEditor 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; 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, notifications, recommendations (apply/dismiss = recommendation:update), dashboards, AI virtual keys View-only on the administrative entities: roles, users, organisation, assignments, cloud accounts, AI models 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 every Editor/Admin boundary 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 (a FinOps Analyst who wants to dismiss but not apply recommendations needs a custom role) in exchange for a clear, auditable default. The custom-role path remains open for the 20% of 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. M3.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 always logged: - Who made the change (assigner) - Who received the change (assignee) - Old role → new role - Timestamp - Reason (optional field: recommended for compliance)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 giving Editors the recommend-apply capability they actually needed and Admin only to 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 on the same entity, so no role, system or custom, can grant one without the other. Give them Editor (or Viewer + recommendation:update) and enforce the apply restriction in the remediation approval gate, which is the control designed for it. The verb set is uniform view / create / update / delete per entity; there is no recommendation:apply or recommendation:dismiss policy, which rules out D. Separating the two actions is a job for the approval gate (M2.3.L3), not for RBAC. 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;
Show answer
Correct: D. Editor is probably too restrictive somewhere, so people got promoted to Admin as a workaround Audit the recent admin-tier actions; in most cases, 1-2 missing Editor capabilities would solve the issue. 40% Admin density is a red flag. The fix is usually a small Editor adjustment or a focused custom role, not blanket Admin grants. Quarterly RBAC reviews catch this pattern.
5. Apply
Assign system roles in Settings → Users. For each user, the assignment screen shows the effective policy set so you can confirm before saving.
A useful pre-save check: read the Effective Permissions summary at the bottom of the assignment dialog. It enumerates the (entity, action) pairs the user will have. 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
- T3.M3.3.L1: What gets audit-logged
Glossary terms touched
System role · Viewer · Editor · Admin · Custom role