De basis van Kubernetes RBAC: users, roles en service accounts

Dit is standaard, open-source Kubernetes-gedrag, niet specifiek voor een bepaalde provider of infrastructuurkeuze. Het geldt evengoed of je cluster nu draait op Bare Metal Compute, Flexible VPS of Private Cloud, of waar dan ook.

Wat RBAC bepaalt

RBAC bepaalt wie, of wat, welke acties mag uitvoeren, op welke resources, in je cluster. "Wie" kan een menselijke user zijn die inlogt via een kubeconfig, of een workload die zich authenticeert als service account. "Wat" is een set verbs: get, list, watch, create, update, patch, delete, en nog een paar andere. "Welke resources" betekent Kubernetes-objecten: pods, deployments, secrets, config maps, enzovoort, optioneel beperkt tot één specifieke namespace.

Zonder bewust ingerichte RBAC krijgen al snel iedereen, en elke workload, veel meer toegang dan nodig. RBAC zorgt ervoor dat toegang expliciet en controleerbaar wordt, in plaats van impliciet.

Roles versus ClusterRoles

• Role. Een set rechten die geldt binnen één namespace. Een Role die is gedefinieerd in de namespace billing geeft alleen toegang tot resources in billing, nergens anders.
• ClusterRole. Hetzelfde idee, maar voor het hele cluster. Een ClusterRole kan toegang geven over alle namespaces heen, of tot cluster-scoped resources die helemaal niet bij een namespace horen, zoals nodes of persistent volumes.

Een handige vuistregel: kies standaard voor een Role, tenzij je een specifieke reden hebt om cluster-wide scope nodig te hebben. Toegang binnen één namespace is makkelijker te overzien en beperkt de blast radius als een credential lekt.

RoleBindings versus ClusterRoleBindings

Het definiëren van een Role of ClusterRole geeft op zichzelf nog niemand toegang, het beschrijft alleen een set rechten. Een binding is wat die role daadwerkelijk koppelt aan een user, group of service account.

• RoleBinding. Geeft een Role (of, opvallend genoeg, ook een ClusterRole) aan een subject binnen één namespace. Je kunt een ClusterRole via een RoleBinding binden om een gedeelde set rechten per namespace te hergebruiken, zonder cluster-wide toegang te geven.
• ClusterRoleBinding. Geeft een ClusterRole aan een subject voor het hele cluster.

Voorbeeld: een read-only role binnen één namespace

Onderstaand manifest definieert een Role die alleen pods en hun logs mag lezen in de namespace billing, en koppelt deze vervolgens aan een service account.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: billing
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: billing
subjects:
  - kind: ServiceAccount
    name: billing-readonly
    namespace: billing
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Dit geeft precies drie verbs, op twee resource types, in één namespace, niets meer. Het is een goed patroon voor een monitoring tool, een support engineer, of een CI-job die alleen de status en logs van pods hoeft te bekijken.

kubeconfig en service accounts

Menselijke users authenticeren doorgaans via een kubeconfig-bestand, dat kubectl naar een cluster wijst en credentials bevat: een certificate, een token, of een login via een externe identity provider, afhankelijk van hoe het cluster is ingericht. Elke user of elk team krijgt meestal een eigen kubeconfig context, via RBAC beperkt tot alleen de namespaces en rechten die ze nodig hebben.

Workloads die binnen het cluster draaien, gebruiken in plaats daarvan service accounts. Elke namespace heeft een default service account, maar alles onder die default laten draaien is een veelvoorkomende manier om meer toegang te krijgen dan de bedoeling was. Maak per workload een eigen service account aan, koppel deze aan een specifiek daarvoor bedoelde Role, en mount alleen die identity in de pod die hem nodig heeft.

Het principe van least privilege

Het patroon dat RBAC beheersbaar houdt naarmate een cluster groeit: geef de kleinst mogelijke set verbs, op de kleinst mogelijke set resources, in de kleinst mogelijke scope, waarmee een user of workload zijn werk kan doen. Kies waar mogelijk voor Roles boven ClusterRoles, geef de voorkeur aan read-only verbs (get, list, watch) boven schrijftoegang tenzij die echt nodig is, en geef elke workload zijn eigen service account in plaats van één breed opgezette identity te delen over veel pods. Controleer bindings regelmatig, want toegang die logisch was op het moment dat die werd gegeven, blijft dat niet altijd zo.