Comprendere la rete sicura per impostazione predefinita del cluster VPC

Cloud virtuale privato 4.15 e successivamente

A partire dai nuovi cluster VPC creati con la versione 4.15, Red Hat OpenShift on IBM Cloud ha introdotto una nuova funzione di sicurezza chiamata Secure by Default Cluster VPC Networking. Con Secure by Default, ci sono nuove impostazioni VPC, come i gruppi di sicurezza gestiti, le regole del gruppo di sicurezza e i VPE (virtual private endpoint gateways) che vengono creati automaticamente quando crei un cluster VPC. Esaminare i seguenti dettagli sui componenti VPC che vengono creati e gestiti quando si crea un cluster della versione 4.15 e successive.

Panoramica

Con Secure by Default Networking, quando esegui il provisioning di un nuovo cluster VPC Red Hat OpenShift on IBM Cloud alla versione 4.15 o successiva, è consentito solo il traffico necessario al funzionamento del cluster e tutto l'altro accesso è bloccato. Per implementare Secure by Default Networking, Red Hat OpenShift on IBM Cloud utilizza diversi gruppi di sicurezza e regole del gruppo di sicurezza per proteggere i componenti cluster. Questi gruppi di protezione e regole sono automaticamente creati e collegati ai nodi di lavoro, ai programmi di bilanciamento del carico e ai gateway VPE correlati al cluster.

I gruppi di sicurezza VPC (Virtual Private Cloud) filtrano il traffico a livello di hypervisor. Le regole del gruppo di sicurezza non vengono applicate in uno specifico ordine. Tuttavia, le richieste ai tuoi nodi di lavoro sono consentite solo se la richiesta corrisponde a una delle regole che specifichi. Quando si consente il traffico in una direzione creando una regola in entrata o in uscita, le risposte sono consentite anche nella direzione opposta. I gruppi di sicurezza sono additivi, il che significa che se i tuoi nodi di lavoro sono collegati a più di un gruppo di protezione, tutte le regole incluse nei gruppi di sicurezza vengono applicate ai nodi di lavoro. Le versioni cluster più recenti potrebbero avere più regole nel gruppo di sicurezza kube-<clusterID> rispetto alle versioni cluster precedenti. Le regole del gruppo di sicurezza vengono aggiunti per migliorare la sicurezza del servizio e non interrompere la funzionalità.

Gateway endpoint privati virtuali (VPE)

Quando il primo cluster VPC in Red Hat OpenShift on IBM Cloud 4.14+ viene creato in un determinato VPC o un cluster in tale VPC ha il suo master aggiornato a 4.14+, vengono creati diversi gateway VPE condivisi per vari servizi IBM Cloud. Solo uno di questi tipi di gateway VPE condivisi viene creato per VPC. Tutti i cluster nel VPC condividono lo stesso gateway VPE per questi servizi. A questi gateway VPE condivisi viene assegnato un singolo IP riservato da ogni zona in cui si trovano gli operatori cluster.

Gateway VPE condivisi

I seguenti gateway VPE vengono creati automaticamente quando crei un cluster VPC.

Gateway VPE condivisi
La tabella mostra i gateway VPE creati per i cluster VPC. La prima colonna include il nome del gateway. La seconda colonna include una breve descrizione. La terza colonna comprende i nomi DNS.
Gateway VPE	Descrizione	nomi DNS
IBM Cloud Container Registry	Estrarre le immagini dei container da IBM Cloud Container Registry per le applicazioni in esecuzione nel cluster.	`icr.io`, `*.icr.io`
Gateway IBM Cloud Object Storage s3	Accedere alle API di IBM Cloud Object Storage.	`s3.direct.<region>.cloud-object-storage.appdomain.cloud`, `*.s3.direct.<region>.cloud-object-storage.appdomain.cloud`
Gateway di configurazione IBM Cloud Object Storage	Backup delle immagini del contenitore in IBM Cloud Object Storage	`config.direct.cloud-object-storage.cloud.ibm.com`
Red Hat OpenShift on IBM Cloud (ca-mon, in-che, in-mum)	Accedere alle API di Red Hat OpenShift on IBM Cloud per creare cluster, aggiungere pool di lavoratori e altro ancora.	`private.<region>.containers.cloud.ibm.com`
Red Hat OpenShift on IBM Cloud (altre regioni)	Accedere alle API di Red Hat OpenShift on IBM Cloud per creare cluster, aggiungere pool di lavoratori e altro ancora.	`api.<region>.containers.cloud.ibm.com`
IBM Cloud VPC	Accedere alle API VPC per il provisioning e la gestione delle risorse che fanno parte della VPC Infrastructure as a Service ( IaaS ).	`<region>.private.iaas.cloud.ibm.com`

Gateway VPE non condivisi

Tutti i cluster VPC supportati hanno un gateway VPE per il master del cluster, che viene creato nel vostro account al momento della creazione del cluster.

Gateway VPE non condivisi
La tabella mostra i gateway VPE creati per i cluster VPC. La prima colonna include il nome del gateway. La seconda colonna include una breve descrizione.
Gateway VPE	Descrizione
Red Hat OpenShift on IBM Cloud master del cluster	Questo gateway VPE viene utilizzato dai nodi di lavoro del cluster e può essere utilizzato da altri elementi nel VPC per connettersi al server API master del cluster. A questo gateway VPE viene assegnato un singolo IP riservato da ogni zona in cui si trovano i lavoratori del cluster e questo IP viene creato in una delle sottoreti VPC della zona in cui si trovano i lavoratori del cluster. †

† Ad esempio, se il cluster ha lavoratori in una sola regione di zona (us-east-1) e in una sola sottorete VPC, viene creato un solo IP in quella sottorete e assegnato al gateway VPE. Se un cluster ha dei nodi di lavoro in tutte e tre le zone come us-east-1, us-east-2 e us-east-3 e questi nodi di lavoro sono distribuiti tra 4 sottoreti VPC in ogni zona, allora vengono creati complessivamente 12 sottoreti VPC, tre IP, uno in ogni zona, in una delle quattro sottoreti VPC in tale zona. Si noti che la sottorete viene scelta a caso.

Gruppi di protezione gestiti

Red Hat OpenShift on IBM Cloud crea e aggiorna automaticamente i seguenti gruppi di sicurezza e regole per cluster VPC.

Gruppi di sicurezza gestiti
La tabella mostra i gruppi di sicurezza gestiti creati per i cluster VPC. La prima colonna include il nome del gruppo di sicurezza. La seconda colonna include la convenzione di denominazione.
Gruppo di sicurezza	Convenzione di denominazione
Gruppo di sicurezza dei lavoratori	`kube-<clusterID>`
Gruppo di sicurezza gateway VPE master	`kube-vpegw-<clusterID>`
Gruppo di sicurezza gateway VPE condiviso	`kube-vpegw-<vpcID>`
Gruppo di sicurezza dei servizi di bilanciamento del carico	`kube-lbaas-<clusterID>`

Gruppo di sicurezza Worker

Quando si crea un cluster VPC Red Hat OpenShift on IBM Cloud, viene creato un gruppo di sicurezza per tutti i lavoratori, o nodi, del cluster in questione.

Il nome del gruppo di protezione è kube-<clusterID> dove <clusterID> è l'ID del cluster.
Se i nuovi nodi vengono aggiunti al cluster in un secondo momento, tali nodi vengono aggiunti automaticamente al gruppo di sicurezza del cluster.
Le regole vengono aggiunte o rimosse dinamicamente in base alle esigenze dei bilanciatori di carico.
Le regole aggiunte nell'intervallo di porte del nodo vengono automaticamente rimosse se non sono necessarie. Se i clienti vogliono consentire il traffico in entrata a un servizio di porta del nodo, è necessario aggiungere la regola per consentire il traffico dopo aver creato il servizio di porta del nodo.
Non modificare le regole nel gruppo di sicurezza kube-<clusterID> in quanto ciò potrebbe causare interruzioni nella connettività di rete tra i nodi di lavoro del cluster e il cluster di controllo.

Regole nel gruppo di sicurezza kube-clusterID
La tabella mostra le regole applicate al gruppo di sicurezza dei lavoratori del cluster. La prima colonna include il Protocollo della regola. La seconda colonna include le porte e i tipi. La terza colonna include la destinazione remota della regola. La quarta colonna contiene una breve descrizione della regola.
Descrizione	Direzione	Protocollo	Porte o valori	Origine o destinazione
Consente il traffico in entrata alla sottorete pod.	In entrata	ICMP/ TCP / UDP	Tutti	O 172.17.0.0/18 (l'intervallo di sottorete predefinito) o un intervallo di sottorete personalizzato che specifichi quando crei il tuo cluster.
Consente l'accesso in entrata a se stessi, consentendo la comunicazione tra i nodi di lavoro.	In entrata	ICMP/ TCP / UDP	Tutti	`kube-<clusterID>`
Consente l'accesso ICMP (ping) in entrata.	In entrata	ICMP	type=8	0.0.0.0/0
Consente il traffico in entrata dalle porte nodali aperte dai bilanciatori di carico (ALB/NLB). Man mano che i programmi di bilanciamento del carico vengono aggiunti o rimossi, le regole vengono aggiunte o rimosse in modo dinamico.	In entrata	TCP	Porte del nodo Loadbalancer.	`kube-lbaas-<clusterID>`
Consente il traffico in uscita alla sottorete del pod.	In uscita	ICMP/ TCP / UDP	Tutti	O 172.17.0.0/18 (l'intervallo di sottorete predefinito) o un intervallo di sottorete personalizzato che specifichi quando crei il tuo cluster.
Consente il traffico in uscita al piano di controllo principale che consente il provisioning dei nodi di lavoro.	In uscita	ICMP/ TCP / UDP	Tutti	161.26.0.0/16
Consente l'accesso in uscita a se stessi, consentendo la comunicazione tra i lavoratori.	In uscita	ICMP/ TCP / UDP	Tutti	`kube-<clusterID>`
Consente il traffico in uscita al gruppo di sicurezza del gateway VPE master.	In uscita	ICMP/ TCP / UDP	Tutti	`kube-vpegw-<clusterID>`
Consente il traffico in entrata al gruppo di sicurezza del gateway VPE condiviso.	In uscita	ICMP/ TCP / UDP	Tutti	`kube-vpegw-<vpcID>`
Consente il traffico verso l'endpoint pubblico tramite la porta oauth per tutte le zone dell'MZR in cui si trova il cluster.`*`	In uscita	TCP	Porta Oauth	IP endpoint pubblici per tutte le zone di MZR.
Consente il traffico di TCP attraverso l'ALB di ingresso	In uscita	TCP	Ports:Min=443,Max=443	Indirizzo IP pubblico ALB `n`
Consente il traffico di TCP e UDP attraverso il resolver DNS personalizzato per la zona `n`.`**`	In uscita	TCP/UDP	Min=53,Max=53	Indirizzo IP del resolver DNS nella zona `n`.
Consente il traffico all'intero intervallo di servizi CSE.	In uscita	ICMP/ TCP / UDP	Tutti	166.8.0.0/14
Consente il traffico all'endpoint privato IAM per tutte le zone. Gli IP possono variare in base alla regione. Viene aggiunta una regola per zona in cui si trova il cluster.	In uscita	ICMP/ TCP / UDP	Tutti	Indirizzo IP dell'endpoint privato IAM per tutte le zone.
Consente il traffico in uscita verso l'API dei metadati dell'istanza.	In uscita	ICMP/ TCP / UDP	Tutti	169.254.169.254
4.18 e successivi Consente il traffico in uscita verso l'API dei metadati dell'istanza.	In uscita	ICMP/ TCP / UDP	Tutti	169.254.169.254

* Queste regole vengono aggiunte solo ai cluster con endpoint di servizio pubblico abilitati per consentire l'accesso alla console web OpenShift e all'endpoint pubblico attraverso la porta OAuth. Viene aggiunta una regola per ogni zona della regione multizona (MZR) in cui si trova il cluster. Se il tuo cluster si trova in un MZR con 3 zone, vengono create 3 regole.

** I VPC hub e Spoke utilizzano resolver DNS personalizzati sul VPC. Il traffico deve passare attraverso gli indirizzi IP di ogni resolver DNS. Ci sono due regole per zona ( TCP e UDP ) attraverso la porta 53.

Gruppo di sicurezza gateway VPE principale

Quando crei un cluster VPC, viene creato un gateway VPE (Virtual Private Endpoint) nello stesso VPC del cluster. Il nome del titolo è kube-vpegw-<clusterID> dove <clusterID> è l'ID del cluster. Lo scopo di questo gateway VPE è di fungere da gateway per il master del cluster, gestito da IBM Cloud. Al gateway VPE viene assegnato un singolo indirizzo IP in ciascuna zona nel VPC in cui il cluster ha dei nodi di lavoro.

Per consentire l'accesso a un master del cluster solo dai suoi nodi di lavoro, viene creato un gruppo di sicurezza per ogni gateway VPE master del cluster. Viene quindi creata una regola remota che consente la connettività Ingress dal gruppo di sicurezza del nodo di lavoro del cluster alle porte richieste sul gateway VPE del master cluster. Per le connessioni private, comprese quelle provenienti da una VPC VPN, per connettersi al gateway VPE endpoint del servizio privato del cluster, il traffico TCP è consentito dai CIDR della sottorete per ogni pool di lavoratori attivo del cluster.

Regole in entrata nel gruppo di sicurezza del gateway VPE master
La tabella mostra le regole in entrata applicate al gruppo di sicurezza dei lavoratori del cluster. La prima colonna include lo scopo della regola. La seconda colonna include la direzione della regola. La terza colonna include il protocollo. La quarta colonna include le porte o i valori. La quinta colonna include la destinazione remota della regola.
Descrizione	Direzione	Protocollo	Porte o valori	Origine o destinazione
Consente il traffico in ingresso dal gruppo di sicurezza del nodo di lavoro del cluster al server nodeport.	In entrata	TCP	Server URL porta del nodo	`kube-<clusterID>`
Consente il traffico in entrata dal gruppo di sicurezza del nodo di lavoro del cluster alla porta openVPN o Konnectivity.	In entrata	TCP	Porta di Konnectivity	`kube-<clusterID>`
Consente il traffico in entrata dal gruppo di sicurezza worker del cluster alla porta Oauth.	In entrata	TCP	Porta Oauth	`kube-<clusterID>`
CoreOS-enabled. Consente il traffico in entrata dal gruppo di sicurezza del nodo di lavoro del cluster alla porta del server Ignition	In entrata	TCP	Porta server Ignition	`kube-<clusterID>`
Consente il traffico in entrata dalla sottorete di ogni pool di lavoratori attivo nel cluster.`*`	In entrata	TCP	Server URL porta del nodo	CIDR sottorete
Consente il traffico in entrata dalla sottorete di ogni pool di lavoratori attivo nel cluster.`*`	In entrata	TCP	OAuth porto	CIDR sottorete

* Viene aggiunta una regola per la sottorete di ogni pool di lavoratori attivo. Se si hanno lavoratori in tre zone, verranno aggiunte tre regole (una per ogni subnet della zona).

Gruppo di sicurezza gateway VPE condiviso

I gateway VPE condivisi vengono creati quando il primo cluster di una VPC viene provisioned.The viene creato quando si crea un cluster (se non esiste già da cluster precedenti). Il nome del gruppo di sicurezza è kube-vpegw-<vpcID> dove <vpcID> è l'ID della VPC. Viene quindi creata una regola remota che consente la connettività Ingress dal gruppo di sicurezza del nodo di lavoro del cluster per il cluster fornito. Il gruppo di sicurezza del gateway VPE condiviso contiene i gateway VPE condivisi da tutti i cluster in tale VPC. Nelle versioni successive potrebbero essere aggiunti gateway VPE condivisi per consentire le connessioni ad altri servizi IBM Cloud.

Se questo gruppo di sicurezza del gateway VPE condiviso già esiste quando viene eseguito il provisioning di un cluster, viene riconosciuto dal processo di provisioning e non viene ricreato. Tuttavia, viene ancora aggiunta una regola remota tra il gruppo di sicurezza del gateway VPE condiviso esistente e il nuovo gruppo di sicurezza del nodo di lavoro. Questa operazione viene eseguita in modo che la connettività sia consentita da tutti i cluster nel VPC fornito. Viene creata una regola per ogni cluster nel VPC.

Ci sono un massimo di 15 regole che possono essere indirizzate ad altri gruppi di sicurezza come origine o destinazione. Per impostazione predefinita, Red Hat OpenShift on IBM Cloud applica 1 regola che ha come obiettivo il gruppo di sicurezza kube-<clusterID> per ogni cluster nella VPC. A causa di questa quota, è possibile creare solo 15 cluster in un determinato VPC. Per ulteriori informazioni, vedi Quote VPC.

Regole in ingresso nel gruppo di sicurezza del gateway VPE condiviso
La tabella mostra le regole in entrata applicate al gruppo di sicurezza del gateway VPE condiviso. La prima colonna include lo scopo della regola. La seconda colonna include la direzione della regola. La terza colonna include il protocollo. La quarta colonna include la destinazione remota della regola.
Descrizione	Direzione	Protocollo	Origine o destinazione
Consente il traffico in entrata dal cluster specificato.	In entrata	TCP	`kube-<clusterID>`

Gruppo di sicurezza dei servizi del programma di bilanciamento del carico

Il gruppo di sicurezza predefinito collegato a tutti i programmi di bilanciamento del carico (ALB e NLB).

Ogni cluster ottiene il proprio gruppo di sicurezza univoco condiviso da tutti i programmi di bilanciamento del carico nel cluster.
Il nome del gruppo di sicurezza è kube-lbaas-<clusterID> dove <clusterID> è l'ID del cluster.
Le regole su questo gruppo di protezione vengono aggiunte o eliminate in modo dinamico quando i programmi di bilanciamento del carico vengono aggiunti, rimossi o aggiornati. Si noti che gli SDNLB non supportano il collegamento dei gruppi di protezione.
È possibile aggiungere regole a questo gruppo di sicurezza. Tuttavia, alcune regole potrebbero essere rimosse se sono incompatibili con le altre regole o se interrompono la funzionalità.

Regole del gruppo di sicurezza del bilanciatore di carico
La tabella mostra le regole applicate al gruppo di sicurezza Load balancer. La prima colonna include lo scopo della regola. La seconda colonna include la direzione della regola. La terza colonna include il protocollo. La quarta colonna include le porte o i valori. La quinta colonna include la destinazione remota della regola.
Descrizione	Direzione	Protocollo	Porta o valore	Origine o destinazione
Consente l'accesso in uscita alla porta del nodo aperta dal programma di bilanciamento del carico. A seconda del programma di bilanciamento del carico, potresti avere più regole.	In uscita	TCP	Porte Node aperte dal programma di bilanciamento del carico.	`kube-<clusterID>`
Il programma di bilanciamento del carico ascolta sulla porta 80 consentendo l'accesso in entrata da tale porta.	In entrata	TCP	Porta LB pubblica. Esempio `80`	0.0.0.0/0
Il programma di bilanciamento del carico è in ascolto sulla porta 443 consentendo l'accesso in entrata da tale porta.	In entrata	TCP	Porta LB pubblica. Esempio `443`	0.0.0.0/0

Fornito dall'utente Security Groups

Quando si crea un cluster VPC, è possibile fornire fino a quattro gruppi di sicurezza aggiuntivi di proprietà.

Per ulteriori informazioni, vedere Creazione e gestione dei gruppi di sicurezza VPC.

Limitazioni

Gruppi di sicurezza nodo di lavoro

Poiché i nodi worker nel cluster VPC esistono in un account di servizio e non sono elencati nella dashboard dell'infrastruttura VPC, non è possibile creare un gruppo di sicurezza e applicarlo alle istanze dei nodi worker. È possibile modificare solo il gruppo di sicurezza kube-<clusterID> esistente.

Registrazione e monitoraggio

Quando si configura la registrazione e il monitoraggio su un cluster 4.15 o successivo, è necessario utilizzare l'endpoint del servizio privato quando si installa l'agent di registrazione nel cluster. I dati di log non vengono salvati se viene utilizzato l'endpoint pubblico.

Monitoraggio di cluster con nodi di lavoro RHCOS

L'agent di monitoraggio si basa sulle intestazioni kernel nel sistema operativo, tuttavia RHCOS non ha intestazioni kernel. In questo scenario, l'agent ritorna a sysdig.com per utilizzare l'agent precompilato. Nei cluster senza accesso alla rete pubblica questo processo non riesce. eBPF è ora abilitato per impostazione predefinita per le nuove implementazioni di Sysdig. Tuttavia, se si verificano problemi su un cluster esistente, verificare se eBPF è abilitato e, se necessario, abilitarlo. In alternativa, è possibile consentire il traffico in uscita o consultare la documentazione Sysdig per l'installazione dell'agente in ambienti air-gapped.

Quote cluster VPC

Crittografia in transito per VPC File Storage.

Per utilizzare EIT con i cluster Secure by Default, è necessario aggiungere la seguente regola in uscita al gruppo di sicurezza kube-<clusterID>.

Protocollo: Qualsiasi
Tipo di fonte: Qualsiasi
Fonte: 0.0.0.0/0
Destinazione 169.254.169.254.

Comunicazione di backup sulla rete pubblica

I nodi di lavoro del cluster VPC utilizzano la rete privata per comunicare con il master cluster. In precedenza, per i cluster VPC che avevano l'endpoint del servizio pubblico abilitato, se la rete privata era bloccata o non disponibile, i nodi di lavoro del cluster potevano utilizzare la rete pubblica per comunicare con il master cluster. Nei cluster Secure by Default, il ritorno alla rete pubblica non è un'opzione perché il traffico in uscita pubblico dai nodi di lavoro del cluster è bloccato. Si potrebbe voler disabilitare la protezione del traffico in uscita per consentire questa opzione di backup della rete pubblica, tuttavia, esiste un'alternativa migliore. Invece, se si verifica un problema temporaneo con la connessione worker - to - master sulla rete privata, puoi aggiungere una regola del gruppo di sicurezza temporanea al gruppo di sicurezza kube-clusterID per consentire il traffico in uscita alla porta del cluster master apiserver. Successivamente, una volta risolto il problema, è possibile rimuovere la regola temporanea.

Crittografia OpenShift Data Foundation e Portworx

Se pensi di utilizzare OpenShift Data Foundation o Portworx in un cluster senza accesso alla rete pubblica e vuoi utilizzare Hyper Protect Crypto Services o Key Protect per la crittografia, devi creare un VPE (virtual private endpoint gateway) che consenta l'accesso alla tua istanza KMS. Assicurati di collegare almeno 1 indirizzo IP da ogni sottorete nel tuo VPC al VPE.