# Kubernetes Rbac

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**](https://kubernetes.io/docs/admin/authorization/rbac/) for details on Kubernetes RBAC Authorization APIs.

In Kubernetes, roles are categorized as Roles and ClusterRoles, whereas permissions are categorized as RoleBinding and ClusterRoleBinding.

## Kubernetes RBAC Privileges for Platform9 Users and Roles

A user that has the admin role for a Platform9 Tenant has complete access to all Kubernetes clusters in the tenant.

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 Platform9 Tenant 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 access the Kubernetes Dashboard from Platform9 SaaS Managment Plane.
* List all namespaces (strictly read only), which allows the users to use the SaaS Management Plane to view cluster resources.

## 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 `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.

{% hint style="info" %}
**Info**

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

To implement RBAC, you must invoke RBAC APIs.
{% endhint %}

The following table briefly describes the Role and its corresponding Role Binding defined by Kubernetes RBAC API.

| **Role in RBAC API** | **Scope**      | **Applicable Role Binding** |
| -------------------- | -------------- | --------------------------- |
| Role                 | namespace-wide | RoleBinding                 |

The following example for Role defines a role which lets users to read pods in the default namespace.

{% tabs %}
{% tab title="YAML" %}

```yaml
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"]
```

{% endtab %}
{% endtabs %}

The following example for RoleBinding allows the user 'jane' to read pods.

{% tabs %}
{% tab title="YAML" %}

```yaml
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
```

{% endtab %}
{% endtabs %}

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

{% hint style="info" %}
**Info**

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

To implement RBAC, you must invoke RBAC APIs.
{% endhint %}

The following table briefly describes the ClusterRole and its corresponding ClusterRoleBinding defined by Kubernetes RBAC API.

| **Role in RBAC API** | **Scope**    | **Applicable Role Binding** |
| -------------------- | ------------ | --------------------------- |
| ClusterRole          | cluster-wide | ClusterRoleBinding          |

The following example for ClusterRole grants read access to pods.

{% tabs %}
{% tab title="YAML" %}

```yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
```

{% endtab %}
{% endtabs %}

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

{% tabs %}
{% tab title="YAML" %}

```yaml
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
```

{% endtab %}
{% endtabs %}

{% hint style="info" %}
**Important**

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.
{% endhint %}

Refer to [**Kubernetes RBAC documentation**](https://kubernetes.io/docs/admin/authorization/rbac/) for details on Kubernetes RBAC Authorization APIs.

In Kubernetes, roles are categorized as Roles and ClusterRoles, whereas permissions are categorized as RoleBinding and ClusterRoleBinding.

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.

{% hint style="info" %}
**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.
{% endhint %}