Come funziona l'RBAC con i ServiceAccount, e come si mette in sicurezza un cluster Kubernetes?

Question

IT Interview Practice · Accepted Answer

L'**RBAC (Role-Based Access Control)** governa *chi può fare cosa* sull'API. I permessi sono concessi a **subject** (utenti, gruppi, **ServiceAccount**) tramite il **binding** a **Role** che elencano i verb consentiti sulle risorse. L'RBAC è uno strato di una strategia più ampia di hardening del cluster.

## Il modello RBAC

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

## Esempio di Role + RoleBinding

```yaml
# A Role: read-only access to Pods in the "app" namespace
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 that Role to a 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
```

## ServiceAccount: l'identità per i Pod

```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   # opt out if no API calls are needed
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # run Pods under this identity
```

## Difesa in profondità — oltre l'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          # what can the current user do?
```

## Perché è importante

Mettere in sicurezza un cluster è una responsabilità senior, e l'RBAC con i ServiceAccount ne è il fondamento, quindi capire entrambi è una conoscenza di sicurezza essenziale. Il modello RBAC è elegante e vale la pena interiorizzarlo: i permessi sono **puramente additivi, senza deny**, concessi tramite il **binding di subject** (utenti, gruppi e soprattutto **ServiceAccount**) a **Role** (namespaced) o **ClusterRole** (a livello di cluster) che enumerano i **verb consentiti sulle risorse** — il che significa che una buona sicurezza deriva dal concedere solo ciò di cui ogni workload ha bisogno (**least privilege**) anziché affidarsi ai deny. Capire che un **ServiceAccount è l'identità che un Pod usa per chiamare l'API** — che ogni Pod ottiene un token, che il SA `default` è una comune trappola di over-privilege, e che dovresti dare a ogni workload il proprio SA a privilegio minimo (e disabilitare l'automount del token quando non serve accesso all'API) — è di diretta utilità pratica e una frequente fonte di misconfigurazione reale. Cosa cruciale, un ingegnere senior sa che l'RBAC è solo uno strato della **difesa in profondità**: **NetworkPolicy** default-deny, impostazioni **securityContext** rafforzate (non-root, filesystem di root in sola lettura, capability rimosse, seccomp), **Pod Security Admission**, **encryption at rest** e manager esterni per i Secret, scansione e firma delle immagini, admission controller (OPA/Gatekeeper, Kyverno) e accesso a etcd/API bloccato si combinano tutti per proteggere un cluster. Poiché un cluster Kubernetes è un bersaglio di alto valore in cui un singolo ServiceAccount troppo permissivo o una NetworkPolicy aperta possono portare alla compromissione totale, padroneggiare l'RBAC e il più ampio toolkit di hardening è fondamentale per operare cluster in sicurezza in produzione.

Il modello RBAC

Esempio di Role + RoleBinding

ServiceAccount: l'identità per i Pod

Difesa in profondità — oltre l'RBAC

Perché è importante

Domande correlate