User Roles and Personas

One-Click Least Privilege. Zero Disruption.

© 2026 Sonrai Security. All rights reserved.

Overview

The Sonrai platform provides Role Based Access (RBAC) to support the needs of a wide variety of users and public cloud security use cases.

RBAC capabilities enable you to manage your users within the platform along with their role assignments (and corresponding permissions).

A Sonrai role determines which capabilities a user has access to within the Cloud Permissions Firewall.

Most roles are assigned together with a scope — the part of your cloud hierarchy the assignment applies to. The role determines what a user can do; the scope determines where they can do it. The Administrator role is the exception: it grants full access across your organization and is never restricted to a scope. See Role Assignment Scope for how scoping works.

---

Roles

Roles are managed through user invitations and the section listed within the User Profile.

To manage roles, users must have an appropriate level of permissions to manage roles and permissions (i.e., "Administrator" role).

Available Roles

Administrator

Full administrative access across your entire organization, including user and cloud account management, plus full administrative access of all available Cloud Permissions Firewall features

Scope
Administrator

Administrative access to the services, controls and Permissions on Demand (PoD) requests within an assigned scope

Cloud Permission Firewall
Approver

Ability to approve/deny Permissions on Demand (PoD) requests

Cloud Permission Firewall
Viewer

Ability to view information within the Cloud Permissions Firewall

caution

To affect role addition/removal, users are urged to log out then log back into the platform

Role Assignment Scope

A role on its own says what a user can do. Pairing it with a scope says where — restricting the assignment to one part of your cloud hierarchy, such as a single AWS Organizational Unit (OU) or an individual account.

When you assign a role that supports scoping, an Assign Scope field appears beneath the role. Choose a scope from the picker, or select All Scopes to grant the role across your entire cloud hierarchy. Click to add the pairing to the Selected Roles table, where the Role, Scope, and Source of each assignment is listed.

The role list shows which roles are scoped. Administrator is marked (Platform) — it applies to your whole organization and offers no scope field. The roles marked (CPF Scope), including Scope Administrator, Cloud Permission Firewall Approver, and Cloud Permission Firewall Viewer, are each assigned at a scope.

Scopes can be assigned at any level of your cloud hierarchy:

Scope	Example	What the assignment covers
All Scopes	—	Your entire cloud hierarchy, across every cloud you have onboarded.
Root	An AWS root, a GCP organization, an Azure tenant	The root and everything nested beneath it.
Intermediate	An AWS OU, a GCP folder, an Azure management group	That container, its child containers, and every account, project, or subscription beneath it.
Individual resource	An AWS account, a GCP project, an Azure subscription	That resource only.

How scope is applied

A scoped assignment covers the scope you select and everything nested beneath it. Assigning a role at an OU covers that OU, its child OUs, and every account within them. Scopes elsewhere in the hierarchy — the parent of the selected scope, its siblings, and anything under them — are not covered.

Scope governs what a user sees, not only what they can change. Pages throughout the Cloud Permissions Firewall are filtered to the scopes a user is assigned, so a scoped user's Services, Requests, and reporting views show only their own part of the hierarchy.

info

Each role assignment carries exactly one scope. To grant a user the same role over several separate parts of your hierarchy, assign the role once per scope — for example, once at an AWS OU and once at a GCP folder. A user's access is the combination of all their assignments.

Existing and overlapping assignments

Role assignments made before scoping was introduced are treated as All Scopes, so existing users keep the access they have today. Narrowing a user's access is a deliberate step: replace their All Scopes assignment with one or more scoped assignments.

Where assignments overlap, the widest one wins. A user holding the same role at both All Scopes and at a single OU has that role across the whole hierarchy — the narrower assignment does not restrict the broader one.

tip

Groups are assigned roles and scopes exactly as users are, and members inherit both. See Groups for managing group role assignments.

Personas

Platform Administrators

These users need full administrative capabilities for the entire platform. They can complete every available Cloud Permissions Firewall process and manage your users and cloud accounts.

Their responsibilities span the whole application — the following are examples:

Responsibility Description	Cloud Permissions Firewall Page
Configuration and use of ChatOps integrations
Management of role-based access for users	Manage > Users
Onboarding of Accounts (at the Org level)	Manage > Accounts
Execution of Service changes (disabling, exempting identities, etc.)	Controls > Services
Review of reporting/audit information	Utilities > Reporting
Template generation for pending cloud changes	Workflow > Pending Changes
Assignment of Permissions on Demand Approvers at scope	Workflow > Approvers
Approval/denial of Permissions on Demand Requests at scope	Workflow > Requests

tip

If this user should be able to approve Permissions on Demand (PoD) requests, assign them as an Approver at scope within the Cloud Permissions Firewall.

*Platform Administrators can assign themselves as PoD Approvers, for convenience!

Scope Administrators

These users hold administrative capabilities over one part of your cloud hierarchy. Within their assigned scope they run the day-to-day Cloud Permissions Firewall work — staging service changes and handling Permissions on Demand (PoD) requests — while everything outside that scope stays out of view.

This role suits a team that owns its own OU or set of accounts: they manage their own controls without being given the keys to the wider organization.

Within their scope they work across the Cloud Permissions Firewall much as an Administrator does — the following are examples:

Responsibility Description	Cloud Permissions Firewall Page
Execution of Service changes within their scope (disabling, exempting identities, etc.)	Controls > Services
Staging of cloud changes within their scope, and discarding their own staged changes	Workflow > Pending Changes
Approval/denial of Permissions on Demand Requests at scope	Workflow > Requests
Creation of Permissions on Demand Requests	Workflow > Requests

info

Actions that apply to your whole cloud organization, such as deploying staged changes, managing Cloud Permissions Firewall settings, or onboarding accounts, are carried out by a user with the Administrator role.

Cloud Permission Firewall Approver

These users approve/deny cloud access requests spurred by your users, once service protections are in place.

Responsibility Description	Cloud Permissions Firewall Page
Approval/denial of Permissions on Demand Requests at scope	Workflow > Requests

Cloud Permission Firewall Viewer

These users are allowed to view services, pending changes, etc.

Responsibility Description	Cloud Permissions Firewall Page
Viewers have read-only access to all pages, and see the data for the scope their role is assigned at. Where a Viewer is also assigned as a Permissions on Demand (PoD) Approver, they see the PoD Requests raised at the scope they approve for.	All Cloud Permissions Firewall pages

---

Default RBAC User Permissions

For reference, the Sonrai platform requires specific user permissions to work properly out-of-the box and so the following are assigned to every user by default:

Permission	Description
Role, Read	Ability to read Role elements
UserToken, Read	Ability to read User Token elements

---

Advanced - Searching for Detailed Role Permissions

To review a granular list of the specific permissions granted to each role, use the following query in the Explorer area:

Example Query

query SonraiRoleDetails {
  SonraiRoles {
    count
    items {
      name
      description
      permissions

# Optionally return users for each role 
      roleAssignments {
        count
        items {
          scope
          user {
            count
            items {
              email
              name
            }
          }
        }
      }

    }  
  }
}