Skip to main content

dM8EuJ_ZbG6ImYOm9ge6Zzo8iyjGyFzCnS0fmTs1C1mdsepP-sQl1a0w_PK6blQwOjNLcsoslM0TYuN1WjoO8lsZIHYT69OdIpm7QpoTVC7ehKqkoDSjmsgMZ-HeKOtHhLPDDW5myHokpuFbYRDLfKw

Netskope Global Technical Success (GTS)

Role Based Access Control v3 (RBAC v3)

 

Netskope Cloud Version - 125

 

Objective
This article explains the new capabilities introduced with RBAC V3, available starting from Netskope release R125Link

 

Requirement

  • To enable RBAC V3, a backend flag needs to be enabled.
  • Customers are requested to raise a support case ‘Case Type: How-To Question

 

Author Notes

  • In the near future, this RBAC V3 will be rolled out to all tenants.

 

Details

New features introduced with RBACv3

(A). Roles for Rest API endpoints
The role definition remained unchanged in comparison to RBAC V2, however, each function has now a set of associated REST API endpoints, which are granted when selecting the functions, for example:

AD_4nXe6jyS40TctNNpoIBx6kdGNNVaHegg7Mp39MfBQGjIiYncQVNXnrTRSF6PKCRS9doPiCwxrEelTfLsqV-qh1rDTRImAsT7oooWUV57xKQIWvlyvbVeFnzYSPieuyjVTq43togg5?key=WcT1uaB44pPY02uUM9fY-A

 

ℹ️ For Users and Groups provisioning through SCIM, the below function will be needed:

 

AD_4nXeYYn1H6rnSJ72d9fecleccinzW37d1onE64WGyPppSs6Rhcs7kStD9ML3QsW0wQeZKyPLEeest0-G10dpr_CFfaULBYcKOtPOxpxvRcXTwSDqpHbPTLUIRfkr8v8qtrkHK0BcB7Q?key=WcT1uaB44pPY02uUM9fY-A

More info can be found in the following article: SCIM Allowlist and RBAC v3 enabling - Customer Instructions 

 

(B.) Roles for IP Allowlist
Within the role, it is now possible to define an IP Allowlist. By assigning the role to an Administrative User (or Service Account), we will be able to restrict access to the Netskope UI or REST API endpoint access. These IP Allowlist will override the global IP allowlist. For example:

AD_4nXelUz84kulzjCWHk1CLENc3_GP_VtbUEwBxw_7ytVOASd420TMUa2Swg0xpltJ7nPfFnojvaKuX0AAk7lUemo7qfUlk1G7JMWRjyIK2Ud7HnASJeFxu1dg_gs-5UFyzSm2my6OO?key=WcT1uaB44pPY02uUM9fY-A

ℹ️ It is possible to enter a list of IPs by uploading a CSV file containing IPs or public networks eg. X.X.X.X, X.X.X.X/32, X.X.X.Y/24

 

(C.) Service Account
RBAC v3 introduces the concept of “Service Account”; Service accounts are users who access the tenant via REST API, each service account has its own associated API key with an expiration date. For example:

 

Creating a New Service Account:

Path: Netskope Tenant UI >>> Administration >>> Administrators & Roles

AD_4nXdGFjKLJKfuT-ZKLBbHTeG-nPK0PGWf0LBTXxBKMo-OO7gaS99Logv9OSbEvGA4Iq8BEjKLIgbGos9oBulj4m-h2y3Qua8mv46PklU0a1teqIPGLLnTebhxPq9JTXLQtpRhWbnz?key=WcT1uaB44pPY02uUM9fY-A

 

Service Account settings:

AD_4nXfd1bVOWo22XMlj4AWYwAwLdFXl7P86-wnFwHKNYVCHHW9XH_eM7ngcZUn9Q7jf2jICodD6XPl7sHE82Vew7OAjpY_XxMBPBQf7aiNXBlgiKo-NVWx1t77puO0XodOZnvE0l4Ruow?key=WcT1uaB44pPY02uUM9fY-A

⚠️ WARNING: The Service accounts will replace the REST API V2 Tokens (Settings >>> Tools >>> REST API V2). After enabling RBAC V3 on customer’s tenant, you will no longer be able to create new tokens from REST API V2. On the other hand, post RBAC V3 enablement, all new REST API tokens will have to be defined as Service Accounts.

Any existing and valid REST API V2 token present before RBAC V3 enablement will continue to work after the migration until its expiration. However, customers will not be able to edit, renew, and reissued these REST API V2 token after the migration.

 

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'.
Be the first to reply!