Scopes
Control what each person, token, and automation can see and change in ZopNight by combining scope boundaries with built-in and custom roles.
ZopNight visibility and remediation reach are controlled by scopes: every user, API token, and automation policy acts only within the scope its role grants, and findings, schedules, and remediations are filtered to that scope on the server. Use this page to understand the scope levels, pick or build a role, and work out why someone can or can’t see a resource.
Settings → Roles: system roles (badged System, not editable) beside custom and imported roles, each with its policy count. Imported roles carry a badge naming the cloud and account they came from.
Before you start
- To create or edit roles: a role with the
rolepolicies. The built-in Admin role has every policy. - To assign people to teams: a role with the
teampolicies, and the people already members of the organisation (Settings → Organization → Members). - Optional: connected cloud accounts, if you want to import IAM users, groups, and policies with Cloud IAM Import.
How it works
The scope hierarchy
Scopes nest in this order:
Organisation → Cloud account → Environment → Team → Resource group → Resource| Scope | What it is |
|---|---|
| Organisation | The top-level tenancy. Every organisation has its own resource inventory, its own audit trail, its own credentials, and its own members. Organisations never share data. |
| Cloud account | An AWS account, a GCP project, or an Azure subscription. An organisation can have any number of cloud accounts, each with its own credential and its own permission level (Read-only or Read + Write). |
| Environment | A logical label attached to resources, such as prod, stage, uat, or dev. It usually comes from your cloud tags or labels, and a Smart Tag policy can derive a consistent value for resources whose cloud tags are inconsistent. |
| Team | Derived from your team / member configuration in ZopNight and (optionally) from the Cloud IAM Import wizard, which can ingest IAM users, groups, and policies from AWS, GCP, and Azure. Each resource is attributed to one or more owning teams. Shared resources (e.g. a cluster running multiple teams’ workloads) split daily cost equally across their owning teams. |
| Resource group | An explicit collection of resources that you want to govern together: for example, “all of payments-platform’s RDS instances” or “the dev clusters across all accounts.” You build a group by adding resources to it (search by name or UID, or bulk-select), and each resource belongs to at most one group. See Resource groups. |
| Resource | The leaf: an individual EC2 instance, RDS cluster, or GKE node pool. Every audit-trail entry, finding, and action carries the resource ID. |
Environment is the most useful scope in practice: it is how you tell production from non-production when you filter findings, build resource groups, and decide which resources go on an off-hours schedule.
Default-deny
ZopNight is default-deny outside the granted scope. A user whose role is scoped to the prod account’s resources cannot see findings for resources in stage. The filter is applied on the server, before results reach the browser.
Team-scoped access
Team members inherit their role’s policies scoped to the team’s assigned resource UIDs. An Editor on team payments, for example, sees only payments-owned resources, regardless of which other accounts ZopNight has connected.
Create a custom role
Custom roles are supported alongside the built-in roles. A custom role picks any subset of the policy table and scopes each policy independently. The scope filter is enforced server-side on every request.
Open Settings → Roles → Create Role
Name the role after the job it does, for example FinOps Analyst or Operator.
Pick the policies
Choose from the policy families below. Grant only the verbs the role needs (
view,create,update,delete).Scope each policy
Grant each policy on all resources, on a specific set of resources, or on none.
Assign the role
Give the role to members in Settings → Organization → Members. To narrow it to one team’s resources, add those members to the team in Governance → Teams.
RBAC roles
ZopNight defines three built-in roles: Admin, Editor, and Viewer. Every policy in a role is scoped either to all resources or to a specific list of resources, and team membership narrows it to the team’s resources.
| Role | What it does |
|---|---|
| Admin | All policies on all resources; full read, write, apply, and member management. |
| Editor | Create, update, and delete on resources (schedules, groups, overrides, recommendations) and view-only on admin surfaces. |
| Viewer | View-only across the organisation. No mutations. |
The policy families are:
| Area | Policies |
|---|---|
| Inventory and lifecycle | resource, schedule, resource-group, override, state-history |
| Cost and reporting | report, budget, recommendation, dashboard |
| Governance | smart-tags, iac-policy, iac-validation |
| AI Gateway | ai-usage, virtual-key, ai-model |
| Accounts and org | cloud-account, notification, team, role, user, organisation, assignment, audit-log |
Each takes the usual verbs (view, create, update, delete) where they apply, so dashboard:update is what authorises setting the organisation default, and audit-log:view is granted like any other policy.
Sign-in methods
How people sign in (GitHub, Google, SSO, or email, with SAML configured per email domain) is covered in Authentication.
Policy boundaries for automation
Auto-remediation runs through the same RBAC model. Every action a wizard or policy runs is gated by the actor’s effective policies on the target resource. Destructive operations (Pause, Delete) can carry an admin approval step before the cloud API call fires; it applies when the person starting the remediation is not an admin. A one-shot Stop from a recommendation is always advisory: for schedule-class recommendations, Review & remediate opens schedule creation with the resource prefilled rather than stopping it.
The RBAC scope sets the limit. Outside the granted scope, the actor can change nothing. Inside it, every applied change lands in the audit log with actor, action, timestamp, and request body.
Troubleshooting
A page shows Access restricted
The person’s role lacks the policy that page needs (for example, report:view for Costs → Reports). Add the policy to their role, or give them a role that has it.
Someone can't see resources in another account
ZopNight is default-deny outside the granted scope. Check whether their role’s policies are scoped to specific resources, and whether team membership narrows them to that team’s resources.
A member lands on Needs attention instead of the dashboard
Their role lacks dashboard:view, so Home opens on Needs attention. Grant dashboard:view to land them on Home → Overview.
Imported cloud IAM roles didn't give anyone access
Cloud IAM Import only proposes ZopNight users, teams, and roles; nothing is written until you review the preview and click Apply in the wizard. See Cloud IAM Import.