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|
Read only roles map to the following verbs for ZTKA Access (Cluster Resources) - get, list, watch
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.
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.
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.
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|
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.