Cum funcționează RBAC împreună cu ServiceAccounts și cum securizezi un cluster Kubernetes?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** guvernează *cine ce poate face* pe API. Permisiunile sunt acordate **subiecților** (utilizatori, grupuri, **ServiceAccounts**) prin **legarea (binding)** lor de **Roles** care listează verbele permise pe resurse. RBAC este un strat dintr-o strategie mai amplă de întărire a clusterului.

## Modelul RBAC

```text
SUBIECT (user / grup / ServiceAccount)
   │  legat de
   ▼
RoleBinding ───────► Role         (namespaced: permisiuni într-UN singur namespace)
ClusterRoleBinding ► ClusterRole  (la nivel de cluster, sau reutilizabil între namespace-uri)

Role/ClusterRole = un set de REGULI: "aceste VERBE pe aceste RESURSE"
Binding-urile sunt ADITIVE și NU există deny — acorzi doar ce e necesar.
```

## Exemplu Role + RoleBinding

```yaml
# Un Role: acces read-only la Pod-urile din namespace-ul "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"]
---
# Leagă acel Role de un 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: identitate pentru Pod-uri

```text
Un ServiceAccount este IDENTITATEA pe care o folosește un Pod pentru a vorbi cu API server-ul.
  → Fiecare Pod primește unul (SA-ul "default" al namespace-ului dacă nu e specificat).
  → Un token proiectat este montat în Pod; RBAC decide ce poate face acel token.
Best practice: dă fiecărui workload PROPRIUL SA cu RBAC de privilegiu minim,
și setează automountServiceAccountToken: false când Pod-ul nu are nevoie de acces la API.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # renunță dacă nu sunt necesare apeluri la API
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # rulează Pod-urile sub această identitate
```

## Apărare în adâncime — dincolo de RBAC

```text
AUTH        → RBAC de privilegiu minim; ServiceAccounts per workload; auditează accesul
NETWORK     → NetworkPolicies default-deny (Pod-urile nu comunică decât dacă e permis)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, drop capabilities
              profile seccomp; Pod Security Admission (restricted) pentru a impune
SECRETS     → criptare la repaus pentru etcd; managere externe de secrete; RBAC strict pe secrete
IMAGES      → scanează imaginile, folosește registre de încredere, impune cu admission (ex. policy engines)
API/etcd    → restricționează & criptează etcd; TLS peste tot; limitează accesul anonim & cluster-admin
SUPPLY CHAIN→ imagini semnate, 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          # ce poate face utilizatorul curent?
```

## De ce contează

Securizarea unui cluster este o responsabilitate de senior, iar RBAC cu ServiceAccounts este fundația ei, așa că înțelegerea ambelor este cunoaștere esențială de securitate. Modelul RBAC este elegant și merită internalizat: permisiunile sunt **pur aditive, fără deny**, acordate prin **legarea subiecților** (utilizatori, grupuri și în special **ServiceAccounts**) de **Roles** (namespaced) sau **ClusterRoles** (la nivel de cluster) care enumeră **verbele permise pe resurse** — ceea ce înseamnă că securitatea bună vine din acordarea doar a ce are nevoie fiecare workload (**privilegiu minim**) și nu din bazarea pe interdicții. Înțelegerea faptului că un **ServiceAccount este identitatea pe care o folosește un Pod pentru a apela API-ul** — că fiecare Pod primește un token, că SA-ul `default` este o capcană comună de supra-privilegiere, și că ar trebui să dai fiecărui workload propriul SA de privilegiu minim (și să dezactivezi automontarea token-ului când nu e necesar acces la API) — este direct practic și o sursă frecventă de configurare greșită în lumea reală. Crucial, un inginer senior știe că RBAC este doar un strat de **apărare în adâncime**: NetworkPolicies **default-deny**, setări **securityContext** întărite (non-root, filesystem root read-only, capabilities eliminate, seccomp), **Pod Security Admission**, **criptare la repaus** și managere externe pentru Secrets, scanarea și semnarea imaginilor, admission controllers (OPA/Gatekeeper, Kyverno) și acces blocat la etcd/API se combină pentru a proteja un cluster. Deoarece un cluster Kubernetes este o țintă de mare valoare unde un singur ServiceAccount supra-permisionat sau o NetworkPolicy deschisă poate duce la compromitere totală, stăpânirea RBAC și a setului mai larg de unelte de întărire este fundamentală pentru a opera clustere în siguranță în producție.

Modelul RBAC

Exemplu Role + RoleBinding

ServiceAccounts: identitate pentru Pod-uri

Apărare în adâncime — dincolo de RBAC

De ce contează

Întrebări conexe