Kubernetes Security — RBAC, Network Policy e Pod Security: Configurarli senza Fare Disastri

Gestisci un cluster Kubernetes? Allora sai che la sicurezza non è un'opzione. Ma tra RBAC, Network Policy e Pod Security Standards, è facile perdersi o, peggio, configurare tutto male. Noi di Meteora Web lavoriamo con cluster reali per clienti, e abbiamo visto errori che costano accessi non autorizzati e traffico fuori controllo. In questa guida vediamo come impostare queste tre componenti senza buchi.

Perché RBAC è il primo passo per la sicurezza di Kubernetes?

RBAC (Role-Based Access Control) è il sistema che decide chi può fare cosa nel cluster. Senza RBAC, chiunque abbia accesso al cluster può leggere segreti, cancellare namespace, eseguire pod arbitrari. Noi, di Meteora Web, partiamo sempre da qui: identità minime e permessi granulari. La regola d'oro è: nessun utente, servizio o pod deve avere più permessi di quelli necessari per funzionare.

Role vs ClusterRole

Un Role assegna permessi dentro un singolo namespace. Un ClusterRole li assegna a livello di cluster (su tutti i namespace o risorse non namespaced).

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

RoleBinding e ClusterRoleBinding

Un RoleBinding lega un Role a un soggetto (utente, gruppo, service account) in un namespace. Un ClusterRoleBinding lega un ClusterRole a livello di cluster.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
- kind: ServiceAccount
  name: my-app
  namespace: production
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Errore comune: usare un ClusterRoleBinding per dare permessi a livello di cluster quando basterebbe un RoleBinding. Questo espone ogni namespace a potenziali abusi.

Come si scrive una Network Policy che blocca davvero il traffico?

Di default, Kubernetes permette tutto il traffico tra pod e verso l'esterno. Una Network Policy serve per limitarlo. Attenzione: se non si applica almeno una policy, il traffico è completamente aperto. Una singola policy mal configurata può isolare un'intera applicazione.

Struttura di base

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-frontend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

Questa policy permette solo ai pod con label app: frontend di comunicare con i pod app: api sulla porta 8080, e solo ai pod app: api di uscire verso i pod app: database sulla porta 5432. Tutto il resto è bloccato.

Regole per l'accesso esterno

Per permettere traffico esterno (es. da un load balancer), si usa ipBlock o namespaceSelector. Ma attenzione: se non definisci una policy di egress per i DNS (porta 53), i pod potrebbero non risolvere i nomi. Noi aggiungiamo sempre una policy aperta su UDP 53 verso il DNS del cluster.

- to:
  - namespaceSelector: {}
    podSelector:
      matchLabels:
        k8s-app: kube-dns
  ports:
  - protocol: UDP
    port: 53

Checklist operativa per Network Policy:

• Specifica sempre policyTypes (Ingress/Egress)
• Non dimenticare il DNS (UDP 53)
• Usa podSelector con label chiare e consistenti
• Testa con kubectl run --rm -it busybox -- sh per verificare connettività

Quali sono le regole fondamentali di Pod Security Standards?

Pod Security Standards (PSS) hanno sostituito le vecchie PodSecurityPolicy. Definiscono tre livelli: Privileged, Baseline e Restricted. Noi consigliamo di partire da Baseline come minimo, e passare a Restricted per carichi non privilegiati.

Applicare PSS con Pod Security Admission

Kubernetes 1.23+ ha integrato il Pod Security Admission controller. Si applica a livello di namespace con label:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

La modalità enforce blocca la creazione di pod non conformi, audit registra violazioni, warn mostra avvisi all'utente.

Errori tipici

• Usare privileged per tutti i pod, annullando ogni protezione.
• Non considerare i container con securityContext inadeguato (es. runAsUser: 0).
• Dimenticare di aggiornare l'admission controller dopo l'upgrade del cluster.

Come testare e verificare che le policy funzionino?

Scrivere yaml è solo metà del lavoro. Noi, di Meteora Web, testiamo sempre con:

• kubectl auth can-i per RBAC: kubectl auth can-i list pods --as=system:serviceaccount:production:my-app
• Pod di test busybox per verificare connettività di rete: kubectl run test --image=busybox --rm -it -- sh e poi wget ...
• Strumenti come kube-bench e kube-hunter per audit automatici.

Un consiglio concreto: tieni un repository Git con tutti i manifest di sicurezza e usa un pipeline CI/CD (es. GitHub Actions) per validare ogni cambio con kubectl apply --dry-run=server e conftest per policy as code.

Cosa fare adesso

1. Controlla i permessi correnti: esegui kubectl describe clusterrolebinding e identifica account con permessi eccessivi.
2. Applica almeno una Network Policy di default deny: crea una policy che blocca tutto il traffico in entrata e uscita su ogni namespace, poi aggiungi regole specifiche.
3. Imposta Pod Security Standards su ogni namespace: inizia con warning e audit, poi passa a enforce in produzione.
4. Automatizza i test: aggiungi un job periodico che esegue kube-bench e invia report.
5. Leggi la documentazione ufficiale: RBAC Good Practices e Pod Security Standards.

Questa guida fa parte della nostra Pillar sulla Sicurezza Cloud e DevSecOps. Abbiamo toccato solo RBAC, Network Policy e Pod Security; lì trovi tutto il resto da pipeline a IAM. Buona configurazione — e se vuoi un controllo del tuo cluster, sappiamo dove cercare.