Hvordan fungerer RBAC med ServiceAccounts, og hvordan sikrer man en Kubernetes-klynge?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** styrer *hvem der må gøre hvad* på API'et. Tilladelser gives til **subjects** (users, groups, **ServiceAccounts**) ved at **binde** dem til **Roles**, der lister tilladte verbs på ressourcer. RBAC er ét lag i en bredere strategi for klynge-hærdning.

## RBAC-modellen

```text
SUBJECT (user / group / ServiceAccount)
   │  bundet af
   ▼
RoleBinding ───────► Role         (namespaced: tilladelser inden for ÉT namespace)
ClusterRoleBinding ► ClusterRole  (klynge-dækkende, eller genbrugelig på tværs af namespaces)

Role/ClusterRole = et sæt REGLER: "disse VERBS på disse RESSOURCER"
Bindings er ADDITIVE, og der er INGEN deny — du giver kun det nødvendige.
```

## Role + RoleBinding-eksempel

```yaml
# En Role: skrivebeskyttet adgang til Pods i "app"-namespacet
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 den Role til en 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: identitet for Pods

```text
En ServiceAccount er den IDENTITET, en Pod bruger til at tale med API-serveren.
  → Hver Pod får én (namespacets "default" SA, hvis uspecificeret).
  → Et projiceret token mountes ind i Pod'en; RBAC afgør, hvad det token kan.
Best practice: giv hver workload sin EGEN SA med least-privilege RBAC,
og sæt automountServiceAccountToken: false, når Pod'en ikke behøver API-adgang.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # fravælg, hvis ingen API-kald er nødvendige
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # kør Pods under denne identitet
```

## Defense in depth — ud over RBAC

```text
AUTH        → least-privilege RBAC; ServiceAccounts pr. workload; auditér adgang
NETWORK     → default-deny NetworkPolicies (Pods kan ikke tale sammen, medmindre det tillades)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, drop capabilities
              seccomp-profiler; Pod Security Admission (restricted) til at håndhæve
SECRETS     → encryption at rest for etcd; eksterne secret managers; stram RBAC på secrets
IMAGES      → scan images, brug betroede registries, håndhæv med admission (fx policy engines)
API/etcd    → begræns & kryptér etcd; TLS overalt; begræns anonym & cluster-admin-adgang
SUPPLY CHAIN→ signerede 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          # hvad kan den nuværende bruger?
```

## Hvorfor det betyder noget

At sikre en klynge er et senioransvar, og RBAC med ServiceAccounts er dets fundament, så det er essentiel sikkerhedsviden at forstå begge. RBAC-modellen er elegant og værd at internalisere: tilladelser er **rent additive uden deny**, givet ved at **binde subjects** (users, groups og især **ServiceAccounts**) til **Roles** (namespaced) eller **ClusterRoles** (klynge-dækkende), der opremser tilladte **verbs på ressourcer** — hvilket betyder, at god sikkerhed kommer af kun at give det, hver workload har brug for (**least privilege**), frem for at stole på afvisninger. At forstå, at en **ServiceAccount er den identitet, en Pod bruger til at kalde API'et** — at hver Pod får et token, at `default`-SA'en er en almindelig fælde for over-privilegering, og at man bør give hver workload sin egen least-privilege-SA (og deaktivere token-automounting, når ingen API-adgang er nødvendig) — er direkte praktisk og en hyppig kilde til fejlkonfiguration i den virkelige verden. Afgørende ved en senioringeniør ved, at RBAC kun er ét lag af **defense in depth**: default-deny **NetworkPolicies**, hærdede **securityContext**-indstillinger (non-root, skrivebeskyttet root-filsystem, droppede capabilities, seccomp), **Pod Security Admission**, **encryption at rest** og eksterne managers til Secrets, image-scanning og -signering, admission controllers (OPA/Gatekeeper, Kyverno) og aflåst etcd/API-adgang kombineres alle for at beskytte en klynge. Fordi en Kubernetes-klynge er et højværdimål, hvor en enkelt over-privilegeret ServiceAccount eller åben NetworkPolicy kan føre til fuld kompromittering, er det at mestre RBAC og det bredere hærdnings-værktøjssæt fundamentalt for at drive klynger sikkert i production.

RBAC-modellen

Role + RoleBinding-eksempel

ServiceAccounts: identitet for Pods

Defense in depth — ud over RBAC

Hvorfor det betyder noget

Relaterede spørgsmål