Opzione 1: Disabilitazione della protezione del traffico in uscita quando si crea un cluster

Questa opzione consente tutte le connessioni di rete in uscita.

• Nella console, selezionare l'opzione Consenti traffico in uscita.
• Nella CLI, quando si crea un cluster usando il comando'cluster create vpc-gen2, specificare l'opzione '--disable-outbound-traffic-protection.
• In Terraform, specificare l'opzione 'disable_outbound_traffic_protection = true.
• Nell'API, specificare l'opzione 'disableOutboundTrafficProtection=true.

Opzione 2: Consentire il traffico in uscita attraverso un gruppo di sicurezza personalizzato

Prima di creare il cluster, creare un gruppo di sicurezza personalizzato nella VPC che consenta l'accesso al sito o al servizio esterno a cui il cluster deve accedere. Quindi, collegare questo gruppo di sicurezza al cluster durante la creazione del cluster.

• Nella console, specificare il gruppo di sicurezza personalizzato.
• Nella CLI, quando si crea un cluster usando il comando'cluster create vpc-gen2, specificare l'opzione '--cluster-security-group <security-group-ID> e includere l'ID del gruppo di sicurezza personalizzato.
• In Terraform, specificare l'opzione 'security_groups e includere il gruppo personalizzato.

Opzione 1: Disabilitazione della protezione del traffico in uscita dalla CLI

Questa opzione consente tutte le connessioni di rete esterne.

ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER

Opzione 2: Aggiunta di una regola del gruppo di sicurezza al gruppo di sicurezza predefinito dei lavoratori del cluster

È possibile aggiungere una regola del gruppo di sicurezza al gruppo di sicurezza dei lavoratori del cluster (kube-<clusterID>) che consente l'accesso al sito esterno specifico. Ripetere questo passaggio per ogni sito o sottorete a cui il cluster deve accedere. Per ulteriori informazioni, scenari di esempio per consentire selettivamente il traffico in uscita.

ibmcloud is sg-rulec kube-CLUSTERID outbound icmp_tcp_udp --remote IP-ADDRESS-OR-SUBNET

Accesso alle immagini da registri di container esterni come DockerHub o 'quay.io

Per accedere alle immagini da registri come DockerHub o 'quay.io o 'registry.redhat.com, scegliere una delle seguenti opzioni.

• Disattivare la protezione del traffico in uscita.

  ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER
  

• Specchiare le immagini di cui l'applicazione ha bisogno in 'icr.io. Estrarre, etichettare e spingere le immagini in IBM Cloud Container Registry. Per ulteriori informazioni, vedere Spinta delle immagini a IBM Cloud Container Registry.

Consentire il traffico in uscita verso Red Hat Marketplace e OperatorHub

I passaggi seguenti abilitano tutto il traffico in uscita. Se non desideri abilitare questa funzione, puoi duplicare le immagini presenti su Red Hat Marketplace e OperatorHub, necessarie alla tua app, sul tuo icr.io.

1. Disattivare la protezione del traffico in uscita.

   ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER
   

2. Applicare le patch di OperatorHub sul cluster per consentire l'avvio dei pod.

   oc patch OperatorHub cluster --type json -p '[{"op": "remove", "path": "/spec/disableAllDefaultSources"}]'
   

Per ripristinare queste modifiche in un secondo momento e disabilitare OperatorHub, completare i passaggi seguenti.

1. Abilitare la protezione del traffico in uscita.

   ibmcloud oc vpc outbound-traffic-protection enable --cluster CLUSTER
   

2. Applicare una patch a OperatorHub sul cluster per disabilitare i pod

   oc patch OperatorHub cluster --type json -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
   

Consentire il traffico in uscita ai flussi di immagini

Per accedere ai flussi di immagini dal cluster, scegliere una delle seguenti opzioni.

• Eseguire il mirroring delle immagini necessarie nel registro 'icr.io. Per ulteriori informazioni, vedere Spinta delle immagini a IBM Cloud Container Registry.

• Disattivare la protezione del traffico in uscita.

  ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER
  

• Aggiungere una regola del gruppo di sicurezza 'kube-<clusterID> agli indirizzi IP del flusso di immagini che si desidera utilizzare. Si noti che gli indirizzi IP dei flussi di immagini potrebbero cambiare.

  ibmcloud is sg-rulec kube-vpegw-<clusterID> inbound tcp --port-min PORT  --port-max PORT --remote IP-OR-CIDR
  

Consentire il traffico in uscita per il monitoraggio remoto della salute con Telemetria

Per consentire il monitoraggio remoto dello stato di salute, è necessario disabilitare la protezione del traffico in uscita eseguendo il seguente comando.

ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER

Accesso ai cluster 4.15 e alla console web tramite VPE

È possibile configurare Kubernetes per consentire l'accesso al cluster tramite il gateway vpe privato. Questa opzione è disponibile sia per i cluster VPC privati che per quelli pubblici e privati. Poiché l'accesso avviene tramite l'endpoint privato, il cliente deve impostare una VPN dal client al proprio VPC per accedere al cluster.

A partire dai cluster 4.15, per l'accesso a VPE è necessaria una regola di gruppo di sicurezza aggiuntiva. La regola aggiuntiva del gruppo di sicurezza è necessaria sia per i cluster solo privati che per i cluster con endpoint pubblici e privati.

1. Elencare i server VPN.

   ibmcloud is vpn-servers
   

2. Ottenete i dettagli del vostro server VPN.

   ibmcloud is vpn-server SERVER
   

3. Ottenere il pool di IP client del server VPN.

   ibmcloud is vpn-server | grep "Client IP pool"
   

4. Ottenere i dettagli del cluster e prendere nota della porta VPE.

   ibmcloud ks cluster get --cluster CLUSTERID
   

5. Avviare la VPN sul client.

6. Accedere al cluster tramite VPE.

   ibmcloud ks cluster config --admin --cluster CLUSTERID --endpoint vpe
   

7. Elenco baccelli. Si noti che questo comando fallisce perché il client non può accedere al cluster tramite la VPN attraverso il gateway VPE.

   kubectl get pods -A
   

8. Aggiungere una regola del gruppo di sicurezza al 'kube-vpegw-<clusterID> per la VPN. In questo caso, il remoto proviene dal CIDR IP del client della VPN.

   ibmcloud is sg-rulec kube-vpegw-<clusterID> inbound tcp --port-min PORT  --port-max PORT --remote IP-OR-CIDR
   

   Esempio di comando.

   ibmcloud is sg-rulec kube-vpegw-<clusterID> inbound tcp --port-min 30829  --port-max 30829 --remote 192.168.192.0/22
   

9. Elenco baccelli.

   kubectl get pods -A
   

Consentire il traffico in uscita per i webhook

Se si utilizzano webhook che contattano un sito URL o un servizio esterno al cluster, è necessario aggiungere regole di gruppo di sicurezza che consentano il traffico in uscita dai worker del cluster verso il sito URL o il servizio esterno. In alternativa, è possibile disattivare completamente la protezione del traffico in uscita.

Di solito, i webhook di ammissione che utilizzano i riferimenti ai servizi del cluster non richiedono alcuna modifica.

Nell'esempio seguente, un webhook di ammissione che si connette a un servizio del cluster di solito non richiede alcuna modifica perché il master si connette al servizio tramite la connessione Konnectivity, consentita per impostazione predefinita. Un'eccezione è rappresentata dal caso in cui i pod che implementano il servizio del cluster debbano connettersi a URL o a un servizio esterno. In caso affermativo, consentire a questi pod di accedere a URL o a un servizio esterno, come mostrato in questo esempio.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: my-cluster-service.webhook.io
webhooks:
- admissionReviewVersions:
  - v1
  clientConfig:
    caBundle: ABCDEFG...
    service:
      name: my-admission-webhook
      namespace: default
      path: /validate
      port: 443
...

Tuttavia, se i webhook di ammissione utilizzano un sito URL, sono necessarie regole di gruppo di sicurezza aggiuntive.

Esempio di webhook che si connette a un sito URL.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: my-url.webhook.io
webhooks:
- admissionReviewVersions:
  - v1
  clientConfig:
    caBundle: ABCDEFG...
    url: https://webhook.ibm.com:20001/validate
...

Per consentire l'accesso al sito URL o al servizio esterno per il webhook, è possibile scegliere una delle seguenti opzioni

• Disattivare la protezione del traffico in uscita eseguendo il seguente comando.

  ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER
  

• Aggiungere le regole del gruppo di sicurezza in uscita al gruppo di sicurezza 'kube-<clusterID> per consentire la connessione dei lavoratori del cluster. Nell'esempio precedente, viene utilizzato il servizio " webhook.ibm.com sulla porta " 20001.

  1. Cercare gli IP per l'accesso a URL utilizzando dig.

      dig +short URL
      ```
      Esempio di comando.
      ```sh {: pre}
      dig +short webhook.ibm.com
      ```
      Output di esempio
      ```sh {: screen}
      1.2.3.4
      4.5.6.7
      ```
  1. Creare una regola per ogni indirizzo IP restituito.
  
  ```sh {: pre}
      ibmcloud is sg-rulec kube-<clusterID> outbound icmp_tcp_udp --remote <IP-address-or-subnet>
      ```
      Esempi di comandi.
      ```sh {: pre}
      ibmcloud is sg-rulec kube-CLUSTERID outbound tcp --port-min 20001 --port-max 20001 --remote 1.2.3.4
      ibmcloud is sg-rulec kube-CLUSTERID outbound tcp --port-min 20001 --port-max 20001 --remote 4.5.6.7
      ```
  
  

Per ulteriori informazioni, consultare la sezione " Controllo dinamico delle ammissioni "

Consentire il traffico in uscita verso un servizio pubblico

Se il servizio o i servizi esterni richiamati dall'applicazione hanno un piccolo insieme di IP/CIDR utilizzati per ospitare il servizio che non cambiano molto spesso, è possibile consentire selettivamente l'accesso in uscita a tali IP o CIDR nel gruppo di sicurezza 'kube-clusterID.

L'esempio seguente utilizza le API di github.com a 'api.github.com.

1. Trovare gli IP in modo programmatico per 'curl.

   curl -sS -H "Accept: application/vnd.github+json" https://api.github.com/meta | jq '.api'
   

2. Aggiungere ciascuno dei CIDR individuati nel passaggio precedente come destinazione di una regola del gruppo di sicurezza in uscita sul gruppo di sicurezza 'kube-clusterID. In alternativa, è possibile creare un gruppo di sicurezza personalizzato da aggiungere ai lavoratori del cluster al momento della creazione del cluster.

   ibmcloud is sg-rulec kube-<clusterID> outbound icmp_tcp_udp --remote <IP-address-or-subnet>
   

Per ulteriori informazioni, vedere Informazioni sugli indirizzi IP GitHub's.

Considerazioni per le VPC hub e spoke con protezione del traffico in uscita

In un modello hub and spoke, solo il cluster VPC dell'hub viene utilizzato per la risoluzione DNS. I cluster spoke accedono al DNS tramite l'hub. I cluster hub e spoke si trovano spesso in VPC diverse, collegate tramite Transit Gateway.

Nei cluster della versione 4.15 e successive, il modello hub and spoke non funziona se non si modificano i gruppi di sicurezza per ciascuno di essi. Queste regolazioni consentono il traffico tra l'hub e le VPC spoke.

1. Aggiornare i cluster nella VPC spoke in modo che possano accedere alla VPC hub aggiungendo regole al gruppo di sicurezza 'kube-<clusterID> per ogni cluster spoke. Assicurarsi di aggiungere una regola in uscita a ciascuna subnet CIDR della VPC in cui sono distribuiti i lavoratori del cluster hub. Ad esempio, se uno spoke si connette a un singolo hub e tale hub ha lavoratori in tre zone, è necessario aggiungere tre regole al gruppo di sicurezza 'kube-<clusterID> dello spoke, una per ogni sottorete.

   ibmcloud is sg-rulec kube-<spoke-clusterID> outbound icmp_tcp_udp --remote <hub-subnet-CIDR>
   

2. Aggiornare i cluster hub per consentire il traffico dagli spokes aggiungendo regole al gruppo di sicurezza del gateway VPE condiviso dell'hub (kube-vpegw-vpcID). In alternativa, se si utilizzano gruppi di sicurezza personalizzati per i gateway VPE condivisi, aggiungere le regole a tali gruppi di sicurezza personalizzati.

3. Eseguire il seguente comando per trovare i gateway VPE, quindi esaminare i dettagli del gateway per trovare il gruppo di sicurezza associato. Prendere nota dell'ID del gruppo di sicurezza per aggiungervi le regole nel passaggio successivo.

   ibmcloud is egs
   

4. Aggiungere una regola in entrata da ciascuna sottorete VPC in cui sono distribuiti i lavoratori spoke. Ad esempio, se gli spokes sono distribuiti in tre zone diverse ma in una singola subnet in ognuna di esse, vengono aggiunte tre regole ai gruppi di sicurezza del gateway VPE condiviso dell'hub.

   ibmcloud is sg-rulec kube-vpegw-<hub-vpcID> inbound icmp_tcp_udp --remote <spoke-subnet-CIDR>
   

Consentire il traffico temporaneo verso il server API del cluster attraverso la rete pubblica

I lavoratori del cluster VPC utilizzano la rete privata per comunicare con il master del cluster. In precedenza, per i cluster VPC con l'endpoint del servizio pubblico abilitato, se la rete privata era bloccata o non disponibile, i lavoratori del cluster potevano tornare a usare la rete pubblica per comunicare con il master del cluster.

Nei cluster 4.15 e successivi, il ritorno alla rete pubblica non è un'opzione perché il traffico pubblico in uscita dai lavoratori del cluster è bloccato. È possibile disattivare la protezione del traffico in uscita per consentire questa opzione di backup della rete pubblica, ma esiste un'alternativa migliore. Se invece si verifica un problema temporaneo con la connessione worker-master sulla rete privata, è possibile aggiungere una regola temporanea del gruppo di sicurezza 'kube-clusterID per consentire il traffico in uscita verso la porta 'apiserver del cluster master. In seguito, quando il problema sarà risolto, sarà possibile rimuovere la regola temporanea.

È possibile scegliere una delle seguenti opzioni per consentire il traffico sulla rete pubblica se la rete privata è inattiva.

• Aggiungere una regola del gruppo di sicurezza al gruppo di sicurezza 'kube-clusterID per consentire il traffico verso il server API.

  1. Ottenere i dettagli del cluster e prendere nota della porta del server API.

      ic ks cluster get --cluster <clusterID>
      ```
      Esempio di output dove la porta del server API è '`30685`.
  
      ```sh {: screen}
      Name:                           prestg-sbd-vpc-4.15
      ID:                             coekl4a107ovqfndhh60
      ...
      Public Service Endpoint URL:    https://c100-e.containers.cloud.ibm.com:30685
      Private Service Endpoint URL:   https://c100.private.containers.cloud.ibm.com:30685
      ...
      ```
  1. Aggiungere una regola del gruppo di sicurezza in uscita da '`kube-<clusterID>` a '`0.0.0.0/0` per consentire l'accesso alla rete pubblica.
  ```sh {: pre}
      ibmcloud is sg-rulec kube-<clusterID> outbound tcp --port-min <API port> --port-max <API port> --remote 0.0.0.0/0
      ```
      Comando di esempio con una porta del server API di '`30685`.
      ```sh {: pre}
      ibmcloud is sg-rulec kube-<clusterID> outbound tcp --port-min 30685 --port-max 30685 --remote 0.0.0.0/0
      ```
  
  

• Disattivare la protezione del traffico in uscita.

  ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER
  

Verifica dell'integrazione di Sysdig su cluster RHCOS solo privati

Se i pod sysdig-agent si trovano in CrashLoopBackOff su un cluster di soli privati che utilizza i worker RHCOS, è possibile disabilitare la protezione del traffico in uscita o aggiornare l'agente Sysdig per utilizzare il driver eBPF. Per ulteriori informazioni, vedere Perché i pod sysdig-agent si trovano in CrashLoopBackOff su un cluster RHCOS privato?