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

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** styrer *hvem som kan gjøre hva* på API-et. Tillatelser gis til **subjects** (brukere, grupper, **ServiceAccounts**) ved å **binde** dem til **Roles** som lister opp tillatte verbs på resources. RBAC er ett lag i en bredere strategi for klynge-herding.

## RBAC-modellen

```text
SUBJECT (user / group / ServiceAccount)
   │  bundet av
   ▼
RoleBinding ───────► Role         (namespaced: tillatelser innen ÉN namespace)
ClusterRoleBinding ► ClusterRole  (klynge-vidt, eller gjenbrukbart på tvers av namespaces)

Role/ClusterRole = et sett med RULES: "disse VERBS på disse RESOURCES"
Bindings er ADDITIVE og det finnes INGEN deny — du gir kun det som trengs.
```

## Role + RoleBinding-eksempel

```yaml
# En Role: read-only tilgang 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 Rollen 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 IDENTITETEN en Pod bruker for å snakke med API-serveren.
  → Hver Pod får en (namespacets "default" SA hvis uspesifisert).
  → Et projisert token monteres inn i Pod-en; RBAC avgjør hva det tokenet kan gjøre.
Beste praksis: gi hver workload sin EGEN SA med least-privilege RBAC,
og sett automountServiceAccountToken: false når Pod-en ikke trenger API-tilgang.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # velg bort hvis ingen API-kall trengs
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # kjør Pods under denne identiteten
```

## Defense in depth — utover RBAC

```text
AUTH        → least-privilege RBAC; ServiceAccounts per workload; auditér tilgang
NETWORK     → default-deny NetworkPolicies (Pods kan ikke snakke med mindre tillatt)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, drop capabilities
              seccomp-profiler; Pod Security Admission (restricted) for å håndheve
SECRETS     → encryption at rest for etcd; eksterne secret managers; stram RBAC på secrets
IMAGES      → scan images, bruk betrodde registries, håndhev med admission (f.eks. policy engines)
API/etcd    → begrens og krypter etcd; TLS overalt; begrens anonym og cluster-admin-tilgang
SUPPLY CHAIN→ signerte 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          # hva kan den nåværende brukeren gjøre?
```

## Hvorfor det er viktig

Å sikre en klynge er et senior-ansvar, og RBAC med ServiceAccounts er fundamentet, så å forstå begge er essensiell sikkerhetskunnskap. RBAC-modellen er elegant og verdt å internalisere: tillatelser er **rent additive uten deny**, gitt ved å **binde subjects** (brukere, grupper, og særlig **ServiceAccounts**) til **Roles** (namespaced) eller **ClusterRoles** (klynge-vidt) som lister opp tillatte **verbs på resources** — noe som betyr at god sikkerhet kommer fra å gi bare det hver workload trenger (**least privilege**) i stedet for å stole på avslag. Å forstå at en **ServiceAccount er identiteten en Pod bruker for å kalle API-et** — at hver Pod får et token, at `default`-SA-en er en vanlig over-privilegie-felle, og at du bør gi hver workload sin egen least-privilege SA (og deaktivere token-automount når ingen API-tilgang trengs) — er direkte praktisk og en hyppig kilde til feilkonfigurering i virkeligheten. Kritisk nok vet en senioringeniør at RBAC bare er ett lag i **defense in depth**: default-deny **NetworkPolicies**, herdet **securityContext** (non-root, read-only rot-filsystem, droppede capabilities, seccomp), **Pod Security Admission**, **encryption at rest** og eksterne managere for Secrets, image-scanning og -signering, admission controllers (OPA/Gatekeeper, Kyverno), og nedlåst etcd/API-tilgang kombineres alle for å beskytte en klynge. Fordi en Kubernetes-klynge er et høyverdi-mål der en enkelt over-privilegert ServiceAccount eller åpen NetworkPolicy kan føre til full kompromittering, er det å mestre RBAC og det bredere herdings-verktøysettet grunnleggende for å drifte klynger trygt i produksjon.

RBAC-modellen

Role + RoleBinding-eksempel

ServiceAccounts: identitet for Pods

Defense in depth — utover RBAC

Hvorfor det er viktig

Relaterte spørsmål