Hur fungerar RBAC med ServiceAccounts, och hur säkrar man ett Kubernetes-kluster?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** styr *vem som får göra vad* mot API:et. Behörigheter beviljas till **subjekt** (användare, grupper, **ServiceAccounts**) genom att **binda** dem till **Roles** som listar tillåtna verb på resurser. RBAC är ett skikt i en bredare strategi för klusterhärdning.

## RBAC-modellen

```text
SUBJECT (user / group / ServiceAccount)
   │  bound by
   ▼
RoleBinding ───────► Role         (namespaced: permissions within ONE namespace)
ClusterRoleBinding ► ClusterRole  (cluster-wide, or reusable across namespaces)

Role/ClusterRole = a set of RULES: "these VERBS on these RESOURCES"
Bindings are ADDITIVE and there is NO deny — you grant only what's needed.
```

## Exempel med Role + RoleBinding

```yaml
# En Role: läsåtkomst till Pods i namespace:t "app"
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:n till 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 för Pods

```text
A ServiceAccount is the IDENTITY a Pod uses to talk to the API server.
  → Every Pod gets one (the namespace "default" SA if unspecified).
  → A projected token is mounted into the Pod; RBAC decides what that token can do.
Best practice: give each workload its OWN SA with least-privilege RBAC,
and set automountServiceAccountToken: false when the Pod doesn't need API access.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # välj bort om inga API-anrop behövs
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # kör Pods under denna identitet
```

## Djupförsvar — bortom RBAC

```text
AUTH        → least-privilege RBAC; per-workload ServiceAccounts; audit access
NETWORK     → default-deny NetworkPolicies (Pods can't talk unless allowed)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, drop capabilities
              seccomp profiles; Pod Security Admission (restricted) to enforce
SECRETS     → encryption at rest for etcd; external secret managers; tight RBAC on secrets
IMAGES      → scan images, use trusted registries, enforce with admission (e.g. policy engines)
API/etcd    → restrict & encrypt etcd; TLS everywhere; limit anonymous & cluster-admin access
SUPPLY CHAIN→ signed 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          # vad kan den aktuella användaren göra?
```

## Varför det är viktigt

Att säkra ett kluster är ett senioransvar, och RBAC med ServiceAccounts är dess grund, så att förstå båda är väsentlig säkerhetskunskap. RBAC-modellen är elegant och värd att internalisera: behörigheter är **rent additiva utan neka**, beviljade genom att **binda subjekt** (användare, grupper, och särskilt **ServiceAccounts**) till **Roles** (namespace-avgränsade) eller **ClusterRoles** (klusteromfattande) som räknar upp tillåtna **verb på resurser** — vilket betyder att god säkerhet kommer av att bevilja endast vad varje workload behöver (**least privilege**) snarare än att förlita sig på nekanden. Att förstå att en **ServiceAccount är den identitet en Pod använder för att anropa API:et** — att varje Pod får en token, att `default`-SA:n är en vanlig fälla för överbehörighet, och att du bör ge varje workload sin egen least-privilege-SA (och stänga av automount av token när ingen API-åtkomst behövs) — är direkt praktiskt och en frekvent källa till felkonfiguration i verkligheten. Avgörande är att en senior ingenjör vet att RBAC bara är ett skikt av **djupförsvar**: default-deny **NetworkPolicies**, härdade **securityContext**-inställningar (non-root, skrivskyddat rot-filsystem, borttagna capabilities, seccomp), **Pod Security Admission**, **encryption at rest** och externa managers för Secrets, image-skanning och -signering, admission controllers (OPA/Gatekeeper, Kyverno), och nedlåst etcd/API-åtkomst kombineras alla för att skydda ett kluster. Eftersom ett Kubernetes-kluster är ett högvärdigt mål där en enda överbehörig ServiceAccount eller öppen NetworkPolicy kan leda till full kompromettering är det grundläggande att behärska RBAC och den bredare härdningsverktygslådan för att driva kluster säkert i produktion.

RBAC-modellen

Exempel med Role + RoleBinding

ServiceAccounts: identitet för Pods

Djupförsvar — bortom RBAC

Varför det är viktigt

Relaterade frågor