Usare Gestione API di Azure con i microservizi distribuiti nel servizio Azure Kubernetes

SI APPLICA A: Tutti i livelli di Gestione API

I microservizi sono perfetti per la creazione di API. Con il servizio Azure Kubernetes (AKS) è possibile distribuire e gestire rapidamente un'architettura basata su microservizi nel cloud. È quindi possibile sfruttare Gestione API di Azure (Gestione API) per pubblicare i microservizi come API per l'utilizzo interno ed esterno. Questo articolo descrive le opzioni di distribuzione di Gestione API con il servizio Azure Kubernetes. Presuppone una conoscenza di base di Kubernetes, Gestione API e rete di Azure.

Background

Quando si pubblicano microservizi come API per l'utilizzo, può essere difficile gestire la comunicazione tra i microservizi e i client che li usano. Esistono numerose problematiche trasversali, ad esempio l'autenticazione, l'autorizzazione, la limitazione, la memorizzazione nella cache, la trasformazione e il monitoraggio. Questi problemi sono validi indipendentemente dal fatto che i microservizi siano esposti a client interni o esterni.

Il modello di gateway API risolve questi problemi. Un gateway API funge da frontdoor ai microservizi, disaccoppia i client dai microservizi, aggiunge un altro livello di sicurezza e riduce la complessità dei microservizi eliminando il carico di lavoro di gestione delle problematiche trasversali.

Gestione API di Azure è una soluzione chiavi in mano per risolvere le esigenze del gateway API. È possibile creare rapidamente un gateway coerente e moderno per i microservizi e pubblicarli come API. In quanto soluzione di gestione delle API a ciclo completo, offre anche funzionalità aggiuntive, tra cui un portale self-service per gli sviluppatori per la scoperta delle API, la gestione del ciclo di vita delle API e l'analisi delle API.

Se usati insieme, il servizio Azure Kubernetes e Gestione API offrono una piattaforma per la distribuzione, la pubblicazione, la protezione, il monitoraggio e la gestione delle API basate su microservizi. Questo articolo illustra alcune opzioni per la distribuzione del servizio Azure Kubernetes in combinazione con Gestione API.

Servizi Kubernetes e API

In un cluster Kubernetes i contenitori vengono distribuiti in pod, che sono temporanei e hanno un ciclo di vita. Quando un nodo di lavoro muore, i pod in esecuzione nel nodo vanno perduti. Di conseguenza, l'indirizzo IP di un pod può cambiare in qualsiasi momento. Non è possibile fare affidamento su quell'indirizzo per comunicare con il pod.

Per risolvere questo problema, Kubernetes ha introdotto il concetto di servizi. Un servizio Kubernetes è un livello di astrazione che definisce un gruppo logico di pod e consente l'esposizione del traffico esterno, il bilanciamento del carico e l'individuazione dei servizi per tali pod.

Una volta pronti a pubblicare i microservizi come API tramite Gestione API, è necessario considerare come eseguire il mapping dei servizi in Kubernetes alle API in Gestione API. Non esistono regole fisse. Dipende dal modo in cui inizialmente sono state progettati e partizionati le funzionalità o i domini aziendali. Ad esempio, se i pod dietro un servizio sono responsabili di tutte le operazioni su una determinata risorsa (ad esempio, cliente), il servizio può essere mappato a un'API. Se le operazioni su una risorsa vengono partizionate in più microservizi (ad esempio, GetOrder, PlaceOrder), più servizi possono essere aggregati logicamente in un'unica API in Gestione API (vedere la figura 1).

I mapping possono anche evolversi. Poiché Gestione API crea un'interfaccia con i microservizi, consente di effettuare il refactoring e dimensionare correttamente i microservizi nel tempo.

Distribuire Gestione API davanti al servizio Azure Kubernetes

Sono disponibili alcune opzioni per la distribuzione di Gestione API davanti a un cluster del servizio Azure Kubernetes.

Mentre un cluster del servizio Azure Kubernetes viene sempre distribuito in una rete virtuale (VNet), non è necessario distribuire un'istanza di Gestione API in una rete virtuale. Quando Gestione API non si trova all'interno della rete virtuale del cluster, il cluster del servizio Azure Kubernetes deve pubblicare endpoint pubblici per la connessione di Gestione API. In tal caso, è necessario proteggere la connessione tra Gestione API e servizio Azure Kubernetes. In altre parole, è necessario assicurarsi che il cluster sia accessibile esclusivamente tramite Gestione API. Di seguito vengono riportate le diverse opzioni.

Opzione 1: Esporre i servizi pubblicamente

I servizi in un cluster del servizio Azure Kubernetes possono essere esposti pubblicamente usando i tipi di servizio di NodePort, LoadBalancer o ExternalName. In questo caso, i servizi sono accessibili direttamente da Internet pubblico. Dopo aver distribuito Gestione API davanti al cluster, è necessario assicurarsi che tutto il traffico in ingresso attraversi Gestione API applicando l'autenticazione nei microservizi. Ad esempio, Gestione API può includere un token di accesso in ogni richiesta inviata al cluster. Ogni microservizio è responsabile della convalida del token prima di elaborare la richiesta.

Questa potrebbe essere l'opzione più semplice per distribuire Gestione API davanti al servizio Azure Kubernetes, soprattutto se nei microservizi è già stata implementata la logica di autenticazione.

Vantaggi:

• Configurazione semplice sul lato di Gestione API perché non deve essere inserita nella rete virtuale del cluster
• Nessuna modifica sul lato del servizio Azure Kubernetes se i servizi sono già esposti pubblicamente e la logica di autenticazione esiste già nei microservizi

Svantaggi:

• Potenziale rischio di sicurezza dovuto alla visibilità pubblica degli endpoint
• Nessun punto di ingresso singolo per il traffico del cluster in ingresso
• Complica i microservizi con la logica di autenticazione duplicata

Opzione 2: Installare un controller in ingresso

Anche se l'opzione 1 potrebbe essere più semplice, presenta notevoli svantaggi, come indicato in precedenza. Se un'istanza di Gestione API non si trova nella rete virtuale del cluster, l'autenticazione TLS reciproca (mTLS) è un modo efficace per garantire che il traffico sia sicuro e attendibile in entrambe le direzioni tra un'istanza di Gestione API e un cluster del servizio Azure Kubernetes.

L'autenticazione TLS reciproca è supportata in modo nativo da Gestione API e può essere abilitata in Kubernetes tramite l'installazione di un controller in ingresso (figura 3). Di conseguenza, l'autenticazione verrà eseguita nel controller di ingresso, semplificando i microservizi. Inoltre, è possibile aggiungere gli indirizzi IP di Gestione API all'elenco consentito in ingresso per assicurarsi che solo Gestione API abbia accesso al cluster.

Vantaggi:

• Configurazione semplice sul lato di Gestione API perché non deve essere inserita nella rete virtuale del cluster e mTLS è supportato in modo nativo
• Centralizza la protezione per il traffico del cluster in ingresso a livello di controller in ingresso
• Limita il rischio di sicurezza riducendo al minimo gli endpoint del cluster visibili pubblicamente

Svantaggi:

• Aumenta la complessità della configurazione del cluster a causa di operazioni aggiuntive per installare, configurare e mantenere il controller in ingresso e gestire i certificati usati per mTLS
• Rischio di sicurezza dovuto alla visibilità pubblica degli endpoint del controller in ingresso

Quando si pubblicano le API con Gestione API, è facile e comune proteggere l'accesso a tali API usando le chiavi di sottoscrizione. Gli sviluppatori che devono utilizzare le API pubblicate devono includere una chiave di sottoscrizione valida nelle richieste HTTP quando effettuano chiamate a tali API. In caso contrario, le chiamate vengono rifiutate immediatamente dal gateway di Gestione API. Non vengono inoltrate ai servizi back-end.

Per ottenere una chiave di sottoscrizione per l'accesso alle API, è necessaria una sottoscrizione. Una sottoscrizione è essenzialmente un contenitore denominato per una coppia di chiavi di sottoscrizione. Gli sviluppatori che devono utilizzare le API pubblicate possono ottenere sottoscrizioni. E non è necessaria l'approvazione da parte degli editori delle API. Gli editori delle API possono anche creare sottoscrizioni direttamente per i consumer di API.

Opzione 3: Distribuire Gestione API all'interno della rete virtuale del cluster

In alcuni casi, i clienti con vincoli normativi o requisiti di sicurezza rigorosi possono trovare le opzioni 1 e 2 soluzioni non valide a causa di endpoint esposti pubblicamente. In altri casi, il cluster del servizio Azure Kubernetes e le applicazioni che usano i microservizi potrebbero risiedere nella stessa rete virtuale, pertanto non esiste alcun motivo per esporre il cluster pubblicamente perché tutto il traffico API rimarrà all'interno della rete virtuale. Per questi scenari, è possibile distribuire Gestione API nella rete virtuale del cluster. I livelli Developer e Premium di Gestione API supportano la distribuzione della rete virtuale.

Esistono due modalità di distribuzione di Gestione API in una rete virtuale, esterna e interna.

Se i consumer di API non risiedono nella rete virtuale del cluster, è necessario usare la modalità esterna (fig. 4). In questa modalità, il gateway di Gestione API viene inserito nella rete virtuale del cluster, ma è accessibile da Internet pubblico tramite un servizio di bilanciamento del carico esterno. Aiuta a nascondere completamente il cluster, consentendo comunque ai client esterni di utilizzare i microservizi. È anche possibile usare funzionalità di rete di Azure, ad esempio gruppi di sicurezza di rete (NSG) per limitare il traffico di rete.

Se tutti i consumer di API si trovano all'interno della rete virtuale del cluster, è possibile usare la modalità interna (fig. 5). In questa modalità, il gateway di Gestione API viene inserito nella rete virtuale del cluster ed è accessibile da questa rete virtuale solo tramite un servizio di bilanciamento del carico esterno. Non è possibile raggiungere il gateway di Gestione API o il cluster del servizio Azure Kubernetes da Internet pubblico.

In entrambi i casi, il cluster del servizio Azure Kubernetes non è visibile pubblicamente. Rispetto all'opzione 2, il controller in ingresso potrebbe non essere necessario. A seconda dello scenario e della configurazione, l'autenticazione potrebbe essere comunque necessaria tra Gestione API e i microservizi. Ad esempio, se viene adottata una mesh di servizi, richiede sempre l'autenticazione TLS reciproca.

Vantaggi:

• L'opzione più sicura perché il cluster del servizio Azure Kubernetes non ha alcun endpoint pubblico
• Semplifica la configurazione del cluster perché non ha alcun endpoint pubblico
• Possibilità di nascondere sia Gestione API che il servizio Azure Kubernetes all'interno della rete virtuale usando la modalità interna
• Possibilità di controllare il traffico di rete usando le funzionalità di rete di Azure, ad esempio gruppi di sicurezza di rete (NSG)

Svantaggi:

• Aumenta la complessità della distribuzione e della configurazione di Gestione API per funzionare all'interno della rete virtuale

Passaggi successivi

• Altre informazioni su Concetti relativi alla rete per le applicazioni nel servizio Azure Kubernetes
• Altre informazioni su Come usare Gestione API con reti virtuali