Kubernetes: RBAC minimo e audit che non espone i Secret

Una revisione RBAC non termina cercando chi possiede get su secrets. Bisogna considerare anche chi può creare workload, impersonare identità o modificare le autorizzazioni. L’audit deve dare evidenza delle operazioni senza trasformarsi in un secondo deposito di credenziali.

Permessi diretti e indiretti

Le buone pratiche RBAC di Kubernetes raccomandano privilegi minimi e scope per namespace quando appropriato. list e watch sui Secret sono sensibili: la risposta può comprendere il contenuto, non soltanto i nomi.

La possibilità di creare Pod in un namespace può fornire accesso indiretto ai Secret utilizzabili dai workload in quel namespace. Valutare insieme permessi sui workload, service account, bind, escalate e impersonate. Una restrizione soltanto sulla lettura diretta può lasciare un percorso alternativo.

Inventario che non esporta i segreti

Come procedura editoriale, partire da Role, ClusterRole, RoleBinding e ClusterRoleBinding e costruire una mappa identità-permessi-namespace. Non usare come inventario un dump globale del contenuto dei Secret. Per ogni concessione chiedere quale operazione reale la richieda e chi possa assegnarla.

Un primo controllo di autorizzazione, da eseguire con il proprio contesto di laboratorio, è:

kubectl auth can-i get secrets -n laboratorio
kubectl auth can-i list secrets -n laboratorio
kubectl auth can-i create pods -n laboratorio

Questo controllo non esaurisce la superficie dei privilegi. Ripeterlo per l’identità effettiva del workload con strumenti e permessi di impersonazione autorizzati. L’esito “no” per get non rende innocuo il “yes” per creare Pod.

Usare Metadata dove il corpo non serve

La documentazione dell’audit distingue livelli come Metadata, Request e RequestResponse. Metadata conserva informazioni sull’operazione senza il corpo della richiesta o risposta. Il seguente frammento illustra una regola da integrare nella policy:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets"]

Le regole sono valutate in ordine: verificare che una regola precedente non intercetti già queste richieste con un livello più dettagliato. La policy non configura da sola backend, attivazione o conservazione. Nei servizi gestiti controllare le opzioni del control plane e i limiti imposti dal provider.

Un test di copertura e di minimizzazione

In laboratorio creare un Secret sintetico con un valore riconoscibile e non sensibile. Eseguire un’operazione autorizzata e una negata, poi verificare l’identità e l’operazione registrate. Cercare il valore sintetico nella destinazione di audit: la sua presenza può indicare una policy troppo dettagliata o un’altra fonte che esporta corpi.

Ripetere il test sulle operazioni effettivamente usate dai controller. Un singolo get non prova la visibilità di list, watch o delle attività che montano Secret nei Pod. La revisione deve spiegare quali percorsi siano coperti e quali restino indiretti.

Mitigazioni: dal controllo al ciclo di revisione

Per ciascuna identità annotare proprietario, giustificazione e data di revisione. Confrontare i privilegi con le attività attese; richieste ripetute a segreti da un workload nuovo meritano investigazione, ma un controller autorizzato può legittimamente leggere molte risorse.

Proteggere il repository di audit con accesso separato, retention e controllo degli export. L’obiettivo operativo è poter attribuire una modifica o un accesso senza conservare inutilmente il materiale segreto che si voleva proteggere.

Fonti essenziali

Riferimenti primari consultati il 3 ottobre 2026. Le procedure di analisi e gli scenari di laboratorio sono proposte editoriali: vanno adattati alla telemetria e alle versioni installate.

• Kubernetes — RBAC good practices
• Kubernetes — Auditing