Se stai lavorando su Kubernetes o hai intenzione di farlo, non puoi ignorare il tema della sicurezza.
Molto spesso, quando un’azienda decide di adottare k8s, il tema sicurezza è l’ultimo a essere affrontato/implementato. Giustamente si dà priorità a conoscere al meglio lo strumento e a capire come può ottimizzare il funzionamento delle nostre applicazioni. Magari non si vede l’ora di andare in produzione o di poter dire finalmente di aver migrato tutto su Kubernetes!
In questo articolo vedremo alcuni punti chiave da tenere in considerazione parlando di “Security” in Kuberentes.
I temi trattati in questo articolo saranno i seguenti:
Sicurezza in K8s - Namespaces
In Kubernetes, i namespaces forniscono un meccanismo per isolare gruppi di risorse all’interno di un singolo cluster. I nomi delle risorse devono essere univoci all’interno di un determinato namespace, ma non tra gli altri namespaces. L’isolamento dei namespaces è applicabile solo per oggetti di tipo namespace-level (ad es. Deployment, Servizi, ecc.) e non per oggetti cluster-level (ad es. StorageClass, Nodes, PersistentVolumes, ecc.).
In poche parole, i namespaces permettono di segmentare logicamente un cluster suddividendolo in “spazi di lavoro” che possono essere dedicati a team, applicazioni e/o fasi di sviluppo.
Tuttavia, i namespaces da soli non bastano: sarà invece necessario utilizzare le seguenti componenti per rafforzare l’isolamento:
- Network Policies: gli amministratori di un cluster possono configurare le NP per controllare il traffico di rete (OSI layer 3 e 4) tra i vari namespaces. Tali NP consentono di definire le regole di comunicazione all’interno del cluster, permettendo o bloccando le comunicazioni di rete in base alle scelte definite dagli amministratori.
- LimitRange e ResourceQuota: grazie a queste due risorse, gli amministratori possono costruire un perimetro attorno ad ogni namespace definendo delle soglie di risorse hardware (CPU , RAM e Storage) che non possono essere superate. Gli amministratori, inoltre, possono governare il quantitativo di risorse k8s che possono essere create all’interno di un namespace.
- RBAC: grazie al modello “Role-based access control (RBAC)” gli amministratori possono definire delle regole in termini di permessi. Ogni utente, gruppi di utenti e servizi potranno accedere esclusivamente alle risorse k8s (Kubernetes API) indicate dagli amministratori.
In aggiunta, è possibile anche installare degli add-on nel cluster che permetto di rafforzare la security e governance. Uno strumento maturo che può essere d’aiuto è sicuramente OPA (Open Policy Agent) con il suo progetto OPA Gatekeeper. Possibile alternativa (in crescita nell’ultimo periodo) è Kyverno.
Autenticazione
È fondamentale che venga implementato un meccanismo solido e affidabile di autenticazione al cluster k8s.
Una soluzione built-in potrebbe essere quella di usare certificati x509, ma purtroppo risultano essere scomoda da gestire nel lungo termine.
Una soluzione consigliata da utilizzare in un cluster Production-Grade è sicuramente adottare autenticazione basata su OIDC (OpenID Connect).
OIDC permette di integrare il cluster kubernetes con identity provider esterni come ActiveDirectory/LDAP, GitHub, Google, SAML 2.0.
Due strumenti che vengono utilizzati frequentemente per implementare l’autenticazione basata su OIDC sono DEX e Keycloak.
Container Image Scan
Quando si lavora su kubernetes è necessario assicurarsi che tutti i containers che vengono creati utilizzino delle immagini sicure ed affidabili.
Le immagini non aggiornate molto spesso contengono delle vulnerabilità note che possono essere sfruttate da eventuali malintenzionati per accedere ai dati applicativi o per inizializzare un processo di privilege escalation.
Per questo è essenziale che venga predisposto un flusso coordinato per il deployment delle applicazioni sul cluster utilizzando degli strumenti ad-hoc per effettuare delle scansioni sulle immagini.
Il consiglio sarebbe quello di adottare una pipeline per il deployment di nuove applicazioni o per aggiornare applicazioni esistenti. All’interno della pipeline sarà necessario definire uno step dedicato per valutare se l’immagine che si intende utilizzare sia pronta per un ambiente di produzione o se invece presenta delle vulnerabilità critiche. Uno degli strumenti maggiormente utilizzati è Trivy, un image scanner che si basa su un database CVE sempre aggiornato per fornirci un report dettagliato su ogni immagine che intendiamo controllare.
Security Context
Un altro aspetto importante è il security context dei nostri containers, ovvero la “libertà” che si intende dare ai processi che girano all’interno dei nostri containers. Il consiglio generale è sicuramente quello di evitare tassativamente di eseguire come ROOT (user ID:0) i vari containers che intendiamo configurare all’interno dei pod di kuberentes. Per rafforzare il contesto di sicurezza dei container è possibile adottare le seguenti strategia:
- Configurare Linux Capabilities: fornire ai containers solo le linux capabilities effettivamente necessarie per il corretto funzionamento dell’applicazione
- Configurare AppArmor: utilizzare un profilo dedicato per limitare le chiamate al kernel.
- Configurare laddove possibile il filesystem del container in Read-Only mode, evitando cosi che processi infetti possano alterare il filesystem.
L’ideale sarebbe quello di installare nel cluster una Cloud Native Runtime Security come FALCO, che permetta di monitorare costantemente l’intero ambiente di kubernetes, e avvisare in tempo reale laddove ci fossero delle reali o possibili vulnerabilità.
Audit
L’ultimo aspetto (non per importanza) che trattiamo in questo articolo è quello dell’ “Audit”.
Attivando e configurando delle policy di auditing in kubernetes, gli amministratori sapranno in tempo reale chi sta facendo cosa e in quale momento.
Gli amministratori potranno intercettare qualsiasi tipo di richiesta che passa dall’ API server di kubernetes e memorizzarne un record su storage persistente. In particolare, sarà possibile intercettare eventuali richieste di autorizzazioni non andate a buon fine, individuando cosi potenziali attaccanti o utenti malintenzionati.
Conclusione e considerazioni
Il tema sicurezza è molto ampio e delicato, ed è una delle sfide più interessanti che si trovano nel mondo di Kubernetes.
Come sempre, non è mai tutto rosa e fiori, ma sicuramente qui troviamo degli ottimi spunti per andarci con i piedi di piombo.
Per approfondire ulteriormente il tema della sicurezza in Kubernetes, consigliamo di partecipare al nostro corso DSK303 – Kubernetes Security!
Condividi l’articolo!!
Scopri i nostri corsi!
Francesco Grimaldi
VMware Certified Instructor | Kubernetes Instructor | DAI | LFAI | SCI | CKA + CKAD
Team Leader, docente e consulente IT su tecnologie verticalizzate al mondo datacenter e Cloud-Native, attento ai dettagli, cerco di essere il più preciso possibile e non mi fermo finché non risolvo il problema.
Nel 2022 ho ricevuto da VMware il premio come “VMware Instructor of Excellence” in tutta EMEA. Quando spiego mi piace essere chiaro e diretto, senza dare nulla per scontato. Adoro trasmettere le mie conoscenze ad altri!
