Hoe werkt RBAC met ServiceAccounts, en hoe beveilig je een Kubernetes-cluster?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** regelt *wie wat mag doen* op de API. Rechten worden verleend aan **subjects** (users, groups, **ServiceAccounts**) door ze te **binden** aan **Roles** die toegestane verbs op resources opsommen. RBAC is één laag van een bredere cluster-hardening-strategie.

## Het RBAC-model

```text
SUBJECT (user / group / ServiceAccount)
   │  gebonden door
   ▼
RoleBinding ───────► Role         (namespaced: rechten binnen ÉÉN namespace)
ClusterRoleBinding ► ClusterRole  (cluster-breed, of herbruikbaar over namespaces)

Role/ClusterRole = een set RULES: "deze VERBS op deze RESOURCES"
Bindings zijn ADDITIEF en er is GEEN deny — je verleent alleen wat nodig is.
```

## Voorbeeld Role + RoleBinding

```yaml
# Een Role: alleen-lezen toegang tot Pods in de "app"-namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# Bind die Role aan een ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: app
  name: read-pods
subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: app
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```

## ServiceAccounts: identiteit voor Pods

```text
Een ServiceAccount is de IDENTITEIT die een Pod gebruikt om met de API server te praten.
  → Elke Pod krijgt er een (de "default" SA van de namespace indien niet gespecificeerd).
  → Een projected token wordt in de Pod gemount; RBAC bepaalt wat dat token mag doen.
Best practice: geef elke workload zijn EIGEN SA met least-privilege RBAC,
en zet automountServiceAccountToken: false wanneer de Pod geen API-toegang nodig heeft.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # opt-out als er geen API-calls nodig zijn
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # draai Pods onder deze identiteit
```

## Defense in depth — voorbij RBAC

```text
AUTH        → least-privilege RBAC; ServiceAccounts per workload; toegang auditen
NETWORK     → default-deny NetworkPolicies (Pods praten niet tenzij toegestaan)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, capabilities droppen
              seccomp-profielen; Pod Security Admission (restricted) om af te dwingen
SECRETS     → encryption at rest voor etcd; externe secret managers; strakke RBAC op secrets
IMAGES      → images scannen, vertrouwde registries gebruiken, afdwingen met admission (policy engines)
API/etcd    → etcd beperken & encrypten; overal TLS; anonymous & cluster-admin-toegang beperken
SUPPLY CHAIN→ gesigneerde images, admission control (OPA/Gatekeeper, Kyverno)
```

```bash
kubectl auth can-i list pods --as=system:serviceaccount:app:my-app -n app
kubectl auth can-i --list -n app          # wat mag de huidige gebruiker doen?
```

## Waarom het belangrijk is

Een cluster beveiligen is een senior-verantwoordelijkheid, en RBAC met ServiceAccounts is de fundering ervan, dus beide begrijpen is essentiële beveiligingskennis. Het RBAC-model is elegant en het internaliseren waard: rechten zijn **puur additief zonder deny**, verleend door **subjects te binden** (users, groups, en vooral **ServiceAccounts**) aan **Roles** (namespaced) of **ClusterRoles** (cluster-breed) die toegestane **verbs op resources** opsommen — wat betekent dat goede beveiliging voortkomt uit alleen verlenen wat elke workload nodig heeft (**least privilege**) in plaats van te vertrouwen op denials. Begrijpen dat een **ServiceAccount de identiteit is die een Pod gebruikt om de API aan te roepen** — dat elke Pod een token krijgt, dat de `default` SA een veelvoorkomende over-privilege-valkuil is, en dat je elke workload zijn eigen least-privilege SA moet geven (en token-automounting moet uitschakelen wanneer er geen API-toegang nodig is) — is direct praktisch en een frequente bron van misconfiguratie in de praktijk. Cruciaal is dat een senior engineer weet dat RBAC slechts één laag van **defense in depth** is: default-deny **NetworkPolicies**, geharde **securityContext**-instellingen (non-root, read-only root filesystem, gedropte capabilities, seccomp), **Pod Security Admission**, **encryption at rest** en externe managers voor Secrets, image-scanning en -signing, admission controllers (OPA/Gatekeeper, Kyverno), en dichtgetimmerde etcd/API-toegang combineren allemaal om een cluster te beschermen. Omdat een Kubernetes-cluster een waardevol doelwit is waar één ServiceAccount met te veel rechten of één open NetworkPolicy tot volledige compromittering kan leiden, is het beheersen van RBAC en de bredere hardening-toolkit fundamenteel om clusters veilig in productie te bedienen.

Het RBAC-model

Voorbeeld Role + RoleBinding

ServiceAccounts: identiteit voor Pods

Defense in depth — voorbij RBAC

Waarom het belangrijk is

Gerelateerde vragen