Option 1 : Désactiver la protection du trafic sortant lors de la création d'un cluster

Cette option autorise toutes les connexions réseau sortantes.

• Dans la console, sélectionnez l'option Autoriser le trafic sortant.
• Dans l'interface de programmation, lorsque vous créez un cluster à l'aide de la commande" cluster create vpc-gen2, spécifiez l'option " --disable-outbound-traffic-protection
• Dans Terraform, spécifiez l'option 'disable_outbound_traffic_protection = true
• Dans l'API, spécifiez l'option " disableOutboundTrafficProtection=true

Option 2 : Autoriser le trafic sortant par l'intermédiaire d'un groupe de sécurité personnalisé

Avant de créer votre cluster, créez un groupe de sécurité personnalisé dans votre VPC qui autorise l'accès au site ou au service externe auquel votre cluster doit accéder. Attachez ensuite ce groupe de sécurité à votre cluster lors de la création du cluster.

• Dans la console, indiquez votre groupe de sécurité personnalisé.
• Dans l'interface de gestion, lorsque vous créez un cluster à l'aide de la commande" cluster create vpc-gen2, spécifiez l'option " --cluster-security-group <security-group-ID> et incluez votre identifiant de groupe de sécurité personnalisé.
• Dans Terraform, spécifiez l'option 'security_groups et incluez votre groupe personnalisé.

Option 1 : Désactivation de la protection du trafic sortant à partir de la CLI

Cette option autorise toutes les connexions réseau externes.

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

Option 2 : Ajout d'une règle de groupe de sécurité au groupe de sécurité par défaut du travailleur en grappe

Vous pouvez ajouter une règle de groupe de sécurité au groupe de sécurité du travailleur en cluster (kube-<clusterID>) qui autorise l'accès au site externe spécifique. Répétez cette étape pour chaque site ou sous-réseau auquel votre cluster doit accéder. Pour plus d'informations, voir Exemples de scénarios pour l'autorisation sélective du trafic sortant.

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

Accès aux images à partir de registres de conteneurs externes tels que DockerHub ou " quay.io

Pour accéder à des images provenant de registres tels que DockerHub ou 'quay.io ou 'registry.redhat.com, choisissez l'une des options suivantes.

• Désactiver la protection du trafic sortant.

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

• Mettez en miroir les images dont votre application a besoin dans 'icr.io. Tirez ces images, marquez-les et publiez-les dans IBM Cloud Container Registry Pour plus d'informations, voir Pousser des images vers IBM Cloud Container Registry

Autoriser le trafic sortant vers Red Hat Marketplace et OperatorHub

Les étapes suivantes permettent d'activer tout le trafic sortant. Si vous ne souhaitez pas activer cette fonctionnalité, vous pouvez dupliquer les images Red Hat Marketplace et OperatorHub dont votre application a besoin sur votre propre icr.io.

1. Désactiver la protection du trafic sortant.

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

2. Patch OperatorHub sur votre cluster pour permettre aux pods de démarrer.

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

Pour revenir ultérieurement sur ces modifications et désactiver OperatorHub, procédez comme suit.

1. Activer la protection du trafic sortant.

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

2. Patch OperatorHub sur votre cluster pour désactiver les pods

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

Autoriser le trafic sortant vers les flux d'images

Pour accéder aux flux d'images de votre cluster, choisissez l'une des options suivantes.

• Mettez en miroir les images dont vous avez besoin dans le registre " icr.io Pour plus d'informations, voir Pousser des images vers IBM Cloud Container Registry

• Désactiver la protection du trafic sortant.

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

• Ajoutez une règle de groupe de sécurité au groupe de sécurité " kube-<clusterID> pour les adresses IP du flux d'images que vous souhaitez utiliser. Notez que les adresses IP des flux d'images peuvent changer.

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

Autoriser le trafic sortant pour la surveillance de la santé à distance avec Telemetry

Pour permettre la surveillance de l'état de santé à distance, vous devez désactiver la protection du trafic sortant en exécutant la commande suivante.

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

Accès aux clusters 4.15 et à la console web via le VPE

Vous pouvez configurer Kubernetes pour autoriser l'accès au cluster via la passerelle vpe privée. Cette option est disponible pour les clusters VPC privés uniquement, mais aussi pour les clusters publics et privés. Comme l'accès se fait via le point d'extrémité privé, le client doit mettre en place un VPN entre le client et son VPC pour accéder à la grappe.

À partir des clusters 4.15, une règle de groupe de sécurité supplémentaire est nécessaire pour que l'accès VPE fonctionne. La règle de groupe de sécurité supplémentaire est nécessaire pour les clusters privés uniquement et les clusters avec des points d'extrémité publics et privés.

1. Listez vos serveurs VPN.

   ibmcloud is vpn-servers
   

2. Obtenez les détails de votre serveur VPN.

   ibmcloud is vpn-server SERVER
   

3. Obtenez le pool d'IP client de votre serveur VPN.

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

4. Obtenez les détails de votre cluster et notez le port VPE.

   ibmcloud ks cluster get --cluster CLUSTERID
   

5. Démarrez votre VPN sur le client.

6. Accédez à votre cluster via VPE.

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

7. Répertoriez les pods. Notez que cette commande échoue parce que le client ne peut pas accéder au cluster via le VPN à travers la passerelle VPE.

   kubectl get pods -A
   

8. Ajoutez une règle de groupe de sécurité au " kube-vpegw-<clusterID> pour votre VPN. Dans ce cas, la distance provient du CIDR de l'IP du client du VPN.

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

   Exemple de commande.

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

9. Répertoriez les pods.

   kubectl get pods -A
   

Autoriser le trafic sortant pour les webhooks

Si vous utilisez des webhooks qui contactent un site URL ou un service externe au cluster, vous devez ajouter des règles de groupe de sécurité qui autorisent le trafic sortant des travailleurs de votre cluster vers le site URL ou le service externe. Vous pouvez également désactiver complètement la protection du trafic sortant.

En général, les webhooks d'admission qui utilisent les références des services de cluster ne nécessitent aucune modification.

Dans l'exemple suivant, un webhook d'admission qui se connecte à un service de cluster ne nécessite généralement aucune modification car le maître se connecte au service via la connexion Konnectivity, qui est autorisée par défaut. Une exception serait si les pods mettant en œuvre ce service de cluster devaient se connecter à URL ou à un autre service externe. Si c'est le cas, autorisez ces pods à accéder à URL ou à un service externe, comme le montre cet exemple.

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
...

Toutefois, si vos webhooks d'admission utilisent une adresse URL, des règles de groupe de sécurité supplémentaires sont nécessaires.

Exemple de webhook qui se connecte à 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
...

Pour autoriser l'accès à l'adresse URL ou au service externe pour votre webhook, vous pouvez choisir l'une des options suivantes

• Désactivez la protection du trafic sortant en exécutant la commande suivante.

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

• Ajoutez des règles de groupe de sécurité sortantes au groupe de sécurité 'kube-<clusterID> pour permettre aux travailleurs du cluster de se connecter. Dans l'exemple précédent, le service " webhook.ibm.com sur le port " 20001 est utilisé.

  1. Recherchez les adresses IP auxquelles URL doit accéder en utilisant dig.

      dig +short URL
      ```
      Exemple de commande.
      ```sh {: pre}
      dig +short webhook.ibm.com
      ```
      Exemple de sortie
      ```sh {: screen}
      1.2.3.4
      4.5.6.7
      ```
  1. Créez une règle pour chaque adresse IP renvoyée.
  
  ```sh {: pre}
      ibmcloud is sg-rulec kube-<clusterID> outbound icmp_tcp_udp --remote <IP-address-or-subnet>
      ```
      Exemple de commandes.
      ```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
      ```
  
  

Pour plus d'informations, consultez la section « Contrôle dynamique des admissions ».

Autoriser le trafic sortant vers un service public

Si le ou les services externes appelés par votre application ont un petit ensemble d'IPs/CIDRs utilisés pour héberger ce service et qui ne changent pas très souvent, vous pouvez autoriser sélectivement l'accès sortant à ces IPs ou CIDRs dans votre groupe de sécurité 'kube-clusterID

L'exemple suivant utilise les API de github.com à " api.github.com.

1. Trouver les adresses IP de manière programmatique par 'curl.

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

2. Ajoutez chacun des CIDR trouvés à l'étape précédente comme destination d'une règle de groupe de sécurité sortante sur le groupe de sécurité 'kube-clusterID Vous pouvez également créer un groupe de sécurité personnalisé que vous ajoutez aux travailleurs de votre grappe au moment de la création de la grappe.

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

Pour plus d'informations, voir À propos des adresses IP GitHub's.

Considérations relatives aux VPC hub et spoke avec protection du trafic sortant

Dans un modèle en étoile, seul le cluster VPC de l'étoile est utilisé pour la résolution DNS. Les grappes de rayons accèdent au DNS par l'intermédiaire du concentrateur. Les clusters hub et spoke se trouvent le plus souvent dans des VPC différents, qui sont connectés via Transit Gateway.

Dans les clusters de la version 4.15 et des versions ultérieures, le modèle "hub and spoke" ne fonctionne pas sans ajustement des groupes de sécurité pour chacun d'entre eux. Ces ajustements permettent le trafic entre les VPCs hub et spoke.

1. Mettez à jour les clusters dans le VPC de rayon afin qu'ils puissent accéder au VPC du hub en ajoutant des règles au groupe de sécurité 'kube-<clusterID> pour chaque cluster de rayon. Veillez à ajouter une règle de sortie à chaque sous-réseau VPC CIDR dans lequel les travailleurs du cluster hub sont déployés. Par exemple, si un rayon se connecte à un hub unique et que ce hub a des employés dans trois zones, trois règles doivent être ajoutées au groupe de sécurité 'kube-<clusterID> du rayon, une pour chaque sous-réseau.

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

2. Mettez à jour les clusters du hub pour autoriser le trafic en provenance des spokes en ajoutant des règles au groupe de sécurité de la passerelle VPE partagée du hub (kube-vpegw-vpcID). Si vous utilisez vos propres groupes de sécurité personnalisés pour les passerelles VPE partagées, ajoutez des règles à ces groupes de sécurité personnalisés.

3. Exécutez la commande suivante pour trouver les passerelles VPE, puis consultez les détails de la passerelle pour trouver le groupe de sécurité qui lui est associé. Notez l'identifiant du groupe de sécurité pour y ajouter des règles à l'étape suivante.

   ibmcloud is egs
   

4. Ajoutez une règle de réception à partir de chaque sous-réseau VPC dans lequel les travailleurs itinérants sont déployés. Par exemple, si les rayons sont déployés dans trois zones différentes, mais sur un seul sous-réseau dans chacune de ces zones, trois règles sont ajoutées aux groupes de sécurité de la passerelle VPE partagée du concentrateur.

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

Autoriser le trafic temporaire vers le serveur API du cluster via le réseau public

Les travailleurs d'un cluster VPC utilisent le réseau privé pour communiquer avec le maître du cluster. Auparavant, pour les clusters VPC dont le point de terminaison de service public était activé, si le réseau privé était bloqué ou indisponible, les travailleurs du cluster pouvaient se rabattre sur le réseau public pour communiquer avec le maître du cluster.

Dans les clusters 4.15 et ultérieurs, le repli sur le réseau public n'est pas une option car le trafic public sortant des travailleurs du cluster est bloqué. Il se peut que vous souhaitiez désactiver la protection du trafic sortant pour permettre cette option de sauvegarde du réseau public, mais il existe une meilleure solution. En revanche, s'il y a un problème temporaire avec la connexion travailleur-maître sur le réseau privé, vous pouvez à ce moment-là ajouter une règle de groupe de sécurité temporaire au groupe de sécurité " kube-clusterID pour autoriser le trafic sortant vers le port " apiserver " du maître de cluster. Plus tard, lorsque le problème sera résolu, vous pourrez supprimer la règle temporaire.

Vous pouvez choisir l'une des options suivantes pour autoriser le trafic sur le réseau public si le réseau privé est en panne.

• Ajoutez une règle de groupe de sécurité au groupe de sécurité " kube-clusterID pour autoriser le trafic vers le serveur API.

  1. Obtenez les détails de votre cluster et notez le port du serveur API.

      ic ks cluster get --cluster <clusterID>
      ```
      Exemple de sortie lorsque le port du serveur API est " `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. Ajoutez une règle de groupe de sécurité sortante de votre " `kube-<clusterID>` à votre " `0.0.0.0/0` pour autoriser tous les accès au réseau public.
  ```sh {: pre}
      ibmcloud is sg-rulec kube-<clusterID> outbound tcp --port-min <API port> --port-max <API port> --remote 0.0.0.0/0
      ```
      Exemple de commande avec un port de serveur API de " `30685`.
      ```sh {: pre}
      ibmcloud is sg-rulec kube-<clusterID> outbound tcp --port-min 30685 --port-max 30685 --remote 0.0.0.0/0
      ```
  
  

• Désactiver la protection du trafic sortant.

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

Vérification de l'intégration de Sysdig sur des clusters RHCOS uniquement privés

Si les pods sysdig-agent sont dans CrashLoopBackOff sur un cluster privé qui utilise des travailleurs RHCOS, vous pouvez soit désactiver la protection du trafic sortant, soit mettre à jour l'agent Sysdig pour utiliser le pilote eBPF. Pour plus d'informations, voir Pourquoi les pods sysdig-agent se trouvent-ils dans CrashLoopBackOff sur un cluster RHCOS privé?