RBAC V3 represents a foundational architectural shift to a decentralized, “API First” model. This ensures that security controls and permissions are consistent across both the WebUI and REST API, establishing a unified security posture. The migration to V3 is a mandatory platform evolution required for all new Netskope features.
Key Concepts and Best Practices
- Service Accounts: a new workflow for programmatic API access through role-driven Service Accounts, replacing the deprecated V2 token system. A critical best practice is to copy and securely store the API token immediately upon creation, as it is only displayed once.
- Principle of Least Privilege (PoLP): Emphasizes creating custom roles with the minimum necessary permissions for any given function. This reduces the potential “blast radius” of a compromised account and includes creating dedicated roles for service accounts with UI permissions deselected.
- Label-Based Access Control (LBAC): Extends RBAC V3 with powerful, object-level access control via a hierarchical labeling system. Key use cases include delegated administration (multitenancy), visual separation of automated configurations, and the enforcement of a Zero Trust access model.
- “Roles First” Workflow: Create and configure roles before adding administrators is a foundational best practice.
- Object Dependency Matrix (ODM): Review and re-save all custom roles after migration to RBAC V3 to trigger the ODM and ensure the roles are functional.
RBAC V3 Benefits
- Simplify Administration: Drastically reduce the number of custom roles to manage by identifying and consolidating redundant configurations.
- Enhance Security: Eliminate redundant roles to ensure a consistent, auditable, and secure permission model based on the least privileges.
RBAC V3 Max Permissions
There are permission changes for Custom Roles when migrating to RBAC V3. The core reason for this change is the introduction of a new security concept in RBAC V3 called Max Permissions.
In our previous system (RBAC V2), it was possible to assign permissions to a role that didn’t logically apply to the feature itself. The classic example is assigning “Manage” to the Audit Log. The Audit Log is designed to be an immutable, unchangeable record of events; its only function is to be read or viewed. There is nothing to create, edit, or delete.
Therefore, a “Manage” permission for the Audit Log in RBAC V2 was effectively a “no-op” (no operation); it granted no additional capabilities beyond “View” and could be misleading.
RBAC V3 corrects this by assigning a maximum possible permission to every resource in the system. For the Audit Log, the highest and only logical permission is “View”.
How the Migration Adjusts Permissions
During the migration from RBAC V2 to RBAC V3, the system automatically audits the permissions in every custom role. If a role had a permission that exceeded the new Max Permission for a specific resource, the system automatically and correctly adjusted it down to the highest allowable level. This change is a deliberate improvement to enhance the security and clarity of our platform’s permission system.
Example: Your custom role had “Manage” for the Audit Log in RBAC V2.
The Logic: The Max Permission for the Audit Log in RBAC V3 is “View”.
The Result: The migration process corrects the permission from “Manage” to “View” to accurately reflect the true functionality.
This ensures that a role’s permissions are clear, accurate, and adhere to the principle of least privilege, which is a foundational security best practice.
Key Takeaways
No Loss of Functionality: Your users have not lost any actual capabilities. A user with “Manage” in the Audit Log in the old system could only ever view it, which is exactly what the new “View” permission allows.
Increased Clarity: Permissions are clear. The roles now accurately represent what a user can and cannot do within the platform.
Improved Security: By enforcing logical limits on permissions, RBAC V3 provides a more secure and robust access control framework.