Definizione di sottoreti personalizzate durante la creazione della tua posizione

Durante la creazione della posizione

Quando crei la tua ubicazione nella CLI, puoi definire i seguenti parametri per personalizzare la rete nella tua ubicazione. Per ulteriori informazioni, consultare il riferimento al comando ibmcloud sat location create.

Puoi specificare l'opzione --pod-subnet per specificare un CIDR di sottorete personalizzato per fornire gli indirizzi IP privati per i pod. Questa opzione può essere utilizzata solo se si abilita anche Red Hat CoreOS con il flag --coreos-enabled. La sottorete deve avere almeno /23 o più. Il valore predefinito è 172.16.0.0/16.

Puoi anche specificare l'opzione --service-subnet per specificare un CIDR di sottorete personalizzata per fornire indirizzi IP privati per servizi. Questa opzione può essere utilizzata solo se si abilita anche Red Hat CoreOS con il flag --coreos-enabled. La sottorete deve avere almeno /24 o più. Il valore predefinito è 172.20.0.0/16.

Definizione dell'interfaccia di rete del pod durante la creazione della tua posizione

Durante la creazione della posizione

Quando crei la tua ubicazione nella CLI, puoi definire il --pod-network-interface per configurare l'interfaccia di rete del pod. I metodi disponibili sono can-reach e interface.

• Per fornire un indirizzo URL o IP diretto, specificare can-reach=<url> o can-reach=<ip_address>. Se l'interfaccia di rete può raggiungere l'indirizzo URL o IP fornito, viene utilizzata questa opzione. Ad esempio, utilizzare can-reach=www.exampleurl.com per specificare un indirizzo URL e can-reach=172.19.0.0 per specificare un indirizzo IP.
• Per scegliere un'interfaccia con una stringa Regex, specificare interface=<regex_string>; ad esempio, interface=eth.*.

Per ulteriori informazioni, consultare il riferimento al comando ibmcloud sat location create.

Definizione dell'interfaccia di rete del pod durante la creazione del tuo cluster

Durante la creazione del cluster

Quando crei il tuo cluster nella CLI, puoi definire --pod-network-interface per impostare l'interfaccia di rete del pod. I metodi disponibili sono can-reach e interface.

• Per fornire un indirizzo URL o IP diretto, specificare can-reach=<url> o can-reach=<ip_address>. Se l'interfaccia di rete può raggiungere l'indirizzo URL o IP fornito, viene utilizzata questa opzione. Ad esempio, utilizzare can-reach=www.exampleurl.com per specificare un indirizzo URL e can-reach=172.19.0.0 per specificare un indirizzo IP.
• Per scegliere un'interfaccia con una stringa Regex, specificare interface=<regex_string>; ad esempio, interface=eth.*.

Per ulteriori informazioni, consultare il riferimento al comando ibmcloud oc cluster create satellite.

Limitazione dell'accesso al tuo cluster Satellite

Dopo la localizzazione e la creazione del cluster

Dopo aver creato la tua ubicazione e il tuo cluster, puoi utilizzare il comando ibmcloud ks cluster master satellite-service-endpoint allowlist add per aggiungere una sottorete a un elenco di valori consentiti dell'endpoint del servizio del cluster Satellite. Le richieste autorizzate rivolte al master del cluster provenienti dalla sottorete sono consentite tramite l'endpoint del servizio Satellite. L'elenco dei consentiti deve essere abilitato per applicare le restrizioni.

Creazione di politiche di rete utilizzando gli endpoint host Calico

Dopo la localizzazione e la creazione del cluster

Se crei un cluster Satellite versione 4.12 e successive, ci sono delle istanze Calico Hostendpoint distribuite al cluster per ogni interfaccia di rete del nodo di lavoro.

Puoi utilizzare queste istanze di Hostendpoint per definire le politiche di rete globali con l'aiuto dell'etichetta “ibm-cloud.kubernetes.io/interface-name: <network_interface_name>” aggiunta a ogni istanza Hostendpoint.

Oltre a questa etichetta, tutte le etichette del nodo di lavoro vengono aggiunte per ulteriori opzioni di personalizzazione.

Questi Hostendpoints hanno il profilo “projectcalico-default-allow", il che significa che questi Hostendpoints potrebbero cambiare il comportamento precedentemente previsto quando si aggiorna a 4.12.

Prima di eseguire l'aggiornamento a 4.12, assicurarsi che tutte le regole di rete, le politiche Hostendpoints precedentemente previste funzionino allo stesso modo dopo l'aggiornamento.

Per ulteriori informazioni, consulta la documentazione diCalico.

Limitazione dell'accesso al servizio NodePort

Dopo la localizzazione e la creazione del cluster

Per impostazione predefinita, i servizi NodePort sono accessibili su tutte le interfacce di rete disponibili per il cluster, ad esempio 0.0.0.0.

Tuttavia, nelle ubicazioni Satellite in cui sono disponibili più reti per gli host, puoi limitare le interfacce di rete disponibili per i tuoi servizi.

Per limitare l'intervallo, limitare gli indirizzi in ascolto per servizi NodePort a livello di cluster. Questa limitazione consente al responsabile del cluster di limitare l'accesso a una specifica interfaccia di rete utilizzando la sottorete IP come intervallo di indirizzi di ascolto consentito. Completa la seguente procedura per riconfigurare il componente kube-proxy per limitare l'intervallo di indirizzi in ascolto per i servizi NodePort.

La configurazione non corretta di node-port-addresses potrebbe isolare i tuoi servizi da origini valide. Assicurarsi di pianificare tutte le subnet necessarie al servizio. IBM Cloud non richiede l'accesso a nessuna subnet per gestire i cluster.

1. Accedi al tuo cluster Red Hat OpenShift.

2. Prepara il tuo elenco CIDR di sottorete di origine pianificato a cui vuoi consentire l'accesso ai servizi NodePort.

3. Eseguire il seguente comando per richiamare la configurazione di network.operator.openshift.io e salvare una copia nel caso in cui sia necessario ripristinare le modifiche.

   kubectl get network.operator.openshift.io cluster -o yaml
   

4. Modifica la configurazione di network.operator.openshift.io e imposta l'elenco di sottoreti nella sezione spec e includi le sottoreti richieste per il servizio NodePort.

   spec:
     kubeProxyConfig:
       proxyArguments:
         node-port-addresses:
         - 192.0.2.0/24
         - 198.51.100.0/24
   

5. Salvare le modifiche e applicarle al cluster.

   oc apply -f updated-network-config.yaml
   

6. Per cluster versione 4.10.x e precedenti, impostare lo stato di gestione dell'operatore di rete del cluster su Unmanaged.

    oc patch network.operator.openshift.io cluster --type=merge --patch  '{"spec": {"managementState": "Unmanaged"}}'
   

7. Riavviare kube-proxy DaemonSet per applicare le modifiche. Questa operazione non comporta interruzioni.

   oc rollout restart ds -n openshift-kube-proxy openshift-kube-proxy
   

8. Attendi che tutti i tuoi pod kube-proxy vengano riavviati. Verifica lo stato eseguendo il seguente comando.

   oc get po -n openshift-kube-proxy --selector app=kube-proxy
   

9. Per la versione cluster di 4.10.x e precedenti, reimpostare lo stato di gestione dell'operatore di rete del cluster su Managed. Tieni presente che questa azione potrebbe riavviare i pod proxy.

    oc patch network.operator.openshift.io cluster --type=merge --patch  '{"spec": {"managementState": "Managed"}}'
   

Una volta riavviati tutti i pod, il cluster viene configurato con le sottoreti limitate. È possibile ripetere questi passi per aggiornare o rimuovere l'elenco di sottoreti in base alle necessità.

È possibile limitare ulteriormente il traffico utilizzando NetworkPolicies in base al servizio.