Ciao, e benvenuto nella settima puntata della settantanovesima stagione. Abbiamo costruito un palazzo dove chiunque raggiunge qualsiasi reparto, da dentro e ora anche da fuori. Oggi il rovescio scomodo di quella comodità: appena nato, il palazzo lascia chiamare tutti a tutti. Vediamo perché, e come si chiude. Il titolo: chi può chiamare chi.
Partiamo dalla sorpresa dell'aperto di default. Ricorda la stanza sola della seconda puntata: ogni container raggiunge ogni altro, direttamente. Te l'ho presentata come un regalo, e lo è. Ma giralo: vuol dire anche che, di default, lo stagista dello smistamento posta può chiamare direttamente la linea privata del direttore; il container esposto al pubblico può raggiungere direttamente la base di dati, il reparto fatturazione, il deposito dei segreti, qualsiasi cosa. In un cluster Kubernetes, appena installato, non ci sono muri interni. Tutti parlano con tutti. Quasi nessuno, al primo cluster, se ne rende conto: pensano ci sia una sicurezza sottintesa tra i servizi. Non c'è. La stanza sola è anche una stanza spalancata.
Perché è pericoloso, concretamente. Un solo lavoratore compromesso raggiunge tutto. Se un attaccante entra nel tuo container meno importante e più esposto, la facciata web pubblica, la rete piatta fa sì che da lì possa provare a parlare direttamente con ogni altro servizio del cluster, compresi quelli delicati, senza niente in mezzo. La comodità che ha reso facile lo sviluppo è, dal punto di vista della sicurezza, un palazzo aperto. Il raggio dell'esplosione di una singola effrazione è l'intero cluster.
La cura: regole interne su chi può chiamare chi. Kubernetes ti lascia aggiungere regole d'accesso interne, frasi del tipo il reparto fatturazione può essere chiamato solo dal reparto ordini, e da nessun altro, oppure la base di dati accetta chiamate solo dall'applicazione, mai dalla facciata web. Non sono la reception dell'ingresso, quella è per chi viene da fuori: sono chi, dentro, è autorizzato a salire sul piano di chi. Descrivi, per ogni reparto, quali altri reparti possono raggiungerlo.
E qui la piega decisiva sul comportamento di default, quella in cui cascano tutti. Queste regole sono facoltative, e ribaltano il default in un modo preciso. Finché nessuna regola nomina un reparto, quel reparto resta spalancato: chiunque lo chiama. Ma nell'istante in cui scrivi una sola regola che dice la base di dati può essere chiamata dall'applicazione, hai detto implicitamente e da nessun altro: la base di dati è appena passata da aperta a tutti ad aperta solo all'applicazione. Scrivere una sola regola di permesso accende la chiusura di default per quel bersaglio. E questo frega la gente in entrambi i sensi: credono che aggiungere una regola aggiunga solo un permesso, e invece toglie tutti gli altri; oppure credono che il cluster sia segmentato quando non hanno scritto nessuna regola, e invece è spalancato. Devi ragionarci così: nessuna regola vuol dire aperto; qualsiasi regola vuol dire solo ciò che è elencato.
La postura giusta, soprattutto dove c'è una regolamentazione, è ribaltare tutto il palazzo a chiuso per impostazione: una regola di base che nega tutte le chiamate interne, e poi aprire, apposta, solo i percorsi che devono esistere. La facciata web può chiamare l'applicazione, l'applicazione può chiamare la base di dati, e nient'altro. È il minimo privilegio: ogni reparto raggiunge solo ciò di cui ha davvero bisogno. Così un'effrazione nella facciata web è contenuta: l'attaccante è in una stanza sola, con le porte che può aprire elencate a chiare lettere, non in tutto il palazzo. È lo stesso principio di sicurezza di sempre; la sorpresa è solo che Kubernetes parte dall'estremo opposto, tutto aperto.
Il costo onesto, per restare equilibrati. Queste regole sono facili da sbagliare in modo sottile, perché sono invisibili finché non mordono. Una regola troppo stretta lascia cadere in silenzio traffico che dovrebbe passare, e un pacchetto lasciato cadere sembra identico a un bug da un'altra parte, un tempo scaduto, un servizio che a caso non raggiunge l'altro. Una troppo larga dà un falso senso di sicurezza. E non tutti i cluster le fanno davvero rispettare: se le regole hanno effetto dipende dall'impianto che hai scelto, che è la prossima puntata.
Voglio lasciarti con le due sorprese sul chi può chiamare chi. La prima: un cluster, appena nato, non ha muri interni. La stanza sola che ti serviva per sviluppare è, dal lato sicurezza, un palazzo aperto: chiunque chiama chiunque, e un singolo container violato può provare a raggiungere tutto. Non dare per scontata una segmentazione che non c'è. La seconda: le regole di chi può chiamare chi ribaltano il default in modo insidioso. Nessuna regola vuol dire aperto; appena ne scrivi una che permette qualcosa, hai detto implicitamente e nient'altro. Perciò ragiona sempre così: senza regole è tutto aperto, con una regola è aperto solo ciò che elenchi. E dove conta, chiudi per impostazione e apri a mano solo i percorsi che devono esistere.
Per oggi ci fermiamo qui. Abbiamo visto l'aperto di default, cioè che un cluster nasce senza muri interni; il pericolo, un singolo container violato che raggiunge tutto; le regole di chi può chiamare chi; la piega insidiosa per cui scrivere un permesso accende la chiusura di default per quel bersaglio; la postura del chiuso per impostazione e del minimo privilegio; e il costo, regole invisibili facili da sbagliare. Nella prossima puntata: chi ha steso i cavi. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.