This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

Sicurezza

Questo argomento fornisce una panoramica descrittiva generale della sicurezza di Tanzu Kubernetes Grid.

Introduzione

Tanzu Kubernetes Grid (TKG) consente un'esperienza coerente nativa di Kubernetes in qualsiasi cloud. Anche i controlli di sicurezza possono quindi essere applicati in modo coerente in tutti gli ambienti utilizzando diversi componenti predefiniti di TKG che consentono di ottenere una maggiore sicurezza per i cluster del carico di lavoro e il relativo ambiente sottostante. Il modello di responsabilità condivisa si applica anche per gli ambienti di protezione in cui vengono eseguiti i cluster con provisioning Tanzu Kubernetes Grid per tutti i livelli dello stack nativo del cloud: Codice, Container, Cluster e Cloud.

Questo documento è un tentativo di condividere la situazione attuale della sicurezza di TKG. In ogni versione VMware si impegna per migliorare la sicurezza di TKG, con l'obiettivo di rendere la sicurezza parte intrinseca del prodotto, mantenendo un'esperienza di sviluppo ottimale. Tutte le raccomandazioni del presente documento devono essere prese in considerazione in base al comportamento di sicurezza e al grado di rischio dell'azienda.

I dettagli della sicurezza di TKG distribuito con un supervisore di vSphere with Tanzu sono diversi da quelli di TKG distribuito con un cluster di gestione autonomo. Nella documentazione di vSphere with Tanzu, raggiungibile tramite il collegamento seguente, è disponibile la storia della sicurezza delle distribuzioni basate su supervisore. Il resto di questo argomento descrive le distribuzioni di TKG con cluster di gestione autonomi.

Sicurezza del supervisore di vSphere with Tanzu

Tanzu Kubernetes Grid v2.0 in vSphere 8 con supervisore è un modulo aggiuntivo di vSphere. Sfrutta molte funzionalità di vSphere, tra cui la sicurezza di vSphere e vCenter SSO. Per ulteriori informazioni sulla sicurezza di Tanzu Kubernetes Grid v2.0, vedere Sicurezza di vSphere with Tanzu nella documentazione di vSphere 8.

Questo documento riguarda solo l'offerta multi-cloud Tanzu Kubernetes Grid. La documentazione ufficiale del prodotto e le differenze con le altre offerte sono descritte qui.

Per le linee guida della sicurezza delle altre offerte di VMware Tanzu, vedere:

Sicurezza del cluster di gestione autonomo

Le sezioni seguenti descrivono la sicurezza all'interno e all'esterno di TKG distribuito con un cluster di gestione autonomo. Gli argomenti includono i controlli di sicurezza disponibili per l'uso integrati nel prodotto e le procedure consigliate per implementare controlli di sicurezza complementari che proteggono gli ambienti in cui sono distribuiti i cluster Tanzu Kubernetes Grid.

Codice

Tanzu Kubernetes Grid esegue il codice scritto dagli sviluppatori di applicazioni, distribuito come pod Kubernetes. Tanzu Kubernetes Grid è costituito da componenti diversi, molti dei quali sono open source e alcuni proprietari di VMware. Se il codice di tutte queste applicazioni e componenti è sicuro, migliora il comportamento di protezione dell'ambiente che esegue i cluster con provisioning di Tanzu Kubernetes Grid.

Tanzu Kubernetes Grid è sviluppato in conformità con il Processo VMware Security Development Lifecycle. In particolare, vengono implementate le seguenti procedure consigliate per garantire la sicurezza del prodotto Tanzu Kubernetes Grid:

  • Revisione del modello delle minacce per ogni cambiamento di progettazione importante nel prodotto.

  • Risoluzione dei problemi con priorità alta per i risultati ottenuti nell'ambito dell'esercizio della modellazione delle minacce.

  • Build automatizzate per tutti i componenti principali di Tanzu Kubernetes Grid per compilarli dal codice sorgente.

  • Partecipazione in upstream per le correzioni relative a sicurezza, gestione della release e valutazione delle vulnerabilità.

  • Per il codice proprietario VMware prima dell'unione al ramo main:

    • Implementazione delle revisioni del codice peer per garantire un doppio controllo.

    • Esecuzione della scansione automatica del codice statico utilizzando strumenti come golint, gosec govet.

  • Firma di file binari come kubectl o tanzu-cli con le chiavi di firma VMware.

Per proteggere il codice delle app containerizzate in esecuzione in Tanzu Kubernetes Grid, le seguenti risorse possono essere utili come riferimento:

Container

I container vengono istanziati come processi isolati dello spazio dei nomi Linux, utilizzando immagini preconfezionate che sono essenzialmente tarball di tutte le dipendenze di runtime e binarie dell'app per eseguire l'applicazione containerizzata. Tanzu Kubernetes Grid esegue questi container come parte dei pod Kubernetes. Molti componenti di Tanzu Kubernetes Grid sono anche inclusi nel pacchetto come immagini del container e sono configurati per essere eseguiti come pod (a volte come daemonset Kubernetes o pod statici). Le seguenti procedure consigliate sono implementate per proteggere i container dei componenti di Tanzu Kubernetes Grid:

  • Scansionare tutte le immagini del container con lo scanner di vulnerabilità per Common Vulnerability and Exposures (CVE) durante push nel registro del container di staging.

  • Limitare l'accesso push al registro del container rivolto all'esterno al team di rilascio di Tanzu Kubernetes Grid in base al principio del privilegio minimo.

  • Utilizzare un servizio gestito centralmente (LDAP), o un account robot, che automatizza il push di immagini del container dallo staging alla produzione dopo il completamento dei criteri di rilascio del test appropriato.

  • Eseguire una valutazione dell'impatto interno che documenti le vulnerabilità critiche non corrette nelle immagini dei container.

  • Correggere le vulnerabilità con un impatto significativo sul prodotto [1][2] senza dover attendere la prossima versione secondaria.

  • Aggiornare regolarmente i componenti di Tanzu Kubernetes Grid con le immagini di base più recenti per ottenere correzioni per le vulnerabilità appena identificate.

  • Preferire immagini minime per tutti i componenti Tanzu Kubernetes Grid, se possibile, e limitare le distribuzioni delle immagini di base a un numero ridotto per ridurre l'area di superficie di installazione delle patch per tutte le immagini.

Per creare, eseguire e utilizzare le immagini del container in modo sicuro in generale, le seguenti risorse sono una guida utile:

Aggiornamenti del sistema operativo e versioni dell'immagine del nodo

VMware racchiude immagini del sistema operativo della macchina base con versioni in Tanzu Kubernetes (TKr), oltre alle versioni compatibili di Kubernetes e ai componenti di supporto. Tanzu Kubernetes Grid utilizza quindi questi sistemi operativi, Kubernetes e versioni dei componenti incluse nel pacchetto per creare nodi del cluster e del piano di controllo. Per ulteriori informazioni, vedere Versioni di Tanzu Kubernetes e immagini dei nodi personalizzate.

Ogni TKR pubblicato utilizza l'aggiornamento stabile più recente e generalmente disponibile della versione del sistema operativo che racchiude, contenente tutte le correzioni CVE e USN correnti, a partire dal giorno in cui l'immagine viene creata. VMware rigenera queste immagini del nodo, immagini vSphere OVA, AMI AWS e Azure VM, con ogni versione di Tanzu Kubernetes Grid e, probabilmente, con una maggiore frequenza. I file di immagine sono firmati da VMware e hanno nomi di file che contengono un identificatore di codice hash univoco.

Quando viene segnalato un CVE critico o ad alta priorità, VMware collabora per una correzione e, quando la correzione viene pubblicata, rigenera tutte le immagini dei nodi interessati e le immagini di base dei container, per includere l'aggiornamento.

Versioni abilitate per FIPS

È possibile installare ed eseguire versioni di Tanzu Kubernetes Grid v2.1.0 e v2.1.1 abilitate per FIPS, in cui i componenti principali utilizzano primitive crittografiche fornite da una libreria abilitata per FIPS in base al modulo BoringCrypto/Boring SSL. Questi componenti principali includono componenti di Kubernetes, Containerd e CRI, plug-in CNI, CoreDNS ed etcd.

Per informazioni su come installare Tanzu Kubernetes Grid v2.1 abilitata per FIPS, vedere Versioni compatibili con FIPS nella documentazione di TKG v2.1.

Cluster

Un cluster Kubernetes è costituito da diversi componenti che fungono da piano di controllo del cluster e da un set di componenti di supporto e nodi worker che consentono di eseguire carichi di lavoro distribuiti. Esistono due tipi di cluster nella configurazione di Tanzu Kubernetes Grid, ovvero il cluster di gestione e il cluster del carico di lavoro. Il cluster di gestione Tanzu Kubernetes Grid ospita tutti i componenti di Tanzu Kubernetes Grid utilizzati per gestire i cluster dei carichi di lavoro. I cluster dei carichi di lavoro attivati tramite gli amministratori di Tanzu Kubernetes Grid vengono quindi utilizzati per eseguire le applicazioni containerizzate. La sicurezza del cluster è una responsabilità condivisa tra gli amministratori, gli sviluppatori e gli operatori del cluster Tanzu Kubernetes Grid che eseguono app nei cluster con provisioning di Tanzu Kubernetes Grid. Questa sezione enumera i componenti inclusi con Tanzu Kubernetes Grid per impostazione predefinita, che può aiutare a implementare procedure consigliate sicure sia per i cluster di gestione sia per i cluster dei carichi di lavoro.

Gestione di identità e accessi

Tanzu Kubernetes Grid dispone di un pacchetto Pinniped che consente l'accesso sicuro ai cluster Kubernetes, come descritto in Gestione di identità e accessi.

Gli operatori Tanzu Kubernetes Grid sono ancora responsabili della concessione dell'accesso alle risorse del cluster ad altri utenti di Kubernetes tramite il controllo integrato degli accessi basato sui ruoli. Le procedure consigliate per la gestione delle identità nei cluster sottoposti a provisioning con Tanzu Kubernetes Grid sono le seguenti:

  • Limitare l'accesso alle risorse del cluster in base al principio del privilegio minimo.

  • Limitare l'accesso ai cluster di gestione al set di utenti appropriato. Ad esempio, fornire l'accesso solo agli utenti responsabili della gestione delle risorse cloud e dell'infrastruttura, ma non agli sviluppatori di applicazioni. Ciò è particolarmente importante perché l'accesso al cluster di gestione fornisce implicitamente l'accesso a tutti i cluster dei carichi di lavoro.

  • Limitare l'accesso degli amministratori del cluster per i cluster dei carichi di lavoro al set di utenti appropriato. Ad esempio, agli utenti responsabili della gestione delle risorse dell'infrastruttura e della piattaforma nell'azienda, ma non agli sviluppatori di applicazioni.

  • Con Pinniped, connettersi a un fornitore di identità centralizzato per gestire le identità utente autorizzate ad accedere alle risorse del cluster anziché affidarsi ai file kubeconfig generati.

Multi-tenancy

Uno dei vantaggi principali di Tanzu Kubernetes Grid è la possibilità di gestire l'intero ciclo di vita di più cluster tramite un singolo piano di gestione. Ciò è importante perché da un punto di vista multi-tenancy, è possibile la forma più elevata di isolamento tra carichi di lavoro non attendibili quando vengono eseguiti in cluster Kubernetes separati. Questi sono alcuni dei valori predefiniti configurati per supportare carichi di lavoro multi-tenant in Tanzu Kubernetes Grid:

  • I nodi non vengono condivisi tra i cluster.

  • I nodi sono configurati per ospitare solo carichi di lavoro del container.

  • Il piano di gestione viene eseguito nel proprio cluster dedicato per consentire la separazione dei problemi relativi ai cluster dei carichi di lavoro.

  • I componenti di gestione Kubernetes come api-server, scheduler, controller-manager e così via, vengono eseguiti nei nodi dedicati. È inoltre consigliabile applicare una regola di controllo per rilevare la distribuzione di qualsiasi pod del carico di lavoro per controllare i nodi del piano.

  • La pianificazione del pod dell'applicazione in nodi dedicati per i componenti di gestione (indicati in precedenza) è disattivata tramite i taint dei nodi e le regole di affinità.

Per migliorare la sicurezza in un ambiente AWS multi-tenant, distribuire i cluster dei carichi di lavoro in un account AWS diverso da quello utilizzato per distribuire il cluster di gestione. Per distribuire i cluster dei carichi di lavoro in più account AWS, vedere Cluster in account AWS diversi.

Per informazioni più dettagliate sulle considerazioni relative alla progettazione durante la distribuzione in ambienti multi-tenant, vedere Tenancy del carico di lavoro.

Isolamento del carico di lavoro

I requisiti di isolamento del carico di lavoro sono univoci per ogni cliente. Pertanto, per isolare ragionevolmente i carichi di lavoro l'uno dall'altro con una tolleranza di rischio accettabile, è necessario un ulteriore sforzo in linea con il modello di responsabilità condivisa. Ciò include la limitazione del numero di container che devono essere eseguiti con privilegi più elevati ad alcuni spazi dei nomi e l'implementazione di meccanismi di difesa approfondita come AppArmor e SELinux a livello di runtime, pod e nodo. In Tanzu Kubernetes Grid 1.6 e versioni successive, AppArmor è abilitato per impostazione predefinita nelle immagini di Ubuntu 20.04.

Queste configurazioni possono essere applicate centralmente nei pod tramite i controller di ammissione sicurezza pod.

Per i casi d'uso avanzati e la gestione dei criteri personalizzati, in generale le seguenti risorse fungono da punto di partenza valido: OPA, Controllo ammissione e Standard di sicurezza pod

Proteggere la comunicazione tra i servizi

Uno degli aspetti fondamentali di un'architettura di microservizi è la creazione di servizi che fanno solo una cosa. In questo modo è possibile separare i problemi e consentire ai team di procedere più rapidamente. Tuttavia, ciò aumenta anche la necessità di comunicare con diversi microservizi che sono spesso in esecuzione nello stesso cluster nei propri pod. Pertanto, considerare le seguenti procedure consigliate per proteggere queste comunicazioni in runtime:

  • Criteri di rete con privilegi minimi: Antrea è il plug-in CNI predefinito abilitato in Tanzu Kubernetes Grid. Per ulteriori informazioni su come utilizzarlo per implementare i criteri di rete che possono essere applicati in base al comportamento di rischio, consultare i documenti ufficiali di Antrea. Per utilizzare un plug-in CNI diverso, seguire questa guida: Rete di pod e container

  • TLS reciproca per impostazione predefinita: Questa implementazione è una responsabilità dei clienti di Tanzu Kubernetes Grid. È possibile implementare questa funzionalità come parte del manifesto dell'applicazione o utilizzando un mesh servizio che consente a un container sidecar di gestire la comunicazione TLS per il container delle app.

  • Proteggere i segreti: è possibile scegliere tra diverse opzioni quando si gestiscono i segreti in un cluster Kubernetes. Per un rapido riepilogo delle opzioni, vedere Gestione dei segreti.

Controllo, registrazione e monitoraggio

Per garantire l'osservabilità e il ripudio delle risorse del cluster, inclusi i pod delle applicazioni, è importante attivare il controllo e il monitoraggio dei cluster con provisioning di Tanzu Kubernetes Grid. Tanzu Kubernetes Grid è dotato di una serie di estensioni che consentono agli amministratori di effettuare l'attivazione in modo nativo. Le guide seguenti lo spiegano in dettaglio:

  1. Registrazione di controllo del server API e del sistema: come abilitare la registrazione di controllo del server API e il controllo a livello di sistema (nodo) per impedire il ripudio dell'utilizzo del cluster. Tanzu Kubernetes Grid include un criterio predefinito per il controllo del server API. È consigliabile impostare un criterio appropriato per il daemon di controllo a livello di nodo per garantire il rilevamento della manomissione dei file binari di runtime del container e della configurazione.

  2. Inoltro dei registri con Fluent Bit: come attivare la raccolta centralizzata dei registri in modo da evitare la perdita del ripudio a causa della manomissione locale dei registri.

  3. Monitoraggio con Prometheus e Grafana: come attivare l'osservabilità delle metriche di cluster e di sistema per gli avvisi e la visualizzazione che possono rilevare picchi improvvisi nel consumo di risorse a causa degli attacchi DoS (Denial of Service).

In base alla minaccia pertinente descritta, qualsiasi o tutti i controlli precedenti possono essere applicati a un cluster Tanzu Kubernetes Grid.

Provider di servizi cloud

I provider di servizi cloud agiscono come risorsa underlay per tutti i cluster Kubernetes con provisioning Tanzu Kubernetes Grid, indipendentemente dal fatto che sia una distribuzione locale (ad esempio, vSphere) o un cloud pubblico (ad esempio, AWS, Azure o Google Cloud). La protezione dell'infrastruttura sottostante è in genere una responsabilità condivisa tra i clienti di Tanzu Kubernetes Grid e i provider di servizi cloud. Di seguito vi sono alcuni consigli per migliorare la sicurezza del cloud sottostante ai cluster sottoposti a provisioning di Tanzu Kubernetes Grid:

  • Ruotare o aggiornare regolarmente le credenziali cloud utilizzando questa guida (solo vSphere): Segreti dei cluster Tanzu (se si automatizza la rotazione, valutare di effettuare il test in ambienti non di produzione per osservare e pianificare eventuali interruzioni dell'attività che potrebbe causare).

  • Applicare le autorizzazioni con privilegi minimi per le credenziali cloud come descritto nella documentazione di per i provider AWS, Azure e vSphere. Quando possibile, eseguire cluster di gestione e carichi di lavoro in zone separate (VPC) e di firewall. Questa è l'impostazione predefinita per i cluster sottoposti a provisioning di Tanzu Kubernetes Grid.

  • L'accesso al nodo SSH, specialmente ai nodi del piano di controllo, deve essere limitato a un piccolo gruppo di utenti che svolge il ruolo di amministratore dell'infrastruttura.

  • L'accesso SSH deve essere utilizzato raramente, principalmente come procedura di emergenza in caso di perdita delle credenziali del cluster di gestione.

  • Verificare che le risorse del cluster non siano accessibili agli utenti non autenticati su Internet. I clienti con tolleranza di rischio bassa devono distribuire i cluster senza esporre la porta del server API a Internet con una configurazione del bilanciamento del carico appropriata.

  • Isolare l'ambiente Tanzu Kubernetes Grid (cluster di gestione e carico di lavoro) in VPC dedicati o dietro a un firewall da altri carichi di lavoro cloud non Tanzu, per limitare lo spostamento laterale e ridurre l'area di superficie di attacco nel caso di un cluster compromesso.

  • Applicare, testare e convalidare gli scenari di ripristino di emergenza per ridondanza e disponibilità in più regioni tra i cluster.

  • Implementare un piano di ripristino dopo una perdita di dati causata da dati corrotti, da attacchi ransomware o da errori naturali che causano danni all'hardware fisico.

  • È consigliabile utilizzare il backup e il ripristino nativi delle risorse cluster con Velero per semplificare la pianificazione del ripristino di emergenza e gli scenari di ripristino con perdita di dati.

Questi consigli si aggiungono alle linee guida generali sulla sicurezza per i provider di servizi cloud. Per istruzioni generali sulla sicurezza cloud, fare riferimento alla documentazione ufficiale sulla sicurezza del provider di servizi cloud pertinente.

In conclusione, questo documento fornisce un quadro generale dello stato corrente e dei controlli di sicurezza consigliati che possono essere applicati a Tanzu Kubernetes Grid. Ci impegniamo a fornire un servizio Tanzu Kubernetes Grid sempre più sicuro versione dopo versione, per avere un'esperienza di sviluppo agevole.

In caso di feedback sul documento o di richieste di funzionalità relative alla sicurezza, contattare il rappresentante VMware.

Riferimenti

Risorse della community upstream

Ecco alcune risorse correlate alla sicurezza basate sulla community (CNCF/Kubernetes) upstream:

Standard e linee guida di terze parti

Di seguito è riportato, in ordine sparso, un elenco di documenti pubblicati dagli organismi governativi e di normazione:

check-circle-line exclamation-circle-line close-line
Scroll to top icon