Users And Roles in PMK
- User Roles Supported In PMK
- Role Based Privileges 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:
- Self-service user
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 https://kubernetes.io/docs/reference/access-authn-authz/rbac/
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.
|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|
|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|
|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|