Best Practice Essenziali RBAC per Proteggere i Tuoi Cluster Kubernetes

Il RBAC di Kubernetes decide chi può fare cosa nel tuo cluster. Un singolo binding ampio può permettere a un account compromesso di leggere segreti, modificare carichi di lavoro o prendere il controllo delle risorse del cluster.

Questa guida spiega gli oggetti RBAC fondamentali, mostra esempi funzionanti e fornisce abitudini di revisione che impediscono all'accesso di derivare nel tempo.

Comprendere i Fondamenti del RBAC di Kubernetes

Il RBAC in Kubernetes è un meccanismo di autorizzazione che regola l'accesso alle risorse di Kubernetes in base ai ruoli dei singoli utenti o account di servizio. È un livello cruciale di difesa, garantendo che solo entità autorizzate possano eseguire azioni specifiche su risorse specifiche.

Al suo interno, il RBAC si basa su quattro tipi principali di oggetti Kubernetes:

Role: Un Role è un insieme di permessi che si applica all'interno di un namespace specifico. Definisce quali azioni (verbi come get, list, create, update, delete) possono essere eseguite su quali risorse (come pods, deployments, services, secrets). Ad esempio, un Role potrebbe concedere il permesso di leggere pods e deployments nel namespace development.
ClusterRole: Simile a un Role, ma un ClusterRole definisce permessi che si applicano a livello di cluster o a risorse non basate su namespace (es., nodes, persistentvolumes). Un ClusterRole può anche definire permessi per risorse basate su namespace in tutti i namespace. Ad esempio, un ClusterRole potrebbe permettere di elencare tutti i nodes nel cluster.
RoleBinding: Un RoleBinding concede i permessi definiti in un Role (o un ClusterRole applicato a un namespace) a un utente, gruppo o account di servizio. Opera sempre all'interno di un namespace specifico.
ClusterRoleBinding: Un ClusterRoleBinding concede i permessi definiti in un ClusterRole a un utente, gruppo o account di servizio, applicando tali permessi all'intero cluster.

Insieme, questi oggetti permettono agli amministratori di costruire un sistema di controllo degli accessi robusto e granulare. Quando un utente o un'applicazione (rappresentata da un account di servizio) tenta di eseguire un'azione, Kubernetes valuta i RoleBindings e ClusterRoleBindings esistenti per determinare se l'azione richiesta è permessa.

Implementare il Principio del Minimo Privilegio con RBAC

Un principio centrale della sicurezza informatica è il principio del minimo privilegio. Un utente, programma o processo dovrebbe ricevere solo i permessi necessari per svolgere il proprio lavoro. In Kubernetes, ruoli eccessivamente permissivi sono un modo comune per cui un piccolo compromesso può diventare un problema a livello di cluster.

Definire Permessi Granulari

Quando si creano politiche RBAC, pensa alle azioni e risorse precise richieste:

Verbi: Invece di concedere * (tutti i verbi), specifica esattamente quali azioni sono necessarie (get, list, watch, create, update, delete, patch, exec).
Risorse: Sii specifico sulle risorse (pods, deployments, secrets, configmaps). Evita di concedere accesso a * per le risorse a meno che non sia assolutamente necessario e per ruoli amministrativi ben giustificati.
Nomi di Risorsa: Per risorse molto sensibili come secrets, puoi limitare alcuni verbi, come get, a specifici resourceNames all'interno di un tipo di risorsa. Non fare affidamento su resourceNames per accessi di tipo elenco, perché list e watch non sono limitati a un singolo oggetto nominato allo stesso modo.
Gruppi API: La maggior parte delle risorse Kubernetes appartiene a un gruppo API (es., apps, rbac.authorization.k8s.io, "" per le risorse core). Specifica il gruppo API corretto per restringere ulteriormente l'ambito.

Scoping dei Namespace

Per la maggior parte delle applicazioni e dei team di sviluppo, i permessi dovrebbero essere confinati a namespace specifici. Questa segregazione garantisce che un compromesso nell'ambiente di un'applicazione o di un team non porti automaticamente all'accesso a livello di cluster. Preferisci sempre Role e RoleBinding rispetto a ClusterRole e ClusterRoleBinding quando possibile.

Implementazione Pratica del RBAC: Esempi

Esaminiamo alcuni esempi pratici di creazione e binding di politiche RBAC.

Esempio 1: Accesso Sviluppatore a un Namespace Specifico

Immagina che uno sviluppatore debba gestire i deployment e visualizzare i log nel suo namespace dedicato, dev-team-a. Non dovrebbe avere accesso ad altri namespace o risorse a livello di cluster.

Prima, definisci un Role per lo sviluppatore nel namespace dev-team-a:

# dev-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-team-a
  name: dev-deployer
rules:
- apiGroups: ["apps"] # Per Deployments
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "delete", "patch"]
- apiGroups: [""] # Gruppo API core per Pod e log dei Pod
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

Applica questo ruolo:

kubectl apply -f dev-role.yaml

Successivamente, collega questo Role a un utente specifico (es., [email protected] tramite un provider di identità esterno) o a un account di servizio all'interno del namespace dev-team-a:

# dev-role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev-team-a
  name: john-dev-deployer-binding
subjects:
- kind: User
  name: [email protected] # Il nome è sensibile alle maiuscole
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-deployer
  apiGroup: rbac.authorization.k8s.io

Applica questo binding:

kubectl apply -f dev-role-binding.yaml

Ora, [email protected] può solo gestire i deployment e visualizzare i log all'interno del namespace dev-team-a. Non può, ad esempio, creare segreti in kube-system o elencare tutti i nodi.

Esempio 2: Account di Servizio dell'Applicazione che Accede ai Segreti

Un'applicazione in esecuzione come ServiceAccount deve leggere un segreto specifico nel proprio namespace.

Prima, assicurati che l'account di servizio esista o creane uno:

# app-sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: my-app-namespace
  name: my-app-service-account

Applica questo account di servizio:

kubectl apply -f app-sa.yaml

Successivamente, definisci un Role che permetta la lettura di un segreto specifico:

# secret-reader-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: my-app-namespace
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["my-app-db-credentials"]
  verbs: ["get"]

Applica questo ruolo:

kubectl apply -f secret-reader-role.yaml

Infine, collega questo Role a my-app-service-account:

# app-secret-reader-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: my-app-namespace
  name: my-app-secret-reader-binding
subjects:
- kind: ServiceAccount
  name: my-app-service-account
  namespace: my-app-namespace
roleRef:
  kind: Role
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Applica questo binding:

kubectl apply -f app-secret-reader-binding.yaml

L'applicazione ora potrà solo leggere il segreto specificato e nient'altro.

Esempio 3: Ruolo di Amministratore del Cluster (con cautela)

I ruoli amministrativi a livello di cluster dovrebbero essere concessi con estrema parsimonia. Ecco un esempio di ClusterRole per elencare tutti i nodi, che potrebbe essere necessario per uno strumento di monitoraggio.

# node-viewer-clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

Applica questo ClusterRole:

kubectl apply -f node-viewer-clusterrole.yaml

Quindi, collegalo a un account di servizio di monitoraggio usando un ClusterRoleBinding:

# monitoring-node-viewer-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: monitoring-node-viewer-binding
subjects:
- kind: ServiceAccount
  name: monitoring-sa
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: node-viewer
  apiGroup: rbac.authorization.k8s.io

Applica questo binding:

kubectl apply -f monitoring-node-viewer-binding.yaml

Attenzione: Sii estremamente cauto con ClusterRole e ClusterRoleBinding per utenti umani. Limita il loro uso a veri amministratori del cluster e account di servizio infrastrutturali specifici.

Best Practice Essenziali RBAC

Aderire a queste best practice migliorerà significativamente la postura di sicurezza del tuo cluster:

Applica il Principio del Minimo Privilegio (PoLP):
- Concedi solo i permessi minimi necessari. Rivedi attentamente ogni permesso.
- Evita i wildcard (*) per resources e verbs quando possibile. Se usati, giustificali e cerca di limitarli il più possibile.
- Limita l'accesso a risorse sensibili (come secrets) usando resourceNames nei ruoli.
Usa i Namespace per la Segregazione:
- Organizza le tue applicazioni e i tuoi team in namespace distinti.
- Predefinisci l'uso di Role e RoleBinding per concedere permessi all'interno di questi namespace.
Preferisci i Ruoli ai ClusterRole:
- Usa ClusterRole e ClusterRoleBinding solo quando i permessi devono essere veramente a livello di cluster (es., gestione dei nodi, definizioni di risorse personalizzate, agenti di monitoraggio specifici).
- La maggior parte dei permessi specifici dell'applicazione dovrebbe essere basata su namespace.
Controlla e Rivedi Regolarmente le Politiche RBAC:
- Le politiche RBAC possono derivare nel tempo. Rivedi periodicamente chi ha quale accesso.
- Usa strumenti come kubectl auth can-i per testare i permessi per utenti/account di servizio specifici.
```
# Controlla se '[email protected]' può ottenere i pod in 'dev-team-a'
kubectl auth can-i get pods --namespace=dev-team-a [email protected]

# Controlla se 'monitoring-sa' può elencare i nodi (a livello di cluster)
kubectl auth can-i list nodes --as=system:serviceaccount:monitoring:monitoring-sa
```
- Considera strumenti di terze parti o script personalizzati per un audit RBAC completo.
Separa i Ruoli Amministrativi:
- Non dare mai privilegi cluster-admin a sviluppatori o account di servizio delle applicazioni.
- Crea ClusterRoles amministrativi specifici con solo i permessi elevati necessari (es., cluster-reader, node-reader).
Sfrutta gli Account di Servizio per le Applicazioni:
- Le applicazioni in esecuzione all'interno del cluster dovrebbero usare ServiceAccounts per interagire con l'API di Kubernetes.
- Ogni applicazione o microservizio dovrebbe idealmente avere il proprio ServiceAccount dedicato con permessi minimi.
- Imposta automountServiceAccountToken: false per i pod che non richiedono accesso all'API di Kubernetes, sia sul pod che sull'account di servizio.
Integra con la Gestione dell'Identità Esterna:
- Per gli utenti umani, integra Kubernetes con un provider di identità esterno (es., OIDC, LDAP, Active Directory) per l'autenticazione e la gestione dei gruppi.
- Mappa i gruppi esterni a RoleBindings o ClusterRoleBindings di Kubernetes per una gestione più semplice.
Automatizza la Gestione RBAC con GitOps:
- Tratta le tue politiche RBAC come codice. Conservale in un repository con controllo di versione (Git).
- Usa i principi GitOps per gestire e distribuire le configurazioni RBAC, garantendo coerenza, tracciabilità e rollback più facili.
Monitora gli Eventi RBAC tramite Log di Audit:
- Abilita e configura la registrazione di audit di Kubernetes per tracciare le richieste API, incluso chi ha eseguito quale azione e quando.
- Rivedi regolarmente i log di audit per rilevare tentativi di accesso non autorizzati o attività sospette relative al RBAC.
Aggiorna Regolarmente Kubernetes:
- Rimani aggiornato con le versioni di Kubernetes per beneficiare di patch di sicurezza e miglioramenti, inclusi i potenziamenti RBAC.

Insidie Comuni e Come Evitarle

Wildcard Eccessivamente Permissivi: Concedere apiGroups: ["*"], resources: ["*"] o verbs: ["*"] è un grave rischio per la sicurezza. Sii sempre esplicito.
Uso Predefinito di cluster-admin: Non usare il gruppo system:masters o il ClusterRole cluster-admin per le operazioni quotidiane o assegnarlo a utenti non amministratori. Entrambi danno un controllo esteso sul cluster.
Ignorare automountServiceAccountToken: In molti cluster, i pod ricevono un token dell'account di servizio a meno che non si disabiliti il montaggio automatico. Se un pod non ha bisogno di interagire con l'API di Kubernetes, imposta automountServiceAccountToken: false nella specifica del pod o nella definizione dell'account di servizio per ridurre la sua superficie di attacco.
Mancanza di Audit: Senza revisioni regolari, le politiche RBAC possono diventare obsolete o eccessivamente permissive man mano che le esigenze del cluster evolvono. Implementa un processo di revisione.
Confondere Role e ClusterRole: Fraintendere l'ambito può portare a concedere accesso a livello di cluster quando era previsto solo accesso basato su namespace.

Conclusione

RBAC funziona meglio quando lo mantieni noioso e specifico: ruoli basati su namespace per i team delle applicazioni, permessi stretti per gli account di servizio, nessun wildcard senza revisione e controlli regolari con kubectl auth can-i. Tratta ogni binding come codice di produzione, perché in un cluster Kubernetes lo è effettivamente.