Approfondimento sul gateway IAM VPE per i cluster VPC

Cloud privato virtuale

A partire da novembre 2026, Red Hat OpenShift on IBM Cloud creerà automaticamente un gateway VPE (Virtual Private Endpoint) per IAM ( Cloud Identity and Access Management ) in ogni VPC che contenga un cluster Red Hat OpenShift on IBM Cloud. Una volta creato questo gateway, l'indirizzo private.iam.cloud.ibm.com viene risolto agli indirizzi IP del gateway VPE presenti nelle sottoreti dei worker del cluster, anziché all'intervallo di endpoint del servizio privato IBM Cloud. A seconda di come è configurato il proprio ambiente, questa modifica potrebbe causare il malfunzionamento delle applicazioni che effettuano chiamate IAM all'indirizzo private.iam.cloud.ibm.com.

Perché Red Hat OpenShift on IBM Cloud sta aggiungendo un IAM VPE Gateway?

Sono già stati creati dei gateway VPE per i servizi utilizzati dai cluster di Red Hat OpenShift on IBM Cloud, come Container Registry e le API dei container. Ora che IAM supporta VPE, verrà aggiunto anche un gateway per IAM. I gateway VPE instradano il traffico di servizio sulla rete privata utilizzando gli indirizzi delle sottoreti esistenti nella VPC e consentono di controllare tale traffico tramite gruppi di sicurezza e ACL di rete.

Chi è interessato da questa modifica?

La maggior parte degli ambienti non ne risente. Potresti essere interessato se si verifica una delle seguenti situazioni:

  • Si esegue un'applicazione su un VSI o su un'altra macchina all'interno del proprio VPC — al di fuori di un cluster Red Hat OpenShift on IBM Cloud — che effettua chiamate IAM all'indirizzo private.iam.cloud.ibm.com. Una volta creato il gateway, è probabile che il traffico proveniente da quella macchina venga bloccato dalle regole predefinite del gruppo di sicurezza sul nuovo VPE Gateway.
  • È possibile personalizzare le ACL di rete su qualsiasi sottorete VPC e limitare il traffico tra le sottoreti. I nuovi indirizzi IP del VPE Gateway vengono assegnati dalle sottoreti dei worker del cluster e le regole ACL potrebbero bloccare il traffico diretto verso di essi.
  • Sono presenti criteri di rete di tipo “ Kubernetes ” o “ Calico ” che consentono il traffico in uscita verso l’intervallo di endpoint del servizio privato “ IBM Cloud ” (166.8.0.0/14), ma non consentono esplicitamente il traffico in uscita verso le sottoreti VPC. Poiché gli indirizzi IP del gateway VPE provengono dalle sottoreti della tua VPC anziché dall'intervallo 166.8.0.0/14, tali politiche bloccano il traffico.

Non sei interessato se si verificano entrambe le seguenti condizioni:

  • Nessuna applicazione esterna ai tuoi cluster si connette a private.iam.cloud.ibm.com.
  • Le ACL di rete e le politiche di rete Kubernetes e Calico consentono tutto il traffico non pubblico.

Verifica se il tuo ambiente è interessato dal problema

Il modo più sicuro per verificare se questa modifica ti riguarda è creare tu stesso il gateway IAM VPE utilizzando lo script fornito e monitorare il tuo ambiente per individuare eventuali problemi di connettività prima che IBM crei automaticamente il gateway. IBM consiglia di eseguire lo script prima nel proprio ambiente di test.

Lo script verifica se nella tua VPC esiste già un VPE Gateway per IAM. Se il gateway non esiste, lo script ne crea uno. Se esiste già ed è stabile, lo script termina senza apportare modifiche.

Prima di iniziare

Assicurati che i seguenti strumenti siano installati e configurati:

  • ibmcloud CLI
  • ibmcloud is Plugin (Infrastruttura VPC): ibmcloud plugin install vpc-infrastructure
  • ibmcloud ks Plugin ( Kubernetes Service ): ibmcloud plugin install kubernetes-service
  • jq

Accedi e seleziona la regione in cui si trova il tuo cluster VPC. Disattiva il gruppo di risorse in modo che lo script possa rilevare i cluster presenti in tutti i tuoi gruppi di risorse:

ibmcloud login
ibmcloud target -r <region>
ibmcloud target --unset-resource-group

Scarica lo script e rendilo eseguibile:

curl -LO https://raw.githubusercontent.com/IBM-Cloud/kube-samples/master/vpe-gateway/create-iam-vpe-gateway.sh
chmod +x create-iam-vpe-gateway.sh

Creare il gateway VPE di IAM

Esegui lo script per creare il gateway. Lo script rileva automaticamente la VPC e le sottoreti dai nodi di lavoro del cluster. È anche possibile specificarli esplicitamente.

# Auto-detect the VPC and subnets
./create-iam-vpe-gateway.sh add
# Specify the VPC and subnets explicitly
./create-iam-vpe-gateway.sh add --vpc <vpc-name-or-id> --subnets <subnet-zone1-id>,<subnet-zone2-id>,<subnet-zone3-id>

Una volta eseguito lo script, controlla che non ci siano problemi di connettività nel tuo ambiente. Se non si verificano problemi, è possibile lasciare il gateway in funzione. Red Hat OpenShift on IBM Cloud riconoscerà il gateway e lo gestirà automaticamente quando verrà eseguito l'aggiornamento nel novembre 2026.

Per rimuovere il gateway e ripristinare il comportamento precedente, eseguire il seguente comando:

./create-iam-vpe-gateway.sh remove --vpc <vpc-name-or-id>

Risolvere i problemi di connettività

Se la creazione del gateway IAM VPE interrompe la connettività a private.iam.cloud.ibm.com nel proprio ambiente, consultare le sezioni seguenti per individuare la causa e ripristinare la connettività.

Aggiorna le regole del gruppo di sicurezza

Ciò vale nel caso in cui l'applicazione interessata sia in esecuzione su un VSI o su un sistema esterno al cluster.

Il nome del gruppo di sicurezza che lo script associa al gateway IAM VPE dipende dal tipo di cluster:

  • Cluster con sicurezza predefinita: kube-vpegw-<vpcID>
  • Tutti gli altri cluster: kube-<vpcID>

Lo script visualizza il nome del gruppo di sicurezza nell'output.

Per ripristinare la connettività, aggiornare i gruppi di sicurezza sia sul sistema client che sul gateway IAM VPE:

  1. Nel gruppo di sicurezza del sistema client, aggiungere una regola in uscita per consentire tutto il traffico verso il gruppo di sicurezza IAM VPE Gateway.
  2. Nel gruppo di sicurezza del gateway IAM VPE, aggiungere una regola in entrata per consentire tutto il traffico proveniente dal gruppo di sicurezza del sistema client.

Non aggiungere regole che specifichino direttamente gli indirizzi IP del gateway VPE. Tali indirizzi IP possono variare se cambiano le sottoreti VPC utilizzate dai worker del cluster.

Aggiornamento delle regole personalizzate dell'ACL di rete

Ciò vale se si utilizzano ACL di rete personalizzate sulle sottoreti della propria VPC. Si sconsiglia l'uso di ACL di rete personalizzate per i cluster di " Red Hat OpenShift on IBM Cloud ".

Potrebbe essere necessario aggiornare le ACL in due punti:

  • Le ACL di rete relative alla sottorete in cui è in esecuzione il sistema client interessato.
  • Le ACL di rete per tutte le sottoreti VPC utilizzate dai worker in qualsiasi cluster all'interno della VPC, poiché gli indirizzi IP dei gateway VPE vengono assegnati da tali sottoreti.

A differenza delle regole dei gruppi di sicurezza, le ACL di rete richiedono sia una regola in entrata che una in uscita per consentire un flusso. Per ulteriori informazioni, consultare la sezione "Informazioni sulle ACL di rete".

Network ACL È difficile definire correttamente le regole. L'approccio diagnostico raccomandato è il seguente:

  1. Creare il gateway VPE per IAM utilizzando lo script.
  2. Aggiungere una regola temporanea che consenta tutto il traffico in entrata e in uscita all'inizio di ogni ACL di rete.
  3. Se in questo modo si ripristina la connettività, la causa è da ricercarsi nelle ACL di rete. A questo punto è possibile individuare l'insieme minimo di regole necessario e sostituire le regole temporanee che consentono l'accesso a tutto.

Aggiornare le politiche di rete Kubernetes e Calico

Ciò si verifica se si dispone di criteri di rete di tipo " Kubernetes " o " Calico " che consentono il traffico in uscita verso l'intervallo di endpoint del servizio privato " IBM Cloud " (166.8.0.0/14), ma non consentono esplicitamente il traffico in uscita verso le proprie sottoreti VPC.

Poiché gli indirizzi IP del gateway VPE vengono assegnati dalle sottoreti dei worker della VPC — e non dall'intervallo 166.8.0.0/14 — tali policy bloccano il traffico diretto al nuovo gateway.

Non è possibile prevedere quali indirizzi IP specifici vengano assegnati ai gateway VPE, e tali indirizzi IP possono cambiare. Per qualsiasi politica di rete che limiti il traffico in uscita dai pod o dai nodi di lavoro, consentire il traffico in uscita verso tutte le sottoreti VPC che contengono nodi di lavoro del cluster. I lavoratori e i gruppi senza restrizioni di uscita non devono essere aggiornati.

Passi successivi