Namespace Kubernetes: come trasformarli in un vero confine di sicurezza

TL;DR

• Un namespace delimita i nomi, non la sicurezza. Da solo non impedisce l'accesso API tra namespace, il traffico di rete o la contesa di risorse.
• RBAC controlla chi può agire sulle risorse di un namespace. Nega per impostazione predefinita: nessuno ottiene accesso finché non si concede un Role e lo si assegna con un binding.
• NetworkPolicy controlla cosa può comunicare con cosa. Qui Kubernetes fa l'esatto contrario di RBAC: ogni pod può raggiungere qualsiasi altro pod finché non si aggiunge una policy che lo limita.
• ResourceQuota e LimitRange pongono un tetto a quanto un namespace può consumare, sia in risorse di calcolo sia in numero di oggetti, così un singolo tenant non può sottrarre risorse al resto del cluster o al control plane.
• Nulla di tutto questo arriva già configurato. Ognuno di questi controlli va aggiunto, namespace per namespace, altrimenti l'isolamento semplicemente non esiste.

I namespace sembrano garantire isolamento. Se ne crea uno per il team A e uno per il team B, e i pod, i service e le configurazioni dei due team finiscono in contenitori separati con nomi separati. Ma il confine si ferma lì. Nulla in un namespace, di per sé, impedisce al service account del team A di leggere i secret del team B, ai pod del team A di aprire una connessione verso il database del team B, o ai workloads del team A di sottrarre risorse ai pod del team B su un nodo condiviso.

La multi-tenancy in Kubernetes si regge su tre controlli che trasformano quel confine di nomi in un vero confine di sicurezza e di risorse: RBAC, NetworkPolicy e ResourceQuota. Ognuno governa un tipo diverso di accesso, e ognuno ha un comportamento predefinito che coglie i team di sorpresa.

RBAC: controllare chi può agire

RBAC decide quali utenti, gruppi e service account possono fare cosa, su quali risorse e in quali namespace. Il suo stato predefinito gioca a nostro favore: un service account o un utente ha zero permessi finché un Role non ne concede alcuni e un RoleBinding non glielo assegna. Nulla viene esposto per errore.

Un Role con scope di namespace limita il raggio d'impatto di quella concessione a un singolo namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-a
  name: team-a-editor
rules:
  - apiGroups: ["", "apps"]
    resources: ["pods", "deployments", "services"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-editor-binding
  namespace: team-a
subjects:
  - kind: Group
    name: team-a-engineers
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: team-a-editor
  apiGroup: rbac.authorization.k8s.io

Tre abitudini evitano che RBAC diventi a sua volta un rischio:

Creare binding verso gruppi, non verso singoli utenti. Un RoleBinding legato a utenti nominali diventa obsoleto nel momento in cui qualcuno cambia team; un binding a un gruppo si aggiorna automaticamente quando cambia la composizione del gruppo nell'identity provider.

Fare attenzione ai ClusterRoleBinding concessi per comodità dei tenant. Un ClusterRole associato a livello di cluster distribuisce l'accesso a ogni namespace del cluster, vanificando in partenza il senso di limitare un Role a team-a. Ricorrere a un ClusterRole solo quando serve davvero, e associarlo con un RoleBinding con scope di namespace quando possibile.

Rivedere i binding a scadenze regolari. La proliferazione di RBAC (decine di Role quasi identici e binding obsoleti riferiti a persone che hanno lasciato il team) trasforma un audit da questione di minuti a questione di giorni. Un controllo trimestrale intercetta le derive prima che diventino un incidente di sicurezza.

RBAC decide anche chi può leggere i Kubernetes Secrets e gestire la ownership delle risorse all'interno di un namespace, quindi un Role troppo ampio espone ben più del semplice accesso alle risorse di calcolo. E quando RBAC blocca una richiesta, Kubernetes restituisce un errore Forbidden anziché un 404, una distinzione utile da conoscere quando si fa il debug degli errori del cluster.

NetworkPolicy: controllare cosa può comunicare con cosa

Basta capovolgere il default di RBAC per ottenere lo stato di partenza di NetworkPolicy. Kubernetes nasce con una rete piatta: qualsiasi pod può aprire una connessione verso qualsiasi altro pod del cluster, attraverso tutti i namespace, a meno che qualcosa non lo blocchi. Una NetworkPolicy lo blocca, ma solo dopo che è stata aggiunta; fino a quel momento, il rigoroso controllo degli accessi di RBAC non fa nulla per impedire a un pod compromesso di attraversare i confini dei namespace via rete.

Il punto di partenza è una policy default-deny per ogni namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Negando l'egress si blocca anche il DNS. CoreDNS gira normalmente nel namespace kube-system sulla porta 53. Senza accesso al DNS, i pod in team-a non possono risolvere i nomi dei service, quindi le applicazioni che dipendono dal DNS inizieranno a fallire. Consentire il DNS prima di aggiungere altre regole di egress: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-dns namespace: team-a spec: podSelector: {} policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system ports: - protocol: UDP port: 53 - protocol: TCP port: 53

A quel punto si aggiungono permessi espliciti per ciò che deve davvero comunicare. Questa policy consente il traffico solo dai pod dello stesso namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: team-a

C'è un tranello che coglie di sorpresa chi non l'ha mai incontrato: NetworkPolicy funziona solo se il plugin CNI la applica. Calico, Cilium e pochi altri implementano l'API NetworkPolicy; alcuni plugin CNI no, e su questi le policy scritte con cura vengono accettate dall'API server e silenziosamente ignorate a livello di rete. Verificare che il proprio CNI applichi le NetworkPolicy prima di considerarle un confine reale, non dopo.

ResourceQuota e LimitRange: limitare quanto un namespace può consumare

RBAC e NetworkPolicy fermano gli accessi. ResourceQuota ferma i consumi. Senza una quota, un namespace può richiedere abbastanza CPU e memoria da non lasciare nulla al resto del cluster, o creare abbastanza oggetti da rallentare l'API server per tutti i tenant, innescando lo stesso meccanismo alla base del problema del noisy neighbor.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    pods: "50"
    count/deployments.apps: "20"

Quell'ultima riga conta quanto i limiti di calcolo che la precedono. Una quota limitata al solo compute lascia comunque che un namespace crei Deployment, ConfigMap o Service senza limiti, sovraccaricando etcd e rallentando il control plane per tutti gli altri tenant del cluster. Limitare il numero di oggetti protegge ciò che ogni namespace condivide.

È bene abbinare la quota a un LimitRange, così i pod che non dichiarano richieste e limiti propri ricevono valori predefiniti sensati invece di essere rifiutati, e impostare un massimo per container in modo che nessun singolo pod possa accaparrarsi l'intero budget del namespace. Per il funzionamento completo, incluso come dimensionare i valori sull'uso reale invece di tirare a indovinare, si veda la guida dedicata a ResourceQuota e LimitRange.