RBAC for Cloud Cost Tools: Roles, Policies and Scope

Role-based access control (RBAC) grants permissions to people through roles rather than one person at a time. A role bundles permissions; an assignment gives a role to a user or group; a scope limits where that assignment applies. Change the role and everyone holding it changes with it; remove the assignment and access ends.

How the three clouds model it

The vocabulary differs but the shape is the same:

• Azure RBAC defines a role assignment as three elements: a security principal (user, group, service principal, or managed identity), a role definition, and a scope. Scope can be a management group, a subscription, a resource group, or a single resource, in a parent-child hierarchy.
• Google Cloud IAM grants a principal a role on a resource through an allow policy, and child resources inherit the policies of their parents along the resource hierarchy of organization, folders, projects, and resources.
• AWS IAM attaches policies to identities (users, groups, and roles) and to resources. AWS’s own best-practice guidance is to apply least-privilege permissions, starting from AWS managed policies and moving toward narrower ones.

A cost platform sits on top of all three and needs its own RBAC, because the questions are different. Someone may be allowed to read every bill without being allowed to stop a single instance.

Designing roles for cost work

Separate the actions by consequence:

1. Viewing cost, recommendations, and reports. Broad read access helps cost awareness; the only reason to narrow it is data sensitivity.
2. Changing operational settings: schedules, overrides, resource groups, budgets. These change what runs and when, so scope them to the resources a team owns.
3. Connecting and administering: cloud account credentials, integrations, users and roles. Keep these to a small admin group.

Then scope roles to ownership. A team lead who can edit schedules for their own services should not be able to edit anyone else’s.

RBAC in ZopNight

ZopNight enforces RBAC at its gateway: every endpoint maps to a required policy such as report:view or state-history:view, and a request without it is refused before it reaches a service. There are three system roles: Admin (all policies on all resources), Editor (create, update, and delete on resources, view-only on admin areas), and Viewer (view-only). Custom roles can scope each policy to all resources or to a list of specific ones, and team members inherit their role’s policies scoped to the resources assigned to their team. Scope is three-state: no filter, nothing, or an explicit list, applied as a filter in each service’s queries. Pages a user cannot use show “Access restricted”.

Two layers combine. ZopNight RBAC decides what a person may ask for; the cloud account’s permission level decides what ZopNight itself may do. An Editor on a read-only account still cannot start or stop anything, because read-only accounts are limited to discovery and recommendations.

Keeping roles current

• Mirror existing cloud access instead of rebuilding it: see cloud IAM import.
• Review who holds Admin at least as often as you rotate credentials.
• Use the audit trail to see what each role actually does with its access.