Outcome
By the end of this lesson, you will be able to describe the three tiers of policy translation, predict which cloud grants land in Needs Attention, and resolve them.
| Tier | Architect |
| JTBD | ”Understand what the importer inferred, and fix the cases it could not.” |
| Personas | Security/Compliance · Platform Engineer |
| Prerequisites | M3.9.L1 · M3.1.L1 (the policy table) |
| Time | 9 minutes |
| Bloom verb | Describe (Understand), Predict (Analyze), Resolve (Apply) |
1. Concept
Translation runs as a staircase with three tiers, and each step down means less certainty.
TIER 1: CURATED MAPPING A KNOWN cloud policy or role maps to a curated ZopNight policy set. Someone decided this mapping deliberately. Highest confidence.
TIER 2: ACTION TRANSLATION A CUSTOM role is translated by its actions. The importer reads what the role can do and derives an approximate ZopNight equivalent. Medium confidence: derived, not decided.
TIER 3: NEEDS ATTENTION Anything unrecognised. Not guessed at, not dropped silently: surfaced for a human to resolve.The important property of the staircase is that it never guesses at the bottom. An unrecognised grant does not fall through to a default; it stops and asks.
Tier 1: curated mappings
The managed policies and predefined roles that appear in most estates have deliberate mappings. ReadOnlyAccess on AWS, a Viewer role on GCP, a Reader role on Azure: these have obvious ZopNight equivalents and someone wrote them down.
This tier covers most of a typical import, which is what makes the feature useful at all.
Tier 2: action translation for custom roles
A custom role has no curated mapping by definition, so the importer reads its actions and derives an equivalent.
A CUSTOM AWS POLICY GRANTING ec2:Describe*, rds:Describe*, cloudwatch:GetMetric*
TRANSLATES TOWARD read access on the corresponding ZopNight entities
BUT NOTE WHAT IS BEING INFERRED: "this person can describe EC2 instances in AWS" -> "this person should be able to view resources in ZopNight"
That inference is reasonable and it is still aninference. It is why the review step exists.Action translation is where most of the review effort belongs. The mapping is usually right and it is the tier where being wrong is least visible.
Tier 3: Needs Attention
WHAT LANDS HERE - custom roles whose actions do not translate cleanly - grants using conditions or scoping the importer cannot represent - principals with no clear ZopNight equivalent - service-account-only roles with no human behind themNeeds Attention is not an error list. It is the honest residue of a translation that refuses to guess, and it is where the genuinely interesting cases are. A grant that could not be translated is frequently a grant that was unusual in the cloud too.
The service-account case
Service-account-only principals are worth calling out because they are common and the answer is usually simple.
A ROLE ASSUMED ONLY BY A SERVICE ACCOUNT, with no humanprincipal behind it, has no meaningful ZopNight user tocreate.
Usually the right resolution is to DROP it. A costplatform's users are people who look at costs; apipeline's execution role is not one of them.If you genuinely need a non-human identity in ZopNight, a PAT against a purpose-made user is the mechanism, not an imported role.
How to work the Needs Attention list
FOR EACH ENTRY, ASK IN THIS ORDER
1. Is there a human behind this principal? No -> drop it.
2. Does this person need to see cost data at all? No -> drop it. Cloud access is not the question.
3. What is the SMALLEST ZopNight role that lets them do their actual job? Assign that, not an approximation of their cloud grant.
Question 3 is the one that matters. The temptation is tofind the closest equivalent to their cloud role. Theright answer is the smallest role that fits the job theydo in ZopNight, which is frequently narrower.Why the tiers matter for a security review
Being able to say which tier a given user’s role came from is a genuinely useful answer:
"This person's Editor role came from a curated mapping of the Azure Contributor role." -> a decision someone made and documented
"This person's Editor role was derived from the actions on a custom role." -> an inference we reviewed and accepted
"These eleven were unrecognised and we resolved them by hand." -> nothing was guessedThat third line is the one that closes reviews, because the concern behind the question is always “what did the tool assume”.
2. Demo
Working an 11-entry Needs Attention list:
ENTRIES: 11
GROUP 1: service-account-only (2) `svc-data-pipeline-exec` `svc-backup-runner` Both are roles assumed by service accounts. No human principal. RESOLUTION: dropped. A pipeline's execution role is not a person who looks at costs.
GROUP 2: custom roles with conditional scoping (4) Roles carrying condition keys restricting them to specific tag values and times of day. The importer cannot represent a time-of-day condition, so it did not try. RESOLUTION: assigned each holder a Viewer role with team scoping (M3.1.L4). The team scope covers the tag-based intent; the time restriction has no ZopNight analogue and was not needed for cost visibility.
GROUP 3: custom roles with mixed read/write actions (3) Roles granting reads across many services and writes to one. Action translation could not decide between Viewer and Editor, correctly: the answer depends on whether the write matters in ZopNight's terms, and it did not (the writes were to a service ZopNight does not act on). RESOLUTION: Viewer.
GROUP 4: a principal with no email (2) Two IAM users with no email attribute. Covered in L4. RESOLUTION: filled from the HR directory by CSV, then re-applied.
TIME TAKEN: about 25 minutes for 11 entries.
THE PATTERN IN THE RESOLUTIONS 9 of the 11 resolved to something NARROWER than their cloud grant, and 2 resolved to nothing at all.
Not one resolved to something broader. That is the expected shape: cloud grants are about infrastructure and are almost always wider than the cost-visibility question requires.3. Hands-on (6 min)
1. Open your import's Needs Attention list. Entries: ______
2. Classify each: service-account-only (no human) ______ conditional / scoped grants ______ mixed read/write custom roles ______ missing email ______ other ______
3. For the service-account entries, confirm there is no human behind them, then drop. dropped: ______
4. For one custom-role entry, answer the three questions in order: human behind it? Y / N needs cost visibility at all? Y / N smallest role that fits their ZopNight job: ______________________________________________
5. Count your resolutions by direction: narrower than the cloud grant ______ same ______ broader ______ Any "broader" is worth a second look.4. Knowledge check
Q1
The three translation tiers are:
A. Automatic, then manual, and finally skipped altogether where nothing could be worked out for the principal at all in the end
B. A curated mapping for known cloud policies and roles, action translation for custom roles, and Needs Attention for anything unrecognised
C. Per-provider first, then per-account, and then per-principal at the very end of the import pass
D. Read grants, then write grants, and then the admin grants at the very top of the ladder itself
Show answer
Correct: B. The staircase never guesses at the bottom: an unrecognised grant stops and asks rather than falling through to a default. Being able to say which tier a user’s role came from is what closes a security review, because the concern behind the question is always “what did the tool assume”. Nothing was assumed at tier 3.
Q2
A role is assumed only by a service account, with no human principal behind it. The usual resolution:
A. Import it as a ZopNight user with a PAT
B. Import it as a team
C. Drop it
D. Import it with Viewer access for auditability
Show answer
Correct: C. A cost platform’s users are people who look at costs, and a pipeline’s execution role is not one of them. If a non-human identity is genuinely needed, a PAT against a purpose-made user is the mechanism rather than an imported role. This is the most common Needs Attention category and the one with the simplest answer. Importing it creates a user nobody logs in as and that shows up in every access review from then on.
Q3
When resolving a Needs Attention entry, the question that matters most is:
A. What is the smallest ZopNight role that lets them do their actual job in ZopNight
B. What the closest ZopNight equivalent to their existing cloud role is
C. Which cloud provider the grant originally came from in the first place
D. Whether the underlying cloud role is a managed or a custom one entirely
Show answer
Correct: A. The temptation is to find the closest equivalent to the cloud grant, but cloud grants are about infrastructure and are almost always wider than the cost-visibility question requires. In a typical resolution pass, most entries resolve to something narrower than the cloud grant and some resolve to nothing at all. A resolution that comes out broader is worth re-examining.
5. Apply
Work your Needs Attention list with the three questions in order, and track the direction of your resolutions. A pass where most entries end up narrower than the original cloud grant is the expected shape; one where several end up broader means the closest-equivalent instinct is winning over the smallest-role principle.
Related lessons
- L1: Suggestions, never grants
- L3: The org-management exclusion (next)
- T3.M3.1.L3: Custom roles
- T3.M3.1.L4: Team-scoped access
Glossary terms touched
Curated mapping · Action translation · Needs Attention · Service account