Accedere a un server API del servizio Azure Kubernetes

Questa guida illustra le opzioni per la connessione al server API del cluster del servizio Azure Kubernetes. In un cluster del servizio Azure Kubernetes standard il server API viene esposto tramite Internet. In un cluster del servizio Azure Kubernetes privato è possibile connettersi solo da un dispositivo con accesso di rete al cluster privato.

La pianificazione dell'accesso al server API è un'attività senza giorno e il metodo di accesso 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. È essenziale limitare l'accesso del server API solo agli utenti necessari. L'accesso granulare può essere fornito integrando il cluster del servizio Azure Kubernetes con Microsoft Entra ID. Gli amministratori possono usare il controllo degli accessi in base al ruolo per gestire l'accesso, posizionare utenti e identità nei gruppi entra e assegnare ruoli e autorizzazioni appropriati. L'autenticazione Di Microsoft Entra è abilitata nei cluster del servizio Azure Kubernetes tramite OpenID Connect. Per altre informazioni, vedere queste risorse:

• 'integrazione di Microsoft Entra gestita dal servizio Azure Kubernetes
• integrare l'ID Microsoft Entra per il cluster

Protezione DDoS di Azure, insieme alle procedure consigliate per la progettazione delle applicazioni, offre funzionalità di mitigazione avanzate contro gli 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, viene assegnato un indirizzo IP pubblico per impostazione predefinita. È possibile connettersi al cluster usando il portale di Azure o una shell, ad esempio l'interfaccia della riga di comando di Azure, PowerShell o il prompt dei comandi.

Azure Cloud Shell

Cloud Shell è una shell incorporata nel portale di Azure. È possibile gestire e connettersi alle risorse di Azure da Cloud Shell come si farebbe da PowerShell o dall'interfaccia della riga di comando di Azure. Per altre informazioni, vedere Panoramica di Azure Cloud Shell.

Accedere al cluster privato del servizio Azure Kubernetes

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

• Jump box distribuito in una subnet come workstation operativa. Può trattarsi di di macchine virtuali permanenti autonome in un set di disponibilità . È anche possibile usare set di scalabilità di macchine virtuali di Azure.
• Azure Bastion.
• rete privata virtuale (VPN).
• Azure ExpressRoute.
• L'interfaccia della riga di comando di Azure comando del servizio Azure Kubernetes richiama.
• 'istanza di Cloud Shell distribuita in una subnet connessa al server API per il cluster.
• Desktop virtuale Azure. Se il team si connette in remoto da vari sistemi operativi, è possibile usare questo servizio per fornire l'accesso alle macchine virtuali Windows usate come jumpbox.
• Istanze di Azure Container e un client OpenSSHcompatibile con SSH (Secure Shell).

Azure Bastion

Azure Bastion è un'offerta PaaS che consente connessioni RDP o SSH sicure a una macchina virtuale all'interno della rete virtuale, senza richiedere un indirizzo IP pubblico nella macchina virtuale. Quando ci si connette a un cluster del servizio Azure Kubernetes privato, è possibile usare Azure Bastion per accedere a una jump box nella rete virtuale hub, mentre il cluster del servizio Azure Kubernetes si trova in una rete spoke. Un peering di rete virtuale viene usato per connettere la rete hub-spoke. Il jumpbox può risolvere il nome di dominio completo del server API del servizio Azure Kubernetes usando l'endpoint privato di Azure, una zona DNS privata e un record A DNS. Questa configurazione garantisce che il nome di dominio completo del server API sia risolvibile solo all'interno della rete virtuale, fornendo una connessione attendibile al cluster del servizio Azure Kubernetes privato.

Scaricare un file di Visio di questa architettura.

Flusso

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.

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:

  • di peering di rete virtuale
  • Che cos'è un collegamento di rete virtuale?

  Nota

  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).

Per proteggere i carichi di lavoro del servizio Azure Kubernetes e i jumpbox, usare l'accesso JIT (Just-In-Time) e una workstation con accesso con privilegi (PAW). L'accesso JIT, parte di Microsoft Defender for Cloud, riduce il panorama delle minacce bloccando il traffico in ingresso alla jump box e consentendo l'accesso solo per un periodo di tempo specificato quando necessario. Dopo la scadenza, l'accesso viene revocato automaticamente. Per altre informazioni sull'accesso JIT, vedere Understanding just-in-time (JIT) VM access.

Le workstation PAW sono dispositivi con protezione avanzata che forniscono sicurezza elevata per gli operatori bloccando vettori di attacco comuni come posta elettronica e esplorazione Web. È 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.

Rete privata virtuale (VPN)

Una connessione VPN offre connettività ibrida dall'ambiente locale ad Azure, consentendo l'accesso a un cluster del servizio Azure Kubernetes privato. Il server API del cluster privato non è raggiungibile all'esterno delle reti virtuali. Con una VPN è possibile connettersi alla rete virtuale in Azure tramite un tunnel crittografato, quindi accedere alla jump box e, da questa posizione, connettersi al server API del cluster privato.

Scaricare un file di Visio di questa architettura.

Flusso

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.

ExpressRoute

ExpressRoute offre connettività al cluster privato del servizio Azure Kubernetes da un ambiente locale. ExpressRoute usa Border Gateway Protocol (BGP) per scambiare le route tra la rete locale e Azure creando un percorso tra le risorse IaaS e le workstation locali. ExpressRoute offre una connessione dedicata e isolata con larghezza di banda e latenza coerenti, rendendola ideale per gli ambienti aziendali.

Scaricare un file di Visio di questa architettura.

Flusso

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 (MSEE) lì. 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.

Eseguire il comando del servizio Azure Kubernetes invoke

Con un cluster privato del servizio Azure Kubernetes è possibile connettersi da una macchina virtuale che ha accesso al server API. Usando l'interfaccia della riga di comando di Azure aks command invoke, è possibile eseguire comandi come kubectl o helm in remoto tramite l'API di Azure. In questo modo viene creato un pod temporaneo nel cluster, che dura solo durante il comando. Il aks command invoke funge da metodo di connessione alternativo se manca una rete virtuale VPN, ExpressRoute o con peering. Assicurarsi che il cluster e il pool di nodi dispongano di risorse sufficienti per creare il pod temporaneo.

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

Connettere 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. La distribuzione di Cloud Shell in una subnet gestita consente la connettività al server API di un cluster privato del servizio Azure Kubernetes. In questo modo è 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 gestisce e accede in modo sicuro ai file in un host remoto usando coppie di chiavi pubbliche-private. Dal computer locale è possibile usare SSH con l'estensione Remote - SSH di Visual Studio Code per connettersi a una jump box nella rete virtuale. Il tunnel SSH crittografato termina con l'indirizzo IP pubblico della jump box, semplificando 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. La regola predefinita del gruppo di sicurezza di rete blocca tutto il traffico in ingresso dall'esterno di Azure, quindi creare una nuova regola che consenta il traffico SSH dall'INDIRIZZO IP pubblico del computer locale.
• Controllare il percorso del certificato. Verificare la corretta posizione dei certificati. La chiave privata deve trovarsi nella directory C:\Users\User\.ssh\id_rsa nel computer locale. La chiave pubblica deve essere inserita nel file ~/.ssh/id_rsa.pub nella macchina virtuale in Azure.

Conclusione

• È possibile accedere al server API del cluster del servizio Azure Kubernetes tramite Internet se il nome di dominio completo pubblico è abilitato.
• Cloud Shell è una shell della riga di comando predefinita nel portale di Azure che è possibile usare per connettersi a un cluster del servizio Azure Kubernetes.
• Per un accesso più sicuro, usare Azure Bastion e un endpoint privato.
• VPN ed ExpressRoute forniscono connettività ibrida al cluster del servizio Azure Kubernetes privato.
• Se non è disponibile alcuna soluzione di connettività esterna, è possibile usare aks command invoke in remoto.
• Cloud Shell può anche essere distribuito direttamente in una rete virtuale gestita per accedere al cluster privato.
• L'uso di Visual Studio Code con SSH in una jump box crittografa la connessione e semplifica la modifica dei file manifesto, anche se espone un indirizzo IP pubblico nell'ambiente in uso.

Contributori

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

Autori principali:

• Ayobami Ayoodeji | Program Manager 2
• Ariel Ramirez | Consulente senior
• Bahram Rushenas | Incubazione Architetto

Altri collaboratori:

• Shubham Agnihotri | Consulente

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

Passaggi successivi

• Che cos'è Azure Bastion?
• Introduzione a OpenSSH
• Che cos'è un endpoint privato?
• Che cos'è Azure ExpressRoute?
• Che cos'è il gateway VPN?

Risorse correlate

• architettura di base per un cluster del servizio Azure Kubernetes
• 'architettura dei microservizi del servizio Azure Kubernetes avanzato
• progettazione dell'architettura del servizio Azure Kubernetes