Configure Kubernetes RBAC
Access to Kubernetes resources can be granted based on roles and the permissions associated with roles. With role-based access control (RBAC), it is possible to restrict unauthorized access to Kubernetes resources.
Refer to Kubernetes RBAC documentation for details on Kubernetes RBAC Authorization APIs.
In Kubernetes, roles are categorized as Roles and ClusterRoles, whereas permissions are categorized as RoleBinding and ClusterRoleBinding.
Role and RoleBinding
A role is a set of permissions that can be granted on resources in a namespace.
Roles are used to associate resources to actions. A role specifies the actions that are allowed on one or more resources.
Resources are denoted as nouns and actions as verbs in Kubernetes. For example, a
create action can be performed on a
Role binding grants permission on a Kubernetes resource and operations related to the Kubernetes resource, to a user, a group, or a service account.
ClusterRole and ClusterRoleBinding
A ClusterRole is a set of permission that can be granted on resources in a cluster.
A ClusterRoleBinding is about binding or associating a ClusterRole with a user, a group of users, or a service account.
Role-based Access Control (RBAC) is enabled, by default, on all Platform9 Managed Kubernetes clusters.
To implement RBAC, you must invoke RBAC APIs.
The following table briefly describes the roles and corresponding role bindings defined by the Kubernetes RBAC API.
|Role in RBAC API||Scope||Applicable Role Binding||Example|
|Role||namespace-wide||RoleBinding||The following example for Role defines a role which lets users to read pods in the default namespace.
The following example for RoleBinding allows the user 'jane' to read pods.
|ClusterRole||cluster-wide||ClusterRoleBinding||The following example for ClusterRole grants read access to pods.
The following example for ClusterRoleBinding allows users in the 'ssu_users' group to to view pods across all namespaces in the cluster.
Any user that wants to access a Kubernetes resource must have the following.
- A valid token for the Keystone project to which the cluster belongs.
- A RBAC role binding granted to the user (or to a group that the user belongs to) for that resource.
Kubernetes RBAC Privileges for Keystone Roles
A user that has the admin role on a Keystone project, has complete access to all Kubernetes clusters in the project.
A user with the admin role has the permissions to do the following.
- Create relevant RBAC roles and role bindings for any user or group for any cluster in the project with Kubernetes APIs.
- Create additional groups and assign role binding to the group.
All users who have member role for a Keystone project are part of the ssu_users group. To grant common permissions to all users, an admin user can grant the required permissions to the ssu_users group.
For existing apps and workloads to continue to work, make sure to add appropriate RBAC permissions for the service accounts being used for the apps.
All users have the permissions to do the following.
- Proxy into the API server, which allows the users to open dashboard from Platform9 Clarity UI and to open web CLI from Platform9 Clarity UI.
- List all namespaces (strictly read only), which allows the users to use dashboard and App Catalog by selecting the namespace they have access to.
Thank you for your feedback! What did you like about this article?
Thank you for your feedback! How could this article be improved?
Thank you for your feedback! For specific questions about PMK or PMK free tier, visit our PMK forum.