Scopes

The scope hierarchy

ZopNight visibility and remediation reach are controlled by scopes. Scopes nest in this order:

Workspace → Cloud account → Environment → Team → Resource group → Resource

Every user, every PAT, and every automation policy is anchored to one or more scopes. A finding, a schedule, or an auto-remediation never reaches outside the scope it’s authorized for.

Workspace

A workspace is the top-level tenancy. Every workspace has its own resource inventory, its own audit trail, its own credentials, and its own user directory. Workspaces never share data.

Cloud account

An AWS account, a GCP project (or organisation), or an Azure subscription. A workspace can have any number of cloud accounts; each account has its own credential, its own role, its own audit thread.

Environment

Environment is a logical label attached to resources; prod, stage, uat, dev. ZopNight auto-detects environments from cloud tags or labels, and a Smart Tag policy can derive a consistent value for resources whose cloud tags are inconsistent.

Environment is the most important scope in practice because most policy decisions hinge on it; production resources require explicit opt-in for schedules, certified rules apply automatically only in non-prod, anomaly thresholds are tighter in prod.

Team

Teams are derived from your team / member configuration in ZopNight and (optionally) from the Cloud IAM Import wizard, which can ingest IAM users / groups / policies from AWS and GCP. 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

A resource group is 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.” Groups are defined by selectors (tags, labels, name patterns, account + region) and re-evaluated on every inventory cycle.

Resource

The leaf; an individual EC2 instance, RDS cluster, GKE node pool. Every audit-trail entry, every finding, every action carries the resource ID.

RBAC roles

ZopNight ships three system roles. Each role is scope-aware; you can grant a role on the whole workspace, on a single account, or on a single resource group.

Custom roles are supported alongside the three system roles. A custom role picks any subset of the policy table (resource, schedule, resource-group, override, cloud-account, notification, team, role, user, organisation, assignment, state-history, report, audit-log, recommendation) and scopes each policy independently: grant it on all resources, on a specific set of resources, or on none. The scope filter is enforced server-side on every request.

Team-scoped access: team members inherit their role’s policies scoped to the team’s assigned resource UIDs. So an Editor on team payments sees only payments-owned resources, regardless of which other accounts ZopNight has connected.

Sign-in methods

ZopNight supports Google OAuth, GitHub OAuth, SAML / SSO (per-domain IdP configuration via the internal admin SAML operations page), and email + password sign-in. Customer SAML configs are scoped per email domain; domain matching at the sign-in page routes the user to the right IdP. See Authentication for the full sign-in flow.

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) additionally require an admin approval step before the cloud API call fires; non-destructive operations (Start / Stop) run as soon as the policy check passes.

The RBAC scope is the contract: outside the granted scope, ZopNight stays read-only. Inside it, every applied change lands in the audit log with actor, action, timestamp, and request body.

Default-deny

ZopNight is default-deny outside the granted scope. A user with Viewer on account: prod cannot see findings for account: stage. The visibility filter is enforced server-side; no client-side scope leakage is possible.