Introduction
TOC
Role Introduction
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:
- Platform Roles: System-provided templates that guarantee core product scenarios. They are read-only in the UI; you can only bind or unbind them for users and groups.
- Kubernetes Roles: Native Kubernetes
RoleandClusterRoleobjects 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.
System Roles
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.
Custom Permissions
The legacy “checkbox-based” custom role creation experience has been removed. To implement new authorization scenarios you must:
- Use the Kubernetes Roles page to create native roles (Role/ClusterRole) in the desired cluster, or
- Request role templates from the owning plug-in team and bind them through RoleBinding/ClusterRoleBinding.
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.