Sysdig
Learn Cloud Native

Sign up to receive our newsletter

Gestire le minacce alla sicurezza di runtime in Kubernetes

La maggior parte degli amministratori sa cos’è la sicurezza di runtime e perché è importante. Eppure, solitamente molti di essi trascurano o non investono a sufficienza in questo aspetto nel contesto della propria strategia di sicurezza di Kubernetes.

È facile capire perché: Kubernetes è un sistema così complesso e offre così tanti strumenti nativi per accedere ai privilegi e isolare i workload, che i team sono solitamente così impegnati a proteggere il cluster da dimenticare la sicurezza di runtime.

Per aiutarli a colmare la lacuna, questo articolo spiega perché la sicurezza di runtime di Kubernetes è così importante e quali sono gli strumenti disponibili per aiutare a proteggere Kubernetes dalle minacce.

Cos’è la sicurezza di runtime in Kubernetes?

La sicurezza di runtime in Kubernetes è la protezione dei container (o dei pod) in esecuzione dalle minacce attive.

La sicurezza di runtime aiuta a proteggere i workload da moltissime minacce che potrebbero emergere quando i container vengono utilizzati, ad esempio:

  • Attivazione di malware nascosto nell’immagine di un container.
  • Attacchi di escalation dei privilegi in cui un container sfrutta bug nella sicurezza di runtime del container, in Kubernetes o nell’OS host per accedere a risorse a cui non dovrebbe poter accedere (come volumi di archiviazione o file binari esterni).
  • Distribuzione di container non autorizzati da parte dell’autore di un attacco che sfrutta una falla nelle policy di controllo degli accessi o un bug in Kubernetes.
  • Accesso non autorizzato a informazioni segrete o ad altre informazioni sensibili che un container attivo non dovrebbe essere in grado di leggere ma a cui riesce ad accedere a causa di configurazioni improprie dei controlli degli accessi o vulnerabilità nella sicurezza che consentono tale escalation dei privilegi.

In un mondo perfetto, non si materializzerebbe nessuna di queste minacce, perché tutte le pipeline e i cluster di un’applicazione sarebbero protetti in modo tale da risultare inattaccabili. Verrebbero anche impiegati controlli molto rigidi degli accessi per garantire che ogni workload sia propriamente isolato, al fine di impedire con efficacia che un container compromesso danneggi il cluster.

Nel mondo reale, ovviamente, è impossibile garantire che non vengano introdotti malware nelle immagini dei container, ad esempio compromettendo il repository dei codici sorgente o gli strumenti di scrittura, o che le policy RBAC di Kubernetes e i contesti di protezione garantiscano un perfetto isolamento tra i workload.

Ecco perché la sicurezza di runtime è estremamente importante. Rappresenta il livello finale di difesa dalle minacce che potrebbero insinuarsi in un ambiente Kubernetes. Sebbene si possano e si debbano adottare tutte le misure ragionevoli per mitigare i rischi per la sicurezza all’interno delle pipeline e nell’architettura dei cluster, è anche necessario utilizzare la sicurezza di runtime per rilevare e controllare le minacce che riescono a superare le altre difese.

Strumenti per la sicurezza di runtime di Kubernetes

Kubernetes non offre molto in termini di strumenti per la sicurezza di runtime. L’unica vera risorsa disponibile è il controllo, che consente di generare registri che tracciano tutte le richieste di risorse indirizzate all’API di Kubernetes.

Tuttavia, sebbene Kubernetes possa registrare queste informazioni, non fa nulla da solo per analizzarle o per avvisare di attività che potrebbero risultare sospette.

Quindi, invece che rivolgersi a Kubernetes per proteggere l’ambiente dalle minacce al runtime, è necessario affidarsi a strumenti di sicurezza esterni. Per Kubernetes, questi strumenti ricadono in due principali categorie: strumenti di applicazione e strumenti di controllo.

Strumenti di applicazione della sicurezza di runtime

Gli strumenti di applicazione consentono di definire policy per limitare i diritti di accesso e le autorizzazioni per le risorse in un ambiente di runtime. Sebbene questi strumenti non possano impedire a una minaccia di manifestarsi, possono minimizzarne l’impatto facendo in modo che, per esempio, il malware che compare in un container non possa accedere a risorse esterne a quel container.

Tra gli strumenti di applicazione per Kubernetes ci sono:

  • Seccomp: Seccomp è uno strumento Linux a livello di kernel che consente di eseguire forzatamente i processi in modalità sicura. Quando si utilizza seccomp per mettere un processo in modalità sicura, il kernel impedirà al processo in questione di effettuare chiamate di sistema diverse da exit, sigreturn e dalla lettura e scrittura di file già aperti.
  • SELinux: SELinux è un modulo kernel che consente di definire una vasta gamma di controlli di accesso che vengono applicati dal kernel. È possibile utilizzare SELinux per ottenere regole granulari che stabiliscono a quali risorse può accedere un container e quali tipi di azioni può svolgere.
  • AppArmor: Anche AppArmor è un modulo kernel che consente di definire una vasta gamma di regole per il controllo degli accessi. Per diversi aspetti è molto simile a SELinux; il dibattito sulla scelta di SELinux o AppArmor è come l’eterna lotta tra vi ed emacs: alcuni preferiscono il primo strumento, altri il secondo, ma con entrambe le soluzioni si raggiungono grosso modo gli stessi risultati.

Da questo punto di vista, anche le policy RBAC e i contesti di protezione di Kubernetes offrono un certo livello di controllo sull’applicazione delle policy, poiché possono essere utilizzati per svolgere operazioni quali impedire a un container di eseguire la modalità privilegiata o negare l’accesso alle risorse a livello di kernel.

Tuttavia, la differenza tra le policy RBAC e i contesti di protezione da una parte e strumenti quali SELinux e AppArmor dall’altra sta nel fatto che questi ultimi applicano il controllo degli accessi a livello di kernel. Ciò significa che, anche se lo stesso Kubernetes viene compromesso in qualche modo o presenta una vulnerabilità nella sicurezza, gli strumenti di applicazione a livello kernel possono mitigare l’impatto delle violazioni impedendo che container compromessi accedano a risorse esterne.

SELinux, AppArmor e seccomp sono molto utili anche perché possono essere utilizzati per controllare gli accessi per qualunque tipo di workload Linux. Non sono specifici di Kubernetes. Se si gestisce un ambiente che include un insieme di container e VM, quindi, gli strumenti per il controllo degli accessi a livello di kernel risulteranno molto vantaggiosi, perché sarà possibile utilizzarne uno per gestire tutti i workload.

Strumenti di controllo della sicurezza di runtime

Gli strumenti di controllo in Kubernetes aiutano a rilevare e a reagire alle minacce in base ai dati raccolti dal cluster.

Anche in questo caso, Kubernetes fornisce gli strumenti per generare i rapporti di controllo ma non li analizza. Per questo, è necessario ricorrere a uno strumento come Falco, un motore di rilevamento delle minacce open source. Falco consente di definire regole che attiveranno avvisi se il motore di Falco rileva la presenza di alcune condizioni in base a dati quali i registri di controllo di Kubernetes.

Per esempio, prendiamo questa regola di Falco:

- rule: Example rule (nginx). This is the human name for the rule. desc: Detect any listening socket outside our expected one.
condition: evt.type in (accept,listen) and (container.

image!=myregistry/nginx or proc.name!=nginx or k8s.ns.name!=”load- balancer”)

output: This is where I write the alert message and I provide some extra information (command=%proc.cmdline connection=%fd.name).
priority: WARNING

In questa regola, tutti i socket in ascolto che non soddisfano i seguenti criteri genereranno un avviso:

  • L’immagine è myregistry/nginx.
  • Il processo di ascolto è nginx.
  • Il namespace è load-balancer.

Con una regola come questa, è possibile rilevare i container in esecuzione che potrebbero cercare di raccogliere dati o accedere a risorse non autorizzate. È anche possibile utilizzare una regola come questa per rilevare i container non autorizzati.

Falco è di fatto diventato lo strumento di controllo per Kubernetes e altre piattaforme simili per diverse ragioni. Oltre a essere open source, offre la possibilità di lavorare con qualunque tipo di ambiente cloud nativo, non solo con Kubernetes.

Allo stesso tempo, il Security Hub cloud nativo, che offre decine di regole Falco preconfigurate e specifiche per diversi tipi di workload, consente di configurare Falco velocemente senza dover scrivere a mano un incredibile numero di regole di controllo.

Migliori prassi per la sicurezza di runtime in Kubernetes

Adottare strumenti di applicazione e di controllo è uno dei primi passi da compiere per affrontare le minacce alla sicurezza di runtime in Kubernetes, ma configurarli non è sufficiente. È anche necessario accertarsi di:

  • Effettuare continue scansioni delle immagini: Sebbene la scansione delle immagini non sia di per sé un’operazione relativa alla sicurezza di runtime (ricade nell’ambito della sicurezza delle pipeline), è importante per evitare che i malware raggiungano gli ambienti di runtime.
  • Scansionare i file delle policy di Kubernetes: È anche possibile evitare problemi alla sicurezza di runtime scansionando i file RBAC di Kubernetes, le distribuzioni e altre risorse per rilevare errori di configurazione che potrebbero consentire o aggravare le violazioni.
  • Scansionare i file delle policy esterni: È inoltre buona norma scansionare i file delle policy creati per SELinux, AppArmor o altri strumenti. Sviste in questi file potrebbero indebolire le difese.
  • Non dimenticare gli ambienti dev/test: Quando si difende la sicurezza di runtime, di solito ci si concentra prima e soprattutto sull’ambiente di produzione. Dopotutto, è il punto in cui le minacce tendono ad avere l’impatto maggiore. Ma non bisogna dimenticare di proteggere l’ambiente dev/test. Rilevare le minacce nell’ambiente dev/test è un ottimo modo per evitare che raggiungano la produzione. Inoltre, anche in questo ambiente un problema alla sicurezza di runtime potrebbe determinare conseguenze molto gravi se, per esempio, l’autore di un attacco riesce ad accedere a informazioni segrete da una risorsa dev/test.
  • Elaborare un piano per intervenire in caso di incidente: È importante non aspettare che avvenga una violazione per pianificare un intervento di risposta. Bisogna sviluppare playbook per guidare i team nella gestione dei diversi tipi di eventi che mettono a repentaglio la sicurezza di runtime. Ad esempio, cosa si deve fare in caso di un attacco di escalation dei privilegi? Cosa fare se un nodo viene compromesso ma gli altri no? Valutare attentamente questi problemi prima che accadano aiuterà a rispondere più velocemente alle minacce attive.

La sicurezza di runtime è l’unica barriera esistente tra il cluster e le minacce che sono riuscite a eludere tutte le altre difese erette a protezione della pipeline di sviluppo di un’applicazione e dell’architettura Kubernetes. Controllando continuamente gli ambienti di runtime e utilizzando strumenti di applicazione per segmentare le risorse, è possibile minimizzare il potenziale impatto delle minacce.