In this article, we'll learn about authorization in Kubernetes using Role-based access control(RBAC). We need the authorization to restrict user access, shared the same cluster between the different teams, and to differentiate administrative tasks.

Prerequisites

1. Minikube or Kubernetes cluster
2. Basic knowledge of Kubernetes

Authorization in Kubernetes is basically of two types.

1. Within Namespace
2. Within multiple namespaces or across the cluster

Below are a few keywords that we need to understand before diving into authorization.

Role

• It helps to define permission within a namespace so we have to provide a specific namespace while creating the role.

ClusterRole

• It helps to define permission within a namespace, all namespace, and cluster scoped resources.

RoleBinding

• It helps to grant permission defined in role to a user, group, or service accounts. As they link it to Role so it is within a specific namespace.

ClusterRoleBinding

• It helps to grand permission defined in ClusterRole to a user, group, or service accounts. As they link it to ClusterRole it is for all the namespace or all cluster resources.

As part of the example, we'll create two users, one will have access to only one namespace and the other will have access to all the namespace.

1. Create two service accounts - developer and architect.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: developer
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: architect

2. Create a Role for a single namespace and ClusterRole for all the namespace. As the role is for a single namespace we have to provide a namespace name while creating it and ClusterRole is for the whole cluster so we can avoid the same. For simplicity, we will grant all the permission to Role and ClusterRole. If we want, then we can provide granular level permission like read-only a pod, delete a pod, read-only secret, etc with the help of API groups, resources, and verbs.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: within-workspace
rules:
  - apiGroups:
      - '*'
    resources:
      - '*'
    verbs:
      - '*'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: multiple-workspace
rules:
  - apiGroups:
      - '*'
    resources:
      - '*'
    verbs:
      - '*'

3. Create RoleBinding and ClusterRoleBinding to assign created Role and Cluster role to developer and architect service accounts. After we create bindings we can not update the underlying Role or ClusterRole. If we want, then we have to delete bindings first and then change the same.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-user-bindings
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: within-workspace
subjects:
  - kind: User
    name: developer
    apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: architect-user-bindings
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: multiple-workspace
subjects:
  - kind: User
    name: architect
    apiGroup: rbac.authorization.k8s.io

4. Test with developer and architect service account, as shown below. The developer can access only the dev namespace while the architect can access all the namespace.