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.

Role in RBAC APIScopeApplicable Role BindingExample
Rolenamespace-wideRoleBindingThe following example for Role defines a role which lets users to read pods in the default namespace.
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"]


The following example for RoleBinding allows the user 'jane' to read pods.
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
ClusterRolecluster-wideClusterRoleBindingThe following example for ClusterRole grants read access to pods.
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: pod-reader
rules:
- apiGroups: [""]
resources:
- pods
verbs: ["get", "watch", "list"]


The following example for ClusterRoleBinding allows users in the 'ssu_users' group to to view pods across all namespaces in the cluster.

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.

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.

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.


January 16, 2018