Base Roles

Roles in the platform are used to enforce governance and access controls to ensure that there are guardrails in terms of what a user can and cannot do. Users with the role of organization administrator are responsible for role assignments and user management. The platform provides several roles that can be used to control what users can do in the platform. The roles defined are based on Kubernetes RBAC and role bindings.

Dynamic Role Calculation

In a typical organization, as users move around organizationally, their roles and responsibilities can change dramatically. It is therefore practical and sensible to centralize the management of user's roles in a central system. The flowchart below describes how roles are “dynamically calculated” and assigned to users. Note that RBAC assignments are ephemeral and valid only for the session. When the user signs in the next time, the role is dynamically calculated based on the user’s current identity and group membership.

Local Group/Role

Assertion from IDP

Local Group Override

Local User

Group/Role

Calculate RBAC

IDP User

IDP Group

IDP Group + Group Override

Organization Types and Role Model Overview

A role-based access model is aligned with organization structure and platform responsibilities. Roles define access at two levels:

• Controller Access — permissions within the controller to manage organizational and platform resources.
• ZTKA Access (Cluster Resources) — Kubernetes access provided through Zero Trust Kubernetes Access (ZTKA), mapped to Kubernetes RBAC bindings.

Roles

These roles are primarily used for Cloud Native Automation (CNA) and infrastructure management.

• It is strongly recommended to have at least two active Organization Admins per Org.
• User role changes are automatically synchronized with managed clusters to maintain the platform’s zero-trust access model. During the short interval before these updates are fully applied to clusters, access requests (such as ZTKA requests) from the affected user may temporarily return a 401 Unauthorized response. This response is expected behavior until the role synchronization completes.

Note

To get the list of resources that are namespace scoped, use the below command

kubectl api-resources --namespaced=true

Organization Administrator Role

The organization administrator role is a privileged, super user with the ability to manage and configure everything in an organization including all projects. This user is responsible for configuring everything that spans an entire organization including users, org-level settings, RBAC, and more.

In order to create an organization administrator, see detailed documentation.

Project-Specific Roles

While users can have a specific role for all projects, many times as an admin you may want to limit access to certain projects. In addition, for given projects that are more important or need more governance than others, you may want to set more limits in terms of what a user can/cannot do in those more governed projects.

This is where project-specific roles are extremely helpful. With project-specific roles, you can set a different role per user per project. This means for example that as a user, you may have namespace admin permissions in one project for example but then project admin permissions in another.

Multiple Roles For a User

In the platform, a user can have multiple roles. The user can have multiple roles within the same organization as well as across multiple organizations.

Multiple Roles Within The Same Organization

The following summarizes what happens when a user gets multiple roles within the same organization:

• Union of roles: The user gets the union or summation of all the privileges assigned from all the roles. For example, if a user gets assigned infra admin along with project admin role, then they can both create clusters (infra admin role privilege) and manage workload resources (project admin role privilege).

• Roles Precedence: For any permission that is conflicting, precedence is taken into effect with the user getting the higher privilege role. For example, if a user gets infra admin and cluster admin privileges, then the user can create clusters even though the cluster admin role is not allowed to create clusters.

Similarly, if a user has a read-only role and management role for the same type (for ex Infra Admin and Infra Read-Only), the management role will ALWAYS take precedence.

• Organization Administrator Role: If a user has an org admin privilege along with say namespace admin for a given project, then the user will have organization admin privilege across the board.

• Multiple Roles Per Project:: Per project roles are still taken into effect here. If a user has for example project admin and infra admin in project-dev, but only project admin in project-prod, then the user will be allowed to manage workloads and clusters in project A but will not be allowed to manage workloads in project B as the project admin privileges for the user are only given for project A.

• Namespace Permissions Within a Project: Within a project, a user can have different permissions for different namespaces, namespace admin for a set of namespaces and namespace read-only for another set of namespaces. This can be achieved by adding the user to two user groups. One that maps to a namespace admin role, another group that maps to a namespace read-only for the desired namespaces.

Multiple Roles Within Different Organizations

A user can also different roles for different organizations. For example, for one org that is used for demos, they may have a project admin role but for a production org, they may have a namespace admin role.

Examples

The following table summarizes some examples for clarity with Project A and Project B referenced as examples:

Manage Roles

Org Administrators are responsible for assigning and managing roles for users in the Organizations. All changes and activities with user role assignments are audited and can be viewed in the Audit section. Users can be assigned roles in one of two ways providing flexibility in how organizations would like to manage access.

• By Group (Associate role to a specific group. Add/remove users to the group)
• Per User (Associate role to a specific user)

Manage Role By Group

Group based role assignments are well suited for handling a large number of users that need similar roles. For example, it is much easier to create a group called "developers", configure this group with the required role and manage users.

Manage Role Per User

In some cases, it may be required to manage roles with a "per user" granularity. Perform the below steps.

• Login into the Web Console as an Org Admin

• Select System -> Users

• Search and select the desired user

• If required, make any changes in the profile page and click Save

• Select the Projects tab

• Click Assign User To Project

• Select the project from the drop down

• Assign Role(s) and click SAVE & EXIT

• Click DISCARD CHANGES & EXIT to abort the process

Determine Role as End User

Authorized users in an Org can quickly determine their exact role and profile in the Web Console.

• Login into the Web Console
• Click on your name/email address on the top right
• Select Profile from the drop-down

The below example is for a user having an "Org Admin" role for "ALL PROJECTS".

The below example is for a user having an "Infra Admin" role for the "Production Project"

Determine User's Role as Org Admin

An Org Admin can quickly determine a user's role assignments.

• Navigate to System -> Users
• Search for the specific user
• View current role assignments

The example below shows a list of users in an organization.