Sicurezza per il servizio Azure Kubernetes

Questo articolo illustra gli aspetti della governance della sicurezza del servizio Azure Kubernetes servizio Azure Kubernetes da considerare prima di implementare qualsiasi soluzione.

L'articolo è incentrato su come implementare soluzioni usando Azure e il software open source. Le decisioni prese quando si crea una zona di destinazione su scala aziendale possono parzialmente predefinito la governance. Per comprendere i principi di governance, vedere Governance e conformità della sicurezza su scala aziendale.

Superfici di attacco

Quando si crea una strategia di sicurezza per i cluster Kubernetes, considerare le cinque superfici di attacco seguenti:

• Build
• Registro
• Cluster
• Nodo
• Applicazione

Per ogni categoria vengono illustrati i principali rischi da considerare e contromisure per tali rischi.

Creare la sicurezza

La sicurezza della compilazione riguarda l'uso corretto di DevSecOps con le immagini del contenitore.

Principali rischi

Una configurazione di immagine scarsa può causare vulnerabilità di sicurezza nella pipeline. Ad esempio, potrebbero essere presenti contenitori in esecuzione con privilegi maggiori di quelli necessari. I contenitori potrebbero anche essere configurati per consentire un certo accesso alla rete e questo potrebbe mettere a rischio il sistema. La mancata limitazione delle chiamate di sistema consentite a tali chiamate necessarie per il funzionamento sicuro dei contenitori può aumentare il rischio di un contenitore compromesso.

Un'altra vulnerabilità potrebbe consentire al contenitore di accedere a una directory sensibile dell'host o consentire ai contenitori di modificare i percorsi che controllano la funzione di base dell'host.

I contenitori non autorizzati sono contenitori non pianificati in un ambiente. Possono essere il risultato dei test del codice negli ambienti di test. Questi contenitori potrebbero non aver eseguito un'analisi rigorosa delle vulnerabilità o essere configurati correttamente. Queste vulnerabilità potrebbero di fatto costituire un punto di ingresso per utenti malintenzionati.

L'uso di immagini di base non provenienti da origini attendibili o non aggiornate con gli aggiornamenti della sicurezza può anche causare vulnerabilità nei contenitori usati per la compilazione.

Contromisure di rischio

La sicurezza della compilazione riguarda l'implementazione di DevSecOps per spostare la sicurezza verso sinistra e correggere la maggior parte dei problemi prima che inizino a spostarsi verso il basso nella pipeline. Non si tratta di attribuire tutta la proprietà agli sviluppatori, ma di condividerla con il team delle operazioni. Gli sviluppatori possono quindi identificare e correggere le vulnerabilità e i problemi di conformità che possono effettivamente risolvere.

È possibile creare una pipeline che esegue l'analisi e non riesce a compilare perché presenta una o 10 vulnerabilità critiche. Un approccio migliore potrebbe essere quello di esaminare il livello successivo verso il basso. È possibile iniziare a segmentare il punto di responsabilità in base allo stato del fornitore.

Impostare una soglia a livello di stato della vulnerabilità. Qualsiasi elemento con stato Open, Will not fix o Deferred continua a fluire verso il basso nella pipeline in cui SecOps può accedere al rischio, come fanno oggi. Una vulnerabilità con lo stato delle correzioni fornitore disponibili è un elemento che uno sviluppatore può risolvere. L'uso dei periodi di tolleranza consente agli sviluppatori di correggere le vulnerabilità.

Insieme alla valutazione della vulnerabilità è la valutazione della conformità. Ad esempio, consentire a un'immagine di eseguire come radice o esporre SSH interrompe il comportamento di conformità della maggior parte delle aziende. Risolvere questo problema durante la compilazione anziché durante la distribuzione.

In genere, si analizzano le immagini con il benchmark CIS docker. Quando si usano questi tipi di flussi, non si interrompe lo sviluppo introducendo la correzione della sicurezza, ma è possibile migliorare il livello generale della postura di sicurezza dell'azienda.

L'uso di uno strumento che abiliti queste funzionalità è fondamentale per implementare in modo efficace la strategia appropriata per l'azienda. Gli strumenti tradizionali spesso non sono in grado di rilevare le vulnerabilità all'interno dei contenitori, che possono causare un falso senso di sicurezza. Sono necessari strumenti che prendono in considerazione l'approccio di compilazione basato su pipeline e la natura non modificabile e dichiarativa delle tecnologie dei contenitori per proteggere correttamente l'ecosistema di contenitori.

Questi strumenti devono avere le proprietà seguenti:

• Integrazione con l'intera durata delle immagini, dall'inizio del processo di compilazione al Registro di sistema al runtime.
• Visibilità delle vulnerabilità a tutti i livelli dell'immagine, incluso il livello di base dell'immagine, i framework dell'applicazione e il software personalizzato.
• Applicazione basata su criteri con il livello di granularità corretto, che consente all'organizzazione di creare controlli di qualità in ogni fase dei processi di compilazione e distribuzione.

Sicurezza del registro

La sicurezza del registro riguarda:

• Controllo deriva dalla compilazione.
• Prevenzione del push/pull di immagini contaminate.
• Firma dell'immagine.

Principali rischi

Le immagini contengono spesso informazioni proprietarie, incluso il codice sorgente di un'organizzazione. Se le connessioni ai registri non sono sicure in modo appropriato, il contenuto di un'immagine potrebbe comportare rischi di riservatezza come qualsiasi altra forma di dati trasmessi all'interno dell'organizzazione. Le immagini non aggiornate con versioni obsolete vulnerabili nel Registro di sistema possono aumentare i rischi per la sicurezza se vengono distribuiti accidentalmente.

Un'altra vulnerabilità di sicurezza potrebbe includere restrizioni di autenticazione e autorizzazione insufficienti per i registri contenitori. Questi registri possono ospitare asset proprietari sensibili nelle immagini.

Man mano che il contenuto viene compilato e distribuito, la distribuzione di questo contenuto è uno dei molti vettori di attacco. Come assicurarsi che il contenuto temporaneamente per la distribuzione sia lo stesso contenuto recapitato a un endpoint previsto?

Contromisure di rischio

Configurare i processi di distribuzione per assicurarsi che gli strumenti di sviluppo, le reti e i runtime dei contenitori siano connessi ai registri solo tramite canali crittografati. Assicurarsi anche che il contenuto provenga da un'origine attendibile. Per ridurre i rischi derivanti dall'uso di immagini non aggiornati:

• Rimuovere immagini non sicure e vulnerabili che non devono più essere usate dai registri contenitori.
• Applicare l'accesso alle immagini usando nomi non modificabili che specificano versioni specifiche delle immagini da usare. È possibile implementare questa configurazione usando un tag più recente o una versione specifica delle immagini. Un tag non garantisce la validità della versione. Per questo motivo, inserire un processo per assicurarsi che l'agente di orchestrazione Kubernetes usi i numeri univoci più recenti o che il tag più recente rappresenti le versioni più aggiornate.

L'accesso ai registri che contengono immagini sensibili deve richiedere l'autenticazione e l'autorizzazione. L'autenticazione deve essere richiesta anche per tutti gli accessi in scrittura. Ad esempio, i criteri potrebbero consentire agli sviluppatori di eseguire il push delle immagini solo nei repository specifici per i quali sono responsabili.

L'accesso a questi registri deve essere federato e sfruttare i criteri di accesso a livello di business. Ad esempio, è possibile configurare la pipeline CI/CD per eseguire il push delle immagini nei repository solo dopo aver superato i test di verifica della conformità e del controllo qualità della vulnerabilità.

I registri contenitori ora considerati registri artefatti stanno diventando un mezzo primario per distribuire qualsiasi tipo di contenuto, non solo le immagini del contenitore. Ogni cloud fornisce un registro con progetti open source e prodotti fornitore disponibili per l'hosting locale o privato all'interno dei provider di servizi cloud. Il contenuto viene alzato di livello all'interno e tra registri dalla compilazione iniziale alla distribuzione di produzione.

Come è possibile garantire l'integrità del contenuto inserito nel Registro di sistema è lo stesso contenuto che esce dal Registro di sistema? L'adozione di una soluzione di firma delle immagini garantisce che le distribuzioni provenano solo da registri attendibili e distribuiscano contenuto attendibile.

Sicurezza del cluster

La sicurezza del cluster riguarda:

• Autenticazione e autorizzazione.
• Sicurezza di rete.
• Gestione delle vulnerabilità e della conformità.

Principali rischi

A volte un singolo cluster Kubernetes può essere usato per eseguire applicazioni diverse gestite da team diversi con requisiti a livello di accesso diversi. Se l'accesso viene concesso a utenti senza restrizioni o solo in base alle esigenze, un utente malintenzionato o incauto potrebbe compromettere i carichi di lavoro a cui ha accesso e altri asset nel cluster.

Un'altra vulnerabilità di sicurezza può verificarsi quando la directory utente del cluster gestisce l'autorizzazione e l'autenticazione. Una directory di autenticazione dell'organizzazione è spesso più controllata in modo rigoroso. Poiché questi account sono altamente privilegiati e più spesso orfani, le probabilità di un aumento di un account compromesso.

Questo scenario potrebbe causare vulnerabilità a livello di sistema o cluster. I dati archiviati dai volumi di contenitori vengono gestiti da agenti di orchestrazione, che devono avere accesso ai dati indipendentemente dal nodo in cui è ospitato.

I filtri di rete tradizionali potrebbero avere una cecità di sicurezza a causa di una sovrimpressione di rete progettata per crittografare i dati in transito. Questa progettazione rende difficile monitorare il traffico all'interno del cluster, quindi potrebbero essere necessarie disposizioni speciali per monitorare i cluster Kubernetes.

Il traffico proveniente da applicazioni diverse che condividono lo stesso cluster potrebbe avere livelli di riservatezza diversi, ad esempio un sito Web pubblico e un'applicazione interna che esegue processi aziendali sensibili critici. La condivisione della stessa rete virtuale all'interno del cluster può causare la compromissione di dati sensibili, Ad esempio, un utente malintenzionato potrebbe usare la rete condivisa esposta a Internet per attaccare le applicazioni interne.

Proteggere i componenti che eseguono il cluster stesso da vulnerabilità e problemi di conformità. Assicurarsi di essere in esecuzione nella versione più recente possibile di Kubernetes per sfruttare i vantaggi della correzione.

Contromisure di rischio

L'accesso utente del cluster Kubernetes deve usare un modello di accesso con privilegi minimi. Concedere agli utenti l'accesso solo per eseguire azioni specifiche su host, contenitori e immagini specifici necessari per svolgere il proprio lavoro. I membri del team di test devono avere accesso limitato o nessun accesso ai contenitori nell'ambiente di produzione. Gli account utente con accesso a livello di cluster devono essere strettamente controllati e usati con moderazione.

Usare metodi di autenticazione avanzata come l'autenticazione a più fattori per proteggere l'accesso a questi account. Una directory utente dell'organizzazione deve essere usata per gestire i cluster tramite Single Sign-On anziché gli account utente specifici del cluster che potrebbero non avere lo stesso livello di criteri e controlli.

Usare i metodi di crittografia che consentono ai contenitori di accedere correttamente ai dati in qualsiasi host in cui sono in esecuzione i contenitori. Questi strumenti di crittografia devono impedire l'accesso non autorizzato ai dati da parte di altri contenitori anche all'interno dello stesso nodo che non devono avere accesso ad essi.

Configurare i cluster Kubernetes per separare il traffico di rete in reti virtuali o subnet discrete in base al livello di riservatezza. La segmentazione per ogni applicazione potrebbe anche essere possibile, ma la definizione di reti in base ai livelli di riservatezza potrebbe essere sufficiente. Ad esempio, le reti virtuali per le applicazioni rivolte ai clienti separate da quelle che servono applicazioni interne con traffico sensibile devono essere implementate almeno.

È possibile usare taints e tolleranze per isolare le distribuzioni in set specifici di nodi in base ai livelli di riservatezza. Evitare di ospitare carichi di lavoro altamente sensibili all'interno dello stesso nodo dei carichi di lavoro con sensibilità inferiore. L'uso di cluster gestiti separati costituisce un'opzione più sicura.

Segmentare i contenitori per scopo, sensibilità e comportamento dei thread per offrire una protezione aggiuntiva per i carichi di lavoro sensibili. Segmentando i contenitori in questo modo, è più difficile per un utente malintenzionato che ha ottenuto l'accesso a un segmento per ottenere l'accesso ad altri segmenti. Questa configurazione offre il vantaggio di garantire che i dati residui, ad esempio le cache o i montaggi di volumi, siano isolati dal livello di riservatezza.

I cluster Kubernetes devono essere configurati per:

• Fornire un ambiente sicuro per le applicazioni eseguite su di esse.
• Assicurarsi che i nodi vengano aggiunti in modo sicuro al cluster.
• Disporre di identità persistenti per garantire la sicurezza nel corso del ciclo di vita.
• Fornire informazioni in tempo reale e accurate sullo stato del cluster, inclusi la rete e i nodi al suo interno.

Deve essere facile isolare e rimuovere un nodo compromesso dal cluster senza influire sulle prestazioni del cluster. Il servizio Azure Kubernetes semplifica questa operazione.

Definire gli standard di configurazione del runtime del contenitore per garantire automaticamente la conformità. Esistono molti criteri all'interno di Azure che semplificano questo processo e anche gli utenti possono creare criteri personalizzati. Usare le funzionalità di sicurezza di Azure per valutare continuamente le impostazioni di configurazione nell'ambiente e applicarle attivamente.

Assicurarsi automaticamente che vengano risolte le vulnerabilità dei componenti Kubernetes. Usare ambienti separati per lo sviluppo, il test e la produzione, ognuno con i propri controlli e il controllo degli accessi in base al ruolo per la gestione dei contenitori. Associare la creazione di tutti i contenitori alle singole identità utente e deve essere registrata per il controllo. Questa configurazione consente di ridurre il rischio di contenitori non autorizzati.

Sicurezza del nodo

La sicurezza dei nodi riguarda:

• Protezione di runtime.
• Gestione delle vulnerabilità e della conformità.

Principali rischi

Un nodo di lavoro dispone di accesso con privilegi a tutti i componenti nel nodo. Gli utenti malintenzionati possono usare qualsiasi servizio accessibile dalla rete come punto di ingresso, quindi fornire l'accesso all'host da più punti può aumentare seriamente la superficie di attacco. Maggiore è la superficie di attacco, più è probabile che un utente malintenzionato ottenga l'accesso al nodo e al relativo sistema operativo.

I sistemi operativi specifici del contenitore, ad esempio quelli usati nei nodi del servizio Azure Kubernetes, hanno inoltre una superficie di attacco meno estesa perché non contengono librerie che consentono ai sistemi operativi normali di eseguire direttamente database e server Web. L'uso di un kernel condiviso comporta una superficie di attacco più grande per i contenitori in esecuzione nello stesso ambiente rispetto ai contenitori in macchine virtuali separate. Questo è il caso anche quando sono in uso sistemi operativi specifici del contenitore in esecuzione nei nodi del servizio Azure Kubernetes.

I sistemi operativi host forniscono componenti di sistema di base che possono comportare vulnerabilità e rischi di conformità. Poiché sono componenti di basso livello, le vulnerabilità e la configurazione possono influire su tutti i contenitori ospitati. Il servizio Azure Kubernetes protegge gli utenti assicurandosi che queste vulnerabilità vengano gestite tramite aggiornamenti regolari del sistema operativo nei nodi in esecuzione nel servizio Azure Kubernetes e il comportamento di conformità del nodo di lavoro viene mantenuto.

I diritti di accesso utente non corretti possono anche causare rischi per la sicurezza quando gli utenti accedono direttamente ai nodi per gestire i contenitori anziché tramite il piano di controllo del servizio Azure Kubernetes. L'accesso diretto può consentire all'utente di apportare modifiche aggiuntive alle applicazioni, oltre a quelle cui dovrebbe avere accesso.

I contenitori dannosi potrebbero inoltre causare la manomissione del file system del sistema operativo. Ad esempio, se un contenitore è autorizzato a montare una directory sensibile nel sistema operativo host, tale contenitore potrebbe apportare modifiche ai file. Le modifiche potrebbero influire sulla sicurezza di altri contenitori in esecuzione nell'host.

Contromisure di rischio

Limitare l'accesso ai nodi limitando l'accesso SSH.

L'uso del sistema operativo specifico del contenitore nei nodi del servizio Azure Kubernetes riduce in genere le superfici di attacco perché altri servizi e funzionalità sono disabilitati. Hanno anche file system di sola lettura e usano altre procedure di protezione avanzata del cluster per impostazione predefinita.

La piattaforma Azure applica automaticamente le patch di sicurezza del sistema operativo ai nodi di Linux e Windows durante la notte. Se un aggiornamento della sicurezza del sistema operativo Linux richiede un riavvio dell'host, non verrà riavviato automaticamente. Il servizio Azure Kubernetes fornisce meccanismi di riavvio per applicare queste patch specifiche.

Microsoft Defender per server non è applicabile per i nodi Linux e Windows del servizio Azure Kubernetes perché Microsoft gestisce il sistema operativo. Se non sono presenti altre macchine virtuali nella sottoscrizione in cui è distribuito il servizio Azure Kubernetes, è possibile disabilitare in modo sicuro Microsoft Defender per server.

Se l'ambiente è stato distribuito, inclusi i criteri di Azure consigliati per la zona di destinazione su scala aziendale, è possibile configurare un'esclusione per l'assegnazione dei criteri nel gruppo di gestione che consente automaticamente a Microsoft Defender per server di evitare costi non necessari.

Sicurezza delle applicazioni

La sicurezza delle applicazioni riguarda:

• Protezione di runtime.
• Gestione delle vulnerabilità e della conformità.

Principali rischi

Le immagini sono file che includono tutti i componenti necessari per eseguire un'applicazione. Quando le versioni più recenti di questi componenti vengono usate per creare immagini, potrebbero essere prive di vulnerabilità note al momento, ma possono cambiare rapidamente.

È necessario mantenere questi file aggiornati con le versioni più recenti perché gli sviluppatori di pacchetti identificano regolarmente le vulnerabilità di sicurezza. Aggiornare ulteriormente i contenitori aggiornando le immagini usate per creare i contenitori, a differenza delle applicazioni tradizionali, che in genere vengono aggiornate nell'host.

I file dannosi possono anche essere incorporati in un'immagine, che può quindi essere usata per attaccare altri contenitori o componenti del sistema. I contenitori di terze parti possono essere un possibile vettore di attacco. Dettagli specifici potrebbero essere sconosciuti su di essi e potrebbero perdere dati. Forse i contenitori non sono stati aggiornati con gli aggiornamenti della sicurezza necessari.

Un altro vettore di attacco è l'uso di segreti come password e stringa di connessione direttamente all'interno di un file system di immagini. Questa procedura può causare un rischio per la sicurezza perché chiunque abbia accesso all'immagine può ottenere l'accesso ai segreti.

Potrebbero esserci difetti nelle applicazioni stesse, ad esempio applicazioni vulnerabili allo scripting intersito o a SQL injection. In caso di difetti, la vulnerabilità potrebbe essere usata per consentire l'accesso non autorizzato a informazioni riservate all'interno di altri contenitori o persino del sistema operativo host.

Il runtime del contenitore del servizio Azure Kubernetes semplifica il monitoraggio delle vulnerabilità usando i vari strumenti di sicurezza disponibili in Azure. Per altre informazioni, vedere Introduzione a Microsoft Defender per Kubernetes.

È anche necessario controllare il traffico di rete in uscita inviato ai contenitori per assicurarsi che i contenitori non siano in grado di inviare traffico tra reti di diversi livelli di riservatezza, ad esempio ambienti che ospitano dati sicuri o a Internet. Azure semplifica questo controllo con le diverse funzionalità di sicurezza di rete e del servizio Azure Kubernetes.

Per impostazione predefinita, le utilità di pianificazione di Kubernetes si concentrano sulla scalabilità e sull'ottimizzazione della densità dei carichi di lavoro in esecuzione nei nodi. Potrebbero posizionare pod di diversi livelli di riservatezza nello stesso nodo solo perché l'host ha le risorse più disponibili. Questo scenario può potenzialmente causare eventi imprevisti di sicurezza quando gli utenti malintenzionati usano l'accesso ai carichi di lavoro pubblici per attaccare i contenitori che eseguono processi più sensibili nello stesso host. Un contenitore compromesso può essere usato anche per analizzare la rete allo scopo di individuare altre vulnerabilità che l'utente malintenzionato può sfruttare.

Contromisure di rischio

Non archiviare mai segreti nel codice dell'applicazione o nei file system. I segreti devono essere archiviati negli archivi chiavi e forniti ai contenitori in fase di esecuzione secondo necessità. Il servizio Azure Kubernetes può garantire che solo i contenitori che devono accedere a determinate chiavi possano accedervi e che questi segreti non vengano salvati in modo permanente su disco. Azure Key Vault può, ad esempio, archiviare in modo sicuro questi segreti e fornirli al cluster del servizio Azure Kubernetes secondo necessità. È anche semplice assicurarsi che questi segreti siano crittografati sia nell'archivio che in transito.

Evitare l'uso di immagini e registri non attendibili e assicurarsi che solo le immagini di set attendibili siano autorizzate a essere eseguite nei cluster. Per un approccio multilivello:

• Controllo centralizzato delle immagini e dei registri attendibili.
• Identificazione in modo discreto di ogni immagine in base alla firma di crittografia.
• Inserimento di criteri per assicurare che tutti gli host eseguano solo immagini provenienti dal set approvato.
• Convalida di queste firme prima dell'esecuzione.
• Monitoraggio e aggiornamento di queste immagini e di questi registri in caso di modifica delle vulnerabilità e dei requisiti di configurazione.

I profili di calcolo protetti devono essere usati per vincolare i contenitori e allocare in fase di esecuzione. È possibile creare profili personalizzati e passarli ai runtime dei contenitori per limitarne ulteriormente le funzionalità. Verificare almeno che i contenitori vengano eseguiti con i profili predefiniti. È consigliabile usare profili personalizzati e più limitati per i contenitori che eseguono applicazioni ad alto rischio.

Gli strumenti possono profilarsi automaticamente le applicazioni usando l'apprendimento comportamentale e rilevare anomalie. È possibile usare soluzioni di terze parti per rilevare anomalie in fase di esecuzione. Le anomalie possono includere eventi come:

• Esecuzione di processi o chiamate di sistema non valide o impreviste.
• Modifiche ai file di configurazione protetti e ai file binari.
• Scrive in percorsi e tipi di file imprevisti.
• Creazione di listener di rete imprevisti.
• Traffico inviato a destinazioni di rete impreviste.
• Archiviazione ed esecuzione di malware.

Microsoft Defender per Kubernetes sta attualmente investendo in quest'area.

I contenitori devono essere eseguiti con il file system radice in modalità di sola lettura per isolare le scritture nelle directory definite, che questi strumenti possono monitorare facilmente. Questa configurazione rende i contenitori più resilienti alla compromissione perché si isola la manomissione in queste posizioni specifiche. Possono essere facilmente separati dal resto dell'applicazione.

Considerazioni relative alla progettazione

Il servizio Azure Kubernetes include diverse interfacce per altri servizi di Azure, ad esempio Microsoft Entra ID, Archiviazione di Azure e Azure Rete virtuale. L'uso di questi servizi richiede particolare attenzione durante la fase di pianificazione. Il servizio Azure Kubernetes aggiunge ulteriore complessità in base alla quale è necessario considerare l'applicazione degli stessi meccanismi e controlli di conformità e governance della sicurezza degli altri componenti dell'ambiente dell'infrastruttura.

Ecco altre considerazioni relative alla progettazione per la conformità e la governance della sicurezza del servizio Azure Kubernetes:

• Se si crea un cluster del servizio Azure Kubernetes in una sottoscrizione distribuita in base alle procedure consigliate per la zona di destinazione su scala aziendale, acquisire familiarità con i criteri di Azure che i cluster erediteranno. Per altre informazioni, vedere Criteri inclusi nelle implementazioni di riferimento delle zone di destinazione di Azure.
• Decidere se il piano di controllo del cluster deve essere accessibile tramite Internet (è consigliabile restrizioni IP), ovvero l'impostazione predefinita o solo dall'interno della rete privata in Azure o in locale come cluster privato. Se l'organizzazione segue le procedure consigliate per la zona di destinazione su scala aziendale, il Corp gruppo di gestione ha un Criteri di Azure associato che forza i cluster a essere privati. Per altre informazioni, vedere Criteri inclusi nelle implementazioni di riferimento delle zone di destinazione di Azure.
• Valutare l'uso del modulo di sicurezza predefinito AppArmor di Linux per limitare le azioni che i contenitori possono eseguire, ad esempio lettura, scrittura, esecuzione o funzioni di sistema come il montaggio di file system. Ad esempio, tutte le sottoscrizioni hanno criteri di Azure che impediscono ai pod in tutti i cluster del servizio Azure Kubernetes di creare contenitori con privilegi. Per altre informazioni, vedere Criteri inclusi nelle implementazioni di riferimento delle zone di destinazione di Azure.
• Valutare l'uso di seccomp (modalità secure computing) a livello di processo per limitare le chiamate al processo che i contenitori possono eseguire. È il caso, ad esempio, dei criteri di Azure applicati come parte dell'implementazione generica della zona di destinazione su scala aziendale nel gruppo di gestione delle zone di destinazione per impedire che l'escalation dei privilegi del contenitore all'accesso radice usi seccomp tramite i criteri di Azure per Kubernetes.
• Decidere se il registro contenitori è accessibile tramite Internet o solo all'interno di una rete virtuale specifica. La disabilitazione dell'accesso a Internet in un registro contenitori può avere effetti negativi su altri sistemi che si basano sulla connettività pubblica per accedervi. Gli esempi includono pipeline di integrazione continua o Microsoft Defender per l'analisi delle immagini. Per altre informazioni, vedere Connettersi privatamente a un registro contenitori usando collegamento privato di Azure.
• Decidere se il registro contenitori privato è condiviso tra più zone di destinazione o se si distribuisce un registro contenitori dedicato in ogni sottoscrizione della zona di destinazione.
• Valutare la possibilità di usare una soluzione di sicurezza come Microsoft Defender per Kubernetes per il rilevamento delle minacce.
• Valutare la possibilità di analizzare le immagini del contenitore alla ricerca di vulnerabilità.
• Valutare la possibilità di disabilitare Microsoft Defender per server nella sottoscrizione del servizio Azure Kubernetes se non sono presenti macchine virtuali non del servizio Azure Kubernetes per evitare costi non necessari.

Suggerimenti per la progettazione

• Limitare l'accesso al file di configurazione del cluster Kubernetes usando il controllo degli accessi in base al ruolo di Azure.
• Proteggere l'accesso dei pod alle risorse. Concedere il minor numero possibile di autorizzazioni ed evitare l'uso dell'accesso radice o dell'escalation dei privilegi.
• Usare Entra ID dei carichi di lavoro con il servizio Azure Kubernetes e il provider di Azure Key Vault per il driver CSI dell'archivio segreti per proteggere segreti, certificati e stringa di connessione.
• Usare l'aggiornamento dell'immagine del nodo del servizio Azure Kubernetes per aggiornare le immagini dei nodi del cluster del servizio Azure Kubernetes, se possibile, o kured per automatizzare i riavvii dei nodi dopo l'applicazione degli aggiornamenti.
• Monitorare e applicare la configurazione usando il componente aggiuntivo Criteri di Azure per Kubernetes. Nelle sottoscrizioni distribuite in base alle procedure consigliate per le zone di destinazione su scala aziendale, questa configurazione avviene automaticamente tramite un Criteri di Azure distribuito a livello di gruppo di gestione.
• Visualizzare le raccomandazioni del servizio Azure Kubernetes in Microsoft Defender for Cloud.
• Usare Microsoft Defender per contenitori, la soluzione nativa del cloud per migliorare, monitorare e gestire la sicurezza dei cluster, dei contenitori e delle applicazioni.
• Distribuire un'istanza dedicata e privata di Registro Azure Container in ogni sottoscrizione della zona di destinazione.
• Usare collegamento privato per il Registro Container per connetterlo al servizio Azure Kubernetes.
• Analizzare le immagini per individuare le vulnerabilità con Gestione delle vulnerabilità di Microsoft Defender o qualsiasi altra soluzione di analisi delle immagini.

Importante

Microsoft Defender per il cloud l'analisi delle immagini non è compatibile con gli endpoint del Registro Container. Per altre informazioni, vedere Connettersi privatamente a un registro contenitori tramite collegamento privato.