Custom Roles

Custom roles allow Org Admins to overlay a specific set of ZTKA or ABAC policies to a base role ( RBAC Role).

⚠️ Important

• Limited Access: ABAC (Attribute-Based Access Control) is enabled selectively for certain organizations and is not available to all production organizations.
• When a user belongs to multiple groups within the same project and is assigned both a custom role and a base role, the custom role takes precedence. The base role is not enforced, even if it appears in the user's effective permissions. A RoleBinding or ClusterRoleBinding must exist in the target namespace for any role to be active. If the custom role does not cover the namespace and no binding exists for the base role, access will be denied.
• For clusters shared between two projects, roles from both projects are combined.

Create New Role

Perform the below steps to create a new custom role:

• Login to the console and navigate to System → Custom Roles. Custom Roles page appears

• Click New Custom Role

• Provide a Name

• Click Add Policy to select the required ABAC/ZTKA policies and their versions. Multiple policy selection is allowed

• Select the Base Role

Important
For ABAC (Attribute-based access, only Namespace Admin and Namespace Read Only base roles are supported.

• Click Save Changes

Once the details are saved, the policy is applied to the selected roles and listed as shown below. You can edit the details or delete the custom role if required using the respective icons

On successful custom role creation, now admins can assign the roles to the required users or groups

Custom Role behaviour in Shared projects

The behavior of role combinations involves the interaction among multiple roles assigned to users or entities across different projects. This interaction determines how their permissions and access rights are amalgamated, prioritized, and enforced within a cluster.

Below is an example illustrating how different roles are applied when executing kubectl commands on clusters within various projects:

Scenario 1: Single Project with Custom and Base Roles

• Project: P1, Cluster: C1
  • Roles: CustomRole (INFRA_ADMIN), BaseRole (Project_ReadOnly)
  • Behavior on Kubectl: Only the CustomRole is applied; the base role is ignored
• Project: P3, Cluster: C3
  • Role: BaseRole (Project_ReadOnly)
  • Behavior on Kubectl: The base role is applied

Scenario 2: Multiple Projects with Different Roles

• Project: P1, Cluster: C1
  • Roles: CustomRole (INFRA_ADMIN) - cr1, BaseRole (Project_ReadOnly) - b1
  • Behavior on Kubectl: The CustomRole (cr1) and BaseRole (b2) are applied; b1 is ignored
• Project: P2, Clusters: C1 (Inherited), C2
  • Role: BaseRole (NamespaceReadOnly) - b2
  • Behavior on Kubectl: On C2, BaseRole (b2) is applied
• Project: P3, Cluster: C3
  • Role: BaseRole (INFRA_ReadOnly) - b3
  • Behavior on Kubectl: BaseRole (b3) is applied

Scenario 3: Shared Cluster with Multiple Project Roles

• Cluster: C1 (Shared between Project P1 and Project P2)
  • User U1's Roles:
    • In Project P1: BaseRole (B1), CustomRole (CR1)
    • In Project P2: BaseRole (B2)
  • Behavior on Kubectl: Permissions from CustomRole (CR1) and BaseRole (B2) are applied; BaseRole (B1) is ignored