The platform's user role management is implemented on top of Kubernetes RBAC (Role-Based Access Control). After ACP 4.2, the model is split into two complementary layers:
Role and ClusterRole objects that you can create per cluster to satisfy bespoke permission requirements. These roles are managed from the Kubernetes Roles page and bound through RoleBinding/ClusterRoleBinding.Both layers ultimately translate into Kubernetes permissions. Assigning or removing a role immediately grants or revokes the associated operations (create, view, update, delete, etc.) on targeted resources.
To meet common permission configuration scenarios, the platform provides the following default system roles. These roles enable flexible access control for platform resources and efficient permission management for users.
| Role Name | Description | Role Level |
|---|---|---|
| Platform Administrator | Has full access to all business and resources on the platform | Platform |
| Platform Auditors | Can view all platform resources and operation records, but has no other permissions | Platform |
| Cluster Administrator (Alpha) | Manages and maintains cluster resources with full access to all cluster-level resources | Cluster |
| Project Administrator | Manages namespace administrators and namespace quotas | Project |
| namespace-admin-system | Manages namespace members and role assignments | Namespace |
| Developers | Develops, deploys, and maintains custom applications within namespaces | Namespace |
The legacy “checkbox-based” custom role creation experience has been removed. To implement new authorization scenarios you must:
Deleting or editing a native role affects every RoleBinding/ClusterRoleBinding that references it. Review existing bindings and validate changes in a staging environment when possible.