RBAC Authorisatie

Role-Based Access Control (RBAC) kan gebruikt worden om toegang te geven aan users en/of groepen binnen Kubernetes om resources te kunnen beheren. Dit wordt geregeld via de rbac.autorization.k8s.io API en daarom dient de API server met de RBAC authorization mode te zijn opgestart. Dit kan gecontroleerd worden in /etc/kubernetes/manifests/kube-apiserver.yaml waarbij de volgende opstart parameter aanwezig dient te zijn:

- --authorization-mode=Node,RBAC

De RBAC API kent 4 objecten die gebruikt (kunnen) worden, te weten:

  • Role
  • ClusterRole
  • RoleBinding
  • ClusterRoleBinding

Roles

Roles geven aan welke permissies gebruikt mogen worden en dienen voorzien te worden van een verwijzing naar een namespace. Bijvoorbeeld een Role om pods te kunnen lezen in de default namespace:

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

Het is met Roles ook mogelijk om de permissies te beperken tot enkele resources in de namespace. Gebruik hiervoor ‘resourceNames‘, bijvoorbeeld een beperking op alleen de pod met de naam ‘busybox’:

apiVersion: rbac.authorization.k8s.io/v1 
kind: Role 
metadata: 
  namespace: default 
  name: pod-reader 
rules: 
  - apiGroups: [""] 
    resources: ["pods"]
    verbs: ["get", "watch", "list"]
    resourceNames: ["busybox"]

ClusterRole

Een ClusterRole is een set permissies die gelden voor het hele cluster. Bijvoorbeeld een ClusterRole om in alle namespaces de pods te kunnen lezen:

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

Om de Roles en ClusterRoles te kunnen gebruiken dienen deze gekoppeld te worden via binding.

RoleBinding

Hiermee worden de permissies die in een Role zijn vastgeled aan users of aan groups gekoppeld. Een RoleBinding kan dus verwijzen naar de Roles in dezelfde namespace of naar ClusterRoles maar die worden dan alleen geldig voor de namespace waarin de RoleBinding is vastgelegd. Een voorbeeld om gebruiker ‘nico’ de mogelijkheid te geven om pods te lezen in de default namespace:

apiVersion: rbac.authorization.k8s.io/v1 
kind: RoleBinding 
metadata: 
  name: read-pods 
  namespace: default 
subjects: 
- kind: User 
  name: nico  
  apiGroup: rbac.authorization.k8s.io 
roleRef: 
  kind: Role  
  name: pod-reader 
  apiGroup: rbac.authorization.k8s.io

Het is ook mogelijk een een ClusterRole te gebruiken in RoleBinding. Deze ClusterRole geldt dan uitsluitend voor de namespace waarin de RoleBinding wordt gedefinieerd!

ClusterRoleBinding

Hiermee worden permissies gegeven aan users of groups en gelden voor het gehele cluster, dus ongeacht de namespace. Bijvoorbeeld om gebruiker ‘nico’ de pods in elke namespace te laten lezen:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-all-pods
subjects:
- kind: User
  name: nico
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: all-pods-reader
  apiGroup: rbac.authorization.k8s.io

Testen

Om de roles te testen of deze goed staan ingesteld, kun je met kubectl het commando ‘auth can-i’ geven gevolgd door de actie. Bijvoorbeeld:

$ kubectl auth can-i create pods
yes

Om als administrator te testen of een gebruiken bepaalde rechten heeft, gebruik ‘–as user’, bijvoorbeeld met de role en rolebinding uit de voorbeelden hierboven (pod-reader):

$ kubectl auth can-i create pods --as nico
no
$ kubectl auth can-i get pods --as nico
yes

Op een Kubernetes Cluster (dat toegevoegd is met behulp van Rancher) worden ClusterRoles en ClusterRoleBindings aangemaakt tijdens de installatie en voor de admin roles zijn dat

$ kubectl get clusterroles | grep admin
admin
cattle-admin
cluster-admin
fleetworkspace-admin
monitoring-admin
system:aggregate-to-admin
system:kubelet-api-admin   

$ kubectl get clusterrolebindings | grep admin
cattle-admin-binding                                   ClusterRole/cattle-admin                                           47h
cluster-admin                                          ClusterRole/cluster-admin                                          47h
globaladmin-u-54321                                    ClusterRole/cluster-admin                                          47h
globaladmin-user-98765                                 ClusterRole/cluster-admin                                          47h
job-deployer                                           ClusterRole/cluster-admin                                          47h
system-netes-default-clusterRoleBinding                ClusterRole/cluster-admin                                          47h                                            

hierbij zijn de cattle-admin en cluster-admin roles gelijk voor wat betreft de rules:

rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - '*'
- nonResourceURLs:
  - '*'
  verbs:
  - '*' 

Het toevoegen en testen van een admin-user kunnen we alsolgt doen:

$ kubectl create clusterrolebinding nico --clusterrole=cluster-admin --user=nico
clusterrolebinding.rbac.authorization.k8s.io/nico created

$ kubectl get namespaces --as=nico

$ kubectl auth can-i create deployments --namespace=dev --as=nico
yes

Meer informatie over RBAC Authorization vind je hier: https://kubernetes.io/docs/reference/access-authn-authz/rbac/