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]

Base 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)
Auditor	Allows generation/downloading user access reports and viewing/downloading audit logs	No access
Cluster Admin	A privileged role allowed to build clusters in a Project. Resources: Read + Write access to any Cluster related operations	ClusterRoleBinding Resources: All Verbs: All
Cluster Template User	A privileged role allowed to provision, view and manage cluster resources only using cluster template(s)	ClusterRoleBinding Resources: All Verbs: All
Environment Template User	A privileged role allowed to provision, view and manage environment resources only using environment template(s)	No Access
FinOps Admin	FinOps role is allowed to configure chargeback groups & generate chargeback reports with read access to Cost Management Dashboards	No access
Infrastructure Admin	A privileged role allowed to manage all infrastructure related resources in a Project. Resources: Read + Write access to Environments, Clusters, Cloud Credentials, Fleet Plans, Blueprints, Add-ons, Cluster Overrides, Backup & Restore configurations, OPA Gatekeeper configurations, OPA Policy Violations, Network Policy configurations, Namespaces	ClusterRoleBinding Resources: All Verbs: All
Infrastructure Read Only	A Read Only version of the Infrastructure Admin role	ClusterRoleBinding Resources: All Verbs: get, list, watch
Namespace Admin	A role allowed to view only the assigned 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). Can also view OPA Policy Violations	RoleBinding Resources: All namespaced scoped resources Verbs: All
Namespace Read Only	A Read Only version of the Namespace Admin role	RoleBinding Resources: All namespaced scoped resources Verbs: get, list, watch
Org Admin Read Only	A Read Only version of the Org Admin role	ClusterRoleBinding Resources: All Verbs: get, list, watch
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. Resources: Read + Write access to Environments, Clusters, Cloud Credentials, Fleet Plans, Blueprints, Add-ons, Cluster Overrides, Backup & Restore configurations, OPA Gatekeeper configurations, OPA Policy Violations, Network Policy configurations, Namespaces, Workloads, Secret stores, Secret Provider Classes, Registries, Repositories, GitOps Pipelines/Agents, Chargeback related configurations	ClusterRoleBinding Resources: All Verbs: All
PaaS End Users (Collaborators)	Includes roles such as Developer, Researcher, Data Engineer, Data Scientist, MLOps Engineer, and GenAI Developer. These roles can launch instances (from system or custom profiles), create workspaces, and add collaborators to workspaces	RoleBinding Resources: Instances, workspaces Verbs: Create, view, manage
PaaS Project Admin	A role that allows viewing Profile Catalogs, creating custom profiles (compute/service profiles within the project), and launching instances (from Profile Catalogs or custom profiles)	RoleBinding Resources: Compute/Service profiles, Instances Verbs: Create, view, manage
Project Admin	A privileged role allowed to manage all application related resources in a Project. Resources: Read + Write access to Namespaces, Workloads, Secret stores, Secret Provider Classes, Registries, Repositories, GitOps Pipelines/Agents, OPA Policy Violations	ClusterRoleBinding Resources: All Verbs: All
Project Read Only	A Read Only version of the Project Admin role	ClusterRoleBinding Resources: All Verbs: get, list, watch
Workspace Admin	A role with ability to create new namespaces in a Project and deploy workloads. Resources: Read + Write access to Workloads, Namespaces, Registries, Secret stores, OPA Policy Violations	RoleBinding Resources: All namespaced scoped resources Verbs: All
Workspace Admin Read Only	A Read Only version of the Workspace Admin role	RoleBinding Resources: All namespaced scoped resources Verbs: get, list, watch

Important

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

Note

To get the list of resources that are namespace scoped, use the below command
kubectl api-resources --namespaced=true

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

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.

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.

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

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