Accedere a un server API del servizio Azure Kubernetes servizio Azure Kubernetes

Azure Bastion
Azure ExpressRoute
Servizio Azure Kubernetes
Collegamento privato di Azure
Gateway VPN di Azure

Questa guida descrive varie opzioni per la connessione al server API del cluster servizio Azure Kubernetes (servizio Azure Kubernetes). Con un cluster del servizio Azure Kubernetes standard, il server API viene esposto tramite Internet. Se si crea un cluster del servizio Azure Kubernetes privato, è possibile connettersi al server API solo da un dispositivo con connettività di rete al cluster privato.

La pianificazione dell'accesso al server API è un'attività giornaliera zero. Il modo in cui si sceglie di accedere al server API dipende dallo scenario di distribuzione.

Accesso al server API del servizio Azure Kubernetes

Per gestire un cluster del servizio Azure Kubernetes, interagire con il relativo server API. È fondamentale bloccare l'accesso al server API e concedere l'accesso solo agli utenti che ne hanno bisogno. È possibile fornire un accesso granulare integrando il cluster del servizio Azure Kubernetes con Microsoft Entra ID. Amministrazione istrator può quindi usare il controllo degli accessi in base al ruolo per limitare l'accesso. Tramite il controllo degli accessi in base al ruolo, gli amministratori possono inserire utenti e identità nei gruppi di Microsoft Entra e assegnare ruoli e autorizzazioni appropriati ai gruppi. L'autenticazione Di Microsoft Entra viene fornita ai cluster del servizio Azure Kubernetes con OpenID Connessione. Per ulteriori informazioni, vedi queste risorse:

Nota

È possibile bloccare ulteriormente il cluster del servizio Azure Kubernetes consentendo solo agli intervalli di indirizzi IP autorizzati di comunicare con il server API. Per altre informazioni, vedere Proteggere l'accesso al server API usando intervalli di indirizzi IP autorizzati in servizio Azure Kubernetes (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.

Accedere al cluster del servizio Azure Kubernetes tramite Internet

Quando si crea un cluster non privato che si risolve nel nome di dominio completo (FQDN) del server API, al server API viene assegnato un indirizzo IP pubblico per impostazione predefinita. È quindi possibile usare il portale di Azure per connettersi al cluster oppure usare una shell come l'interfaccia della riga di comando di Azure, PowerShell o il prompt dei comandi.

Nota

Per informazioni dettagliate sull'uso del client kubectl della riga di comando Kubernetes per connettersi a un cluster tramite Internet, vedere Connessione al cluster.

Azure Cloud Shell

Cloud Shell è una shell integrata nel portale di Azure. È possibile gestire e connettersi alle risorse di Azure da Cloud Shell nello stesso modo in cui si esegue da PowerShell o dall'interfaccia della riga di comando di Azure. Per altre informazioni, vedere Panoramica di Azure Cloud Shell.

Accedere a un cluster privato del servizio Azure Kubernetes

Esistono molti modi per connettersi a un cluster privato del servizio Azure Kubernetes. La pianificazione dell'accesso al cluster privato del servizio Azure Kubernetes è un'attività giornaliera che dipende dalle esigenze e dalle limitazioni dello scenario. È possibile connettersi al cluster privato usando i componenti e i servizi seguenti:

Nota

SSH, Remote Desktop Protocol (RDP) e Servizi Desktop remoto sono protocolli alternativi che è possibile usare per controllare le jumpbox in remoto.

Usare Azure Bastion

Azure Bastion è una piattaforma distribuita come servizio (PaaS) che viene distribuita all'interno della rete virtuale per connettersi a una macchina virtuale in tale rete, ad esempio una jump box. Per connettersi, usare RDP o SSH da un browser all'interno del portale di Azure. Il protocollo Tls (Transport Layer Security) protegge la connessione. In genere è presente un indirizzo IP pubblico associato alla scheda di interfaccia di rete (NIC) della macchina virtuale. Questo indirizzo consente di connettersi alla macchina virtuale. Quando si usa Azure Bastion, non è più necessario associare un indirizzo IP pubblico alla jump box.

Quando ci si connette al server API del cluster del servizio Azure Kubernetes, è consigliabile usare una connessione attendibile. Un'opzione consiste nell'usare Azure Bastion per connettersi a una jump box all'interno dell'ambiente Azure. In questo scenario, la jump box si trova nella rete virtuale hub. Il cluster del servizio Azure Kubernetes privato risiede in una rete virtuale spoke. Un peering di rete virtuale connette le reti hub-spoke.

La jump box può risolvere il nome di dominio completo del server API usando l'endpoint privato di Azure, una zona DNS privata e un record DNS A all'interno della zona DNS privata. Usando il cluster privato del servizio Azure Kubernetes e l'endpoint privato, assicurarsi che il nome di dominio completo del server API possa essere risolto solo dall'interno della rete virtuale. Con un cluster privato, il browser deve essere eseguito in un computer che ha accesso alla rete virtuale del cluster privato del servizio Azure Kubernetes. Per altre informazioni, vedere Subnet per ospitare Azure Bastion.

Nota

La disponibilità e la ridondanza del jump box sono fondamentali. Dovresti sempre essere in grado di raggiungere il tuo jump box. Analogamente, dovrebbe essere sempre possibile raggiungere il cluster del servizio Azure Kubernetes privato. Per ottenere disponibilità e ridondanza per i jumpbox, inserirli nei set di disponibilità e usare set di scalabilità di macchine virtuali con un numero ridotto di istanze di macchina virtuale. Per ulteriori informazioni, vedi queste risorse:

Architecture diagram that shows the traffic route from a user to a private AKS cluster. The traffic flows through Azure Bastion and a jump box.

Scaricare un file di Visio di questa architettura.

Flusso di dati

  1. Un utente tenta di connettersi a una jump box usando Azure Bastion e un browser HTML5 con crittografia TLS.
  2. L'utente sceglie dal portale se usare RDP o SSH per connettersi alla jump box.
  3. L'utente accede al jump box tramite Azure Bastion. Il tentativo di connessione al cluster privato del servizio Azure Kubernetes viene eseguito da questa jump box. La rete virtuale hub ha un collegamento di rete virtuale alla zona DNS privata del servizio Azure Kubernetes per risolvere il nome di dominio completo del cluster privato.
  4. La rete virtuale hub e la rete virtuale spoke comunicano tra loro usando un peering di rete virtuale.
  5. Per raggiungere il cluster del servizio Azure Kubernetes privato, il traffico entra nel backbone di Azure. Un endpoint privato stabilisce una connessione privata isolata al cluster del servizio Azure Kubernetes privato.
  6. Il traffico raggiunge il server API del cluster del servizio Azure Kubernetes privato. L'utente può quindi gestire pod, nodi e applicazioni.

Nota

Il nome di dominio completo del cluster privato può comunque essere risolto dall'esterno della rete virtuale se non si disabilita in modo esplicito il nome di dominio completo pubblico. Per informazioni sulla disabilitazione del nome di dominio completo pubblico del cluster privato del servizio Azure Kubernetes, vedere Disabilitare il nome di dominio completo pubblico in un cluster esistente.

Risolvere i problemi di connessione

Se non è possibile connettersi al cluster privato:

  • Controllare il peering di rete virtuale. Questo meccanismo fornisce connettività da rete a rete tra due reti virtuali. Per consentire il flusso del traffico tra queste due reti, è necessario stabilire il peering di rete virtuale tra di essi. Quando si stabilisce un peering di rete virtuale, viene inserita una route nella tabella di route di sistema della rete virtuale. Tale route fornisce un percorso per raggiungere lo spazio degli indirizzi di destinazione. Per altre informazioni sulla risoluzione dei problemi relativi ai peering di rete virtuale, vedere Creare, modificare o eliminare un peering di rete virtuale.

    Nota

    Non è necessario un peering di rete virtuale se la jump box si trova nella stessa rete virtuale dell'endpoint privato e del cluster privato del servizio Azure Kubernetes.

  • Controllare il collegamento alla rete virtuale alla zona DNS privata. I collegamenti di rete virtuale consentono alle macchine virtuali che si trovano all'interno di reti virtuali di connettersi a una zona DNS privata e risolvere i record DNS all'interno della zona. Se non è possibile connettersi al cluster del servizio Azure Kubernetes privato o non è possibile risolvere il nome di dominio completo del cluster privato, verificare se la rete virtuale ha un collegamento di rete virtuale alla zona DNS privata. Il nome della zona DNS privata deve avere il formato seguente:

    privatelink.<region>.azmk8s.io

    Per altre informazioni sulla risoluzione dei problemi relativi ai collegamenti di rete virtuale, vedere queste risorse:

    Nota

    Non è necessario un collegamento di rete virtuale se la jump box si trova nella stessa rete virtuale dell'endpoint privato e del cluster privato del servizio Azure Kubernetes. Quando si crea un cluster del servizio Azure Kubernetes privato, viene creata una zona DNS privata con un collegamento di rete virtuale alla rete virtuale che ospita il cluster del servizio Azure Kubernetes privato.

Migliorare la sicurezza

Per proteggere ulteriormente i carichi di lavoro del servizio Azure Kubernetes e i jumpbox, è possibile usare l'accesso JIT (Just-In-Time) e una workstation con accesso con privilegi (PAW).

La funzionalità di accesso JIT di Microsoft Defender per il cloud riduce il panorama delle minacce. Gli utenti malintenzionati spesso usano le porte RDP e SSH usate per connettersi al jump box. La funzionalità di accesso JIT usa gruppi di sicurezza di rete o Firewall di Azure per bloccare tutto il traffico in ingresso nella jump box. Se un utente tenta di connettersi alla jump box con autorizzazioni di controllo degli accessi in base al ruolo appropriate, questa funzionalità configura i gruppi di sicurezza di rete o Firewall di Azure per consentire l'accesso in ingresso alle porte selezionate per un periodo di tempo specificato. Dopo tale scadenza, le porte negano tutto il traffico in ingresso. Per altre informazioni sull'accesso JIT, vedere Informazioni sull'accesso JIT alle macchine virtuali.

Le workstation PAW sono dispositivi fisici con protezione avanzata che forniscono la configurazione di sicurezza più elevata possibile per gli operatori. Per adottare una buona strategia di accesso con privilegi, usare una workstation PAW per connettersi al jump box e al cluster del servizio Azure Kubernetes. È difficile compromettere le workstation PAW, perché bloccano molti vettori di attacco comuni, ad esempio la posta elettronica e l'esplorazione Web. Per altre informazioni sulle workstation PAW, vedere Protezione dei dispositivi come parte della storia di accesso con privilegi.

Usare una rete privata virtuale

Una connessione VPN offre connettività ibrida dall'ambiente locale ad Azure. È necessaria la connettività all'infrastruttura di rete virtuale interna per accedere a un cluster privato del servizio Azure Kubernetes. Il server API del cluster privato non può essere raggiunto all'esterno delle reti virtuali.

Una VPN consente di raggiungere il cluster del servizio Azure Kubernetes privato. Quando si usa una connessione VPN, è possibile raggiungere l'infrastruttura di rete virtuale in Azure tramite un tunnel crittografato. Dopo la connessione al gateway di rete virtuale, è possibile raggiungere la jump box. Da qui è possibile connettersi al server API del cluster privato.

Architecture diagram that shows traffic flow from a user to a private AKS cluster. The route includes a VPN gateway, an IPsec tunnel, and a jump box.

Scaricare un file di Visio di questa architettura.

Flusso di dati

  1. Un utente avvia il traffico RDP o SSH verso la jump box da una workstation locale.
  2. Il traffico jump box lascia i router perimetrali del cliente e l'appliance VPN. Il traffico usa un tunnel IPsec crittografato per attraversare Internet.
  3. Il traffico jump box raggiunge il gateway di rete virtuale in Azure, ovvero il punto di ingresso e uscita dell'infrastruttura di rete virtuale di Azure.
  4. Dopo che il traffico si sposta oltre il gateway di rete virtuale, raggiunge la jump box. Il tentativo di connessione al cluster privato del servizio Azure Kubernetes viene eseguito dal jump box. La rete virtuale hub ha un collegamento di rete virtuale alla zona DNS privata del servizio Azure Kubernetes per risolvere il nome di dominio completo del cluster privato.
  5. La rete virtuale hub e la rete virtuale spoke comunicano tra loro usando un peering di rete virtuale.
  6. Per raggiungere il cluster del servizio Azure Kubernetes privato, il traffico entra nel backbone di Azure. Un endpoint privato stabilisce una connessione privata isolata al cluster del servizio Azure Kubernetes privato.
  7. Il traffico raggiunge il server API del cluster del servizio Azure Kubernetes privato. L'utente può quindi gestire pod, nodi e applicazioni.

Usare ExpressRoute

ExpressRoute è un'altra opzione che è possibile usare per stabilire la connettività al cluster privato del servizio Azure Kubernetes da un ambiente locale. ExpressRoute usa Border Gateway Protocol (BGP) per scambiare route tra la rete locale, le istanze in Azure e gli indirizzi pubblici Microsoft. Questo scambio fornisce risorse IaaS (Infrastructure as a Service) in Azure e workstation locali un percorso l'uno all'altro. ExpressRoute offre una connessione dedicata e isolata mantenendo al contempo una larghezza di banda e una latenza coerenti per gli ambienti aziendali.

Architecture diagram that shows the traffic route from a user to a private AKS cluster. The route includes ExpressRoute and a jump box.

Scaricare un file di Visio di questa architettura.

Flusso di dati

  1. Un utente avvia il traffico RDP o SSH verso la jump box da una workstation locale.
  2. Il traffico jump box lascia i router perimetrali dei clienti e viaggia su una connessione fiber alla posizione meet-me, dove risiede il circuito ExpressRoute. Il traffico raggiunge i dispositivi Microsoft Enterprise Edge (M edizione Standard E). Quindi entra nell'infrastruttura di Azure.
  3. Il traffico jumpbox raggiunge il gateway ExpressRoute, ovvero il punto di ingresso e uscita dell'infrastruttura di rete virtuale di Azure.
  4. Il traffico raggiunge la jump box. Il tentativo di connessione al cluster privato del servizio Azure Kubernetes viene eseguito dal jump box. La rete virtuale hub ha un collegamento di rete virtuale alla zona DNS privata del servizio Azure Kubernetes per risolvere il nome di dominio completo del cluster privato.
  5. La rete virtuale hub e la rete virtuale spoke comunicano tra loro usando un peering di rete virtuale.
  6. Per raggiungere il cluster del servizio Azure Kubernetes privato, il traffico entra nel backbone di Azure. Un endpoint privato stabilisce una connessione privata isolata al cluster del servizio Azure Kubernetes privato.
  7. Il traffico raggiunge il server API del cluster del servizio Azure Kubernetes privato. L'utente può quindi gestire pod, nodi e applicazioni.

Nota

ExpressRoute richiede un provider di connettività di terze parti per fornire una connessione di peering ai router M edizione Standard E. Il traffico di ExpressRoute non è crittografato. Per altre informazioni, vedere Che cos'è Azure ExpressRoute?.

Eseguire il comando del servizio Azure Kubernetes invoke

Con un cluster privato del servizio Azure Kubernetes, ci si connette al cluster privato da una macchina virtuale che ha accesso al server API del cluster. È possibile usare il comando dell'interfaccia della riga di comando aks command invoke di Azure per eseguire in remoto comandi come kubectl o helm nel cluster privato del servizio Azure Kubernetes tramite l'API di Azure. Quando si usa aks command invoke, viene creato un pod temporaneo in uno spazio dei nomi specifico all'interno del cluster. Il pod esiste solo per la durata del comando. Dall'interno del pod temporaneo è possibile eseguire comandi nel cluster privato.

È possibile usare aks command invoke come modo alternativo di connettersi al cluster privato se non si ha una VPN, ExpressRoute, una soluzione di connettività esterna o una rete virtuale con peering diretto alla rete virtuale del cluster. Prima di usare aks command invoke, controllare le risorse disponibili per il cluster e il pool di nodi. Le risorse insufficienti possono impedire la creazione del pod temporaneo.

Per altre informazioni, vedere Usare command invoke per accedere a un cluster del servizio Azure Kubernetes servizio Azure Kubernetes privato.

Connessione Cloud Shell a una subnet

Quando si distribuisce Cloud Shell in una rete virtuale che si controlla, è possibile interagire con le risorse all'interno di tale rete virtuale. Un'istanza di Cloud Shell viene in genere distribuita in un contenitore all'interno di una rete virtuale gestita da Microsoft. Tale contenitore non può interagire con le risorse in altre reti virtuali. Tuttavia, se si distribuisce un cluster privato del servizio Azure Kubernetes, è possibile connettere Cloud Shell a una subnet gestita con connettività al server API del cluster. È quindi possibile connettersi al cluster privato. Per altre informazioni, vedere Distribuire Cloud Shell in una rete virtuale di Azure.

Usare SSH e Visual Studio Code per il test

SSH è un protocollo che consente di gestire e accedere in modo sicuro ai file in un host remoto. Come parte del processo di autenticazione, SSH usa coppie di chiavi pubbliche-private.

Dal computer locale è possibile usare SSH e l'estensione SSH di Visual Studio Code Remote - SSH per connettersi a una jump box presente nella rete virtuale. Il tunnel SSH viene crittografato e la connessione termina sull'indirizzo IP pubblico collegato alla jump box. Questo approccio semplifica la modifica dei file manifesto di Kubernetes.

Per informazioni su come connettersi alla jump box tramite SSH, vedere Sviluppo remoto tramite SSH.

Se non è possibile connettersi alla macchina virtuale tramite SSH per gestire il cluster privato:

  • Controllare la regola del gruppo di sicurezza di rete in ingresso per la subnet della macchina virtuale. Quando ci si connette alla macchina virtuale in Azure tramite SSH, il gruppo di sicurezza di rete collegato alla subnet o alla scheda di interfaccia di rete della macchina virtuale ha una regola predefinita. Questa regola blocca tutto il traffico Internet in ingresso che ha origine all'esterno di Azure. Per superare questo ostacolo, creare una nuova regola del gruppo di sicurezza di rete in ingresso. Configurare la nuova regola per consentire il traffico SSH originato dall'indirizzo IP pubblico del computer locale.
  • Controllare il percorso del certificato. Quando si usa SSH, verificare la corretta posizione dei certificati. La chiave privata deve trovarsi nella directory del C:\Users\User\.ssh\id_rsa computer locale. La chiave pubblica deve essere inserita nel ~/.ssh/id_rsa.pub file nella macchina virtuale in Azure.

Nota

È consigliabile:

  • Non usare un indirizzo IP pubblico per connettersi alle risorse in un ambiente di produzione. Usare indirizzi IP pubblici solo negli scenari di sviluppo e test. Come descritto in precedenza in questa sezione, è necessario creare una regola del gruppo di sicurezza di rete in ingresso in tali ambienti. Questa regola deve consentire al traffico dall'indirizzo IP pubblico del computer locale di accedere all'ambiente. Per altre informazioni sulle regole del gruppo di sicurezza di rete, vedere Creare, modificare o eliminare un gruppo di sicurezza di rete.
  • Non usare SSH per connettersi direttamente ai nodi o ai contenitori del servizio Azure Kubernetes. In altre parole, non usare il sistema di destinazione di gestione come strumento di gestione, perché questo approccio non è affidabile. È preferibile usare una soluzione dedicata esterna al cluster. Tenere presente questo punto quando si valuta se aks command invoke è appropriato per la distribuzione, perché l'uso di questo comando crea un pod temporaneo all'interno del cluster per l'accesso proxy.

Conclusione

  • È possibile accedere al server API del cluster del servizio Azure Kubernetes tramite Internet se il nome di dominio completo pubblico non è disabilitato.
  • Cloud Shell è una shell della riga di comando predefinita nella portale di Azure che è possibile usare per connettersi a un cluster del servizio Azure Kubernetes.
  • Per un modo più sicuro e bloccato per accedere al cluster privato, usare Azure Bastion e un endpoint privato.
  • Vpn ed ExpressRoute consentono entrambi di facilitare la connettività ibrida al cluster del servizio Azure Kubernetes privato.
  • È possibile eseguire aks command invoke in remoto per connettersi al cluster privato del servizio Azure Kubernetes se non si ha una soluzione di connettività esterna.
  • È possibile distribuire Cloud Shell direttamente in una rete virtuale gestita. Cloud Shell può accedere al cluster privato da una rete virtuale gestita.
  • È possibile usare Visual Studio Code e SSH per connettersi a una jump box. Questo approccio crittografa la connessione al jump box, consente di accedere al cluster privato dall'interno della macchina virtuale e semplifica la modifica dei file manifesto negli scenari di sviluppo. Tuttavia, in questo modo la connessione espone un indirizzo IP pubblico nell'ambiente.

Collaboratori

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

Autori principali:

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi