Kubernetes: sicurezza e organizzazione

Kubernetes è una piattaforma on-line ed in quanto tale nasce naturalmente esposta ad una serie di rischi connessi al dialogo in Rete. Inoltre, le componenti che abbiamo già incontrato possono far nascere dubbi e curiosità su come un'applicazione possa essere strutturata. Sicurezza ed organizzazione sono tematiche fortemente connesse in quanto si influenzano reciprocamente. Vediamo insieme alcuni punti di forza in questa lezione.

Sicurezza: principi fondamentali

La sicurezza in Kubernetes è un campo molto ampio. Va approfondita man mano che si scoprono le componenti a disposizione e molto dipende dal tipo di applicazioni che si implementano ed i rischi a cui esse possono essere esposte. Per porre però alcune basi importanti diciamo subito che qualsiasi architettura metteremo in piedi dovremo sempre seguire due principi che non appartengono solo a Kubernetes ma a qualsiasi infrastruttura informatica:

• Sicurezza in profondità: qualsiasi strato la nostra infrastruttura preveda, ognuno di essi deve essere "sicurizzato";
• Principio del privilegio minimo: qualsiasi utente o servizio che abbia diritto a delle autorizzazioni per svolgere i propri compiti dovrà essere munito esclusivamente dei minimi permessi sul numero più ristretto possibile di oggetti.

Inoltre, un elemento che possiamo introdurre in tutti gli oggetti che abbiamo imparato a creare sinora nella guida è il SecurityContext. Questo viene applicato nella configurazione dichiarativa e prevede un elenco di campi che specificano determinate proprietà e abilitazioni che possono essere indicate per Pod e container interni. Tanto per fare alcuni esempi parliamo di: permessi di accesso, scalamento dei privilegi, file system in sola lettura ed altro ancora.

Per utilizzarlo è sufficiente integrarlo nelle nostre dichiarazioni. Ad esempio potremmo creare un Pod con un'indicazione simile allo schema seguente:

apiVersion: v1
kind: Pod
metadata:
    name: mypod
spec:
 containers:
   - image: [IMMAGINE DA APPLICARE]
     name: [NOME DEL CONTAINER]
     securityContext:
        readOnlyRootFilesystem: true

Questo renderebbe il file system di root in sola lettura ma potremmo applicare tutta una serie di altre impostazioni inserendo il blocco securityContext sia in un container sia nel Pod intero. Si faccia attenzione che una sperimentazione simile potrebbe tuttavia portare ad errori in quanto un servizio all'avvio potrebbe aver bisogno di salvare dati in una certa posizione del file system root.

Organizzazione di un'applicazione: cosa inserire in un Pod

Finché si tratta di avviare solo container di un'immagine specifica, anche replicati più volte, non ci si pone alcun problema. Ma quando si inizia a pensare ad istanziare un applicativo composto da web tier e backend con database, ci si inizia a chiedere: posso inserire tutti i container in un solo Pod o dovrei separarli in più di uno?

La risposta come spesso capita è: dipende. Partiamo da due concetti di fondo:

• il Pod è l'unità fondamentale di deployment pertanto tutto ciò che c'è in un Pod viene posizionato sullo stesso nodo del cluster Kubernetes;
• un Pod è una struttura multicontainer in cui tutti i container in esecuzione condividono spazio disco e stesso indirizzo IP (in pratica, possono comunicare tra loro usando localhost come indirizzo ma porte TCP diverse).

In virtù di questi due aspetti, se ad esempio dovessimo avviare un'istanza WordPress (notissima piattaforma per il blogging composta da un'applicazione in PHP ed un database MySQL) potremmo scegliere se posizionare il container con immagine WordPress (per usarne una già pronta) e quello con database MySQL nello stesso Pod o creare Pod diversi.
In entrambi i casi, potrebbero funzionare ma il principio da cui possiamo partire è il seguente: se due container rappresentano applicativi che riescono a collaborare da macchine diverse possono stare in Pod diversi, se hanno bisogno di stare nella stessa macchina è obbligatorio posizionarli nello stesso Pod.

Usare Pod diversi offre anche un'importante opportunità. Visto che molto spesso si userà Kubernetes in Cloud ove la scalabilità ha un'importanza basilare, usare Pod diversi, gestiti con Deployment diversi permette di far scalare i Pod in maniera differente a seconda del loro contenuto. Se parliamo di applicativi tipo WordPress composti da applicazione Web e database queste due componenti scalano in maniera diversa, venendo influenzate da aspetti come numero di richieste utente, quantità di dati prelevati dal database ed eventuale presenza di cache per conservare risposte alle query più frequenti.

Per questo un caso come quello di WorPress potrebbe essere fondato su: un Deployment per il web tier esposto da un Service; un Deployment per il database tier esposto da un altro Service.

Tutto ciò porterebbe alla creazione di Pod diversi gestiti dai rispettivi Deployment con la possibilità di scalare ed essere replicati nella maniera opportuna corredando il tutto con impostazioni di Volume, configurazioni e misure di sicurezza opportune.