Role-based Access Control in Platform9 Managed Kubernetes

Starting from Platform9 Managed Kubernetes version 3.3, Kubernetes Role-based Access Control (Kubernetes RBAC) is enabled by default on all Platform9 Managed Kubernetes clusters.

Roles and role bindings can be added at the cluster level or the namespace level by using Kubernetes RBAC, to control access to Kubernetes resources.

Kubernetes RBAC Basics

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

Role binding grants permission on a Kubernetes resource and operations related to the Kubernetes resource, to a user, a group, or a service account.

Refer to https://kubernetes.io/docs/admin/authorization/rbac/ for details on Kubernetes RBAC.

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.

kind: Role

apiVersion: rbac.authorization.k8s.io/v1

metadata:

  namespace: default

  name: pod-reader

rules:

- apiGroups: [""] # "" indicates the core API group

  resources: ["pods"]

  verbs: ["get", "watch", "list"]

kind: RoleBinding

apiVersion: rbac.authorization.k8s.io/v1

metadata:

  name: pod-reader-access

subjects:

- kind: User

  name: jane

  apiGroup: rbac.authorization.k8s.io

roleRef:

  kind: Role

  name: pod-reader

  apiGroup: rbac.authorization.k8s.io

kind: ClusterRole

apiVersion: rbac.authorization.k8s.io/v1

metadata:

  name: pod-reader

rules:

- apiGroups: [""]

  resources:

      - pods

  verbs: ["get", "watch", "list"]

kind: ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1

metadata:

  name: pod-reader-rb-ssu

subjects:

- kind: Group

  name: ssu_users

  apiGroup: rbac.authorization.k8s.io

roleRef:

  kind: ClusterRole

  name: pod-reader

  apiGroup: rbac.authorization.k8s.io

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

Refer to https://kubernetes.io/docs/admin/authorization/rbac/ for details on Kubernetes RBAC Authorization APIs.

All users have the privilege 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.

Note: Dashboard is Kubernetes RBAC aware, and the login page for Dashboard uses either the Keystone token or the kubeconfig of the user to log in. However, because of underlying limitation of Helm the AppCatalog runs as a service account which has complete access to the cluster, as described in https://github.com/kubernetes/helm/issues/1918. Therefore, the workloads started through AppCatalog will not be bound by RBAC rules.