Sicurezza per IBM Cloud Kubernetes Service

Puoi utilizzare le funzioni di sicurezza integrate in IBM Cloud® Kubernetes Service per l'analisi dei rischi e la protezione di sicurezza. Queste funzioni ti aiutano a proteggere la tua infrastruttura cluster e comunicazione di rete, isolare le tue risorse di calcolo e assicurare la conformità di sicurezza tra i tuoi componenti dell'infrastruttura e le distribuzioni del contenitore.

Per un'analisi delle linee guida sulla sicurezza in base alla versione del prodotto, vedere CIS Kubernetes Benchmark.

Panoramica delle minacce alla sicurezza per il tuo cluster

Per proteggere il tuo cluster da attacchi che potrebbero comprometterlo, devi comprendere i potenziali rischi per la sicurezza per il tuo cluster e cosa puoi fare per ridurre l'esposizione alle vulnerabilità.

Attacchi esterni
Aggressori che ottengono l'accesso al cluster, alle risorse distribuite, alle applicazioni o alle informazioni personali.
Distribuzioni vulnerabili
Le vulnerabilità note vengono sfruttate per ottenere l'accesso all'ambiente cloud ed eseguire software dannoso.
Dati compromessi o persi
Memorizzazione non corretta dei dati sensibili e codifica mancante.
Insider e fornitori terzi
L'isolamento della rete mancante e la segmentazione possono portare all'uso improprio delle autorizzazioni legittime.

La sicurezza cloud e la protezione dei tuoi sistemi, della tua infrastruttura e dei tuoi dati da attacchi sono diventati fattori molto importanti nell'ultimo paio di anni poiché le aziende continuano a spostare i loro carichi di lavoro nel cloud pubblico. Un cluster è costituito da diversi componenti e ciascuno di essi può esporre il tuo ambiente ad attacchi dolosi. Per proteggere il tuo cluster da queste minacce alla sicurezza, ti devi assicurare di applicare le funzioni e gli aggiornamenti della sicurezza IBM Cloud Kubernetes Service e Kubernetes più recenti in tutti i componenti del cluster.

Questi componenti includono:

Server API Kubernetes ed etcd

Il server API Kubernetes e l'archivio dati etcd sono i componenti più sensibili eseguiti nel tuo master Kubernetes. Si desidera impedire l'accesso non autorizzato a questi componenti perché impostano e memorizzano le configurazioni per tutte le risorse eseguite nel cluster, incluse alcune impostazioni di sicurezza delle proprie applicazioni.

Kubernetes fornisce controlli di sicurezza e limita l'accesso per proteggere questi componenti e ridurre il rischio di attacchi.

Come viene concesso l'accesso al mio server API?

Per impostazione predefinita, Kubernetes richiede che ogni richiesta passi attraverso diverse fasi prima che venga concesso l'accesso al server API.

Autenticazione
Verifica l'identità di un utente registrato o di un account di servizio.
Autorizzazione
Limita le autorizzazioni degli utenti autenticati e degli account di servizio per garantire che possano accedere e gestire solo i componenti del cluster che si desidera consentire loro di utilizzare.
Admission Control
Convalida o modifica le richieste prima che vengano elaborate dal server API Kubernetes. Molte funzionalità di Kubernetes richiedono la presenza di controller di ammissione per funzionare correttamente.

Cosa fa IBM Cloud Kubernetes Service per garantire la sicurezza del mio server API e dell'archivio dati etcd?

La seguente immagine mostra le impostazioni di sicurezza del cluster predefinite che si occupano di autenticazione, autorizzazione, controllo di ammissione e connettività protetta tra i nodi master e di lavoro Kubernetes.

Descrive le fasi di sicurezza durante l'accesso al server API.
Fasi di sicurezza durante l'accesso al server API

Esamina le seguenti funzioni di sicurezza per il server API Kubernetes e etcd.

Master Kubernetes dedicato completamente gestito

Ogni cluster in IBM Cloud Kubernetes Service è controllato da un master Kubernetes dedicato gestito da IBM in un account IBM Cloud di proprietà di IBM. Il master Kubernetes è configurato con i seguenti componenti dedicati che non sono condivisi con altri clienti IBM.

  • etcd archivio dati: memorizza tutte le risorse Kubernetes di un cluster, quali Services, Deployments e Pods. Le ConfigMaps e i Secrets di Kubernetes sono dati dell'applicazione che vengono memorizzati come coppie chiave-valore in modo che possano essere utilizzati da un'applicazione che viene eseguita in un pod. I dati in etcd sono archiviati sul disco locale del master Kubernetes e ne viene eseguito il backup su IBM Cloud Object Storage. I dati vengono crittografati durante il transito su IBM Cloud Object Storage e quando inattivi. Puoi scegliere di abilitare la crittografia per i tuoi dati etcd sul disco locale del tuo master Kubernetes abilitando la crittografia IBM Key Protect per il tuo cluster. Quando i dati etcd vengono inviati a un pod, i dati vengono crittografati tramite TLS per garantirne la protezione e l'integrità.
  • kube-apiserver: funge da punto di accesso principale per tutte le richieste di gestione del cluster inviate dal nodo worker al master di Kubernetes. Il server API convalida ed elabora le richieste che modificano lo stato delle risorse cluster, come i pod o i servizi, e archivia questo stato nell'archivio dati etcd.
  • kube-scheduler: Decide dove distribuire i pod, tenendo conto delle esigenze in termini di capacità e prestazioni, dei vincoli imposti dalle politiche hardware e software, delle specifiche di anti-affinità e dei requisiti del carico di lavoro. Se non è possibile trovare alcun nodo di lavoro che corrisponda ai requisiti, il pod non viene distribuito nel cluster.
  • kube-controller-manager: si occupa di monitorare i replica set e di creare i pod corrispondenti per raggiungere lo stato specificato.
  • Konnectivity: componente specifico di IBM Cloud Kubernetes Service che garantisce una connettività di rete sicura per tutte le comunicazioni tra i nodi master e worker di Kubernetes. Il server Konnectivity collabora con l'agente Konnectivity per collegare in modo sicuro il nodo master al nodo worker. Questa connessione supporta le richieste apiserver proxy ai tuoi pod e servizi, nonché le richieste kubectl top, exec, attach e logs al kubelet. La connessione dai nodi di lavoro al master viene protetta automaticamente con i certificati TLS.
Monitoraggio continuo da parte dei Site Reliability Engineer (SRE) IBM

Il master Kubernetes, incluse tutte le risorse di calcolo, di rete e di archiviazione del componente master, vengono continuamente monitorati dagli SRE (Site Reliability Engineer) IBM. Gli SRE applicano i più recenti standard di sicurezza, rilevano e correggono le attività dannose e operano per garantire l'affidabilità e la disponibilità di IBM Cloud Kubernetes Service.

Benchmark del master Kubernetes CIS

Per configurare IBM Cloud Kubernetes Service, i tecnici di IBM seguono le pratiche di sicurezza informatica previste dal benchmark di riferimento “ Kubernetes ”, pubblicato dal Center of Internet Security(CIS). Il master cluster e tutti i nodi di lavoro vengono distribuiti con immagini che soddisfano il benchmark.

Comunicazioni protette tramite TLS

Per utilizzare IBM Cloud Kubernetes Service, devi eseguire l'autenticazione presso il servizio utilizzando le tue credenziali. Quando vieni autenticato, IBM Cloud Kubernetes Service genera i certificati TLS che crittografano le comunicazioni verso e dal server API Kubernetes e verso e dall'archivio dati etcd per garantire comunicazioni end-to-end protette tra i nodi di lavoro e il master Kubernetes. Questi certificati non sono mai condivisi tra i cluster o tra i componenti master Kubernetes.

Connettività ai nodi di lavoro

Sebbene Kubernetes garantisca la sicurezza delle comunicazioni tra i nodi master e worker tramite il protocollo https, per impostazione predefinita non è prevista alcuna autenticazione sul nodo worker. Per garantire la sicurezza di questa comunicazione, IBM Cloud Kubernetes Service configura automaticamente una connessione Konnectivity tra il nodo master Kubernetes e il nodo worker al momento della creazione del cluster.

Controllo dell'accesso dettagliato

Come amministratore dell'account, puoi concedere l'accesso ad altri utenti per IBM Cloud Kubernetes Service utilizzando IBM Cloud Identity and Access Management (IAM). IBM Cloud IAM fornisce un'autenticazione sicura con la piattaforma IBM Cloud, IBM Cloud Kubernetes Servicee tutte le risorse nel tuo account. La definizione di ruoli e autorizzazioni adeguati per gli utenti è fondamentale per limitare l'accesso alle risorse e per ridurre al minimo i danni che un utente può causare in caso di uso improprio delle autorizzazioni legittime. Puoi selezionare dai seguenti ruoli utente predefiniti che determinano l'insieme di azioni che l'utente può eseguire:

  • Ruoli di accesso alla piattaforma: definiscono le azioni relative alla gestione del cluster e dei nodi di lavoro che un utente può eseguire in IBM Cloud Kubernetes Service.
  • Ruoli di accesso al servizio: individuare il ruolo RBAC di Kubernetes assegnato all'utente e le azioni che l'utente può eseguire sul server API di Kubernetes. Grazie ai ruoli RBAC, gli utenti possono creare risorse dell' Kubernetes, come distribuzioni di app, spazi dei nomi o mappe di configurazione. Per ulteriori informazioni sui ruoli RBAC assegnati a un utente e sulle autorizzazioni associate, consultare la sezione " Ruoli di accesso al servizio IAM ".
  • Infrastruttura classica: consente l'accesso alle risorse dell'infrastruttura classica. Le azioni di esempio consentite dai ruoli dell'infrastruttura classica sono la visualizzazione dei dettagli delle macchine del nodo di lavoro del cluster o la modifica delle risorse di rete e archiviazione.
  • Infrastruttura VPC: consente l'accesso alle risorse dell'infrastruttura VPC. Le azioni di esempio consentite dai ruoli dell'infrastruttura VPC sono la creazione di un VPC, l'aggiunta di sottoreti, la modifica di indirizzi IP mobili e la creazione di istanze VPC Block Storage.

Per ulteriori informazioni sul controllo degli accessi in un cluster, consultare la sezione " Assegnazione degli accessi al cluster ".

Accesso pod tramite token account di servizio

Per i cluster che eseguono Kubernetes 1.21 e versioni successive, i token dell'account di servizio che i pod utilizzano per comunicare con il server API Kubernetes sono limitati nel tempo, aggiornati automaticamente, con ambito a un particolare gruppo di utenti (il pod) e invalidati dopo l'eliminazione del pod. Per continuare a comunicare con il server API, devi progettare le tue applicazioni per leggere regolarmente il valore del token aggiornato, ad esempio ogni minuto. Per ulteriori informazioni, vedi Bound Service Account Tokens.

Controller di ammissione

I controller di ammissione sono implementati per specifiche funzioni in Kubernetes e IBM Cloud Kubernetes Service. Con i controller di ammissione, puoi configurare le politiche nel tuo cluster che determinano se una specifica azione nel cluster è consentita o meno. Nella politica è possibile specificare le condizioni in cui un utente non può eseguire un'azione, anche se tale azione rientra nelle autorizzazioni generali assegnate all'utente tramite i ruoli RBAC. Pertanto, i controller di ammissione possono fornire un livello supplementare di sicurezza per il tuo cluster prima che una richiesta API venga elaborata dal server API Kubernetes.

Quando si crea un cluster, IBM Cloud Kubernetes Service installa automaticamente i file di configurazione predefiniti ( Kubernetes controllori di ammissione ) in un ordine specifico nel master di Kubernetes, ordine che non può essere modificato dall'utente. Riesamina l'ordine dei controller di ammissione predefiniti per versione cluster nelle informazioni di riferimento del componente kube-apiserver.

Puoi installare i tuoi propri controller di ammissione nel cluster o scegliere un controller di ammissione facoltativo, come Portieris. Con Portieris, puoi bloccare le distribuzioni del contenitore dalle immagini non firmate.

Se hai installato manualmente i controller di ammissione e non desideri più utilizzarli, assicurati di rimuoverli completamente. Se i controller di ammissione non vengono rimossi completamente, potrebbero bloccare tutte le azioni che vuoi eseguire sul cluster.

Cos'altro posso fare per proteggere il mio server API?

È possibile limitare la connettività di rete al master del cluster in diversi modi

  • Abilitare solo l'endpoint del servizio cloud privato: L'endpoint del servizio pubblico è necessario solo per i cluster classici di OpenShift. Può essere disattivato per tutti i cluster VPC. Può essere disattivato anche per i cluster classici di Kubernetes, purché l'account abbia abilitato VRF e Service Endpoint. Questo protegge il master del cluster da attacchi sulla rete pubblica.
  • Abilitare le restrizioni basate sul contesto: È possibile proteggere l'accesso alla rete agli endpoint dei servizi pubblici e privati del cluster utilizzando restrizioni basate sul contesto (CBR). Sono consentite solo le richieste autorizzate al master del cluster che provengono dalle subnet indicate nelle regole CBR. Per ulteriori informazioni, vedere Uso delle restrizioni basate sul contesto.

Nodo di lavoro

I nodi di lavoro contengono le distribuzioni e dei servizi che formano la tua applicazione. Quando ospiti dei carichi di lavoro nel cloud pubblico, vuoi assicurarti che la tua applicazione sia protetta da eventuali accessi, modifiche o monitoraggio da parte di utenti o software non autorizzati.

Chi è il proprietario del nodo di lavoro e spetta a me garantirne la sicurezza?

La proprietà di un nodo di lavoro dipende dal tipo di cluster che crei e dal provider dell'infrastruttura che scegli.

  • Cluster classici: i nodi di lavoro vengono configurati nel tuo account IBM Cloud. I nodi di lavoro sono dedicati a te ed è una tua responsabilità richiedere degli aggiornamenti tempestivi ai nodi di lavoro per garantire che ai componenti IBM Cloud Kubernetes Service e al sistema operativo dei nodi di lavoro vengano applicati gli aggiornamenti e le patch di sicurezza più recenti.
  • Cluster VPC: i nodi di lavoro vengono allocati in un account IBM Cloud di proprietà di IBM per consentire il monitoraggio delle attività dannose e l'applicazione degli aggiornamenti di sicurezza. Non è possibile accedere ai nodi di lavoro tramite la dashboard VPC. Tuttavia, puoi gestire i tuoi nodi di lavoro utilizzando l'API, la CLI o la console IBM Cloud Kubernetes Service. Le macchine virtuali che formano i tuoi nodi di lavoro sono dedicate a te ed è una tua responsabilità richiedere degli aggiornamenti tempestivi in modo che al sistema operativo del tuo nodo di lavoro e ai componenti IBM Cloud Kubernetes Service vengano applicati gli aggiornamenti e le patch di sicurezza più recenti.

Per ulteriori informazioni, vedi Le tue responsabilità nell'utilizzo di IBM Cloud Kubernetes Service.

Utilizza regolarmente (ad esempio ogni mese) il comando ibmcloud ks worker update per applicare gli aggiornamenti e le patch di sicurezza al sistema operativo e per aggiornare la versione di Kubernetes in esecuzione sui nodi di lavoro. Quando sono disponibili degli aggiornamenti, ne ricevi notifica quando visualizzi le informazioni relative ai nodi master e worker nella console o nella CLI di IBM Cloud, ad esempio tramite i comandi ibmcloud ks clusters ls o ibmcloud ks workers ls --cluster <cluster_name>. Gli aggiornamenti dei nodi di lavoro sono forniti da IBM come un'immagine del nodo di lavoro completa che include le patch di sicurezza più recenti. Per applicare gli aggiornamenti, è necessario ricercare l'immagine e ricaricare il nodo di lavoro con la nuova immagine. Le chiavi per l'utente root vengono ruotate automaticamente quando il nodo di lavoro viene ricaricato.

Com'è la configurazione del mio nodo di lavoro?

La seguente immagine mostra i componenti configurati per ogni nodo di lavoro per proteggerli da attacchi dolosi.

L'immagine non include componenti che garantiscono comunicazioni end-to-end sicure da e verso il nodo di lavoro. Per ulteriori informazioni, vedi sicurezza di rete.

Configurazione del nodo di lavoro in IBM Cloud Kubernetes Service, esclusa la sicurezza di rete.
Configurazione del nodo di lavoro in IBM Cloud Kubernetes Service, esclusa la sicurezza di rete

CIS-immagine conforme
Ogni nodo di lavoro è configurato con un sistema operativo che implementa i benchmark pubblicati dal Center of Internet Security ( CIS ). L'utente o il proprietario della macchina non può modificare questo sistema operativo in un altro sistema operativo. Per verificare la versione corrente del sistema operativo, esegui il comando kubectl get nodes -o wide``. IBM collabora con team di sicurezza esterni e interni per risolvere le vulnerabilità di conformità di sicurezza potenziali. Gli aggiornamenti e le patch di sicurezza per il sistema operativo sono resi disponibili tramite IBM Cloud Kubernetes Service e devono essere installati dall'utente per mantenere protetto il nodo di lavoro.

IBM Cloud Kubernetes Service utilizza un kernel Linux per i nodi worker. Puoi eseguire contenitori basati su qualsiasi distribuzione Linux in IBM Cloud Kubernetes Service. Verifica con il fornitore delle immagini container che le tue immagini container possano essere eseguite su quel kernel.

Monitoraggio continuo da parte dei Site Reliability Engineer (SRE)
L'immagine installata sui tuoi nodi di lavoro è continuamente monitorata dagli SRE (Site Reliability Engineer) IBM per rilevare vulnerabilità e problemi di conformità di sicurezza. Per affrontare le vulnerabilità, gli SRE creano patch di sicurezza e fix pack per i tuoi nodi di lavoro. Assicurati di applicare queste patch non appena saranno disponibili, per garantire un ambiente sicuro per i tuoi nodi di lavoro e per le applicazioni che esegui su di essi.
Benchmark del nodo di lavoro Kubernetes CIS
Per configurare IBM Cloud Kubernetes Service, i tecnici di IBM seguono le migliori pratiche di sicurezza informatica previste dal benchmark per i nodi di lavoro " Kubernetes ", pubblicato dal Center of Internet Security(CIS). Puoi esaminare la conformità dei nodi di lavoro rispetto agli standard CIS Kubernetes benchmark.
Isolamento di calcolo
I nodi di lavoro sono dedicati a un cluster e non ospitano carichi di lavoro di altri cluster. Quando si crea un cluster classico standard, è possibile scegliere di configurare i nodi di lavoro come macchine fisiche (bare metal) oppure come macchine virtuali in esecuzione su hardware fisico condiviso o dedicato. I nodi di lavoro in un cluster VPC possono essere configurati esclusivamente come macchine virtuali su un'infrastruttura condivisa.
Opzione per la distribuzione bare metal su Classic
Se crei un cluster classico standard, puoi scegliere di eseguire il provisioning dei tuoi nodi di lavoro su server fisici bare metal (anziché sulle istanze di server virtuali). Con le macchine bare metal, hai un ulteriore controllo sull'host di calcolo, ad esempio la memoria o la CPU. Questa configurazione elimina l'hypervisor della macchina virtuale che assegna risorse fisiche alle macchine virtuali eseguite sull'host. Al contrario, tutte le risorse di una macchina bare metal sono dedicate esclusivamente al worker, quindi non devi preoccuparti che dei “vicini rumorosi” condividano le risorse o rallentino le prestazioni. I server bare metal sono dedicati a te, con tutte le sue risorse disponibili per l'utilizzo del cluster.
Dischi crittografati
Per impostazione predefinita, il provisioning di ogni nodo di lavoro viene eseguito con due partizioni di dati SSD con crittografia AES a 256 bit locali. La prima partizione contiene l'immagine kernel utilizzata per avviare il nodo di lavoro e non è crittografata. La seconda partizione contiene il file system del contenitore ed è sbloccata utilizzando le chiavi di crittografia LUKS. Ogni nodo di lavoro in un cluster ha la propria chiave di crittografia LUKS, gestita da IBM Cloud Kubernetes Service. Quando crei un cluster o aggiungi un nodo di lavoro a un cluster esistente, le chiavi vengono trasmesse in modo sicuro e quindi scartate dopo che il disco codificato viene sbloccato. La crittografia può influire sulle prestazioni I/O del disco. Per i carichi di lavoro che richiedono I/O del disco di alte prestazioni, esegui il test di un cluster con la codifica sia abilitata che disabilitata per aiutarti a decidere se disattivarla.
Politiche AppArmor degli esperti
Ogni nodo di lavoro è configurato con politiche di sicurezza e di accesso che vengono applicate tramite AppArmor profili caricati nel nodo di lavoro durante la fase di avvio. AppArmor I profili non possono essere modificati né dall'utente né dal proprietario del computer.
SSH disabilitato
Per impostazione predefinita, l'accesso SSH è disabilitato sul nodo di lavoro per proteggere il tuo cluster da attacchi dolosi. Quando l'accesso SSH è disabilitato, l'accesso al cluster viene forzato tramite il server API Kubernetes. Il server API Kubernetes richiede che ogni richiesta venga controllata rispetto alle politiche impostate nel modulo di autenticazione, autorizzazione e controllo di ammissione prima che la richiesta venga eseguita nel cluster.
Se disponi di un cluster standard e desideri installare ulteriori funzionalità sul tuo nodo di lavoro, puoi scegliere tra i componenti aggiuntivi forniti da IBM Cloud Kubernetes Service oppure utilizzare i set di daemon disponibili su Kubernetes per tutte le applicazioni che desideri eseguire su ciascun nodo di lavoro. Per qualsiasi operazione da eseguire una sola volta, utilizza i processi di " Kubernetes ".

Rete

L'approccio classico per proteggere una rete aziendale consiste nel configurare un firewall e bloccare tutto il traffico di rete indesiderato alle tue applicazioni. Anche se questo è ancora vero, la ricerca dimostra che molti attacchi dolosi provengono da persone interne o da utenti autorizzati che utilizzano in modo improprio le autorizzazioni ad essi assegnate.

Segmentazione e privacy della rete per i cluster classici

Per proteggere la tua rete e limitare la gamma di danni che un utente può produrre quando gli viene concesso l'accesso a una rete, devi assicurarti che i tuoi carichi di lavoro siano il più isolati possibile e di limitare il numero di applicazioni e nodi di lavoro esposti pubblicamente.

Quale traffico di rete è consentito per default per il mio cluster Classic?

Tutti i contenitori sono protetti dalle impostazioni della politica di rete Calico predefinite che sono configurate su ogni nodo di lavoro durante la creazione del cluster. Per impostazione predefinita, tutto il traffico di rete in uscita è consentito per tutti i nodi di lavoro. Il traffico di rete in entrata è bloccato con le seguenti eccezioni:

  • NodePort: La gamma di indirizzi Kubernetes NodePort è aperta per impostazione predefinita, in modo da consentire l'esposizione delle applicazioni con servizi NodePort. Per bloccare il traffico di rete in entrata su NodePorts nel tuo cluster, vedi Controllo del traffico in entrata ai servizi NLB o NodePort.
  • Porte di monitoraggio IBM: per impostazione predefinita, IBM apre alcune porte sul tuo cluster in modo che il traffico di rete possa essere monitorato da IBM e per consentire a quest'ultima di installare automaticamente aggiornamenti di sicurezza per il master Kubernetes.

L'accesso dal master di Kubernetes al kubelet del nodo worker è protetto da un tunnel Konnectivity. Per ulteriori informazioni, vedi l'architettura di IBM Cloud Kubernetes Service.

Che cos’è la segmentazione della rete e come posso configurarla per un cluster Classic?

La segmentazione di rete descrive l'approccio di dividere una rete in più sottoreti. Puoi raggruppare le applicazioni e i dati correlati a cui deve avere accesso uno specifico gruppo nella tua organizzazione. Le app in esecuzione in una sottorete non possono vedere né accedere alle app presenti in un'altra sottorete. La segmentazione di rete limita anche l'accesso fornito a una persona interna o a software di terze parti e può limitare la gamma di attività dolose.

IBM Cloud Kubernetes Service fornisce le VLAN IBM Cloud che garantiscono delle prestazioni di rete di qualità e l'isolamento della rete per i nodi di lavoro. Una VLAN configura un gruppo di nodi di lavoro come se fossero collegati con lo stesso cavo fisico. Le VLAN sono dedicate al tuo account IBM Cloud e non sono condivise tra i clienti IBM. Nei cluster classici, se hai più VLAN per il tuo cluster, più sottoreti sulla stessa VLAN o un cluster classico multizona, devi abilitare una VRF (Virtual Router Function) per il tuo account dell'infrastruttura IBM Cloud in modo che i tuoi nodi di lavoro possano comunicare tra loro sulla rete privata. Per abilitare VRF, consultare Abilitazione VRF. Per controllare se una VRF è già abilitata, utilizza il comando ibmcloud account show. Se non puoi o non vuoi abilitare VRF, abilita VLAN spanning. Per eseguire questa operazione, è necessario disporre dell'autorizzazione " Rete > Gestione delle VLAN di rete " oppure è possibile richiedere al proprietario dell'account di abilitarla. Per verificare se lo spanning VLAN è già abilitato, utilizzare il comando ibmcloud ks vlan spanning get --region .

Quando abiliti il VRF o lo spanning della VLAN per il tuo account, la segmentazione di rete viene rimossa per i tuoi cluster.

Esamina la seguente tabella per vedere le opzioni a tua disposizione relative a come ottenere la segmentazione di rete quando abiliti il VRF o lo spanning della VLAN per il tuo account.

Opzioni di segmentazione della rete
Funzione di sicurezza Descrizione
Configura le politiche di rete personalizzate con Calico Puoi utilizzare l'interfaccia Calico integrata per configurare le politiche di rete Calico personalizzate per i tuoi nodi di lavoro. Ad esempio, puoi consentire o bloccare il traffico di rete su specifiche interfacce di rete e per specifici pod o servizi. Per configurare criteri di rete personalizzati, è necessario installare la CLI di calicoctl.
Supporto per i firewall di rete IBM Cloud IBM Cloud Kubernetes Service è compatibile con tutte le offerte del firewall IBM Cloud. Ad esempio, puoi configurare un firewall con politiche di rete personalizzate per fornire una sicurezza di rete dedicata al tuo cluster standard e per rilevare e risolvere intrusioni di rete. Ad esempio, puoi scegliere di configurare una VRA (Virtual Router Appliance) perché funga da tuo firewall e blocchi il traffico indesiderato. Quando configuri un firewall, devi anche aprire le porte e gli indirizzi IP necessari per ogni regione in modo che il master e i nodi di lavoro possano comunicare.

Cos’altro posso fare per ridurre la superficie di attacco esterna dei cluster Classic?

Maggiore è il numero di applicazioni o nodi di lavoro che esponi pubblicamente e più complessa diventa la procedura che devi implementare per evitare attacchi dolosi esterni. Esamina la seguente tabella per trovare le opzioni relative a come mantenere private le applicazioni e i nodi di lavoro.

Servizi privati e opzioni del nodo di lavoro
Funzione di sicurezza Descrizione
Limita il numero di applicazioni esposte Per impostazione predefinita, le tue applicazioni e i tuoi servizi eseguiti all'interno del cluster non sono raggiungibili su Internet pubblico. Puoi scegliere se vuoi esporre le tue applicazioni al pubblico o se desideri che le tue applicazioni e i tuoi servizi siano raggiungibili solo sulla rete privata. Quando mantieni le tue applicazioni e i tuoi servizi privati, puoi avvalerti delle funzioni di sicurezza integrate per garantire delle comunicazioni protette tra i nodi di lavoro e i pod. Per esporre i servizi e le applicazioni a internet pubblico, puoi avvalerti del supporto NLB e ALB Ingress per rendere i tuoi servizi pubblicamente disponibili in modo sicuro. Assicurati che solo i servizi necessari siano esposti e rivisita l'elenco delle applicazioni esposte regolarmente per assicurarti che siano ancora valide.
Mantieni i nodi di lavoro privati Quando crei un cluster, ogni cluster viene automaticamente collegato a una VLAN privata. La VLAN privata determina l'indirizzo IP privato che viene assegnato a un nodo di lavoro. Puoi scegliere di mantenere i tuoi nodi di lavoro privati connettendoli solo a una VLAN privata. Tieni presente che, per comunicare con il master di Kubernetes dal tuo computer locale e affinché IBM Cloud Kubernetes Service possa connettersi ai servizi di IBM Cloud che non supportano un endpoint del servizio cloud privato, è necessario configurare la connettività pubblica a URL e indirizzi IP specifici. Se i servizi di IBM Cloud a cui desideri connetterti dispongono di un endpoint di servizio cloud privato e il tuo account è abilitato per VRF, il traffico di rete da e verso tali servizi viene automaticamente instradato attraverso la rete privata e non è necessaria alcuna connessione alla rete pubblica. Per configurare la connettività pubblica per il cluster connesso solo a una VLAN privata, puoi configurare un firewall, ad esempio una VRA (Virtual Router Appliance) davanti ai tuoi nodi di lavoro e abilitare il traffico di rete a questi URL e indirizzi IP.
Limita la connettività a Internet pubblico con i nodi edge Se non si crea un cluster con un gateway abilitato, ogni nodo worker è configurato per accettare i pod delle applicazioni e i pod associati al bilanciatore di carico o all'ingress. Puoi etichettare i nodi di lavoro come nodi edge per forzare la distribuzione del programma di bilanciamento del carico e dei pod Ingress solo a questi nodi di lavoro. Inoltre, è possibile contrassegnare i nodi worker in modo che i pod delle applicazioni non possano essere pianificati sui nodi periferici. Con i nodi edge, puoi isolare il carico di lavoro di rete su un numero inferiore di nodi di lavoro nel tuo cluster e mantenere privati gli altri nodi di lavoro nel cluster.

E se volessi collegare il mio cluster a un data center on-premise?

Per collegare i nodi worker e le app a un data center on-premise, è possibile configurare un Virtual Router Appliance o una Fortigate Security Appliance.

Segmentazione e privacy della rete per i cluster VPC

Per proteggere la tua rete e limitare la gamma di danni che un utente può produrre quando gli viene concesso l'accesso a una rete, devi assicurarti che i tuoi carichi di lavoro siano il più isolati possibile e di limitare il numero di applicazioni e nodi di lavoro esposti pubblicamente.

Quale traffico di rete è consentito per default per il mio cluster VPC?

Per impostazione predefinita, i nodi di lavoro sono collegati esclusivamente alle sottoreti VPC della rete privata e non dispongono di un'interfaccia di rete pubblica. Tutti gli accessi pubblici ai nodi di lavoro sono bloccati. L'uscita pubblica dai tuoi nodi di lavoro è consentita solo se i nodi di lavoro sono connessi a una sottorete VPC che ha un gateway pubblico.

Se i tuoi nodi di lavoro devono accedere a un endpoint pubblico esterno al cluster, puoi collegare un gateway pubblico alla sottorete VPC in cui sono distribuiti i nodi di lavoro. Ad esempio, il tuo cluster VPC può connettersi automaticamente ad altri servizi di IBM Cloud che supportano endpoint di servizi cloud privati, come IBM Cloud Container Registry. Tuttavia, se è necessario accedere a servizi di " IBM Cloud " che supportano solo endpoint di servizi cloud pubblici, è possibile collegare un gateway pubblico alla sottorete in modo che i pod possano inviare richieste attraverso la rete pubblica. Tutto il traffico in uscita è consentito per i nodi di lavoro su una sottorete con un gateway pubblico collegato, ma tutto il traffico in entrata è ancora bloccato.

Se nel tuo cluster distribuisci applicazioni che devono ricevere richieste di traffico da Internet, puoi creare un programma di bilanciamento del carico VPC per esporre le tue applicazioni. Per consentire il traffico di rete in entrata verso le tue applicazioni, devi configurare il tuo programma di bilanciamento del carico VPC per il traffico di rete in entrata che desideri ricevere.

I gruppi di sicurezza vengono applicati per impostazione predefinita all'istanza VPC e agli ALB e NLB VPC. Per ulteriori informazioni, vedere Comprendere la rete VPC sicura per impostazione predefinita del cluster e Creare e gestire i gruppi di sicurezza VPC.

Che cos’è la segmentazione di rete e come posso configurarla per un cluster VPC?

La segmentazione di rete descrive l'approccio di dividere una rete in più sottoreti. Puoi raggruppare le applicazioni e i dati correlati a cui deve avere accesso uno specifico gruppo nella tua organizzazione. Le app in esecuzione in una sottorete non possono vedere né accedere alle app presenti in un'altra sottorete. La segmentazione di rete limita anche l'accesso fornito a una persona interna o a software di terze parti e può limitare la gamma di attività dolose.

IBM Cloud Kubernetes Service fornisce le sottoreti IBM Cloud VPC che garantiscono prestazioni di rete di qualità e isolamento della rete per i nodi di lavoro. Una sottorete VPC è costituita da un intervallo di indirizzi IP privati specificato (blocco CIDR) e configura un gruppo di nodi di lavoro e pod come se fossero collegati allo stesso cavo fisico. Le sottoreti VPC sono dedicate al tuo account IBM Cloud e non sono condivise tra i clienti IBM.

Le sottoreti VPC forniscono un canale per la connettività tra i nodi di lavoro all'interno del cluster. Qualsiasi sistema connesso a una delle sottoreti private nello stesso VPC può comunicare con i nodi di lavoro. Ad esempio, tutte le sottoreti di un VPC possono comunicare tramite l'instradamento di livello 3 privato con un router VPC integrato. Se i cluster non devono comunicare tra loro, è possibile ottenere la migliore segmentazione di rete creando i cluster in VPC separate. Se hai più cluster che devono comunicare tra loro, puoi creare i cluster nello stesso VPC. Sebbene le sottoreti all'interno di un VPC possano essere condivise da più cluster in quel VPC, puoi ottenere una migliore segmentazione della rete utilizzando sottoreti diverse per i cluster all'interno di un VPC.

Per ottenere un'ulteriore segmentazione della rete privata tra le sottoreti VPC per il tuo account, puoi configurare delle politiche di rete personalizzate con gli ACL (access control list) VPC. Quando si crea una VPC, viene generata un'ACL predefinita nel formato allow-all-network-acl-<VPC_ID> per la VPC. Ogni sottorete che crei nel VPC viene collegata a questo ACL per impostazione predefinita. L'ACL include una regola in entrata e una regola in uscita che consentono tutto il traffico tra i tuoi nodi di lavoro su una sottorete e qualsiasi sistema sulle sottoreti nello stesso VPC. Se vuoi specificare quale traffico di rete privata è consentito ai nodi di lavoro sulle tue sottoreti VPC, puoi creare un ACL personalizzato per ciascuna sottorete nel VPC. Ad esempio puoi creare una serie di regole ACL per bloccare la maggior parte del traffico di rete privata in entrata e in uscita di un cluster, consentendo al contempo le comunicazioni necessarie per il funzionamento del cluster.

Cos’altro posso fare per ridurre la superficie di attacco esterna dei cluster VPC?

Maggiore è il numero di applicazioni o nodi di lavoro che esponi pubblicamente e più complessa diventa la procedura che devi implementare per evitare attacchi dolosi esterni. Esamina la seguente tabella per trovare le opzioni relative a come mantenere private le applicazioni e i nodi di lavoro.

Opzioni di sicurezza della rete VPC
Funzione di sicurezza Descrizione
Limita il numero di applicazioni esposte Per impostazione predefinita, le tue applicazioni e i tuoi servizi eseguiti all'interno del cluster non sono raggiungibili su Internet pubblico. Puoi scegliere se vuoi esporre le tue applicazioni al pubblico o se desideri che le tue applicazioni e i tuoi servizi siano raggiungibili solo sulla rete privata. Quando mantieni le tue applicazioni e i tuoi servizi privati, puoi avvalerti delle funzioni di sicurezza integrate per garantire delle comunicazioni protette tra i nodi di lavoro e i pod. Per esporre i servizi e le applicazioni a internet pubblico, puoi avvalerti del supporto per il programma di bilanciamento del carico VPC e l'ALB Ingress per rendere i tuoi servizi pubblicamente disponibili in modo sicuro. Assicurati che solo i servizi necessari siano esposti e rivisita l'elenco delle applicazioni esposte regolarmente per assicurarti che siano ancora valide.
Limita l'uscita della rete pubblica a una sottorete con un gateway pubblico Se i pod sui tuoi nodi di lavoro devono connettersi a un endpoint esterno pubblico, puoi collegare un gateway pubblico alla sottorete su cui si trovano tali nodi di lavoro. Puoi isolare questo traffico di rete nel tuo cluster collegando un gateway pubblico a solo una sottorete nel tuo cluster. Quindi, puoi impostare le regole di affinità per distribuire i pod dell'applicazione che richiedono l'accesso a endpoint esterni solo alla sottorete con un gateway pubblico collegato.

A seconda della rete alla quale vuoi connettere i tuoi nodi di lavoro, puoi scegliere una soluzione VPN.

Pubblica le app in modo sicuro con i servizi " LoadBalancer " e "Ingress"

Puoi utilizzare i servizi di rete NLB (network load balancer) e ALB (application load balancer) Ingress per connettere le tue applicazioni a internet pubblico oppure a reti private esterne. Esamina le seguenti impostazioni facoltative per NLB e ALB che puoi utilizzare per soddisfare i requisiti di sicurezza delle applicazioni di back-end o crittografare il traffico quando transita per il tuo cluster.

Posso utilizzare i gruppi di sicurezza per gestire il traffico di rete del mio cluster?

Cluster classici: i gruppi di sicurezza IBM Cloud vengono applicati all'interfaccia di rete di un singolo server virtuale per filtrare il traffico a livello dell'hypervisor. Se vuoi gestire il traffico per ogni nodo di lavoro, puoi utilizzare i gruppi di sicurezza. Quando crei un gruppo di sicurezza, devi consentire il protocollo VRRP, utilizzato da IBM Cloud Kubernetes Service per gestire gli indirizzi IP NLB. Per gestire in modo uniforme il traffico del cluster su tutti i nodi di lavoro, utilizzare le politiche Calico e Kubernetes.

Cluster VPC: i gruppi di sicurezza VPC vengono applicati all'interfaccia di rete di un singolo server virtuale per filtrare il traffico a livello di hypervisor. Puoi aggiungere regole in entrata e in uscita al gruppo di sicurezza predefinito per il tuo cluster per gestire il traffico in entrata e in uscita a un cluster VPC. Per ulteriori informazioni, vedere Comprendere la rete VPC sicura per impostazione predefinita del cluster e Creare e gestire i gruppi di sicurezza VPC.

Poiché i nodi di lavoro del tuo cluster VPC risiedono in un account di servizio e non sono elencati nella dashboard dell'infrastruttura VPC, non è possibile creare un gruppo di sicurezza e applicarlo alle istanze dei nodi di lavoro. È possibile modificare solo i gruppi di sicurezza esistenti creati per conto dell'utente.

Come posso proteggere l'indirizzo IP di origine all'interno del cluster?

Negli NLB versione 2.0, l'indirizzo IP di origine della richiesta client viene conservato per impostazione predefinita. Tuttavia, negli NLB versione 1.0 e in tutti gli ALB Ingress, l'indirizzo IP di origine della richiesta client non viene conservato. Quando una richiesta client alla tua applicazione viene inviata al tuo cluster, la richiesta viene instradata a un pod per l'NLB 1.0 o l'ALB. Se sullo stesso nodo di lavoro del pod del servizio del programma di bilanciamento del carico non esiste un pod dell'applicazione, l'NLB o l'ALB inoltra la richiesta a un pod dell'applicazione su un nodo di lavoro diverso. L'indirizzo IP di origine del pacchetto viene modificato nell'indirizzo IP pubblico del nodo di lavoro su cui viene eseguito il pod dell'applicazione.

La conservazione dell'IP del client è utile quando, ad esempio, i server delle applicazioni devono applicare le politiche di sicurezza e di controllo dell'accesso. Per conservare l'indirizzo IP di origine originale della richiesta client, puoi abilitare la conservazione dell'IP di origine per gli NLB versione 1.0 o gli ALB Ingress.

Come posso effettuare la disattivazione dell' TLS e con i servizi " LoadBalancer " e "Ingress"?

Il servizio Ingress offre la terminazione TLS in due punti nel flusso del traffico:

  • Decrittografare il pacchetto all'arrivo: per impostazione predefinita, l'ALB di Ingress distribuisce il carico del traffico di ret HTTP e alle applicazioni presenti nel cluster. Per bilanciare anche il traffico delle connessioni HTTPS in entrata, puoi configurare l'ALB per decodificare il traffico di rete e inoltrare la richiesta decodificata alle applicazioni esposte nel tuo cluster. Se usi il dominio secondario Ingress fornito da IBM, puoi usare il certificato TLS fornito da IBM. Se usi un dominio personalizzato, puoi usare il tuo certificato TLS per gestire la terminazione TLS.
  • Crittografa nuovamente il pacchetto prima di inoltrarlo alle applicazioni upstream: l'ALB decrittografa le richieste HTTPS prima di inoltrare il traffico alle tue applicazioni. Se hai delle applicazioni che richiedono HTTPS e hanno bisogno che il traffico venga crittografato prima di essere inoltrato a queste applicazioni upstream, puoi utilizzare l'annotazione ssl-services. Se le tue applicazioni upstream possono gestire TLS, puoi facoltativamente fornire un certificato che è contenuto in un segreto TLS unidirezionale o di autenticazione reciproca.

Per garantire la sicurezza della comunicazione tra servizi, è possibile utilizzare l'autenticazione reciproca TLS di Istio. Istio è un servizio open source che offre agli sviluppatori un modo per connettere, proteggere, gestire e monitorare una rete di microservizi, nota anche come rete (mesh) di servizi, su piattaforme di orchestrazione cloud come Kubernetes.

Archiviazione persistente

Esamina le opzioni supportate per la crittografia e la protezione dei tuoi dati nell'archiviazione persistente in IBM Cloud.

Per impostazione predefinita, tutte le soluzioni di archiviazione IBM Cloud crittografano automaticamente i tuoi dati inattivi con una chiave di crittografia gestita da IBM senza costi aggiuntivi. Per ulteriori informazioni, vedi i seguenti link.

A seconda del tipo di archiviazione che hai scelto, puoi configurare un'ulteriore crittografia con IBM Key Protect per proteggere i tuoi dati in transito e inattivi con la tua chiave di crittografia.

Puoi anche utilizzare un servizio di database IBM Cloud, ad esempio IBM Cloudant NoSQL DB, per mantenere i dati in un database gestito all'esterno del cluster. I dati che vengono archiviati con un servizio database cloud sono accessibili nei cluster, nelle zone e nelle regioni. Per informazioni relative alla sicurezza, vedi la documentazione di IBM Cloud specifica per il servizio di database.

Monitoraggio e registrazione

La chiave per rilevare attacchi dolosi nel tuo cluster è il monitoraggio e la registrazione corretti delle metriche e di tutti gli eventi che si verificano nel cluster. Il monitoraggio e la registrazione possono inoltre aiutarti a comprendere la capacità del cluster e la disponibilità delle risorse per la tua applicazione in modo da poter pianificare di conseguenza per proteggere le tue applicazioni da un tempo di inattività.

IBM, monitora il mio cluster?
Ogni master cluster viene continuamente monitorato da IBM per controllare e correggere gli attacchi DOS (Denial - Of - Service) a livello di processo. IBM Cloud Kubernetes Service esegue automaticamente la scansione di ogni nodo in cui viene distribuito il master alla ricerca di vulnerabilità trovate in Kubernetes e fix di sicurezza specifiche del sistema operativo. Se vengono trovate delle vulnerabilità, IBM Cloud Kubernetes Service automaticamente applica le correzioni e risolve le vulnerabilità per conto dell'utente per garantire la protezione del nodo master.
Quali informazioni vengono registrate?
Per impostazione predefinita, IBM Cloud Kubernetes Service raccoglie automaticamente i log per i seguenti componenti cluster:
  • Contenitori: i log vengono scritti in STDOUT o STDERR.
  • Applicazioni: i log che vengono scritti in un percorso specifico all'interno della tua applicazione.
  • Nodi di lavoro: i log dal sistema operativo Ubuntu che vengono inviati a /var/log/syslog e /var/log/auth.log.
  • Server API Kubernetes: ogni azione correlata al cluster che viene inviata al server API Kubernetes viene registrata per motivi di controllo, inclusi la data/ora, l'utente e la risorsa interessata. Per ulteriori informazioni, consultare i registri di audit di Kubernetes. Puoi accedere a questi log utilizzando IBM Cloud Logs.
  • Ingress: i log per un ALB (application load balancer) Ingress che gestisce il traffico di rete in entrata.
  • Componenti di sistema Kubernetes: i log da kubelet, da kube-proxy e da altri componenti che vengono eseguiti nello spazio dei nomi kube-system.

Per accedere ai log del componente cluster, puoi scegliere di inoltrare i tuoi log a IBM Cloud Logs}}, un server esterno, oppure a una soluzione di registrazione di terze parti. Per ulteriori informazioni, vedi Scelta di una soluzione di registrazione.

Come posso monitorare lo stato e le prestazioni del mio cluster?
Puoi verificare l'integrità, la capacità e le prestazioni delle tue applicazioni, dei tuoi servizi e dei tuoi nodi di lavoro monitorando i tuoi componenti cluster e le tue risorse di calcolo dalla CLI o dalla console IBM Cloud Kubernetes Service, come ad esempio l'utilizzo della CPU e della memoria. Per visualizzare metriche più approfondite per un cluster standard o per le tue applicazioni, puoi configurare un agent di monitoraggio nel tuo cluster per inviare le metriche a IBM Cloud Monitoring. È inoltre possibile installare soluzioni di monitoraggio di terze parti, come Prometheus, oppure utilizzare le metriche fornite nella dashboard Kubernetes. Per ulteriori informazioni, vedi Scelta di una soluzione di monitoraggio.

Per configurare un sistema di rilevamento delle intrusioni basato su host (HIDS) e il monitoraggio dei log degli eventi di sicurezza (SELM), installa strumenti di terze parti progettati per monitorare il cluster e le applicazioni containerizzate al fine di rilevare intrusioni o usi impropri, come Twistlock o il progetto Sysdig Falco.

Come posso monitorare gli eventi che si verificano nel mio cluster?
Puoi configurare IBM Cloud Logs nel tuo cluster IBM Cloud Kubernetes Service. Per ulteriori informazioni, consulta la documentazione Scopri di più su IBM Cloud Logs.
Quali sono le opzioni a mia disposizione per abilitare la fiducia nel mio cluster?
Per impostazione predefinita, IBM Cloud Kubernetes Service fornisce molte funzioni per i tuoi componenti cluster in modo da consentirti di distribuire le tue applicazioni inserite in un contenitore in un ambiente altamente sicuro. Estendi il tuo livello di attendibilità nel tuo cluster per garantire ulteriormente che le operazioni che esegui all'interno del cluster sono effettivamente quelle che desideri eseguire. Puoi implementare l'attendibilità nel tuo cluster in diversi modi, come mostrato nel seguente diagramma.

Distribuzione di container con contenuti affidabili.
Distribuzione di container con contenuti affidabili

  1. Attendibilità dei contenuti per le tue immagini: assicura l'integrità delle tue immagini abilitando l'attendibilità dei contenuti nel tuo IBM Cloud Container Registry. Con i contenuti attendibili, puoi controllare chi firma le immagini come attendibili. Una volta che i firmatari attendibili inseriscono un'immagine nel tuo registro, gli utenti possono estrarre il contenuto firmato in modo che possano verificare l'origine dell'immagine. Per ulteriori informazioni, vedi Firma le immagini per i contenuti attendibili.

  2. Applicazione delle misure di sicurezza relative alle immagini dei container: utilizzare un controller di ammissione con criteri personalizzati per poter verificare le immagini dei container prima di distribuirle. Con un progetto di applicazione della sicurezza dell'immagine del contenitore come Portieris, controlli da dove vengono distribuite le immagini e assicurati che soddisfino i requisiti di attendibilità del contenuto. Se una distribuzione non soddisfa le politiche che hai impostato, Security Enforcement impedisce le modifiche al tuo cluster.

  3. Programma di scansione vulnerabilità dell'immagine: per impostazione predefinita, Controllo vulnerabilità esegue la scansione delle immagini memorizzate in IBM Cloud Container Registry per trovare potenziali vulnerabilità di sicurezza. Per ulteriori informazioni, vedi Gestione della sicurezza delle immagini con il Vulnerability Advisor.

  4. IBM Cloud Compliance Manager: Quando si attiva IBM Cloud Compliance Manager, è possibile visualizzare i rapporti sul traffico di rete sospetto in entrata e in uscita. Per ulteriori informazioni, consultare la documentazione relativa a “ IBM Cloud Compliance Manager ”.

  5. IBM Cloud® Secrets Manager: puoi archiviare i tuoi segreti Ingress e Kubernetes in IBM Cloud® Secrets Manager. Quando integri Secrets Manager nel tuo cluster, imposti un'istanza Secrets Manager predefinita dove vengono caricati tutti i segreti del dominio secondario Ingress. Per ulteriori informazioni, vedi Configurazione di Secrets Manager nel tuo cluster Kubernetes Service.

Immagine e registro

Ogni distribuzione è basata su un'immagine che contiene le istruzioni su come effettuare lo spin-up del contenitore che esegue la tua applicazione. Queste istruzioni includono il sistema operativo all'interno del contenitore e del software extra che vuoi installare. Per proteggere la tua applicazione, devi proteggere l'immagine e stabilire i controlli per garantire l'integrità dell'immagine.

È meglio utilizzare un archivio pubblico o privato per archiviare le mie immagini?
I registri pubblici, come ad esempio Docker Hub, possono essere utilizzati per iniziare a lavorare con le immagini Docker e Kubernetes per creare la tua prima applicazione inserita in un contenitore in un cluster. Quando si tratta però di applicazioni enterprise, evita i registri che non conosci o che non ritieni attendibili per proteggere il tuo cluster da immagini dolose. Tieni le tue immagini in un registro privato, come quello fornito in IBM Cloud Container Registry, e assicurati di controllare l'accesso al registro e il contenuto dell'immagine di cui può essere eseguito il push.
Perché è importante verificare che le immagini non presentino vulnerabilità?
La ricerca mostra che la maggior parte degli attacchi dolosi sfrutta vulnerabilità software note e configurazioni di sistema deboli. Quando distribuisci un contenitore da un'immagine, il contenitore esegue lo spin-up con il sistema operativo e i file binari extra che hai descritto nell'immagine. Proprio come proteggi la tua macchina virtuale o fisica, devi eliminare le vulnerabilità note nel sistema operativo e nei file binari che usi all'interno del contenitore per proteggere la tua applicazione dall'accesso da parte di utenti non autorizzati.

Per proteggere le tue applicazioni, considera di occuparti delle seguenti aree:

  1. Automatizzare il processo di compilazione e limitare le autorizzazioni: automatizzare il processo di compilazione dell'immagine del container a partire dal codice sorgente per eliminare variazioni e difetti nel codice sorgente. Integrando il processo di creazione nella tua pipeline CI/CD, puoi garantire che la tua immagine venga scansionata e creata solo se supera i controlli di sicurezza da te specificati. Per evitare che gli sviluppatori applichino degli hot fix a immagini sensibili, limita il numero di persone nella tua organizzazione che ha accesso al processo di creazione.

  2. Eseguire la scansione delle immagini prima della loro distribuzione in produzione: assicurarsi di eseguire la scansione di ogni immagine prima di distribuire un container a partire da essa. Ad esempio, se utilizzi IBM Cloud Container Registry, tutte le immagini vengono automaticamente scansionate per rilevare eventuali vulnerabilità quando esegui il push dell'immagine al tuo spazio dei nomi. Se vengono rilevate delle vulnerabilità, considera di eliminare le vulnerabilità o di bloccare la distribuzione per tali immagini. Trova una persona o un team nella tua organizzazione che è responsabile del monitoraggio e della rimozione delle vulnerabilità. A seconda della struttura della tua organizzazione, questa persona potrebbe far parte di un team di sicurezza, operativo o di distribuzione. Abilita l'attendibilità del contenuto in modo che le immagini debbano essere approvate da un firmatario attendibile prima che possano essere inviate al registro del contenitore. Quindi, installa il controller di ammissione Portieris project open source per bloccare le distribuzione del contenitore da immagini non firmate.

  3. Eseguire regolarmente la scansione dei container in esecuzione:. Anche se hai distribuito un contenitore da un'immagine che supera il controllo delle vulnerabilità, il sistema operativo o i file binari in esecuzione nel contenitore potrebbero diventare vulnerabili nel tempo. Per proteggere la tua applicazione, devi assicurarti che i contenitori in esecuzione vengano scansionati regolarmente in modo da poter rilevare e correggere le vulnerabilità. A seconda dell’app, per garantire una maggiore sicurezza, è possibile impostare un’operazione che elimini i container vulnerabili una volta individuati.

Sicurezza per immagini e distribuzioni
Funzione di sicurezza Descrizione
Repository di immagini private Docker protetto in IBM Cloud Container Registry Impostare il proprio repository di immagini Docker in un registro di immagini private multi-tenant, altamente disponibile e scalabile, ospitato e gestito da IBM. Utilizzando il registro, è possibile creare, archiviare in modo sicuro e condividere le immagini Docker tra gli utenti del cluster. /Per saperne di più sulla protezione delle informazioni personali quando si lavora con le immagini dei contenitori
Esegui il push delle immagini solo con contenuto attendibile Assicurati l'integrità delle tue immagini abilitando content trust nel tuo repository di immagini. Con il contenuto attendibile, puoi controllare chi firma le immagini come attendibili ed eseguire il push di immagini a uno specifico spazio dei nomi del registro. Dopo che i firmatari autorizzati hanno caricato un'immagine in uno spazio dei nomi del registro, gli utenti possono scaricare il contenuto firmato per verificare l'identità dell'editore e l'integrità dell'immagine.
Quando si utilizza IBM Cloud Container Registry, si può sfruttare la scansione di sicurezza integrata fornita da Vulnerability Advisor. Ogni immagine di cui viene eseguito il push al tuo spazio dei nomi
del registro viene automaticamente scansionata per rilevare eventuali vulnerabilità
rispetto a un database di problemi CentOS, Debian, Red Hat e Ubuntu noti. Qualora venissero individuate delle vulnerabilità, all'indirizzo Vulnerability Advisor sono disponibili le istruzioni su come risolverle per garantire l'integrità e la sicurezza dell'immagine.
Blocca le distribuzioni da immagini vulnerabili o utenti non attendibili Crea un controller di ammissione con politiche personalizzate in modo da poter verificare le immagini del contenitore prima di distribuirle. Con il progetto open source Portieris, potete controllare da dove vengono distribuite le immagini e garantire che soddisfino i requisiti di affidabilità dei contenuti. Se una distribuzione non rispetta i criteri impostati, il controller di ammissione blocca la distribuzione nel cluster.
Quali opzioni ho a disposizione per eseguire la scansione dei container in esecuzione alla ricerca di vulnerabilità?
È possibile installare soluzioni di terze parti nel proprio cluster, come Twistlock o StackRox per eseguire la scansione dei container in esecuzione e bloccare le attività dannose non appena vengono rilevate.

Isolamento e sicurezza del contenitore

Quando esegui più applicazioni nel tuo cluster, vuoi assicurarti che i tuoi carichi di lavoro vengano eseguiti isolati l'uno dall'altro e di limitare le autorizzazioni dei pod all'interno del cluster per evitare elementi di disturbo o attacchi DoS (denial-of-service).

Che cos’è uno spazio dei nomi “ Kubernetes ” e perché dovrei utilizzarlo?
Gli spazi dei nomi Kubernetes sono un modo per partizionare virtualmente un cluster e fornire l'isolamento per le tue distribuzioni e i gruppi di utenti che desiderano spostare il loro carico di lavoro nel cluster. Con gli spazi dei nomi, puoi organizzare le risorse nei nodi di lavoro e anche nelle zone nei cluster multizona.
Ogni cluster è configurato con una serie di spazi dei nomi Kubernetes predefiniti che includono distribuzioni e servizi necessari affinché IBM Cloud Kubernetes Service venga eseguito correttamente e gestisca il cluster. Per ulteriori informazioni, vedi l'architettura del servizio.
Gli amministratori del cluster hanno automaticamente accesso a questi spazi dei nomi e possono configurare ulteriori spazi dei nomi nel cluster.

Per ogni namespace presente nel cluster, assicurati di configurare politiche RBAC adeguate per limitare l'accesso a tale namespace, controllare cosa viene distribuito e impostare quote di risorse e intervalli di limite appropriati.

È meglio configurare un cluster a tenant singolo o multi-tenant?

In un cluster a singolo tenant, crei un singolo cluster per ogni gruppo di persone che deve eseguire dei carichi di lavoro in un cluster. Di norma, questo team è responsabile della gestione del cluster e della sua adeguata configurazione e protezione. I cluster a più tenant utilizzano più spazi dei nomi per isolare i tenant e i loro carichi di lavoro.

Scegliere tra un cluster a tenant singolo o multi-tenant.
Cluster a tenant singolo contro cluster multi-tenant

Decidere tra i cluster a singolo tenant e multitenant dipende dal numero di team che devono eseguire carichi di lavoro in un cluster, dai loro requisiti di sistema, dalla dimensione del servizio e dal livello di isolamento che vuoi raggiungere per i tuoi carichi di lavoro.

Un cluster a singolo tenant potrebbe essere la tua opzione se hai molti team con servizi complessi e ciascuno di essi deve avere il controllo sul ciclo di vita del cluster. Ciò include la libertà di decidere quando viene aggiornato un cluster o quali risorse possono essere distribuite al cluster. Puoi anche configurare un cluster multitenant per consentire dei pod privilegiati senza mettere altri tenant a rischio di essere compromessi. Tieni presente che la gestione di un cluster richiede una conoscenza approfondita dell'infrastruttura e di Kubernetes per garantire la capacità e la sicurezza per le tue distribuzioni.

I cluster multitenant utilizzano gli spazi dei nomi Kubernetes per isolare i tenant e sono di norma gestiti da un team separato che non appartiene a uno dei tenant. Un cluster multitenant può essere la tua opzione se hai più team che devono eseguire dei piccoli carichi di lavoro in un cluster e in situazioni in cui creare un cluster a singolo tenant che sia altamente disponibile nell'ambito di più zone non porti i vantaggi in termini di costi da te desiderati. Se da una parte richiedono meno persone impegnate nella sua gestione e amministrazione, i cluster multitenant potrebbero non fornire il livello di isolamento che desideri e aggiungere maggiore complessità nelle seguenti aree:

  • Accesso: quando configuri più spazi dei nomi, devi configurare le appropriate politiche RBAC per ogni spazio dei nomi per garantire l'isolamento delle risorse. Le politiche RBAC sono complesse e richiedono una conoscenza approfondita di Kubernetes.
  • Pod privilegiati: se un tenant in un cluster multitenant richiede di eseguire pod privilegiati, tali pod possono accedere ad altri spazi dei nomi nel cluster oppure danneggiare l'host di calcolo condiviso. Controllare i pod privilegiati è un'attività complessa che richiede sforzo e competenze tecniche approfondite. Utilizza le politiche di sicurezza dei pod (PSP) per controllare quali risorse i tuoi tenant possono distribuire nel cluster.
  • Politiche di rete: poiché i nodi di lavoro sono collegati alla stessa rete privata, è necessario assicurarsi di disporre di politiche di rete rigorose per impedire ai pod di accedere a pod presenti in altri namespace.
  • Limiti delle risorse di calcolo: per garantire che ogni team disponga delle risorse necessarie per distribuire servizi ed eseguire applicazioni nel cluster, è necessario configurare le quote delle risorse per ogni namespace. Le quote delle risorse determinano i vincoli di distribuzione, quali il numero di risorse Kubernetes che è possibile distribuire e la quantità di CPU e memoria che tali risorse possono consumare. Dopo che hai impostato una quota, gli utenti devono includere le richieste di risorse e i limiti nelle loro distribuzioni.
  • Risorse cluster condivise: se esegui più tenant in un singolo cluster, alcune risorse cluster, quali l'ALB (application load balancer) Ingress o gli indirizzi IP portatili disponibili, vengono condivise tra i tenant. I servizi più piccoli potrebbero avere difficoltà a utilizzare le risorse condivise se devono competere con servizi di grandi dimensioni nel cluster.
  • Aggiornamenti: puoi eseguire una sola versione API Kubernetes alla volta. Tutte le applicazioni che vengono eseguite in un cluster devono conformarsi alla versione API Kubernetes attuale, indipendentemente dal team proprietario dell'applicazione. Quando vuoi aggiornare un cluster, devi assicurarti che tutti i team siano pronti a passare a una nuova versione API Kubernetes e che le applicazioni vengano aggiornate di conseguenza. Questo significa anche che i singoli team hanno meno controllo sulla versione API Kubernetes che vogliono eseguire.
  • Modifiche nella configurazione del cluster: se vuoi modificare la configurazione del cluster o ripianificare i carichi di lavoro su nuovi nodi di lavoro, devi distribuire tale modifica tra i tenant. Questa distribuzione richiede più riconciliazione e test che in un cluster a singolo tenant.
  • Processo di comunicazione: quando gestisci più tenant, considera l'impostazione di un processo di comunicazione per consentire ai tenant di sapere dove andare quando si verifica un problema con il cluster o quando hanno bisogno di più risorse per i loro servizi. Questo processo di comunicazione include anche l'informare i tuoi tenant delle modifiche nella configurazione del cluster o degli aggiornamenti pianificati.

Anche se i cluster a singolo tenant e multitenant sono forniti a costi pressoché uguali, i cluster a singolo tenant forniscono un livello di isolamento più elevato rispetto agli spazi dei nomi in un cluster multitenant. Per un migliore isolamento del carico di lavoro, usa i cluster a singolo tenant.

Politiche di rete Kubernetes protegge i pod dal traffico di rete interno. Ad esempio, se la maggior parte o tutti i pod non richiedono l'accesso a specifici pod o servizi e vuoi assicurarti che i pod per impostazione predefinita non possano accedere a tali pod o servizi, puoi creare una politica di rete Kubernetes per bloccare il traffico in ingresso a questi pod o servizi. Le politiche di rete di Kubernetes possono anche aiutarti a implementare l'isolamento del carico di lavoro tra gli spazi dei nomi controllando il modo in cui i pod e i servizi in diversi spazi dei nomi possono comunicare.

Come posso gestire i permessi dei pod?
Per impostazione predefinita, ogni cluster abilita il controller di ammissione della politica di sicurezza dei pod " Kubernetes ", che è possibile utilizzare per definire i requisiti che un pod deve soddisfare per essere distribuito in uno spazio dei nomi. Con le politiche di sicurezza del pod, puoi controllare l'utilizzo di contenitori privilegiati, di spazi dei nomi root, di reti host e di porte, di tipi di volume, di file system host, di autorizzazioni Linux come ID di gruppo o di sola lettura.
Cos’altro posso fare per proteggere il mio container?
Limitare il numero di container con privilegi. I contenitori vengono eseguiti come un processo Linux separato sull'host di calcolo che è isolato da altri processi. Sebbene gli utenti abbiano accesso root all'interno del contenitore, le autorizzazioni di tali utenti sono limitate al di fuori del contenitore per proteggere gli altri processi Linux, i file system host e i dispositivi host. Per una corretta esecuzione, alcune applicazioni richiedono l'accesso al file system host o delle autorizzazioni avanzate. Puoi eseguire i contenitori in modalità privilegiata per consentire al contenitore lo stesso accesso dei processi in esecuzione sull'host di calcolo.
Tieni presente che i contenitori privilegiati possono causare notevoli danni al cluster e all'host di calcolo sottostante se vengono compromessi. Prova a limitare il numero di contenitori che vengono eseguiti in modalità privilegiata e considera la modifica della configurazione per la tua applicazione in modo che l'applicazione possa essere eseguita senza autorizzazioni avanzate.

Se desideri impedire l'esecuzione di container con privilegi nel tuo cluster, valuta la possibilità di configurare politiche di sicurezza personalizzate per i pod.

Applica le impostazioni di sicurezza del sistema operativo ai pod
È possibile aggiungere la sezione securityContext ai propri pod per controllare l'ID utente e l'ID gruppo autorizzati a eseguire operazioni all'interno del container, oppure l'ID utente e l'ID gruppo proprietari del percorso di montaggio del volume. L'impostazione di uno specifico ID utente consente di facilitare un modello di privilegi minimi. Se il contesto di sicurezza non specifica un utente, Kubernetes utilizza automaticamente l'utente specificato nell'immagine del contenitore.
Se si desidera utilizzare securityContext per impostare l'ID utente runAsUser o l'ID gruppo fsGroup, si consiglia di utilizzare lo storage a blocchi al momento della creazione dello storage persistente. NFS Storage non supporta l' fsGroup, e l' runAsUser deve essere impostato a livello di container, non a livello di pod.
Imposta i limiti di CPU e memoria per i contenitori
Ogni contenitore richiede una specifica quantità di CPU e memoria per un avvio corretto e per continuare l'esecuzione. È possibile definire richieste di risorse e limiti di risors Kubernetes i per i propri container o pod, al fine di limitare la quantità di CPU e memoria che questi possono consumare. Se non vengono impostati dei limiti per CPU e memoria, e il contenitore è occupato, il contenitore utilizza tutte le risorse disponibili. Questo elevato consumo di risorse potrebbe influire su altri container presenti sul nodo di lavoro che non dispongono di risorse sufficienti per avviarsi o funzionare correttamente, esponendo il nodo di lavoro al rischio di attacchi denial-of-service.
Implementa l'autenticazione controllata dalle politiche
Puoi aggiungere un'annotazione Ingress alle tue distribuzioni per controllare l'accesso ai tuoi servizi e alle tue API. Utilizzando App ID e la sicurezza dichiarativa, puoi garantire l'autenticazione degli utenti e la convalida dei token.

Archiviazione delle informazioni personali

Sei responsabile per la garanzia delle tue informazioni personali nelle immagini del contenitore e nelle risorse Kubernetes. Le informazioni personali includono i tuoi nome, indirizzo, numero di telefono, indirizzo email o altre informazioni che potrebbero identificare, contattare o individuare te, i tuoi clienti o chiunque altro.

Utilizzo di un segreto Kubernetes per archiviare le informazioni personali

Archivia le informazioni personali solo nelle risorse Kubernetes progettate per contenere le informazioni personali. Ad esempio, non utilizzare il proprio nome nel nome di uno spazio dei nomi Kubernetes, di una distribuzione, di un servizio o di una mappa di configurazione. Per garantire una protezione e una crittografia adeguate, è consigliabile archiviare le informazioni personali nei “segreti ”.

Per la gestione centralizzata di tutti i segreti tra i cluster e l'iniezione a tempo di esecuzione dell'applicazione, provate a utilizzare IBM Cloud Secrets Manager.

Utilizza un imagePullSecret Kubernetes per archiviare le credenziali del registro.

Non archiviare le informazioni personali in immagini del contenitore o negli spazi dei nomi del registro. Per garantire una protezione e una crittografia adeguate, è consigliabile conservare le credenziali del registro Kubernetes imagePullSecrets e le altre informazioni personali nei segreti. Ricorda che se le informazioni personali sono archiviate in un livello precedente di un'immagine, l'eliminazione di un'immagine potrebbe non essere sufficiente per eliminare queste informazioni personali.

Per configurare la crittografia per i tuoi segreti, vedi Crittografia dei segreti Kubernetes utilizzando un provider KMS(key management service.

Bollettini di sicurezza di Kubernetes

Se vengono rilevate delle vulnerabilità in Kubernetes, quest'ultima rilascia delle CVE in bollettini di sicurezza per informare gli utenti e descrivere le azioni che devono eseguire per ovviare alla vulnerabilità. I bollettini di sicurezza di Kubernetes che interessano gli utenti IBM Cloud Kubernetes Service o la piattaforma IBM Cloud sono pubblicati nei Bollettini di sicurezza di IBM Cloud.

Alcune CVE richiedono l'aggiornamento patch più recente per una versione Kubernetes che puoi installare come parte del regolare processo di aggiornamento del cluster in IBM Cloud Kubernetes Service. Assicurati di applicare le patch di sicurezza in tempo per proteggere il tuo cluster da attacchi dolosi. Per ulteriori informazioni sui contenuti di una patch di sicurezza, consultare le informazioni sulla versione disponibili all'indirizzo Kubernetes.