Panoramica del gateway self-hosted

Il gateway self-hosted è una versione facoltativa in contenitori del gateway gestito predefinito incluso in ogni servizio Gestione API. È utile per scenari come l'inserimento di gateway negli stessi ambienti in cui si ospitano le API. Usare il gateway self-hosted per migliorare il flusso del traffico api e soddisfare i requisiti di sicurezza e conformità delle API.

Questo articolo illustra come la funzionalità gateway self-hosted di Azure Gestione API abilita la gestione API ibrida e multi-cloud, presenta l'architettura di alto livello ed evidenzia le sue funzionalità.

Per una panoramica delle funzionalità nelle varie offerte di gateway, vedere Gateway API in Gestione API.

Gestione API ibrida e multi-cloud

La funzionalità gateway self-hosted espande Gestione API supporto per ambienti ibridi e multi-cloud e consente alle organizzazioni di gestire in modo efficiente e sicuro le API ospitate in locale e tra cloud da un singolo servizio Gestione API in Azure.

Con il gateway self-hosted, i clienti hanno la flessibilità di distribuire una versione in contenitori del componente gateway Gestione API negli stessi ambienti in cui ospitano le API. Tutti i gateway self-hosted vengono gestiti dal servizio Gestione API con cui sono federati, offrendo così ai clienti la visibilità e l'esperienza di gestione unificata in tutte le API interne ed esterne.

Ogni servizio Gestione API è costituito dai componenti chiave seguenti:

  • Piano di gestione, esposto come API, usato per configurare il servizio tramite il portale di Azure, PowerShell e altri meccanismi supportati.
  • Gateway (o piano dati), responsabile del proxy delle richieste API, dell'applicazione dei criteri e della raccolta dei dati di telemetria
  • Portale per sviluppatori usato dagli sviluppatori per individuare, apprendere ed eseguire l'onboarding per usare le API

Per impostazione predefinita, tutti questi componenti vengono distribuiti in Azure, causando il flusso di tutto il traffico api (mostrato come frecce nere solide nell'immagine seguente) attraverso Azure indipendentemente dalla posizione in cui sono ospitati i back-end che implementano le API. La semplicità operativa di questo modello comporta un aumento della latenza, dei problemi di conformità e, in alcuni casi, costi aggiuntivi per il trasferimento dei dati.

Flusso del traffico API senza gateway self-hosted

La distribuzione di gateway self-hosted negli stessi ambienti in cui sono ospitate le implementazioni dell'API back-end consente al traffico API di passare direttamente alle API back-end, riducendo la latenza, ottimizzando i costi di trasferimento dei dati e garantendo al tempo stesso la conformità mantenendo i vantaggi di avere un singolo punto di gestione, osservabilità e individuazione di tutte le API all'interno dell'organizzazione indipendentemente dalla posizione in cui sono ospitate le implementazioni.

Flusso del traffico API con gateway self-hosted

Packaging

Il gateway self-hosted è disponibile come immagine del contenitore Docker basata su Linux dal Registro artefatti Microsoft. Può essere distribuito in Docker, Kubernetes o in qualsiasi altra soluzione di orchestrazione dei contenitori in esecuzione in un cluster server locale, infrastruttura cloud o per scopi di valutazione e sviluppo in un personal computer. È anche possibile distribuire il gateway self-hosted come estensione del cluster in un cluster Kubernetes abilitato per Azure Arc.

Immagini contenitore

Sono disponibili un'ampia gamma di immagini del contenitore per i gateway self-hosted per soddisfare le proprie esigenze:

Convenzione tag Recommendation Esempio Tag in sequenza Consigliato per la produzione
{major}.{minor}.{patch} Usare questo tag per eseguire sempre la stessa versione del gateway 2.0.0 ✔️
v{major} Usare questo tag per eseguire sempre una versione principale del gateway con ogni nuova funzionalità e patch. v2 ✔️
v{major}-preview Usare questo tag se si vuole sempre eseguire l'immagine del contenitore di anteprima più recente. v2-preview ✔️
latest Usare questo tag se si vuole valutare il gateway self-hosted. latest ✔️

È possibile trovare un elenco completo dei tag disponibili qui.

Uso dei tag nelle opzioni di distribuzione ufficiali

Le opzioni di distribuzione nel portale di Azure usano il v2 tag che consente ai clienti di usare la versione più recente dell'immagine del contenitore del gateway self-hosted v2 con tutti gli aggiornamenti e le patch delle funzionalità.

Nota

Vengono forniti i frammenti di comando e YAML come riferimento, è possibile usare un tag più specifico se si vuole.

Quando si esegue l'installazione con il grafico Helm, l'assegnazione di tag alle immagini è ottimizzata per l'utente. La versione dell'applicazione del grafico Helm aggiunge il gateway a una determinata versione e non si basa su latest.

Altre informazioni su come installare un gateway self-hosted Gestione API in Kubernetes con Helm.

Rischio di uso di tag in sequenza

I tag in sequenza sono tag potenzialmente aggiornati quando viene rilasciata una nuova versione dell'immagine del contenitore. Ciò consente agli utenti del contenitore di ricevere aggiornamenti all'immagine del contenitore senza dover aggiornare le distribuzioni.

Ciò significa che è possibile eseguire versioni diverse in parallelo senza notare, ad esempio quando si eseguono azioni di ridimensionamento dopo v2 l'aggiornamento del tag.

Esempio: v2 il tag è stato rilasciato con 2.0.0 l'immagine del contenitore, ma quando 2.1.0 verrà rilasciato, il v2 tag verrà collegato all'immagine 2.1.0 .

Importante

È consigliabile usare un tag di versione specifico nell'ambiente di produzione per evitare l'aggiornamento involontario a una versione più recente.

Connettività ad Azure

I gateway self-hosted richiedono la connettività TCP/IP in uscita ad Azure sulla porta 443. Ogni gateway self-hosted deve essere associato a un singolo servizio Gestione API ed è configurato tramite il relativo piano di gestione. Un gateway self-hosted usa la connettività ad Azure per:

  • Segnalazione dello stato inviando messaggi heartbeat ogni minuto
  • Verificare regolarmente (ogni 10 secondi) e applicare gli aggiornamenti di configurazione ogni volta che sono disponibili
  • Invio di metriche a Monitoraggio di Azure, se configurato per eseguire questa operazione
  • Invio di eventi ad Application Insights, se impostato su questa operazione

Importante

Il supporto per Azure Gestione API le immagini del contenitore self-hosted versione 0 e 1 del contenitore terminano il 1° ottobre 2023, insieme all'API di configurazione corrispondente v1. Usare la guida alla migrazione per usare il gateway self-hosted v2.0.0 o versione successiva con l'API di configurazione v2. Per altre informazioni, vedere la documentazione relativa alla deprecazione

Dipendenze FQDN

Per funzionare correttamente, ogni gateway self-hosted richiede la connettività in uscita sulla porta 443 agli endpoint seguenti associati all'istanza di Gestione API basata sul cloud:

Descrizione Obbligatorio per v1 Obbligatorio per la versione 2 Note
Nome host dell'endpoint di configurazione <apim-service-name>.management.azure-api.net <apim-service-name>.configuration.azure-api.net
Indirizzo IP pubblico dell'istanza di Gestione API ✔️ ✔️ Gli indirizzi IP della posizione primaria sono sufficienti.
Indirizzi IP pubblici del tag del servizio archiviazione di Azure ✔️ Facoltativo1 Gli indirizzi IP devono corrispondere alla posizione primaria dell'istanza di Gestione API.
Nome host dell'account Archiviazione BLOB di Azure ✔️ Facoltativo1 Account associato all'istanza (<blob-storage-account-name>.blob.core.windows.net)
Nome host dell'account di archiviazione tabelle di Azure ✔️ Facoltativo1 Account associato all'istanza (<table-storage-account-name>.table.core.windows.net)
Endpoint per l'integrazione di applicazione Azure Insights Facoltativo2 Facoltativo2 Gli endpoint necessari minimi sono:rt.services.visualstudio.com:443dc.services.visualstudio.com:443{region}.livediagnostics.monitor.azure.com:443Altre informazioni nella documentazione di Monitoraggio di Azure
Endpoint per l'integrazione di Hub eventi Facoltativo2 Facoltativo2 Altre informazioni sono disponibili nella documentazione di Hub eventi di Azure
Endpoint per l'integrazione della cache esterna Facoltativo2 Facoltativo2 Questo requisito dipende dalla cache esterna usata

1 È necessario solo in v2 quando vengono usati controlli API o quote nei criteri. 2 È necessario solo quando viene usata la funzionalità e richiede informazioni sull'indirizzo IP pubblico, sulla porta e sul nome host.

Importante

  • I nomi host DNS devono essere risolvibili agli indirizzi IP e gli indirizzi IP corrispondenti devono essere raggiungibili.
  • I nomi degli account di archiviazione associati sono elencati nella pagina stato della connettività di rete del servizio nella portale di Azure.
  • Gli indirizzi IP pubblici sottostanti gli account di archiviazione associati sono dinamici e possono cambiare senza preavviso.

Errori di connettività

Quando la connettività ad Azure viene persa, il gateway self-hosted non è in grado di ricevere aggiornamenti di configurazione, segnalarne lo stato o caricare i dati di telemetria.

Il gateway self-hosted è progettato per "fail static" e può sopravvivere alla perdita temporanea della connettività ad Azure. Può essere distribuito con o senza backup di configurazione locale. Con il backup della configurazione, i gateway self-hosted salvano regolarmente una copia di backup della configurazione scaricata più recente in un volume persistente collegato al contenitore o al pod.

Quando il backup della configurazione viene disattivato e la connettività ad Azure viene interrotta:

  • L'esecuzione di gateway self-hosted continuerà a funzionare usando una copia in memoria della configurazione
  • I gateway self-hosted arrestati non saranno in grado di avviare

Quando il backup della configurazione è attivato e la connettività ad Azure viene interrotta:

  • L'esecuzione di gateway self-hosted continuerà a funzionare usando una copia in memoria della configurazione
  • I gateway self-hosted arrestati potranno iniziare a usare una copia di backup della configurazione

Quando la connettività viene ripristinata, ogni gateway self-hosted interessato dall'interruzione riconnetterà automaticamente il servizio Gestione API associato e scarica tutti gli aggiornamenti di configurazione che si sono verificati mentre il gateway era "offline".

Sicurezza

Limitazioni

Le funzionalità seguenti trovate nei gateway gestiti non sono disponibili nei gateway self-hosted:

  • Ripresa della sessione TLS.
  • Rinegoziazione del certificato client. Per usare l'autenticazione del certificato client, i consumer dell'API devono presentare i certificati come parte dell'handshake TLS iniziale. Per garantire questo comportamento, abilitare l'impostazione Negozia certificato client durante la configurazione di un nome host personalizzato del gateway self-hosted (nome di dominio).

Transport Layer Security (TLS)

Importante

Questa panoramica è applicabile solo al gateway self-hosted v1 & v2.

Protocolli supportati

Il gateway self-hosted fornisce il supporto per TLS v1.2 per impostazione predefinita.

I clienti che usano domini personalizzati possono abilitare TLS v1.0 e/o v1.1 nel piano di controllo.

Suite di crittografia disponibili

Importante

Questa panoramica è applicabile solo al gateway self-hosted v2.

Il gateway self-hosted usa le suite di crittografia seguenti per le connessioni client e server:

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA

Gestione di pacchetti di crittografia

A partire da v2.1.1 e versioni successive, è possibile gestire le crittografia usate tramite la configurazione:

  • net.server.tls.ciphers.allowed-suites consente di definire un elenco delimitato da virgole di crittografia da usare per la connessione TLS tra il client API e il gateway self-hosted.
  • net.client.tls.ciphers.allowed-suites consente di definire un elenco delimitato da virgole di crittografia da usare per la connessione TLS tra il gateway self-hosted e il back-end.

Passaggi successivi