Outcome
By the end of this lesson, you will be able to name the four org-management policy families, explain which cloud roles bring them into ZopNight and which do not, and promote someone deliberately afterwards.
| Prerequisites | M4.9.L2 |
| Time | 9 minutes |
1. Concept
Four policy families control who can change access in ZopNight. The import withholds them from every built-in cloud role except the administrator roles.
role:* create / update / delete rolesuser:* create / update / delete usersassignment:* assign roles to usersorganisation:* org administration
WITHHELD for power-user roles (AWS PowerUserAccess, GCProles/editor, Azure Contributor) and for narrower roles.Even AWS IAMFullAccess maps only to view rights.
GRANTED for administrator roles: AWS AdministratorAccess,GCP roles/owner and Azure Owner link to the built-in Adminrole, which carries every policy.Why administrator roles are the exception
This is the case that makes the rule legible.
A PRINCIPAL WITH AWS PowerUserAccess CAN DO EVERYTHINGIN THAT AWS ACCOUNT EXCEPT MANAGE IAM.
The import keeps that line: the role links to thebuilt-in ZopNight Editor, with no role:*, user:*,assignment:* or organisation:*.
A PRINCIPAL WITH AWS AdministratorAccess CAN DO ANYTHINGIN THAT AWS ACCOUNT.
The import translates that literally too: the role linksto the built-in ZopNight Admin, including managing roles,users and assignments.Put differently: the import mirrors where your cloud draws the line between running infrastructure and changing access, and for administrator roles it adds no safety margin of its own. A tool that can import the ability to change the access model can import a wider access model on the next run, so for administrator roles the mapping does not protect you. The review step does. Read every proposal that links to Admin before you apply it.
Custom roles that carry IAM actions
The rules above belong to the curated mapping, the step that handles built-in roles such as AWS AdministratorAccess and PowerUserAccess, GCP roles/owner and roles/editor, or Azure Owner and Contributor. A custom cloud role goes through action translation instead, and that step translates what the role actually carries. If a custom role explicitly grants an IAM write (for example GCP iam.roles.create), the import proposes the matching ZopNight policy (role:create), and a custom AWS or Azure role that allows every action (*) links to Admin. This is deliberate. Here the review step is your control: read any proposed role that links to Admin or includes role:*, user:*, assignment:* or organisation:* before you apply it.
It is the same principle as everywhere else
You have now met this argument four times in this curriculum, in four different mechanisms. That repetition is deliberate.
M4.1 Editor cannot manage RBAC, so a compromised Editor cannot escalate itself to Admin.
M6.5 Role assignments are never writable via MCP at any tier, so an agent cannot hand its caller a different role.
M2.3 The Safety Gate fails closed on destructive levers, so absent evidence cannot authorise a delete.
M4.9 Org-management grants are withheld from power-user cloud roles, so importing a PowerUserAccess holder cannot grant the power to reshape access. Administrator roles are the exception, which is why you review every proposal that links to Admin.The common shape: the mechanism that bounds a capability should not be reachable by that capability. Where the mapping cannot guarantee that itself, as with cloud administrator roles, the review step holds the line.
What happens instead
For a power-user role, the import proposes everything else it can, and the org-management portion simply does not appear. There is no error and no Needs Attention entry: it is not an unresolved case, it is an excluded one.
A CLOUD POWER USER ARRIVES AS the built-in ZopNight Editor
A CLOUD ADMINISTRATOR ARRIVES AS the built-in ZopNight Admin: someone who can create users, edit roles, assign roles and administer the organisation
IF THAT IS NOT WHAT YOU WANT review the proposal before you apply it, and change that person's ZopNight role by hand afterwardsPromoting deliberately
Promotion happens later, by hand, from Settings -> Roles.
That is a SEPARATE, EXPLICIT, AUDIT-LOGGED action takenby an existing Admin.The distinction is not bureaucratic. An imported grant carries the intent of whoever wrote the cloud policy, possibly years ago and for unrelated reasons. A promotion in Settings carries the intent of the person clicking it, right now, about ZopNight specifically. Those are different quantities of consent and the product treats them differently.
How to plan around it
BEFORE the import: decide who your ZopNight Admins are.It should be a short list, and it is not the same aswho holds AdministratorAccess in AWS.
AFTER the import: anyone holding a cloud administratorrole arrives as Admin. Change the role of anyone not onyour list by hand, and promote the rest of the list.
M4.1.L2's guidance applies: for each Admin, name thespecific Admin-only capability they need. If you cannotname one, they are over-permissioned.In practice the ZopNight Admin list and the cloud administrator list overlap only partially, and noticing that is one of the more useful outcomes of running an import at all.
2. Demo
An import into an org with four cloud administrators:
CLOUD SIDE 4 principals hold AWS AdministratorAccess devops-lead@ sre-lead@ platform-eng-01@ (holds it for a migration, temporarily, for 8 months now) terraform-svc (a service account)
WHAT THE IMPORT PROPOSED devops-lead@ linked to the built-in Admin sre-lead@ same platform-eng-01@ same terraform-svc not shown: filtered out before the wizard (name ends in -svc, L2)
ALL THREE proposed with role:*, user:*, assignment:* and organisation:*, because Admin carries every policy.
No error and no Needs Attention entry. Reading the proposal is the only place to catch it.
WHAT THE TEAM DID NEXT Asked the M4.1.L2 question for each: name the specific Admin-only capability this person needs.
devops-lead@ "connects cloud accounts, manages roles" -> kept ADMIN sre-lead@ "...nothing, actually. They operate schedules and read reports." -> changed to EDITOR platform-eng-01@ "nothing. The migration ended." -> changed to EDITOR (and someone opened a ticket to remove their AWS AdministratorAccess too) terraform-svc never appeared
RESULT: 1 ZopNight Admin, from 3 imported Admins.
THE SECOND-ORDER OUTCOME The import did not just populate ZopNight. It surfaced that platform-eng-01@ had held AdministratorAccess in AWS for eight months past a two-week migration, which nobody had reviewed.
Running an import is one of the cheapest ways to get a fresh look at your cloud access model, precisely because it forces someone to read the principal list with a specific question in mind.3. Hands-on (6 min)
1. Before importing, write your intended ZopNight Admin list: ______________________________________________ How many? ______
2. Now list who holds administrator-equivalent access in your cloud: ______ How much do the two lists overlap? ______
3. Run an import. Check every proposed role for role:*, user:*, assignment:* or organisation:*. Administrator roles (linked to Admin) carry them, and so can a custom role with IAM actions. Any found, and what you did: ______
4. For each person you intend to promote to Admin, name the specific Admin-only capability: ______________ needs: ________________________ ______________ needs: ________________________ Any you cannot name is not an Admin.
5. Note anything the exercise surfaced about your CLOUD access model rather than ZopNight's: ______________________________________________Step 5 is frequently the most valuable output.
4. Knowledge check
Q1
A principal holds AWS AdministratorAccess. The import proposes a ZopNight role that:
A. Links to the built-in Admin role, which carries every policy, including role and user management
B. Carries the operational and reporting policies their grant implies, and excludes role:*, user:*, assignment:* and organisation:* entirely
C. Is placed in Needs Attention so that a person has to resolve it manually afterwards, by hand, before it applies
D. Is rejected outright as being far too broad a grant to propose safely at all to a customer’s organisation
Show answer
Correct: A. AdministratorAccess is on the curated list of administrator roles, with GCP roles/owner and Azure Owner, and all three link to the built-in Admin. B describes what a power-user role such as PowerUserAccess gets. There is no error and no Needs Attention entry either way, so the review step is where you decide whether this person should really be a ZopNight Admin.
Q2
Power-user cloud roles such as AWS PowerUserAccess arrive without org-management grants because:
A. They are provider-specific and simply cannot be translated cleanly at all across the three clouds
B. They require an Admin approval, which the importer does not hold at the time it runs
C. Cloud IAM does not expose them reliably enough for the importer to read them back safely
D. The cloud role itself stops short of managing access, and the import keeps that line rather than widening it
Show answer
Correct: D. PowerUserAccess, GCP roles/editor and Azure Contributor all stop short of managing access in the cloud, and the import mirrors that. Administrator roles do not stop short, so they link to the built-in Admin with every policy. One principle runs through this curriculum: the thing that limits a capability should not be reachable by that capability. Editor cannot manage permissions (M4.1). Role assignments are not writable by an assistant at any tier (M6.5). The Safety Gate refuses by default (M2.3). For IAM import, the review step is where that principle is enforced for administrator roles.
Q3
Promoting an imported user to Admin afterwards is:
A. Automatic, once the import has been applied for a second time in succession later
B. A separate, explicit, audit-logged action from Settings → Roles, taken by an existing Admin
C. Done by re-running the import with a deliberately wider scope
D. Not possible at all for users who arrived through an import
Show answer
Correct: B. An imported grant carries the intent of whoever wrote the cloud policy, possibly years ago for unrelated reasons; a promotion carries the intent of the person clicking it, now, about ZopNight specifically. The two are different quantities of consent, which is why the product treats them differently rather than treating promotion as a convenience the import could have saved you.
5. Apply
Write your intended ZopNight Admin list before running an import, and compare it against who holds administrator-equivalent access in your cloud. The overlap is usually partial, and the gap in both directions is informative.
Then adjust by hand, applying M4.1.L2’s test: anyone imported as Admin who cannot name a specific Admin-only capability moves to Editor or Viewer, and anyone on your list who arrived with less is promoted.
Related lessons
- L2: The translation staircase
- L4: Emails, groups and re-import (next)
- T4.M4.1.L2: System roles
- T6.M6.5.L1: The tiered write surface