Mapping API v2 endpoints to RBAC v3 Roles

​Netskope Global Technical Success (GTS)

Mapping API v2 endpoints to RBAC v3 Roles

Netskope Cloud Version - 132

Objective

The objective is to map map API v2 endpoints to RBAC v3 Roles

Prerequisite

Netskope SWG or Next-Gen SWG license is required
Logged in user should have Predefined Tenant Admin role assigned

Context

The customer aims to map the API v2 endpoints to the new RBAC v3 role. This knowledge base article explains how to correctly create a role with exact mapping of endpoints.

Topics covered

How to create a custom Role as per RBAC v3

How to map the endpoint to role

How to create a Service account

How to generate an API token

How to change the expiration of API token

Do You Know?

• As of Nov 7, 2025, Netskope has introduced new RBAC V3, users will not be able to create new token or change expiration of api  from path Netskope Tenant UI >>> Settings >>> Tools >> API v2
• RBAC V3 provides functional controls and uniform authorization for both WebUI and REST API based interactions.
• Admins can use automated service accounts without risk of these accounts being able to access the web UI. API access tokens are now issued to a user or a service account (instead of at the tenant level) along with expiry/renewal workflow.
• Clone of Tenant Admin role will not be able to create Service account

Overview

In Role-Based Access Control (RBAC) V3, a Tenant Admin has the highest level of administrative permissions within their tenant, including the ability to manage other administrators and roles. However, when a user attempts to create or clone a role, the permission "Administration > Admins > Manage" is intentionally disabled for all roles other than the core Tenant Admin role.

This is not a bug, but rather an expected and critical security feature designed to prevent privilege escalation.

The Purpose of the Security Control

The primary reason for this behavior is to maintain a secure and robust RBAC framework. The ability to manage other administrators and roles is a unique privilege reserved exclusively for the pre-defined Tenant Admin role. This restriction is a fundamental principle of the RBAC V3 design and applies to all user-created or cloned roles, not just those derived from the Tenant Admin role.

Here's why this security control is in place:

• Preventing Privilege Escalation: If any user could create a new role and grant it the ability to manage other admins and roles, it would create a potential loophole. A malicious actor could create a new role with this permission and then use it to create new users or roles with even higher privileges, effectively bypassing the security controls. This could allow them to grant full administrative access to unauthorized users.
• Maintaining a Secure Hierarchy: The RBAC V3 model is designed with a clear and secure hierarchy. The Tenant Admin role acts as the root administrator for the tenant. Allowing other, potentially less-controlled roles to manage admins would compromise this structure and make it difficult to track and control administrative permissions.
• Ensuring the Integrity of the RBAC System: By restricting the "Manage" permission to the original Tenant Admin role, the system ensures that the fundamental controls for user and role creation remain in a trusted and uncompromised state. This prevents a user with a non-standard or cloned role from rendering the RBAC controls ineffective.

Expected Behavior

• The only predefined role that has "Administration > Admins > Manage" permission is the Tenant Admin.
• When any other role is created or cloned, the "Administration > Admins > Manage" permission will be grayed out and disabled. This is a deliberate design choice to protect against privilege escalation.

This design ensures that only the designated Tenant Admin can perform critical functions like creating new roles and managing user accounts, thus protecting the integrity of the entire system.

 Configuration

For step-by-step configuration review the below Video:

will be uploaded soon

tentative date 02 Dec 2025

Video will cover the below steps: 

Step 1: Create a custom Role

Step 2: Map the endpoint to the role

Example Endpoints:

/api/v2/events/dataexport/events/application

/api/v2/events/dataexport/events/audit

Follow the same process for all the endpoints

Step 3: Create a Service Account

Step 4: Generate the API

Terms and Conditions

• All documented information undergoes testing and verification to ensure accuracy.
• In the future, it is possible that the application's functionality may be altered by the vendor. If any such changes are brought to our attention, we will promptly update the documentation to reflect them.

Notes

• This article is authored by Netskope Global Technical Success (GTS).
• For any further inquiries related to this article, please contact Netskope GTS by submitting a support case with 'Case Type – How To Questions'.