Modifica

Usare gateway applicazione Controller in ingresso (AGIC) con un servizio Azure Kubernetes multi-tenant

Gateway applicazione di Azure
Insieme di credenziali chiave di Azure
Registro Azure Container
Servizio Azure Kubernetes
Azure Bastion

In questa soluzione, Web application firewall (WAF) di Azure offre protezione centralizzata per le applicazioni Web distribuite in un cluster multi-tenant servizio Azure Kubernetes (servizio Azure Kubernetes) da exploit e vulnerabilità comuni. Le applicazioni Web in esecuzione in un cluster servizio Azure Kubernetes del servizio Azure Kubernetes (AKS) e esposte tramite il controller di ingresso (AGIC) gateway applicazione possono essere protette da attacchi dannosi, ad esempio attacchi SQL injection e scripting tra siti, usando un criterio WAF nel gateway di app Azure lication. I criteri WAF nel gateway di app Azure lication sono preconfigurato con set di regole di base OWASP e possono essere modificati in altre versioni OWASP CRS supportate.

Architettura

Diagramma che mostra un diagramma di questa gateway applicazione soluzione Controller in ingresso.

Scaricare un file di Visio di questa architettura.

Workflow

Il modello di ARM complementare distribuisce una nuova rete virtuale con quattro subnet:

  • AksSubnet: ospita il cluster del servizio Azure Kubernetes
  • VmSubnet: ospita una macchina virtuale jump box ed endpoint privati
  • AppGatewaySubnet: ospita gateway applicazione livello WAF2.
  • AzureBastionSubnet: ospita Azure Bastion

Il cluster servizio Azure Kubernetes (servizio Azure Kubernetes) usa un'identità gestita definita dall'utente per creare risorse aggiuntive, ad esempio servizi di bilanciamento del carico e dischi gestiti in Azure. Il modello di ARM consente di distribuire un cluster del servizio Azure Kubernetes con le funzionalità seguenti:

Il cluster del servizio Azure Kubernetes è composto dagli elementi seguenti:

  • Un pool di nodi di sistema che ospita solo servizi e pod di sistema critici. I nodi di lavoro hanno un taint che impedisce la pianificazione di pod delle applicazioni in questo pool di nodi.
  • Un pool di nodi utente che ospita i carichi di lavoro e gli artefatti degli utenti.

Una macchina virtuale viene distribuita nella stessa rete virtuale che ospita il cluster del servizio Azure Kubernetes. Quando si distribuisce il servizio Azure Kubernetes come cluster privato, la macchina virtuale può essere usata dagli amministratori di sistema per gestire il cluster tramite lo strumento della riga di comando Kubernetes. I log di diagnostica di avvio della macchina virtuale vengono archiviati in un account di archiviazione di Azure.

Un host Azure Bastion offre connettività SSH sicura e trasparente alla macchina virtuale jump box, direttamente nel portale di Azure tramite SSL. Registro Azure Container viene usato per creare, archiviare e gestire le immagini e gli artefatti dei contenitori, ad esempio i grafici Helm.

L'architettura include un gateway applicazione usato dal controller in ingresso. Il gateway applicazione viene distribuito in una subnet dedicata ed esposto alla rete Internet pubblica tramite un indirizzo IP pubblico condiviso da tutti i carichi di lavoro dei tenant. Al gateway applicazione sono associati criteri di Web application firewall (WAF) a livello di radice e a livello di listener HTTP per proteggere i carichi di lavoro dei tenant da attacchi dannosi. I criteri sono configurati in modalità di prevenzione e usano OWASP 3.1 per bloccare le intrusioni e gli attacchi rilevati dalle regole. L'autore dell'attacco riceve un'eccezione di "accesso non autorizzato 403" e la connessione viene chiusa. La modalità di prevenzione registra questi attacchi nei log di WAF.

Un Key Vault viene usato come archivio segreto dai carichi di lavoro eseguiti nel servizio Azure Kubernetes per recuperare chiavi, certificati e segreti tramite una libreria client, il driver CSI dell'archivio di segreti o Dapr. Il collegamento privato di Azure consente ai carichi di lavoro del servizio Azure Kubernetes di accedere ai servizi PaaS di Azure, ad esempio Key Vault, tramite un endpoint privato nella rete virtuale.

La topologia di esempio include gli endpoint privati seguenti:

  • Un endpoint privato per l'account di archiviazione BLOB
  • Un endpoint privato per Registro Azure Container
  • Un endpoint privato per Key Vault
  • Se si sceglie di usare un cluster privato del servizio Azure Kubernetes, un endpoint privato per il server API del cluster Kubernetes

L'architettura include anche le zone di DNS privato seguenti per la risoluzione dei nomi del nome di dominio completo (FQDN) di un servizio PaaS all'indirizzo IP privato dell'endpoint privato associato:

  • Una zona DNS privata per la risoluzione dei nomi dell'endpoint privato per l'account di archiviazione BLOB di Azure
  • Una zona DNS privata per la risoluzione dei nomi dell'endpoint privato per Registro Azure Container
  • Una zona DNS privata per la risoluzione dei nomi dell'endpoint privato per Azure Key Vault
  • Se si distribuisce il cluster come privato, una zona DNS privata per la risoluzione dei nomi dell'endpoint privato per l'API del server Kubernetes

Tra la rete virtuale che ospita il cluster del servizio Azure Kubernetes e le precedenti zone DNS private è presente un collegamento di rete virtuale. Un'area di lavoro Log Analytics viene usata per raccogliere le metriche e i log di diagnostica dalle origini seguenti:

  • Cluster del servizio Azure Kubernetes
  • Macchina virtuale jump box
  • Gateway applicazione di Azure
  • Azure Key Vault
  • Gruppi di sicurezza di rete di Azure

Componenti

  • Registro Azure Container è un servizio gestito di registri Docker privato basato sull'applicazione open source Docker Registry 2.0. È possibile usare i registri contenitori di Azure con le pipeline di sviluppo e distribuzione di contenitori esistenti oppure usare Attività del Registro Azure Container per compilare immagini di contenitore in Azure. È possibile eseguire compilazioni su richiesta o automatizzare completamente le compilazioni con trigger quali i commit del codice sorgente e gli aggiornamenti delle immagini di base.

  • Il servizio Azure Kubernetes semplifica la distribuzione di un cluster Kubernetes gestito in Azure tramite l'offload del sovraccarico operativo in Azure. Come servizio Kubernetes ospitato, Azure gestisce attività critiche quali il monitoraggio dell'integrità e la manutenzione. Dal momento che i master Kubernetes sono gestiti da Azure, le attività di gestione e manutenzione riguardano solo i nodi agente.

  • Azure Key Vault archivia in modo sicuro i segreti e ne controlla l'accesso, ad esempio chiavi API, password, certificati e chiavi crittografiche. Azure Key Vault facilita anche il provisioning, la gestione e la distribuzione dei certificati TLS/SSL (Transport Layer Security/Secure Sockets Layer) pubblici e privati da usare con Azure e con le risorse connesse interne.

  • Il gateway applicazione di Azure è un servizio di bilanciamento del carico del traffico Web che consente di gestire il traffico in ingresso verso più applicazioni Web e API REST downstream. I servizi di bilanciamento del carico tradizionali operano a livello di trasporto (livello OSI 4 - TCP e UDP) ed eseguono il routing del traffico da un indirizzo IP e una porta di origine verso un indirizzo IP e una porta di destinazione. Il gateway applicazione è invece un servizio di bilanciamento del carico di livello applicazione (livello OSI 7). (OSI è l'acronimo di Open Systems Interconnect, TCP sta per Transmission Control Protocol e UDP è l'acronimo di User Datagram Protocol.

  • Web application firewall o WAF è un servizio che fornisce protezione centralizzata delle applicazioni Web da exploit e vulnerabilità comuni. WAF si basa sulle regole dei set principali OWASP (Open Web Application Security Project). WAF di Azure consente di creare regole personalizzate che vengono valutate per ogni richiesta che passa attraverso un criterio. Queste regole hanno una priorità più elevata rispetto alle altre dei set di regole gestiti. Le regole personalizzate contengono un nome, un valore di priorità e una serie di condizioni di corrispondenza. Se tali condizioni sono soddisfatte, viene eseguita un'azione per consentire o bloccare le richieste.

  • Azure Bastion è una soluzione PaaS (piattaforma distribuita come servizio) completamente gestita di cui si effettua il provisioning all'interno della rete virtuale. Azure Bastion offre connettività RDP (Remote Desktop Protocol) e SSH (Secure Shell) facile e sicura alle macchine virtuali nella rete virtuale direttamente dal portale di Azure tramite TLS.

  • Macchine virtuali di Azure offre risorse di calcolo scalabili su richiesta che consentono la flessibilità della virtualizzazione senza la necessità di acquistare e gestire hardware fisico.

  • Rete virtuale di Azure è il blocco predefinito fondamentale per le reti private di Azure. Con la rete virtuale, le risorse di Azure come le macchine virtuali possono comunicare in modo sicuro tra loro, con Internet e con le reti locali. Una rete virtuale di Azure è simile a una rete locale tradizionale, ma include i vantaggi dell'infrastruttura di Azure come scalabilità, disponibilità e isolamento.

  • Le interfacce di rete virtuale consentono alle macchine virtuali di Azure di comunicare con Internet, Azure e le risorse locali. È possibile aggiungere diverse schede di interfaccia di rete a una macchina virtuale di Azure, affinché le macchine virtuali figlio possano avere dispositivi di interfaccia di rete e indirizzi IP dedicati.

  • Azure Managed Disks offre volumi di archiviazione a livello di blocco che vengono gestiti nelle macchine virtuali di Azure. I tipi di dischi disponibili sono Ultra, SSD Premium, SSD Standard e HDD Standard.

  • Archiviazione BLOB di Azure è la soluzione Microsoft per l'archiviazione di oggetti per il cloud. L'archiviazione BLOB è ottimizzata per l'archiviazione di grandi quantità di dati non strutturati. I dati non strutturati sono dati che non seguono una definizione o un modello di dati specifico, ad esempio dati di testo o binari.

  • Il collegamento privato di Azure consente di accedere ai servizi PaaS di Azure, ad esempio Archiviazione BLOB di Azure e Key Vault, nonché ai servizi di proprietà di clienti/partner ospitati in Azure tramite un endpoint privato nella rete virtuale.

Alternative

In questa architettura, il Controller in ingresso del gateway applicazione (AGIC) è stato installato usando il componente aggiuntivo AGIC per il servizio Azure Kubernetes. È anche possibile installare il Controller in ingresso del gateway applicazione (AGIC) tramite un grafico Helm. Per una nuova configurazione, usando una riga nell'interfaccia della riga di comando di Azure, è possibile distribuire un nuovo gateway applicazione e un nuovo cluster del servizio Azure Kubernetes (con AGIC abilitato come componente aggiuntivo). Il componente aggiuntivo è anche un servizio completamente gestito, che offre vantaggi aggiuntivi, ad esempio aggiornamenti automatici e maggiore supporto. Entrambi i metodi di distribuzione del controller AGIC (Helm e il componente aggiuntivo per il servizio Azure Kubernetes) sono completamente supportati da Microsoft. Inoltre, il componente aggiuntivo consente una migliore integrazione con il servizio Azure Kubernetes, come componente aggiuntivo di prima classe.

Il componente aggiuntivo Controller in ingresso del gateway applicazione (AGIC) viene comunque distribuito come pod nel cluster del servizio Azure Kubernetes. Esistono tuttavia alcune differenze tra la versione della distribuzione Helm e quella del componente aggiuntivo AGIC. L'elenco seguente include le differenze tra le due versioni:

  • I valori della distribuzione Helm non possono essere modificati nel componente aggiuntivo del servizio Azure Kubernetes:

    • usePrivateIp viene impostato su false per impostazione predefinita e il parametro può essere sostituito dall'annotazione use-private-ip
    • shared non è supportato dal componente aggiuntivo

  • Il controller AGIC distribuito tramite Helm supporta ProhibitedTargets, il che significa che tale controller può configurare il gateway applicazione specificamente per i cluster del servizio Azure Kubernetes, senza influire su altri back-end esistenti.

  • Poiché il componente aggiuntivo AGIC è un servizio gestito, viene aggiornato automaticamente alla versione più recente, a differenza del controller AGIC distribuito tramite Helm (per cui è necessario eseguire l'aggiornamento manuale).

  • È possibile distribuire un solo componente aggiuntivo AGIC per ogni cluster del servizio Azure Kubernetes e ogni componente aggiuntivo AGIC può al momento controllare una sola istanza del gateway applicazione. Per le distribuzioni che richiedono più controller AGIC per cluster o più controller AGIC per uno stesso gateway applicazione, è possibile continuare a usare la distribuzione tramite Helm.

Una singola istanza del Controller in ingresso del gateway applicazione (AGIC) di Azure può inserire eventi da più spazi dei nomi Kubernetes. Se l'amministratore del servizio Azure Kubernetes decide di usare il gateway applicazione come ingresso, tutti gli spazi dei nomi useranno la stessa istanza del gateway applicazione. Una singola installazione del controller in ingresso monitorerà gli spazi dei nomi accessibili e configurerà il gateway applicazione a cui è associato. Per altre informazioni, vedere Abilitare il supporto di più spazi dei nomi in un cluster del servizio Azure Kubernetes con il Controller in ingresso del gateway applicazione.

Per abilitare il supporto per più spazi dei nomi, eseguire le operazioni seguenti:

  • Modificare il file helm-config.yaml in uno dei modi seguenti:

    • Eliminare completamente la watchNamespace chiave dal file helm-config.yaml . Il controller AGIC osserverà tutti gli spazi dei nomi.
    • Impostare watchNamespace su una stringa vuota. Il controller AGIC osserverà tutti gli spazi dei nomi.
    • Aggiungere più spazi dei nomi, separati da una virgola (watchNamespace: default,secondNamespace). Il controller AGIC osserverà esclusivamente questi spazi dei nomi.

  • Applicare le modifiche del modello Helm con questo script: helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure

Dopo la distribuzione con la possibilità di osservare più spazi dei nomi, il controller AGIC eseguirà le operazioni seguenti:

  • Elencare le risorse in ingresso da tutti gli spazi dei nomi accessibili
  • Filtrare in base alle risorse in ingresso annotate con kubernetes.io/ingress.class: azure/application-gateway
  • Comporre la configurazione combinata del gateway applicazione
  • Applicare la configurazione al gateway applicazione associato tramite ARM

Dettagli dello scenario

Un cluster Kubernetes multi-tenant è condiviso da più utenti e carichi di lavoro comunemente definiti "tenant". Questa definizione include cluster Kubernetes condivisi da team o divisioni diversi all'interno di un'organizzazione. Include anche cluster condivisi da istanze per cliente di un'applicazione SaaS (Software-as-a-Service). L'architettura multi-tenancy del cluster è un'alternativa alla gestione di molti cluster dedicati a tenant singolo. Gli operatori di un cluster Kubernetes multi-tenant devono isolare i tenant l'uno dall'altro. Questo isolamento riduce al minimo i danni che un tenant compromesso o dannoso può fare al cluster e ad altri tenant. Quando più utenti o team condividono un cluster con un numero fisso di nodi, esiste il problema che un team possa usare più risorse rispetto alla quota di sua competenza. Resource Quotas è uno strumento per amministratori che consente di risolvere questo problema.

Quando si prevede di creare un cluster multi-tenant del servizio Azure Kubernetes, è necessario considerare i livelli di isolamento delle risorse forniti da Kubernetes: cluster, spazio dei nomi, nodo, pod e contenitore. È anche necessario considerare le implicazioni per la sicurezza che derivano dalla condivisione di diversi tipi di risorse tra più tenant. Ad esempio, la pianificazione di pod da tenant diversi sullo stesso nodo può consentire di ridurre il numero di computer necessari nel cluster. D'altro canto, può essere necessario impedire che determinati carichi di lavoro condividano la stessa posizione. Si può ad esempio avere la necessità di impedire l'esecuzione di codice non attendibile dall'esterno dell'organizzazione sullo stesso nodo dei contenitori che elaborano informazioni riservate. Criteri di Azure può essere usato per limitare la distribuzione al servizio Azure Kubernetes solo da registri attendibili.

Anche se Kubernetes non può garantire un isolamento perfettamente sicuro tra i tenant, offre funzionalità che potrebbero essere sufficienti per casi d'uso specifici. Come procedura consigliata, è opportuno separare ogni tenant e le relative risorse Kubernetes nei rispettivi spazi dei nomi. È quindi possibile usare il controllo degli accessi in base al ruolo di Kubernetes e Criteri di rete per applicare l'isolamento dei tenant. Il controllo degli accessi in base al ruolo è l'acronimo di role-based access control(Controllo degli accessi in base al ruolo). Ad esempio, l'immagine seguente mostra il tipico modello di provider SaaS che ospita più istanze della stessa applicazione nello stesso cluster, una per ogni tenant. Ogni applicazione risiede in uno spazio dei nomi separato. Quando i tenant necessitano di un livello superiore di isolamento fisico e prestazioni garantite, i carichi di lavoro possono essere distribuiti in un set dedicato di nodi, in un pool dedicato o persino in un cluster dedicato.

Diagramma della multi-tenancy

Scaricare un file di Visio di questa architettura.

Il Controller in ingresso del gateway applicazione (AGIC) è un'applicazione Kubernetes che consente ai clienti del servizio Azure Kubernetes di usare un gateway applicazione di Azure per esporre le proprie applicazioni in contenitori alla rete Internet. AGIC esegue il monitoraggio del cluster Kubernetes in cui è ospitato e aggiorna di continuo un gateway applicazione, consentendo l'esposizione a Internet dei servizi selezionati. Il controller in ingresso viene eseguito in uno specifico pod dell'istanza del servizio Azure Kubernetes del cliente. AGIC esegue il monitoraggio di un subset di risorse Kubernetes per rilevare eventuali modifiche. Lo stato del cluster del servizio Azure Kubernetes viene convertito in una configurazione specifica del gateway applicazione e applicato a Azure Resource Manager (ARM). Questo esempio di architettura illustra le procedure consolidate per distribuire un cluster del servizio Azure Kubernetes pubblico o privato con un gateway applicazione di Azure e il componente aggiuntivo Controller in ingresso del gateway applicazione.

Una singola istanza del Controller in ingresso Kubernetes del gateway applicazione di Azure (AGIC) può inserire eventi da più spazi dei nomi e osservare tali spazi. Se l'amministratore del servizio Azure Kubernetes decide di usare il gateway applicazione come ingresso, tutti gli spazi dei nomi useranno la stessa istanza del gateway applicazione. Una singola installazione del controller in ingresso monitorerà gli spazi dei nomi accessibili e configurerà il gateway applicazione a cui è associato.

Potenziali casi d'uso

Usare il Controller in ingresso del gateway applicazione (AGIC) per esporre e proteggere i carichi di lavoro con connessione Internet che sono in esecuzione in un cluster del servizio Azure Kubernetes in un ambiente multi-tenant.

Considerazioni

Anche se alcune delle considerazioni seguenti non sono del tutto pertinenti alla multi-tenancy nel servizio Azure Kubernetes, si tratta di requisiti essenziali per la distribuzione di questa soluzione. Sono incluse considerazioni su sicurezza, prestazioni, disponibilità e affidabilità, archiviazione, utilità di pianificazione, mesh di servizi e monitoraggio.

Considerazioni sull'architettura multi-tenancy

  • Progettare i cluster del servizio Azure Kubernetes per un'architettura multi-tenancy. Kubernetes offre funzionalità che consentono di isolare in modo logico team e carichi di lavoro nello stesso cluster. L'obiettivo è quello di fornire il minor numero di privilegi, limitati alle risorse di cui ogni team ha bisogno. Uno spazio dei nomi in Kubernetes crea un limite di isolamento logico.
  • Usare l'isolamento logico per separare team e progetti. Provare a ridurre al minimo il numero di cluster fisici del servizio Azure Kubernetes distribuiti per isolare i team o le applicazioni. La separazione logica dei cluster fornisce in genere una maggiore densità dei pod rispetto ai cluster isolati fisicamente.
  • Usare pool di nodi dedicati, o cluster del servizio Azure Kubernetes dedicati, ogni volta che è necessario implementare un isolamento fisico rigoroso. È ad esempio possibile dedicare un pool di nodi di lavoro o un intero cluster a un team o a un tenant in un ambiente multi-tenant.
    • È possibile usare una combinazione di taints e tolerations per controllare la distribuzione dei pod in un pool di nodi specifico. Si noti che un nodo nel servizio Azure Kubernetes può essere tainted solo al momento della creazione del pool di nodi. In alternativa, le etichette e i selettori nodePool possono essere usati per controllare la distribuzione del carico di lavoro in pool di nodi specifici.

Considerazioni sulla sicurezza

Anche se le considerazioni sulla sicurezza non sono del tutto pertinenti alla multi-tenancy nel servizio Azure Kubernetes, si tratta di requisiti essenziali per la distribuzione di questa soluzione.

Sicurezza di rete

  • Creare un endpoint privato per qualsiasi servizio PaaS usato dai carichi di lavoro del servizio Azure Kubernetes, ad esempio Key Vault, il bus di servizio o il database SQL di Azure. In questo modo il traffico tra le applicazioni e questi servizi non viene esposto alla rete Internet pubblica. Per altre informazioni, vedere Informazioni sul collegamento privato di Azure.
  • Configurare la risorsa in ingresso Kubernetes per esporre i carichi di lavoro tramite HTTPS e usare un sottodominio e un certificato digitale separati per ogni tenant. Il Controller in ingresso del gateway applicazione (AGIC) configurerà automaticamente il listener del gateway applicazione di Azure per la terminazione SSL (Secure Socket Layer).
  • Configurare il gateway applicazione di Azure in modo da usare criteri di Web Application Firewall per proteggere da attacchi dannosi i carichi di lavoro pubblici (in esecuzione nel servizio Azure Kubernetes).
  • Per l'integrazione con le reti locali o con le reti virtuali esistenti, usare le funzionalità di rete Azure CNI nel servizio Azure Kubernetes. Questo modello di rete consente inoltre una maggiore separazione delle risorse e dei controlli in un ambiente aziendale.
  • Usare i criteri di rete per separare e proteggere le comunicazioni all'interno dei servizi controllando quali componenti possono comunicare tra loro. Per impostazione predefinita, tutti i pod in Kubernetes possono inviare e ricevere traffico senza limitazioni. Per migliorare la sicurezza, è possibile usare Criteri di rete di Azure o Criteri di rete Calico per definire regole che controllano il flusso del traffico tra microservizi diversi. Per altre informazioni, vedere Criteri di rete.
  • Non esporre la connettività remota ai nodi del servizio Azure Kubernetes. Creare un bastion host, o una jump box, in una rete virtuale di gestione. Usare il bastion host per instradare in modo sicuro il traffico nel cluster del servizio Azure Kubernetes alle attività di gestione remota.
  • Prendere in considerazione l'uso di un cluster del servizio Azure Kubernetes privato nell'ambiente di produzione o almeno proteggere l'accesso al server API usando intervalli di indirizzi IP autorizzati nel servizio Azure Kubernetes.
  • Protezione DDoS di Azure, in combinazione con le procedure consigliate per la progettazione di applicazioni, offre funzionalità avanzate di mitigazione DDoS per difendersi meglio dagli attacchi DDoS. È consigliabile abilitare Protezione DDOS di Azure in qualsiasi rete virtuale perimetrale.

Autenticazione e autorizzazione

  • Distribuire i cluster del servizio Azure Kubernetes con l'integrazione di Microsoft Entra. Per altre informazioni, vedere Integrazione di Microsoft Entra gestita dal servizio Azure Kubernetes. L'uso di Microsoft Entra ID centralizza il componente di gestione delle identità. Qualsiasi modifica all'account utente o allo stato del gruppo viene aggiornata automaticamente nell'accesso al cluster servizio Azure Kubernetes. Usare Role o ClusterRole e Binding per assegnare a utenti o gruppi il minor numero di autorizzazioni richieste.
  • Usare il controllo degli accessi in base al ruolo di Kubernetes per definire le autorizzazioni di utenti o gruppi relativamente alle risorse del cluster. Creare ruoli e associazioni che assegnano il numero minimo di autorizzazioni richieste. Integrare il controllo degli accessi in base al ruolo di Kubernetes con Microsoft Entra ID in modo che qualsiasi modifica dello stato utente o appartenenza a gruppi venga aggiornata automaticamente e l'accesso alle risorse del cluster sia aggiornato.
  • Usare il controllo degli accessi in base al ruolo di Azure per definire le autorizzazioni minime obbligatorie di utenti o gruppi relativamente alle risorse del servizio Azure Kubernetes in una o più sottoscrizioni. Per altre informazioni, vedere Controllo degli accessi in base al ruolo di Kubernetes e Usare il controllo degli accessi in base al ruolo di Azure per l'autorizzazione di Kubernetes.
  • Prendere in considerazione l'uso di ID dei carichi di lavoro di Microsoft Entra per assegnare un'identità gestita per una risorsa di Azure a singoli microservizi, che possono quindi usare per accedere alle risorse gestite( ad esempio Azure Key Vault, database SQL, bus di servizio e Cosmos DB). Tutto senza la necessità di archiviare e recuperare l'uso di stringa di connessione o credenziali dai segreti Kubernetes.
  • Valutare l'opportunità di usare il driver CSI dell'archivio segreti per Azure Key Vault per accedere ai segreti, ad esempio credenziali e stringhe di connessione, da Key Vault anziché dai segreti Kubernetes.
  • Prendere inoltre in considerazione l'uso del blocco predefinito Dapr Secrets Stores, con l'archivio Azure Key Vault con identità gestite in Kubernetes, per recuperare segreti, ad esempio credenziali e stringhe di connessione, da Key Vault.

Carico di lavoro e cluster

  • La protezione dell'accesso al server dell'API Kubernetes è una delle operazioni più importanti per proteggere il cluster. Integrare il controllo degli accessi in base al ruolo di Kubernetes con Microsoft Entra ID per controllare l'accesso al server API. Questi controlli consentono di proteggere il servizio Azure Kubernetes allo stesso modo in cui si protegge l'accesso alle sottoscrizioni di Azure.
  • Limitare l'accesso alle azioni che i contenitori possono eseguire. Usare l'ammissione di sicurezza dei pod per abilitare l'autorizzazione con granularità fine della creazione e degli aggiornamenti dei pod. Concedere il minor numero possibile di autorizzazioni ed evitare l'uso dell'accesso radice o dell'escalation dei privilegi. Per altre procedure consigliate, vedere Proteggere l'accesso dei pod alle risorse.
  • Quando possibile, evitare di eseguire contenitori come utente root.
  • Usare il modulo di protezione del kernel di Linux AppArmor per limitare le azioni che possono essere eseguite dai contenitori.
  • Aggiornare regolarmente i cluster del servizio Azure Kubernetes alla versione più recente di Kubernetes per sfruttare le nuove funzionalità e le correzioni di bug.
  • Il servizio Azure Kubernetes scarica e installa automaticamente le correzioni per la sicurezza in ogni nodo Linux, ma non esegue automaticamente il riavvio del nodo, se necessario. Usare kured per controllare i riavvii in sospeso, bloccare e svuotare i nodi e infine applicare gli aggiornamenti. Per Windows Server, eseguire regolarmente un aggiornamento del servizio Azure Kubernetes per bloccare e svuotare in modo sicuro i pod e distribuire i nodi aggiornati.
  • Prendere in considerazione l'uso di protocolli di trasporto sicuri HTTPS e gRPC per tutte le comunicazioni tra pod e adottare un meccanismo di autenticazione più avanzato che non richieda l'invio delle credenziali semplici per ogni richiesta, come OAuth o JWT. È possibile ottenere comunicazioni tra servizi sicuri sfruttando una mesh di servizi, ad esempio Istio, Linkerd o Consul o Tramite Dapr.

Registro Azure Container

  • Analizzare le immagini del contenitore per verificare la presenza di vulnerabilità e distribuire solo le immagini che hanno superato la convalida. Aggiornare regolarmente le immagini di base e il runtime applicazione e ridistribuire i carichi di lavoro nel cluster del servizio Azure Kubernetes. Il flusso di lavoro di distribuzione CI/CD deve includere un processo per analizzare le immagini del contenitore. Microsoft Defender per il cloud la sicurezza devOps può essere usata per analizzare il codice per individuare le vulnerabilità durante la compilazione/distribuzione nelle pipeline automatizzate. In alternativa, è possibile usare strumenti come Prisma Cloud o Aqua per analizzare e consentire la distribuzione solo di immagini verificate.
  • Quando si usano immagini di base per le immagini dell'applicazione, usare l'automazione per compilare nuove immagini quando l'immagine di base viene aggiornata. Poiché le immagini di base includono in genere correzioni per la sicurezza, aggiornare tutte le immagini del contenitore dell'applicazione downstream. Per altre informazioni sugli aggiornamenti delle immagini di base, vedere Automatizzare la compilazione di immagini in caso di aggiornamento dell'immagine di base con ACR Tasks.

Considerazioni sulle prestazioni

Anche se le considerazioni sulle prestazioni non sono del tutto pertinenti alla multi-tenancy nel servizio Azure Kubernetes, si tratta di requisiti essenziali per la distribuzione di questa soluzione:

  • Per i carichi di lavoro a bassa latenza, è consigliabile distribuire un pool di nodi dedicato in un gruppo di posizionamento di prossimità. Quando si distribuisce l'applicazione in Azure, la distribuzione di istanze di macchine virtuali tra aree o zone di disponibilità crea una latenza di rete che può influire sulle prestazioni complessive dell'applicazione. Un gruppo di posizionamento di prossimità è un raggruppamento logico usato per assicurarsi che le risorse di calcolo di Azure siano vicine tra loro. Alcuni casi d'uso, ad esempio giochi, simulazioni di progettazione e trading ad alta frequenza, richiedono bassa latenza ed esecuzione rapida delle attività. Per scenari HPC (High Performance Computing) come questi, prendere in considerazione l'uso di gruppi di posizionamento di prossimità per i pool di nodi del cluster.
  • Usare sempre immagini di contenitore più piccole, poiché consentono di creare compilazioni più veloci. Le immagini più piccole sono anche meno vulnerabili ai vettori di attacco, poiché la superficie di attacco è ridotta.
  • Usare la scalabilità automatica di Kubernetes per aumentare dinamicamente il numero di nodi di lavoro di un cluster del servizio Azure Kubernetes in caso di aumento del traffico. Con Horizontal Pod Autoscaler e un componente di scalabilità automatica del cluster, i volumi di nodi e pod vengono modificati dinamicamente in tempo reale, per soddisfare la condizione del traffico ed evitare tempi di inattività dovuti a problemi di capacità. Per altre informazioni, vedere Usare il componente di scalabilità automatica del cluster in servizio Azure Kubernetes (servizio Azure Kubernetes).

Considerazioni sulla disponibilità e sull'affidabilità

Anche se le considerazioni sulla disponibilità e sull'affidabilità non sono del tutto pertinenti alla multi-tenancy nel servizio Azure Kubernetes, si tratta di requisiti essenziali per la distribuzione di questa soluzione. Prendere in considerazione i metodi seguenti per ottimizzare la disponibilità per il cluster e i carichi di lavoro del servizio Azure Kubernetes.

Contenitori

  • Usare i probe di integrità di Kubernetes per verificare che i contenitori siano attivi e integri:

    • Il livenessProbe (probe di attività) indica se il contenitore è in esecuzione. Se questo probe ha esito negativo, il kubelet elimina il contenitore, che è quindi soggetto ai criteri di riavvio.
    • Il readinessProbe (probe di idoneità) indica se il contenitore è pronto a rispondere alle richieste. Se questo probe ha esito negativo, il controller degli endpoint rimuove l'indirizzo IP del pod dagli endpoint di tutti i servizi che corrispondono al pod. Lo stato predefinito di idoneità prima del ritardo iniziale è Failure.
    • Lo startupProbe (probe di avvio) indica se l'applicazione all'interno del contenitore è stata avviata. Finché il probe di avvio non ha esito positivo, tutti gli altri probe vengono disabilitati. Se questo probe ha esito negativo, il kubelet elimina il contenitore, che è quindi soggetto ai criteri di riavvio.

  • La contesa di risorse può influire sulla disponibilità del servizio. Definire vincoli per le risorse dei contenitori in modo che nessun contenitore possa sovraccaricare la memoria del cluster e le risorse della CPU. È possibile usare la diagnostica del servizio Azure Kubernetes per identificare eventuali problemi nel cluster.

  • Usare il limite di risorse per limitare le risorse totali consentite per un contenitore, in modo che un contenitore specifico non possa sottrarre risorse agli altri.

Registro contenitori

  • È consigliabile archiviare le immagini del contenitore in Registro Azure Container e quindi eseguire la replica geografica del registro in ogni area del servizio Azure Kubernetes usando Replica geografica in Registro Azure Container. La replica geografica è una funzionalità disponibile solo per le istanze di Registro Azure Container SKU Premium.
  • Analizzare le immagini del contenitore per verificare la presenza di vulnerabilità e distribuire solo le immagini che hanno superato la convalida. Aggiornare regolarmente le immagini di base e il runtime applicazione e quindi ridistribuire i carichi di lavoro nel cluster del servizio Azure Kubernetes.
  • Limitare i registri di immagini che possono essere usati da pod e distribuzioni. Consentire solo i registri attendibili in cui si convalidano e si controllano le immagini disponibili.
  • Quando si usano immagini di base per le immagini dell'applicazione, usare l'automazione per compilare nuove immagini quando l'immagine di base viene aggiornata. Poiché le immagini di base includono in genere correzioni per la sicurezza, aggiornare tutte le immagini del contenitore dell'applicazione downstream. È consigliabile analizzare le immagini del contenitore per individuare le vulnerabilità nell'ambito della pipeline CI/CD prima di pubblicare le immagini nel registro contenitori. Azure Defender per contenitori può essere integrato nei flussi di lavoro CI/CD.
  • Usare Attività del Registro Azure Container per automatizzare l'applicazione di patch al sistema operativo e al framework per i contenitori Docker. Attività del Registro Azure Container supporta l'esecuzione automatica della compilazione quando viene aggiornata l'immagine di base di un contenitore, ad esempio per applicare patch al sistema operativo o al framework applicazioni in una delle immagini di base.

Resilienza all'interno dell'area

  • È consigliabile distribuire i pool di nodi del cluster del servizio Azure Kubernetes in tutte le zone di disponibilità all'interno di un'area e usare un'istanza di Load Balancer Standard di Azure o un gateway applicazione di Azure davanti ai pool di nodi. Questa topologia offre migliore resilienza in caso di interruzione di un singolo data center. In questo modo, i nodi del cluster vengono distribuiti tra più data center, in tre zone di disponibilità separate all'interno di un'area.
  • Abilitare la ridondanza della zona in Registro Azure Container per usufruire di resilienza all'interno dell'area e disponibilità elevata.
  • Usare i vincoli di distribuzione della topologia dei pod per controllare il modo in cui i pod vengono distribuiti nel cluster del servizio Azure Kubernetes tra domini di errore, ad esempio aree, zone di disponibilità e nodi.
  • Prendere in considerazione l'uso del contratto di servizio relativo al tempo di attività per i cluster del servizio Azure Kubernetes che ospitano carichi di lavoro cruciali. Il contratto di servizio relativo al tempo di attività è una funzionalità facoltativa che consente di ottenere un contratto di servizio con copertura finanziaria e disponibilità più elevata per un cluster. Questo contratto di servizio garantisce una disponibilità dell'endpoint del server dell'API Kubernetes pari al 99,95% per i cluster che usano zone di disponibilità. Garantisce inoltre una disponibilità del 99,9% per i cluster che non usano zone di disponibilità. Il servizio Azure Kubernetes usa le repliche dei nodi master nei domini di aggiornamento e di errore per garantire che siano soddisfatti i requisiti del contratto di servizio.

Continuità aziendale e ripristino di emergenza

  • È consigliabile distribuire la soluzione in almeno due aree di Azure abbinate all'interno di un'area geografica. È anche consigliabile adottare un servizio di bilanciamento del carico globale, come Gestione traffico di Azure o Frontdoor di Azure, con un metodo di routing attivo/attivo o attivo/passivo, per garantire la continuità aziendale e il ripristino di emergenza.
  • Assicurarsi di creare script, documentare e testare periodicamente qualsiasi processo di failover a livello di area in un ambiente di controllo di qualità per evitare problemi imprevedibili nel caso in cui un servizio principale subisca un'interruzione nell'area primaria.
  • Questi test sono concepiti anche per convalidare se l'approccio di ripristino di emergenza soddisfa gli obiettivi RPO/RTO, in combinazione con eventuali processi e interventi manuali necessari per un failover.
  • Assicurarsi di testare le procedure di failback per capire se funzionano come previsto.
  • Archiviare le immagini del contenitore in Registro Azure Container ed eseguire la replica geografica del registro in ogni regione del servizio Azure Kubernetes. Per altre informazioni, vedere Replica geografica in Registro Azure Container.
  • Laddove possibile, non archiviare lo stato del servizio all'interno del contenitore. In alternativa, usare una soluzione PaaS (Platform as a Service) che supporta la replica in più aree.
  • Se si usa Archiviazione di Azure, preparare e testare la procedura di migrazione dell'archiviazione dall'area primaria all'area di backup.
  • Valutare la possibilità di distribuire la configurazione del cluster usando GitOps. L'uso di GitOps offre uniformità tra cluster primari e di ripristino di emergenza e un modo rapido per ricompilare il nuovo cluster in caso di perdita del cluster.
  • Prendere in considerazione il backup/ripristino della configurazione del cluster usando strumenti come servizio Azure Kubernetes backup o Velero.

Considerazioni sulle risorse di archiviazione

Anche se le considerazioni sull'archiviazione non sono del tutto pertinenti alla multi-tenancy nel servizio Azure Kubernetes, si tratta di requisiti essenziali per la distribuzione di questa soluzione:

  • È consigliabile distribuire il cluster del servizio Azure Kubernetes con dischi del sistema operativo temporanei che offrono una latenza inferiore per le operazioni di lettura/scrittura, oltre a un ridimensionamento dei nodi e ad aggiornamenti del cluster più rapidi.
  • Comprendere le esigenze dell'applicazione per scegliere il tipo di archiviazione più adatto. Usare l'archiviazione basata su SSD a prestazioni elevate per i carichi di lavoro di produzione. Pianificare un sistema di archiviazione basato sulla rete, ad esempio File di Azure, quando più pod devono accedere contemporaneamente agli stessi file. Per altre informazioni, vedere Opzioni di archiviazione per le applicazioni nel servizio Azure Kubernetes.
  • Ogni dimensione di nodo supporta un numero massimo di dischi. Dimensioni diverse forniscono quantità diverse di spazio di archiviazione locale e larghezza di banda della rete. Pianificare le esigenze dell'applicazione per distribuire le dimensioni dei nodi appropriate.
  • Per ridurre il sovraccarico di gestione e consentire la scalabilità, evitare di creare e assegnare in modo statico volumi permanenti. Usare invece il provisioning dinamico. Nelle classi di archiviazione definire i criteri di recupero appropriati per ridurre al minimo i costi di archiviazione non necessari dopo l'eliminazione dei pod.

Considerazioni sull'utilità di pianificazione

Anche se le considerazioni sull'utilità di pianificazione non sono del tutto pertinenti alla multi-tenancy nel servizio Azure Kubernetes, si tratta di requisiti essenziali per la distribuzione di questa soluzione:

  • Assicurarsi di esaminare e implementare le procedure consigliate per consentire agli operatori del cluster e agli sviluppatori di applicazioni di compilare ed eseguire correttamente le applicazioni nel servizio Azure Kubernetes.
  • Pianificare e applicare quote di risorse a livello di spazio dei nomi, per tutti gli spazi dei nomi. Se i pod non definiscono le richieste di risorse e i limiti, rifiutare la distribuzione. Monitorare l'utilizzo delle risorse e quindi modificare le quote in base alle esigenze. Quando più team o tenant condividono un cluster del servizio Azure Kubernetes con un numero fisso di nodi, è possibile usare le quote di risorse per assegnare una quota equa di risorse a ogni team o tenant.
  • Adottare intervalli di limiti per vincolare le allocazioni di risorse (a pod o contenitori) in uno spazio dei nomi, in termini di CPU e memoria.
  • Definire in modo esplicito le richieste e i limiti di risorse, in termini di CPU e memoria, per i pod nei manifesti YAML o nei grafici Helm usati per distribuire le applicazioni. Quando si specifica la richiesta di risorse per i contenitori in un pod, l'utilità di pianificazione di Kubernetes usa queste informazioni per decidere su quale nodo posizionare il pod. Quando si specifica un limite di risorse (ad esempio in termini di CPU o memoria) per un contenitore, il kubelet applica tale limite per impedire che il contenitore in esecuzione possa usare più risorse rispetto al limite impostato.
  • Per mantenere la disponibilità delle applicazioni, definire i budget di interruzione dei pod in modo da garantire la disponibilità di un numero minimo di pod nel cluster.
  • È possibile usare classi di priorità per indicare l'importanza di un pod. Se un pod non può essere pianificato, l'utilità di pianificazione tenta di rimuovere i pod con priorità più bassa per rendere possibile la pianificazione del pod in sospeso.
  • Usare le tolleranze e i taint di Kubernetes per posizionare le applicazioni a elevato utilizzo di risorse in nodi specifici ed evitare problemi di tipo noisy neighbor nei nodi adiacenti. Mantenere le risorse dei nodi disponibili per i carichi di lavoro che le richiedono e non consentire la pianificazione di altri carichi di lavoro sui nodi.
  • Controllare la pianificazione dei pod sui nodi tramite selettori di nodo, affinità tra nodi o affinità tra pod. Usare le impostazioni di affinità e anti-affinità tra pod per collocare in una posizione condivisa i pod con comunicazioni frequenti, posizionare i pod in nodi diversi ed evitare di eseguire più istanze dello stesso tipo di pod sullo stesso nodo.

Considerazioni sulla mesh di servizi

Anche se le considerazioni sulla mesh di servizi non sono del tutto pertinenti alla multi-tenancy nel servizio Azure Kubernetes, si tratta di requisiti essenziali per la distribuzione di questa soluzione:

  • È consigliabile usare una mesh di servizi open source (ad esempio Istio, Linkerd o Consul) nel cluster del servizio Azure Kubernetes per migliorare l'osservabilità, l'affidabilità e la sicurezza per i microservizi tramite TLS reciproco. È anche possibile implementare strategie di suddivisione del traffico, ad esempio distribuzioni di tipo blu-verde e canary. In breve, una mesh di servizi è un livello di infrastruttura dedicato per rendere sicure, veloci e affidabili le comunicazioni da servizio a servizio. Per visualizzare il componente aggiuntivo Istio integrato nel servizio Azure Kubernetes, vedere: Componente aggiuntivo del servizio Azure Kubernetes istio

  • Prendere in considerazione l'adozione di Dapr per creare applicazioni resilienti di microservizi senza stato e con stato. È possibile usare qualsiasi linguaggio di programmazione e framework di sviluppo.

Considerazioni su DevOps

  • Distribuire i carichi di lavoro nel servizio Azure Kubernetes, con un grafico Helm in una pipeline CI/CD, usando un sistema DevOps, ad esempio GitHub Actions o Azure DevOps. Per altre informazioni, vedere Compilare e distribuire nel servizio Azure Kubernetes.

  • Introdurre test A/B e distribuzioni canary nella gestione del ciclo di vita dell'applicazione per testare correttamente un'applicazione prima di renderla disponibile per tutti gli utenti. È possibile usare varie tecniche per suddividere il traffico tra versioni diverse dello stesso servizio.

  • In alternativa, è possibile usare le funzionalità di gestione del traffico fornite da un'implementazione della mesh di servizi. Per altre informazioni, vedi:

  • Usare Registro Azure Container o un altro registro contenitori come Docker Hub per archiviare le immagini Docker private che vengono distribuite nel cluster. Il servizio Azure Kubernetes può eseguire l'autenticazione con Registro Azure Container usando l'identità Microsoft Entra.

Considerazioni sul monitoraggio

Anche se le considerazioni sul monitoraggio non sono del tutto pertinenti alla multi-tenancy nel servizio Azure Kubernetes, si tratta di requisiti essenziali per la distribuzione di questa soluzione:

  • Prendere in considerazione le opzioni di monitoraggio integrate di Azure per monitorare lo stato di integrità del cluster e dei carichi di lavoro del servizio Azure Kubernetes.
  • Configurare tutti i servizi PaaS, ad esempio Registro Azure Container e Key Vault, per raccogliere le metriche e i log di diagnostica per Log Analytics in Monitoraggio di Azure.

Ottimizzazione dei costi

Il costo di questa architettura dipende da determinati aspetti di configurazione come i seguenti:

  • Livelli di servizio
  • Scalabilità, ovvero numero di istanze allocate dinamicamente dai servizi per supportare una determinata domanda
  • Script di automazione
  • Il livello di ripristino di emergenza

Dopo aver valutato questi aspetti, passare al calcolatore dei prezzi di Azure per eseguire una stima dei costi. Per altre opzioni di ottimizzazione dei prezzi, vedere Principi di ottimizzazione dei costi in Microsoft Azure Well-Architected Framework.

Distribuire lo scenario

Il codice sorgente per questo scenario è disponibile in GitHub. È anche possibile trovare un'applicazione demo, come illustrato nella figura seguente, in questo repository GitHub.

Il diagramma mostra la distribuzione di questo AGIC con l'architettura del servizio Azure Kubernetes.

Scaricare un file di Visio di questa architettura.

Prerequisiti

Per le distribuzioni online, è necessario disporre di un account Azure esistente. Se necessario, creare un account Azure gratuito prima di iniziare.

Distribuzione in Azure

  1. Assicurarsi di avere a portata di mano le informazioni sulla sottoscrizione di Azure.

  2. Prima di tutto, clonare il repository GitHub workbench:

    git clone https://github.com/Azure-Samples/aks-agic.git

  3. Seguire le istruzioni riportate nel file README.md.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Passaggi successivi

Servizio Azure Kubernetes

Gateway applicazione di Azure

Per altre informazioni, vedere Controller di ingresso del gateway applicazione di Azure

Azure Application Gateway WAF

Linee guida per l'architettura

Architetture di riferimento