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.

graph TB
    A[Local User] --> |Local Group/Role|B[Group/Role]
    B --> F
    C[IDP User] --> |Assertion from IDP|D[IDP Group]
    D -->|Local Group Override| E[IDP Group + Group Override]
    E --> F[Calculate RBAC]

Types of Roles¶

Platform Role controls access to both controller and cluster resources (ZTKA Access). The table below details the mapping of each role to controller/cluster access.

Role	Controller Access	ZTKA Access (Cluster Resources)
Organization Admin	A privileged, super user type role with access to everything in the Org. This user can view, manage all workload and infrastructure resources across all projects. Specifically, they have Read + Write access to workloads, namespaces, certificates, secret stores, registries, aggregation endpoints, clusters, add-ons, pipelines, chargeback groups/reports and blueprints	ClusterRoleBinding
Org Admin Read Only	A Read Only version of the Org Admin role	ClusterRoleBinding
Project Admin	A privileged role allowed to manage all workload resources in a Project. Specifically, they have Read + Write access to workloads, certificates, registries, secret stores, pipelines and aggregation endpoints	ClusterRoleBinding
Project Read Only	A Read Only version of the Project Admin role	ClusterRoleBinding
Infrastructure Admin	An infrastructure focused role who has Read and Write access to Clusters, Namespaces, Blueprints, Add-ons, and Cloud Credentials	ClusterRoleBinding
Infrastructure Read Only	A Read Only version of the Infrastructure Admin role	ClusterRoleBinding
Cluster Admin	A privileged role allowed to build clusters in a Project. Specifically, Cluster Admins can perform Cluster CRUD (Create, Read, Update, and Delete) operations	ClusterRoleBinding
Cluster Template User	A privileged role allowed to provision, view and manage cluster resources only using the template(s)	ClusterRoleBinding
Workspace Admin	A role with ability to create new namespaces in a Project and has Read + Write access to workloads, namespaces, certificates, registries, secret stores, and aggregation endpoints	RoleBinding
Workspace Admin Read Only	A Read Only version of the Workspace Admin role	ClusterRoleBinding
Namespace Admin	A role allowed to view only the user specified namespaces but not allowed to create a new namespace. Allowed to perform end-to-end (create, publish/unpublish, edit, delete) actions on workloads with the user selected namespace(s). Specifically, they can view only the Resources that are associated with the selected namespace(s)	RoleBinding
Namespace Read Only	A Read Only version of the Namespace Admin role	RoleBinding
FinOps Admin	FinOps role is allowed to configure chargeback groups & generate chargeback reports with read access to Cost Management Dashboard	No access

Note

Read only roles map to the following verbs for ZTKA Access (Cluster Resources) - get, list, watch

Important

We strongly recommend that customers have at least two active Organization Admins per Org

The image below shows the hierarchy of roles in a typical Org.

Hierarchy of Roles

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.

For example, as seen in the diagram below, you may have a dev-project where it is acceptable for your application teams to have infra admin privileges. However, for the production-project, it is imperative that your application teams only have namespace admin role so that they can manage their applications, but cannot do any other management, for example deploying blueprints etc.

See detailed documentation on how to assign users to specific projects and grant specific roles.

Project Specific Roles

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).

Union of Roles

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.

Role 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.

Project Specific Multiple Role

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.

See detailed documentation on Groups for information on managing roles by the group.

Namespace Role

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:

Role 1	Role 2	Permissions
Org Admin	Project Admin	Org Admin
Project Admin for Project A	Infra Admin for Project A	Project + Infra Admin privileges for project A
Project Admin for ALL PROJECTS	Namespace Admin for ALL PROJECTS	Project Admin for ALL PROJECTS
Project Admin for Project A	Namespace Admin for Project A	Project Admin privileges for Project A
Project Admin for Project A	Namespace Admin for ALL PROJECTS	Project Admin privileges for Project A, Namespace Admin privileges for all other projects
Namespace Admin for Project A	Project Admin for ALL PROJECTS	Project Admin for ALL PROJECTS
Namespace Admin for Project A	Infra Admin for Project B	Namespace Admin privileges for project A, Infra Admin privileges for project B

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.

For example, when a new developer joins the organization, instead of taking on the burden of managing users one by one, the admin has to add this new developer to the "developer" group.

Review detailed documentation on Groups for information on managing roles by the group.

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 Projects Tab

Select the Projects tab
Click Assign User To Project

Projects Dropdown

Select the project from the drop down
Assign Role(s) and click SAVE & EXIT

Assign Role

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".

User with Organization Admin Role

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

Infra Admin

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.

Add User with Organization Admin Role