Skip to content

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) capability is enabled selectively for Orgs and is not available to all Prod Orgs.

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

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

Custom Role

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

Listing

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

Important

  • If a user has both custom role and base role permissions within a project, the custom role takes precedence, and the base role is disregarded
  • For clusters shared between two projects, roles from both projects are combined