Comprendere la rete sicura per impostazione predefinita del cluster VPC
Virtual Private Cloud 1.30 and later
A partire dai nuovi cluster VPC creati con la versione 1.30, IBM Cloud Kubernetes Service 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 1.30 e successive.
Panoramica
Con Secure by Default Networking, quando esegui il provisioning di un nuovo cluster VPC IBM Cloud Kubernetes Service versione 1.30 o successiva, è consentito solo il traffico necessario per il funzionamento del cluster e tutto l'altro accesso è bloccato. Per implementare Secure by Default Networking, IBM Cloud Kubernetes Service utilizza diversi gruppi di sicurezza e regole del gruppo di sicurezza per proteggere i componenti cluster. Questi gruppi di sicurezza e queste regole vengono creati e collegati automaticamente 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 sicurezza, 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 aggiunte per migliorare la sicurezza del servizio e non infrangono la funzionalità.
Gateway per endpoint privati virtuali (VPE)
Quando il primo cluster VPC in IBM Cloud Kubernetes Service 1.28+ viene creato in un determinato VPC o un cluster in tale VPC ha il suo master aggiornato a 1.28+, 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.
Gruppi di protezione gestiti
IBM Cloud Kubernetes Service crea e aggiorna automaticamente i seguenti gruppi di sicurezza e regole per i cluster VPC.
| 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 IBM Cloud Kubernetes Service, 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.
- IBM Cloud Kubernetes Service monitora solo le regole in entrata TCP e UDP nell'intervallo di porte del nodo nel gruppo di sicurezza
kube-<clusterID>. Se IBM Cloud Kubernetes Service rileva una regola nell'intervallo delle porte del nodo e non esiste un servizio corrispondente per quella porta, la regola viene rimossa. Per consentire il traffico in entrata verso un servizio su porta del nodo, aggiungere la regola richiesta al gruppo di sicurezza "kube-<clusterID>" dopo aver creato il servizio su porta del nodo, non prima. - Le regole aggiuntive inserite nel gruppo di sicurezza "
kube-<clusterID>" al di fuori dell'intervallo delle porte dei nodi vengono ignorate da IBM Cloud Kubernetes Service e rimangono in vigore. - Non modificare né rimuovere le regole predefinite nel gruppo di sicurezza "
kube-<clusterID>", poiché ciò potrebbe causare interruzioni nella connettività di rete tra i worker del cluster e il piano di controllo.
| Descrizione | Direzione | Protocollo | Porte o valori | Origine o destinazione |
|---|---|---|---|---|
| Consente il traffico in entrata alla sottorete pod. | In entrata | ICMP/ TCP / UDP | Tutti | 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 ingresso. | 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 pod. | In uscita | ICMP/ TCP / UDP | Tutti | 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 nodi di lavoro. | 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 uscita al gruppo di sicurezza del gateway VPE condiviso. | In uscita | ICMP/ TCP / UDP | Tutti | kube-vpegw-<vpcID> |
| 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. |
| 1.33 and later Consente il traffico in uscita verso l'API dei metadati dell'istanza. | In uscita | ICMP/ TCP / UDP | Tutti | 169.254.169.254 |
| 4.18 and later Consente il traffico in uscita verso l'API dei metadati dell'istanza. | In uscita | ICMP/ TCP / UDP | Tutti | 169.254.169.254 |
** 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.
| Descrizione | Direzione | Protocollo | Porte o valori | Origine o destinazione |
|---|---|---|---|---|
| Consenti il traffico in entrata dal gruppo di sicurezza del nodo di lavoro del cluster al server nodeport. | In entrata | TCP | Server URL porta del nodo | kube-<clusterID> |
| Consentire il traffico in entrata dal gruppo di sicurezza del nodo di lavoro del cluster alla porta Konnectivity. | In entrata | TCP | Porta di Konnectivity | 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 |
* 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
Il gruppo di sicurezza condiviso del gateway VPE viene creato al momento del provisioning del primo cluster in una VPC. Il nome del gruppo di sicurezza è kube-vpegw-<vpcID>, dove <vpcID> è l'ID della tua
VPC. Questo gruppo di sicurezza è associato a tutti i gateway VPE condivisi nella VPC e controlla quali risorse sono autorizzate a inviare traffico attraverso tali gateway.
Quando ogni cluster aggiuntivo viene configurato nella stessa VPC, a questo gruppo di sicurezza viene aggiunta un'unica regola remota in entrata che consente il traffico proveniente dal gruppo di sicurezza dei worker " kube-<clusterID> " del nuovo cluster. Viene creata una regola per ogni cluster nel VPC. Se il gruppo di sicurezza “ kube-vpegw-<vpcID> ” esiste già al momento della creazione di un cluster, viene riconosciuto e riutilizzato, senza
essere ricreato.
Ogni creazione di cluster comporta anche l'aggiunta di gruppi di sicurezza; una VPC supporta un massimo di 100 gruppi di sicurezza. Questo limite viene raggiunto intorno ai 33 cluster, pertanto si consiglia un massimo di 25 cluster per VPC. Per ulteriori informazioni, consultare la sezione " Quote VPC ".
| Descrizione | Direzione | Protocollo | Origine o destinazione |
|---|---|---|---|
| Consente il traffico in entrata dal cluster specificato. | In entrata | TCP | kube-<clusterID> |
È possibile aggiungere regole in entrata al gruppo di sicurezza " kube-vpegw-<vpcID> ", ad esempio per consentire ai VSI o ad altre risorse presenti nella propria VPC di accedere ai gateway VPE condivisi. La funzione
" IBM Cloud Kubernetes Service " non rimuove le regole aggiunte durante il normale funzionamento del cluster, anche quando vengono provisionati cluster aggiuntivi nella VPC. Per indicazioni su come consentire ai VSI di accedere
ai gateway VPE condivisi, consultare la sezione " Perché i miei VSI non riescono ad accedere al gateway VPE?".
L'esecuzione di ibmcloud ks security-group reset elimina tutte le regole presenti nel gruppo di sicurezza, comprese quelle aggiunte dall'utente, e ripristina solo le regole predefinite di IBM Cloud Kubernetes Service.
Se la tua VPC contiene VSI o altre risorse che necessitano di accedere a endpoint condivisi di servizi cloud (come icr.io o s3.direct) prima che venga provisionato qualsiasi cluster, puoi creare autonomamente il gruppo
di sicurezza " kube-vpegw-<vpcID> " e i gateway VPE condivisi. Quando, in un secondo momento, viene creato un cluster di IBM Cloud Kubernetes Service nella VPC, il sistema individua il gruppo di sicurezza esistente
e lo riutilizza, aggiungendo una nuova regola in entrata per il gruppo di sicurezza dei worker del nuovo cluster.
Quando si crea autonomamente un gateway VPE condiviso, è necessario associargli il gruppo di sicurezza “ kube-vpegw-<vpcID> ”. “ IBM Cloud Kubernetes Service ” non associa automaticamente il proprio gruppo di sicurezza ai
gateway che non ha creato.
IBM Cloud Kubernetes Service identifica i gateway VPE condivisi che gestisce in base al prefisso del loro nome. I gateway creati da IBM Cloud Kubernetes Service utilizzano la convenzione di denominazione iks-. I gateway VPE condivisi
e il gruppo di sicurezza “ kube-vpegw-<vpcID> ” non vengono eliminati quando un cluster viene rimosso dalla VPC. “ IBM Cloud Kubernetes Service ” non modifica gli indirizzi IP riservati dei gateway VPE condivisi che non
ha creato. Se si rinomina un gateway creato da IBM Cloud Kubernetes Service (rimuovendo il prefisso iks- ), IBM Cloud Kubernetes Service smette di gestire gli indirizzi IP riservati di quel gateway. Questo è il metodo consigliato
per assumere la proprietà di un gateway creato da IBM Cloud Kubernetes Service senza interrompere la connettività esistente.
In una configurazione VPC di tipo “hub and spoke”, in cui i VPC “spoke” delegano la risoluzione DNS a un VPC “hub”, IBM Cloud Kubernetes Service crea sempre gateway VPE condivisi nel VPC “spoke” quando vi viene provisionato un cluster. Ciò garantisce la connettività nel caso in cui il raggio dovesse mai scollegarsi dal mozzo. Se la delega DNS instrada gli endpoint spoke attraverso l'hub, i gateway spoke non vengono utilizzati per la risoluzione DNS. È comunque necessario configurare i gruppi di sicurezza sui gateway VPE condivisi dell'hub per consentire il traffico in entrata proveniente dalle sottoreti VPC degli spoke. Per ulteriori informazioni, consultare la sezione " Considerazioni relative alle VPC hub-and-spoke con protezione del traffico in uscita ".
Gruppo di sicurezza dei servizi del programma di bilanciamento del carico
Ogni cluster dispone di un gruppo di sicurezza denominato " kube-lbaas-<clusterID> " associato a tutti i propri bilanciatori di carico (ALB e NLB). Gli NLB di tipo "Private Path" non supportano l'associazione
di gruppi di sicurezza.
Le regole di questo gruppo di sicurezza vengono generate e aggiornate dinamicamente man mano che i bilanciatori di carico vengono aggiunti, aggiornati o rimossi. IBM Cloud Kubernetes Service monitora tutte le regole in entrata e in uscita
di questo gruppo di sicurezza e rimuove automaticamente eventuali regole in eccesso che non riconosce come necessarie. Se si esegue il comando ibmcloud ks security-group reset``, tutte le regole vengono eliminate e vengono
ripristinate solo le regole predefinite di IBM Cloud Kubernetes Service.
Le regole in uscita di questo gruppo di sicurezza instradano il traffico verso le porte dei nodi di lavoro a cui sono mappate le porte esterne (come le porte 80 e 443). Non modificare né eliminare alcuna regola in uscita nel gruppo di sicurezza
“ kube-lbaas-<clusterID> ”.
Limitazione del traffico in entrata verso i bilanciatori di carico pubblici
Una situazione comune consiste nel limitare gli indirizzi IP di origine che possono inviare traffico a un bilanciatore di carico pubblico. Per limitare il traffico in entrata su una porta specifica (ad esempio TCP porta 443):
- Aggiungere regole di ingresso al gruppo di sicurezza "
kube-lbaas-<clusterID>" per quella porta, specificando gli indirizzi IP di origine o i blocchi CIDR consentiti. È possibile creare più regole per consentire l'accesso a più indirizzi IP di origine. - Una volta create le regole relative agli indirizzi IP di origine consentiti, elimina la regola in entrata predefinita che consente l'accesso a tutti gli indirizzi IP (
0.0.0.0/0) su quella porta.
Ogni porta in entrata esposta dal bilanciatore di carico deve avere almeno una regola: o la regola predefinita che consente l'accesso a tutti gli indirizzi IP, oppure una o più regole personalizzate relative agli indirizzi IP di origine. Se si elimina la regola predefinita "consenti tutti gli IP" senza aver prima aggiunto una regola che consenta l'IP di origine per quella porta, IBM Cloud Kubernetes Service ricrea automaticamente la regola "consenti tutti gli IP".
Gruppi di sicurezza personalizzati di LBaaS
Se disponi sia di bilanciatori di carico pubblici che privati e desideri applicare regole firewall diverse per ciascuno di essi (ad esempio, limitando gli indirizzi IP di origine per i bilanciatori di carico pubblici mentre consenti tutto
il traffico verso quelli privati), puoi associare un gruppo di sicurezza personalizzato a specifici bilanciatori di carico utilizzando l'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group ,
anziché utilizzare l'impostazione predefinita del cluster.
Quando si utilizza un gruppo di sicurezza personalizzato LBaaS:
- IBM Cloud Kubernetes Service continua a creare automaticamente eventuali regole di ingresso necessarie che mancano.
- IBM Cloud Kubernetes Service non rimuove mai le regole che aggiungi al gruppo di sicurezza personalizzato.
| 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à.
È inoltre possibile associare un gruppo di sicurezza personalizzato a un bilanciatore di carico aggiungendo l'annotazione service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group alla risorsa del
bilanciatore di carico. Ciò risulta utile se si dispone sia di bilanciatori di carico pubblici che privati e si desidera limitare chi può inviare traffico al bilanciatore di carico pubblico. Quando si utilizza un gruppo di sicurezza personalizzato
di LBaaS, IBM Cloud Kubernetes Service crea automaticamente delle regole per il traffico in entrata, ma non elimina automaticamente le regole aggiuntive inserite dall'utente. Per ulteriori informazioni, consultare la sezione " Gruppi di sicurezza personalizzati di LBaaS".
Per ulteriori informazioni, vedere Creazione e gestione dei gruppi di sicurezza VPC.
Limitazioni
- Gruppi di sicurezza nodo di lavoro
- Poiché i nodi di lavoro del tuo cluster VPC risiedono 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 di lavoro. È possibile
modificare solo il gruppo di sicurezza
kube-<clusterID>esistente. - Registrazione e monitoraggio
- Quando si configura la registrazione e il controllo su un cluster 1.30 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.comper 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
- Ogni volta che si crea un cluster, vengono aggiunti dei gruppi di sicurezza alla tua VPC, che può contenere fino a un massimo di 100 gruppi di sicurezza. Questo limite viene raggiunto intorno ai 33 cluster, pertanto si consiglia un massimo di 25 cluster per VPC. Per ulteriori informazioni, consultare la sezione " Quote 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-clusterIDper consentire il traffico in uscita alla porta del master clusterapiserver. 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.