Role-based access control or RBAC

In the last session, we moved from opaque magic authentication to slightly less opaque OIDC based authentication. We also applied some RBAC-based authorization, but it was one quick line and you may have missed it.

kubectl create clusterrolebinding oidc-cluster-admin --clusterrole=cluster-admin
--user='https://auth.mydomain#97277ad0-356d-4e2a-8448-ad8b5d1c024f'

In short, this binds the user we logged into OIDC with to the clusterrole of cluster-admin. This is equivilent of root, or super-user and can do anything in a cluster. if all you wanted was a role of super admin, job done! Sadly, RBAC is usually intended to be finer grained than that, thankfully Kubernetes is up to the task.

Let's look at the cluster-admin role we used above.

kubectl get clusterrole/cluster-admin -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2024-03-01T21:45:46Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
  resourceVersion: "70"
  uid: 0996a0ed-c9f3-4c1c-a0b6-895580cf344d
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - '*'
- nonResourceURLs:
  - '*'
  verbs:
  - '*'

You can see the super-ness of the role, any api group, any resource and any verb.

Here's an example of essentially a read-only role across all namespaces, api groups, verbs and resources:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: NameSpace-SecOps-FullAccess
  namespace: secops
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete

As you can see, permissions are additive. There is no access until you define it in a role, and then bind that role to a user or group. Be careful in what you grant, it may be more open than you think!