Users And Roles in PMK


A user is a person that has been given access to a Platform9 Managed Kubernetes (PMK) deployment. A user can log in to the PMK Clarity UI and / or access the PMK REST APIs to build, test and run their business critical applications as microservices on Kubernetes.

A user can hold multiple roles within a PMK environment depending on the region or tenant they have access to. A user could be an administrator, or a self-service user such as a developer or a tester that performs various operations on Kubernetes clusters deployed in PMK.

A new user can be granted access to a PMK deployment either by setting up a Single-Sign On (SSO) integration using a SAML 2.0 compliant identity federation or a simple username-password combination stored local to the PMK deployment. Users are granted access to PMK based on the user role that has been assigned to the user on a tenant.

User Roles Supported In PMK

A role is a set of privileges that can be assigned to one or more users. When a role is assigned to a user, the user can perform tasks that the role permits the user to perform.

PMK provides following two predefined roles:

  • Administrator
  • Self-service user

Administrator Role

An administrator is a super user of the PMK environment and has unrestricted access to the PMK deployment including all the regions and all tenants in that PMK deployment.

An administrator has the rights to perform all operations within PMK including but not limited to creating tenants, users, cloud providers, clusters and configuring physical or virtual machines to be part of PMK clusters, etc.

Administrators also have full access to the PMK Qbert REST APIs that can be used to automate cluster creation and management.

Self-service User Role

The self-service user role enables users to deploy one or more containerized workloads on the Kubernetes clusters that belong to the tenants the user is a member of. Self-service users have restricted views that are limited to the tenant that they have been assigned to and are not able to access any resources that are outside of their associated tenant/s.

By default, a self-service user in a given tenant does not have access to the Kubernetes clusters in that tenant. An Aministrator needs to explicitly give the self-service user access to one or more clusters in the tenant by creating Kubernetes RBAC policies on those clusters for that user. The self-service user can then perform operations on the clusters that the RBAC policies allow them to do. For more information on Kubernetes RBAC, see

Refer also to Role-based Access Control in PMK for more information.

Role Based Privileges in PMK

Refer to the table below for examples of tasks that can be done by an administrator vs a self-service user.

AdministratorSelf-service User
Infrastructure Management
Create, Delete Cloud Providers Accessible Not Accessible
Create, Edit, Scale, Delete Cluster Accessible Not Accessible
Upgrade Cluster Accessible Not Accessible
Tenant and User Management
Create, Edit, Delete users and / or groups Accessible Not Accessible
Create, Edit, Delete tenant Accessible Not Accessible
API Access
Access PMK (Qbert and Keystone) APIs for cluster and tenant/user management Accessible Not Accessible
Download kubeconfig and access cluster APIs Accessible Accessible only if administrator has enabled access via RBAC policies
Application Management
Deploy applications from catalog Accessible Accessible
Create pods, deployment, services, namespaces, storage classes and other k8s objects Accessible Accessible only if administrator has enabled access via RBAC policies
Creating instances of managed applications such as Prometheus, Fluentd Accessible Accessible only if administrator has enabled access via RBAC policies