Hogyan működik az RBAC a ServiceAccountokkal, és hogyan teszel biztonságossá egy Kubernetes clustert?

Question

IT Interview Practice · Accepted Answer

Az **RBAC (Role-Based Access Control)** azt szabályozza, *ki mit tehet* az API-n. A jogosultságokat **subjectekhez** (felhasználók, csoportok, **ServiceAccountok**) rendeljük úgy, hogy **Role-okhoz kötjük (bind)** őket, amelyek felsorolják az erőforrásokon engedélyezett verbeket. Az RBAC egy rétege egy szélesebb cluster-hardening stratégiának.

## Az RBAC modell

```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.
```

## Role + RoleBinding példa

```yaml
# Egy Role: csak olvasási hozzáférés a Podokhoz az "app" namespace-ben
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# A Role összekötése egy ServiceAccounttal
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
```

## ServiceAccountok: identitás a Podoknak

```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   # kikapcsolás, ha nincs szükség API-hívásra
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # a Podok ezen identitás alatt futnak
```

## Defense in depth — az RBAC-on túl

```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          # mit tehet az aktuális felhasználó?
```

## Miért fontos

Egy cluster biztonságossá tétele senior felelősség, és az RBAC a ServiceAccountokkal ennek az alapja, ezért mindkettő megértése elengedhetetlen biztonsági tudás. Az RBAC modell elegáns és érdemes internalizálni: a jogosultságok **tisztán additívak, deny nélkül**, úgy adva, hogy **subjecteket** (felhasználókat, csoportokat és különösen **ServiceAccountokat**) kötünk **Role-okhoz** (namespace-hez kötött) vagy **ClusterRole-okhoz** (cluster-szintű), amelyek felsorolják az erőforrásokon engedélyezett **verbeket** — ami azt jelenti, hogy a jó biztonság abból ered, hogy csak azt adod meg, amire az egyes workloadoknak szükségük van (**least privilege**), nem pedig tiltásokra hagyatkozol. Annak megértése, hogy egy **ServiceAccount az az identitás, amelyet egy Pod az API hívásához használ** — hogy minden Pod kap egy tokent, hogy a `default` SA gyakori túljogosultsági csapda, és hogy minden workloadnak saját, legkisebb jogosultságú SA-t érdemes adni (és letiltani a token automount-olását, ha nincs szükség API-elérésre) — közvetlenül gyakorlati, és gyakori valós hibás konfiguráció forrása. Kritikusan, egy senior mérnök tudja, hogy az RBAC csak egy rétege a **defense in depth**-nek: a default-deny **NetworkPolicy-k**, a keményített **securityContext** beállítások (nem root, csak olvasható root fájlrendszer, elvett capability-k, seccomp), a **Pod Security Admission**, az **encryption at rest** és a külső managerek a Secretekhez, az image-scannelés és -aláírás, az admission controllerek (OPA/Gatekeeper, Kyverno) és a lezárt etcd/API-hozzáférés együtt védik a clustert. Mivel egy Kubernetes cluster nagy értékű célpont, ahol egyetlen túljogosított ServiceAccount vagy nyitott NetworkPolicy teljes kompromittálódáshoz vezethet, az RBAC és a szélesebb hardening-eszköztár elsajátítása alapvető a clusterek biztonságos üzemeltetéséhez production környezetben.

Az RBAC modell

Role + RoleBinding példa

ServiceAccountok: identitás a Podoknak

Defense in depth — az RBAC-on túl

Miért fontos

Kapcsolódó kérdések