Définition de sous-réseaux personnalisés lors de la création de votre emplacement

Lors de la création d'un lieu

Lorsque vous créez votre emplacement dans l'interface de ligne de commande, vous pouvez définir les paramètres suivants pour personnaliser la mise en réseau dans votre emplacement. Pour plus d'informations, voir la référence de commande ibmcloud sat location create.

Vous pouvez spécifier l'option --pod-subnet pour spécifier un CIDR de sous-réseau personnalisé afin de fournir des adresses IP privées pour les pods. Cette option ne peut être utilisée que si vous activez également Red Hat CoreOS avec le drapeau --coreos-enabled. Le sous-réseau doit avoir une taille d'au moins ou /23 supérieure. La valeur par défaut est 172.16.0.0/16.

Vous pouvez également spécifier l'option --service-subnet pour spécifier un routage CIDR de sous-réseau personnalisé afin de fournir des adresses IP privées pour les services. Cette option ne peut être utilisée que si vous activez également Red Hat CoreOS avec le drapeau --coreos-enabled. Le sous-réseau doit avoir une taille d'au moins ou /24 supérieure. La valeur par défaut est 172.20.0.0/16.

Définition de l'interface réseau de pod lors de la création de votre emplacement

Lors de la création d'un lieu

Lorsque vous créez votre emplacement dans l'interface de ligne de commande, vous pouvez définir le --pod-network-interface pour définir l'interface réseau de pod. Les méthodes disponibles sont can-reach et interface.

• Pour fournir une adresse URL ou IP directe, spécifiez can-reach=<url> ou can-reach=<ip_address>. Si l'interface réseau peut atteindre l'adresse URL ou IP fournie, cette option est utilisée. Par exemple, utilisez can-reach=www.exampleurl.com pour spécifier une adresse URL et can-reach=172.19.0.0 pour spécifier une adresse IP.
• Pour choisir une interface avec une chaîne Regex, spécifiez interface=<regex_string>; par exemple, interface=eth.*.

Pour plus d'informations, voir la référence de commande ibmcloud sat location create.

Définition de l'interface réseau de pod lors de la création de votre cluster

Lors de la création d'un cluster

Lorsque vous créez votre cluster dans l'interface de ligne de commande, vous pouvez définir le --pod-network-interface pour définir l'interface réseau de pod. Les méthodes disponibles sont can-reach et interface.

• Pour fournir une adresse URL ou IP directe, spécifiez can-reach=<url> ou can-reach=<ip_address>. Si l'interface réseau peut atteindre l'adresse URL ou IP fournie, cette option est utilisée. Par exemple, utilisez can-reach=www.exampleurl.com pour spécifier une adresse URL et can-reach=172.19.0.0 pour spécifier une adresse IP.
• Pour choisir une interface avec une chaîne Regex, spécifiez interface=<regex_string>; par exemple, interface=eth.*.

Pour plus d'informations, voir la référence de commande ibmcloud oc cluster create satellite.

Limitation de l'accès à votre cluster Satellite

Après la localisation et la création du cluster

Après avoir créé votre emplacement et votre cluster, vous pouvez utiliser la commande ibmcloud ks cluster master satellite-service-endpoint allowlist add pour ajouter un sous-réseau à la liste autorisée des noeuds finaux de service du cluster Satellite. Les requêtes autorisées adressées au maître du cluster et provenant du sous-réseau sont autorisées via le point de terminaison du service Satellite. La liste autorisée doit être activée pour que les restrictions s'appliquent.

Création de règles réseau à l'aide de noeuds finaux d'hôte Calico

Après la localisation et la création du cluster

Si vous créez un cluster Satellite version 4.12 et ultérieure, des instances Calico Hostendpoint sont déployées sur le cluster pour l'interface réseau de chaque noeud worker.

Vous pouvez utiliser ces instances Hostendpoint pour définir des règles réseau globales à l'aide du libellé “ibm-cloud.kubernetes.io/interface-name: <network_interface_name>” qui est ajouté à chaque instance Hostendpoint.

En plus de ce libellé, tous les libellés du noeud worker sont ajoutés pour des options de personnalisation supplémentaires.

Ces Hostendpoints ont le profil “projectcalico-default-allow", ce qui signifie que ces Hostendpoints peuvent modifier le comportement attendu lors de la mise à jour vers 4.12.

Avant de procéder à la mise à jour vers 4.12, assurez-vous que toutes les règles de mise en réseau, stratégies et Hostendpoints précédemment attendues fonctionnent de la même manière après la mise à jour.

Pour plus d'informations, voir la documentationCalico.

Restriction de l'accès au service NodePort

Après la localisation et la création du cluster

Par défaut, les services NodePort sont accessibles sur toutes les interfaces réseau disponibles pour le cluster, par exemple 0.0.0.0.

Toutefois, dans les emplacements Satellite où plusieurs réseaux sont disponibles pour les hôtes, vous pouvez limiter les interfaces réseau disponibles pour vos services.

Pour limiter la plage, vous limitez les adresses d'écoute des services NodePort au niveau du cluster. Cette restriction permet à l'administrateur de cluster de limiter l'accès à une interface réseau spécifique en utilisant le sous-réseau IP comme plage d'adresses d'écoute autorisée. Procédez comme suit pour reconfigurer le composant kube-proxy afin de limiter la plage d'adresses d'écoute pour vos services NodePort.

Une configuration incorrecte de node-port-addresses peut isoler vos services des sources valides. Veillez à prévoir tous les sous-réseaux dont votre service a besoin. IBM Cloud n'a besoin d'accéder à aucun sous-réseau pour gérer vos clusters.

1. Accédez à votre cluster Red Hat OpenShift.

2. Préparez votre liste CIDR de sous-réseau source planifiée que vous souhaitez autoriser à accéder aux services NodePort.

3. Exécutez la commande suivante pour obtenir la configuration network.operator.openshift.io et sauvegarder une copie au cas où vous auriez besoin d'annuler les modifications.

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

4. Editez la configuration network.operator.openshift.io et définissez la liste de sous-réseaux sous la section spec et incluez les sous-réseaux requis pour votre service NodePort.

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

5. Sauvegardez vos modifications et appliquez-les au cluster.

   oc apply -f updated-network-config.yaml
   

6. Pour la version de cluster 4.10.x et les versions antérieures, définissez l'état de gestion de l'opérateur réseau de cluster sur Unmanaged.

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

7. Redémarrez le service DaemonSetkube-proxy pour appliquer les modifications. Cette opération n'entraîne aucune interruption.

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

8. Attendez que tous vos pods kube-proxy soient redémarrés. Vérifiez l'état en exécutant la commande suivante.

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

9. Pour la version de cluster 4.10.x et les versions antérieures, réinitialisez l'état de gestion de l'opérateur réseau de cluster sur Managed. Notez que cette action peut redémarrer les pods de proxy.

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

Une fois tous les pods redémarrés, votre cluster est configuré avec les sous-réseaux restreints. Vous pouvez répéter ces étapes pour mettre à jour ou supprimer la liste de sous-réseaux si nécessaire.

Vous pouvez restreindre davantage le trafic en utilisant NetworkPolicies par service.