6.3. La politique de réseau
6.3.1. À propos de la politique de réseau Copier lienLien copié sur presse-papiers!
En tant que développeur, vous pouvez définir des stratégies réseau qui limitent le trafic aux pods dans votre cluster.
6.3.1.1. À propos de la politique de réseau Copier lienLien copié sur presse-papiers!
Par défaut, tous les pods d’un projet sont accessibles à partir d’autres gousses et points de terminaison réseau. Afin d’isoler un ou plusieurs pods dans un projet, vous pouvez créer des objets NetworkPolicy dans ce projet pour indiquer les connexions entrantes autorisées. Les administrateurs de projet peuvent créer et supprimer des objets NetworkPolicy dans leur propre projet.
Lorsqu’une pod est appariée par des sélecteurs dans un ou plusieurs objets NetworkPolicy, la pod n’acceptera que des connexions autorisées par au moins un de ces objets NetworkPolicy. La pod qui n’est pas sélectionnée par aucun objet NetworkPolicy est entièrement accessible.
La politique réseau ne s’applique qu’aux protocoles TCP, UDP, ICMP et SCTP. D’autres protocoles ne sont pas affectés.
La stratégie réseau ne s’applique pas à l’espace de noms du réseau hôte. Les pods avec le réseau hôte activé ne sont pas affectés par les règles de stratégie réseau. Cependant, les pods se connectant aux pods en réseau d’hôte pourraient être affectés par les règles de politique du réseau.
Les stratégies réseau ne peuvent pas bloquer le trafic de l’hôte local ou de leurs nœuds résidents.
L’exemple suivant d’objets NetworkPolicy démontre la prise en charge de différents scénarios:
Refuser tout trafic:
Afin de rendre un projet refusé par défaut, ajoutez un objet NetworkPolicy qui correspond à tous les pods mais n’accepte aucun trafic:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Autoriser uniquement les connexions à partir du service Red Hat OpenShift sur AWS Ingress Controller:
Afin de faire un projet, n’autorisez que les connexions à partir du service Red Hat OpenShift sur AWS Ingress Controller, ajoutez l’objet NetworkPolicy suivant.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Accepter uniquement les connexions des pods au sein d’un projet:
ImportantAfin d’autoriser les connexions entrantes à partir des pods hostNetwork dans le même espace de noms, vous devez appliquer la politique d’autorisation de l’hôte avec la politique d’autorisation-même-namespace.
Afin de faire accepter les connexions d’autres pods dans le même projet, mais rejeter toutes les autres connexions de pods dans d’autres projets, ajouter l’objet NetworkPolicy suivant:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Autoriser uniquement le trafic HTTP et HTTPS basé sur les étiquettes de pod:
Afin d’activer uniquement l’accès HTTP et HTTPS aux pods avec une étiquette spécifique (rôle=frontend dans l’exemple suivant), ajoutez un objet NetworkPolicy similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Accepter les connexions en utilisant à la fois namespace et pod sélecteurs:
Afin de faire correspondre le trafic réseau en combinant l’espace de noms et les sélecteurs de pod, vous pouvez utiliser un objet NetworkPolicy similaire à ce qui suit:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Les objets NetworkPolicy sont additifs, ce qui signifie que vous pouvez combiner plusieurs objets NetworkPolicy pour répondre à des exigences réseau complexes.
À titre d’exemple, pour les objets NetworkPolicy définis dans les échantillons précédents, vous pouvez définir à la fois des stratégies d’autorisation-même-namespace et d’autorisation-http-and-https au sein d’un même projet. Ainsi, permettant aux pods avec le label role=frontend, d’accepter toute connexion autorisée par chaque politique. Autrement dit, les connexions sur n’importe quel port à partir de pods dans le même espace de noms, et les connexions sur les ports 80 et 443 à partir de pods dans n’importe quel espace de noms.
6.3.1.1.1. En utilisant la politique de réseau d’autorisation-de-routeur Copier lienLien copié sur presse-papiers!
Utilisez la NetworkPolicy suivante pour autoriser le trafic externe quelle que soit la configuration du routeur:
- 1
- le label policy-group.network.openshift.io/ingress:" prend en charge OVN-Kubernetes.
6.3.1.1.2. À l’aide de la politique de réseau d’autorisation-de-hôte Copier lienLien copié sur presse-papiers!
Ajoutez l’objet Permis-from-hostnetwork NetworkPolicy suivant pour diriger le trafic à partir des pods réseau hôte.
6.3.1.2. Des optimisations pour la stratégie réseau avec le plugin réseau OVN-Kubernetes Copier lienLien copié sur presse-papiers!
Lors de la conception de votre politique de réseau, consultez les lignes directrices suivantes:
- Dans le cas des stratégies réseau avec la même spécification spec.podSelector, il est plus efficace d’utiliser une stratégie réseau avec plusieurs règles d’entrée ou de sortie, que plusieurs stratégies réseau avec des sous-ensembles de règles d’entrée ou de sortie.
Chaque règle d’entrée ou de sortie basée sur la spécification podSelector ou namespaceSelector génère le nombre de flux OVS proportionnels au nombre de pods sélectionnés par stratégie réseau + nombre de pods sélectionnés par la règle d’entrée ou de sortie. Il est donc préférable d’utiliser la spécification podSelector ou namespaceSelector qui peut sélectionner autant de pods que vous en avez besoin en une seule règle, au lieu de créer des règles individuelles pour chaque pod.
À titre d’exemple, la politique suivante contient deux règles:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow La politique suivante exprime ces deux mêmes règles qu’une:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow La même ligne directrice s’applique à la spécification spec.podSelector. Lorsque vous avez les mêmes règles d’entrée ou de sortie pour différentes politiques de réseau, il pourrait être plus efficace de créer une politique réseau avec une spécification spec.podSelector commune. À titre d’exemple, les deux politiques suivantes ont des règles différentes:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow La politique de réseau suivante exprime ces deux mêmes règles qu’une:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Cette optimisation peut être appliquée lorsque seulement plusieurs sélecteurs sont exprimés en un seul. Dans les cas où les sélecteurs sont basés sur différentes étiquettes, il peut être impossible d’appliquer cette optimisation. Dans ces cas, envisagez d’appliquer de nouvelles étiquettes pour l’optimisation des politiques réseau spécifiquement.
6.3.1.3. Les prochaines étapes Copier lienLien copié sur presse-papiers!
6.3.2. Créer une politique de réseau Copier lienLien copié sur presse-papiers!
En tant qu’utilisateur avec le rôle d’administrateur, vous pouvez créer une stratégie réseau pour un espace de noms.
6.3.2.1. Exemple d’objet NetworkPolicy Copier lienLien copié sur presse-papiers!
Ce qui suit annote un exemple d’objet NetworkPolicy:
- 1
- Le nom de l’objet NetworkPolicy.
- 2
- C) un sélecteur qui décrit les pods auxquels la politique s’applique. L’objet de stratégie ne peut sélectionner que des pods dans le projet qui définit l’objet NetworkPolicy.
- 3
- D’un sélecteur qui correspond aux pods à partir desquels l’objet de stratégie permet le trafic d’entrée. Le sélecteur correspond aux pods dans le même espace de noms que NetworkPolicy.
- 4
- Liste d’un ou de plusieurs ports de destination sur lesquels accepter le trafic.
6.3.2.2. Création d’une stratégie réseau à l’aide du CLI Copier lienLien copié sur presse-papiers!
Afin de définir des règles granulaires décrivant le trafic réseau d’entrée ou de sortie autorisé pour les espaces de noms de votre cluster, vous pouvez créer une stratégie réseau.
Lorsque vous vous connectez avec un utilisateur avec le rôle cluster-admin, vous pouvez créer une stratégie réseau dans n’importe quel espace de noms du cluster.
Conditions préalables
- Le cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tels que le plugin réseau OVN-Kubernetes, avec mode: NetworkPolicy set.
- Installation de l’OpenShift CLI (oc).
- Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.
- C’est vous qui travaillez dans l’espace de noms auquel s’applique la stratégie réseau.
Procédure
Créer une règle de politique:
Créer un fichier <policy_name>.yaml:
touch <policy_name>.yaml
$ touch <policy_name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow là où:
<policy_name>
- Indique le nom du fichier de stratégie réseau.
Définissez une stratégie réseau dans le fichier que vous venez de créer, comme dans les exemples suivants:
Dénier l’entrée de tous les pods dans tous les espaces de noms
Il s’agit d’une politique fondamentale, bloquant tout réseau interpod autre que le trafic interpod autorisé par la configuration d’autres stratégies réseau.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Autoriser l’entrée de tous les pods dans le même espace de noms
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Autoriser le trafic d’entrée vers un pod à partir d’un espace de noms particulier
Cette politique permet au trafic de pods étiquetés pod-a à partir de pods fonctionnant dans namespace-y.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Afin de créer l’objet de stratégie réseau, entrez la commande suivante:
oc apply -f <policy_name>.yaml -n <namespace>
$ oc apply -f <policy_name>.yaml -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow là où:
<policy_name>
- Indique le nom du fichier de stratégie réseau.
<namespace>
- Facultatif : Spécifie l’espace de noms si l’objet est défini dans un espace de noms différent de celui de l’espace de noms actuel.
Exemple de sortie
networkpolicy.networking.k8s.io/deny-by-default created
networkpolicy.networking.k8s.io/deny-by-default created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Lorsque vous vous connectez à la console Web avec des privilèges cluster-admin, vous avez le choix de créer une stratégie réseau dans n’importe quel espace de noms du cluster directement dans YAML ou à partir d’un formulaire dans la console Web.
6.3.2.3. Création d’une stratégie de réseau par défaut Copier lienLien copié sur presse-papiers!
Il s’agit d’une politique fondamentale, bloquant tout réseau interpod autre que le trafic réseau autorisé par la configuration d’autres stratégies réseau déployées. Cette procédure applique une politique de refus par défaut.
Lorsque vous vous connectez avec un utilisateur avec le rôle cluster-admin, vous pouvez créer une stratégie réseau dans n’importe quel espace de noms du cluster.
Conditions préalables
- Le cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tels que le plugin réseau OVN-Kubernetes, avec mode: NetworkPolicy set.
- Installation de l’OpenShift CLI (oc).
- Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.
- C’est vous qui travaillez dans l’espace de noms auquel s’applique la stratégie réseau.
Procédure
Créez le YAML suivant qui définit une politique de déni par défaut pour refuser l’entrée de tous les pods dans tous les espaces de noms. Enregistrez le YAML dans le fichier deny-by-default.yaml:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- namespace: par défaut déploie cette stratégie dans l’espace de noms par défaut.
- 2
- le podSelector: est vide, cela signifie qu’il correspond à tous les gousses. La politique s’applique donc à tous les pods dans l’espace de noms par défaut.
- 3
- Il n’y a pas de règles d’entrée spécifiées. Cela provoque la chute du trafic entrant vers toutes les gousses.
Appliquer la politique en entrant la commande suivante:
oc apply -f deny-by-default.yaml
$ oc apply -f deny-by-default.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
networkpolicy.networking.k8s.io/deny-by-default created
networkpolicy.networking.k8s.io/deny-by-default created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.2.4. Création d’une stratégie réseau pour permettre le trafic de clients externes Copier lienLien copié sur presse-papiers!
Avec la stratégie de refus par défaut en place, vous pouvez procéder à la configuration d’une stratégie qui permet le trafic des clients externes vers un pod avec l’app=web d’étiquette.
Lorsque vous vous connectez avec un utilisateur avec le rôle cluster-admin, vous pouvez créer une stratégie réseau dans n’importe quel espace de noms du cluster.
Cette procédure permet de configurer une politique qui permet au service externe de l’Internet public directement ou en utilisant un Balanceur de charge d’accéder au pod. Le trafic n’est autorisé qu’à un pod avec l’étiquette app=web.
Conditions préalables
- Le cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tels que le plugin réseau OVN-Kubernetes, avec mode: NetworkPolicy set.
- Installation de l’OpenShift CLI (oc).
- Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.
- C’est vous qui travaillez dans l’espace de noms auquel s’applique la stratégie réseau.
Procédure
Créez une politique qui permet le trafic depuis l’Internet public directement ou en utilisant un balanceur de charge pour accéder au pod. Enregistrez le YAML dans le fichier web-allow-external.yaml:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Appliquer la politique en entrant la commande suivante:
oc apply -f web-allow-external.yaml
$ oc apply -f web-allow-external.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
networkpolicy.networking.k8s.io/web-allow-external created
networkpolicy.networking.k8s.io/web-allow-external created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Cette politique permet le trafic à partir de toutes les ressources, y compris le trafic externe comme illustré dans le diagramme suivant:
6.3.2.5. Création d’une stratégie réseau permettant le trafic vers une application à partir de tous les espaces de noms Copier lienLien copié sur presse-papiers!
Lorsque vous vous connectez avec un utilisateur avec le rôle cluster-admin, vous pouvez créer une stratégie réseau dans n’importe quel espace de noms du cluster.
Cette procédure permet de configurer une stratégie qui permet le trafic de tous les pods dans tous les espaces de noms à une application particulière.
Conditions préalables
- Le cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tels que le plugin réseau OVN-Kubernetes, avec mode: NetworkPolicy set.
- Installation de l’OpenShift CLI (oc).
- Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.
- C’est vous qui travaillez dans l’espace de noms auquel s’applique la stratégie réseau.
Procédure
Créez une stratégie qui permet le trafic de tous les pods dans tous les espaces de noms vers une application particulière. Enregistrez le YAML dans le fichier web-allow-all-namespaces.yaml:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NotePar défaut, si vous omet de spécifier un namespaceSelector, il ne sélectionne pas d’espaces de noms, ce qui signifie que la stratégie autorise le trafic uniquement à partir de l’espace de noms vers lequel la stratégie réseau est déployée.
Appliquer la politique en entrant la commande suivante:
oc apply -f web-allow-all-namespaces.yaml
$ oc apply -f web-allow-all-namespaces.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
networkpolicy.networking.k8s.io/web-allow-all-namespaces created
networkpolicy.networking.k8s.io/web-allow-all-namespaces created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
La vérification
Démarrez un service Web dans l’espace de noms par défaut en entrant la commande suivante:
oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exécutez la commande suivante pour déployer une image alpine dans l’espace de noms secondaire et démarrer un shell:
oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exécutez la commande suivante dans le shell et observez que la requête est autorisée:
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow A) Produit attendu
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.2.6. Création d’une stratégie réseau permettant le trafic vers une application à partir d’un espace de noms Copier lienLien copié sur presse-papiers!
Lorsque vous vous connectez avec un utilisateur avec le rôle cluster-admin, vous pouvez créer une stratégie réseau dans n’importe quel espace de noms du cluster.
Cette procédure permet de configurer une stratégie qui permet le trafic vers un pod avec l’étiquette app=web à partir d’un espace de noms particulier. Il se peut que vous vouliez faire ceci pour:
- Limitez le trafic à une base de données de production uniquement aux espaces de noms où des charges de travail de production sont déployées.
- Activer les outils de surveillance déployés dans un espace de noms particulier pour gratter des métriques à partir de l’espace de noms actuel.
Conditions préalables
- Le cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tels que le plugin réseau OVN-Kubernetes, avec mode: NetworkPolicy set.
- Installation de l’OpenShift CLI (oc).
- Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.
- C’est vous qui travaillez dans l’espace de noms auquel s’applique la stratégie réseau.
Procédure
Créez une stratégie qui permet le trafic de tous les pods dans un espace de noms particulier avec un but d’étiquette=production. Enregistrez le YAML dans le fichier web-allow-prod.yaml:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Appliquer la politique en entrant la commande suivante:
oc apply -f web-allow-prod.yaml
$ oc apply -f web-allow-prod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
networkpolicy.networking.k8s.io/web-allow-prod created
networkpolicy.networking.k8s.io/web-allow-prod created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
La vérification
Démarrez un service Web dans l’espace de noms par défaut en entrant la commande suivante:
oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exécutez la commande suivante pour créer l’espace de noms prod:
oc create namespace prod
$ oc create namespace prod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exécutez la commande suivante pour étiqueter l’espace de noms prod:
oc label namespace/prod purpose=production
$ oc label namespace/prod purpose=production
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exécutez la commande suivante pour créer l’espace de noms dev:
oc create namespace dev
$ oc create namespace dev
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exécutez la commande suivante pour étiqueter l’espace de noms dev:
oc label namespace/dev purpose=testing
$ oc label namespace/dev purpose=testing
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exécutez la commande suivante pour déployer une image alpine dans l’espace de noms de dev et démarrer un shell:
oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exécutez la commande suivante dans le shell et observez que la requête est bloquée:
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow A) Produit attendu
wget: download timed out
wget: download timed out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exécutez la commande suivante pour déployer une image alpine dans l’espace de noms prod et démarrer un shell:
oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
$ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exécutez la commande suivante dans le shell et observez que la requête est autorisée:
wget -qO- --timeout=2 http://web.default
# wget -qO- --timeout=2 http://web.default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow A) Produit attendu
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.2.7. Création d’une stratégie réseau à l’aide d’OpenShift Cluster Manager Copier lienLien copié sur presse-papiers!
Afin de définir des règles granulaires décrivant le trafic réseau d’entrée ou de sortie autorisé pour les espaces de noms de votre cluster, vous pouvez créer une stratégie réseau.
Conditions préalables
- Connectez-vous à OpenShift Cluster Manager.
- Création d’un Red Hat OpenShift Service sur AWS cluster.
- Configuration d’un fournisseur d’identité pour votre cluster.
- Ajout de votre compte utilisateur au fournisseur d’identité configuré.
- Dans le cadre de votre Red Hat OpenShift Service, vous avez créé un projet sur le cluster AWS.
Procédure
- À partir d’OpenShift Cluster Manager, cliquez sur le cluster auquel vous souhaitez accéder.
- Cliquez sur Ouvrir la console pour accéder à la console Web OpenShift.
- Cliquez sur votre fournisseur d’identité et fournissez vos informations d’identification pour vous connecter au cluster.
- Du point de vue administrateur, sous Networking, cliquez sur NetworkPolicies.
- Cliquez sur Créer NetworkPolicy.
- Indiquez un nom pour la politique dans le champ Nom de la politique.
- Facultatif: Vous pouvez fournir l’étiquette et le sélecteur pour un pod spécifique si cette politique ne s’applique qu’à un ou plusieurs gousses spécifiques. Dans le cas où vous ne sélectionnez pas un pod spécifique, cette politique s’appliquera à tous les pods du cluster.
- Facultatif: Vous pouvez bloquer tous les trafics d’entrée et de sortie en utilisant le Deny tous les trafics entrants ou Deny toutes les cases à cocher du trafic sortant.
- En outre, vous pouvez ajouter n’importe quelle combinaison de règles d’entrée et de sortie, vous permettant de spécifier le port, l’espace de noms ou les blocs IP que vous souhaitez approuver.
Ajoutez des règles d’entrée à votre politique:
Cliquez sur Ajouter une règle d’entrée pour configurer une nouvelle règle. Cette action crée une nouvelle ligne de règles Ingress avec un menu déroulant Ajouter la source autorisée qui vous permet de spécifier la façon dont vous souhaitez limiter le trafic entrant. Le menu déroulant offre trois options pour limiter votre trafic d’entrée:
- Autoriser les pods du même espace de noms limite le trafic aux pods dans le même espace de noms. Dans un espace de noms, vous pouvez spécifier les pods, mais laisser cette option en blanc permet tout le trafic à partir des pods dans l’espace de noms.
- Autoriser les pods de l’intérieur du cluster limite le trafic à des pods dans le même cluster que la politique. Il est possible de spécifier les espaces de noms et les pods à partir desquels vous souhaitez autoriser le trafic entrant. Laisser cette option vide permet le trafic entrant à partir de tous les espaces de noms et les pods dans ce cluster.
- Autoriser les pairs par le blocage IP limite le trafic à partir d’un bloc IP de routage interdomain (CIDR) spécifié. Il est possible de bloquer certaines adresses IP avec l’option exception. Laisser le champ CIDR vide permet tout le trafic entrant de toutes les sources externes.
- Il est possible de limiter tout votre trafic entrant à un port. Dans le cas où vous n’y ajoutez pas de ports, tous les ports sont accessibles au trafic.
Ajoutez des règles de sortie à votre politique de réseau:
Cliquez sur Ajouter une règle de sortie pour configurer une nouvelle règle. Cette action crée une nouvelle ligne de règles Egress avec un menu déroulant Ajouter la destination autorisée* qui vous permet de spécifier la façon dont vous souhaitez limiter le trafic sortant. Le menu déroulant offre trois options pour limiter votre trafic de sortie:
- Autoriser les pods du même espace de noms limite le trafic sortant aux pods dans le même espace de noms. Dans un espace de noms, vous pouvez spécifier les pods, mais laisser cette option en blanc permet tout le trafic à partir des pods dans l’espace de noms.
- Autoriser les pods de l’intérieur du cluster limite le trafic à des pods dans le même cluster que la politique. Il est possible de spécifier les espaces de noms et les pods à partir desquels vous souhaitez autoriser le trafic sortant. Laisser cette option vide permet le trafic sortant de tous les espaces de noms et pods au sein de ce cluster.
- Autoriser les pairs par le blocage IP limite le trafic à partir d’un bloc IP CIDR spécifié. Il est possible de bloquer certaines adresses IP avec l’option exception. Laisser le champ CIDR vide permet tout le trafic sortant de toutes les sources externes.
- Il est possible de limiter tout votre trafic sortant à un port. Dans le cas où vous n’y ajoutez pas de ports, tous les ports sont accessibles au trafic.
6.3.3. Affichage d’une politique de réseau Copier lienLien copié sur presse-papiers!
En tant qu’utilisateur avec le rôle d’administrateur, vous pouvez afficher une stratégie réseau pour un espace de noms.
6.3.3.1. Exemple d’objet NetworkPolicy Copier lienLien copié sur presse-papiers!
Ce qui suit annote un exemple d’objet NetworkPolicy:
- 1
- Le nom de l’objet NetworkPolicy.
- 2
- C) un sélecteur qui décrit les pods auxquels la politique s’applique. L’objet de stratégie ne peut sélectionner que des pods dans le projet qui définit l’objet NetworkPolicy.
- 3
- D’un sélecteur qui correspond aux pods à partir desquels l’objet de stratégie permet le trafic d’entrée. Le sélecteur correspond aux pods dans le même espace de noms que NetworkPolicy.
- 4
- Liste d’un ou de plusieurs ports de destination sur lesquels accepter le trafic.
6.3.3.2. Consulter les stratégies de réseau à l’aide du CLI Copier lienLien copié sur presse-papiers!
Il est possible d’examiner les stratégies réseau dans un espace de noms.
Lorsque vous vous connectez avec un utilisateur avec le rôle cluster-admin, vous pouvez afficher n’importe quelle stratégie réseau dans le cluster.
Conditions préalables
- Installation de l’OpenShift CLI (oc).
- Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.
- Dans l’espace de noms où existe la stratégie réseau, vous travaillez.
Procédure
Liste des stratégies réseau dans un espace de noms:
Afin d’afficher les objets de stratégie réseau définis dans un espace de noms, entrez la commande suivante:
oc get networkpolicy
$ oc get networkpolicy
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Facultatif: Pour examiner une stratégie réseau spécifique, entrez la commande suivante:
oc describe networkpolicy <policy_name> -n <namespace>
$ oc describe networkpolicy <policy_name> -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow là où:
<policy_name>
- Indique le nom de la politique de réseau à inspecter.
<namespace>
- Facultatif : Spécifie l’espace de noms si l’objet est défini dans un espace de noms différent de celui de l’espace de noms actuel.
À titre d’exemple:
oc describe networkpolicy allow-same-namespace
$ oc describe networkpolicy allow-same-namespace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow La sortie pour oc décrit la commande
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Lorsque vous vous connectez à la console Web avec des privilèges d’administration de cluster, vous avez le choix de visualiser une stratégie réseau dans n’importe quel espace de noms du cluster directement dans YAML ou à partir d’un formulaire dans la console Web.
6.3.3.3. Affichage des stratégies de réseau à l’aide d’OpenShift Cluster Manager Copier lienLien copié sur presse-papiers!
Consultez les détails de configuration de votre stratégie réseau dans Red Hat OpenShift Cluster Manager.
Conditions préalables
- Connectez-vous à OpenShift Cluster Manager.
- Création d’un Red Hat OpenShift Service sur AWS cluster.
- Configuration d’un fournisseur d’identité pour votre cluster.
- Ajout de votre compte utilisateur au fournisseur d’identité configuré.
- C’est vous qui avez créé une stratégie de réseau.
Procédure
- Du point de vue administrateur dans la console Web OpenShift Cluster Manager, sous Networking, cliquez sur NetworkPolicies.
- Choisissez la politique de réseau souhaitée à afficher.
- Dans la page Détails de la stratégie réseau, vous pouvez consulter toutes les règles d’entrée et de sortie associées.
Choisissez YAML sur les détails de la stratégie réseau pour afficher la configuration de la stratégie au format YAML.
NoteIl est possible de consulter uniquement les détails de ces politiques. Il est impossible d’éditer ces politiques.
6.3.4. Édition d’une politique de réseau Copier lienLien copié sur presse-papiers!
En tant qu’utilisateur avec le rôle d’administrateur, vous pouvez modifier une stratégie réseau existante pour un espace de noms.
6.3.4.1. Édition d’une politique de réseau Copier lienLien copié sur presse-papiers!
Il est possible d’éditer une stratégie réseau dans un espace de noms.
Lorsque vous vous connectez avec un utilisateur avec le rôle cluster-admin, vous pouvez modifier une stratégie réseau dans n’importe quel espace de noms du cluster.
Conditions préalables
- Le cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tels que le plugin réseau OVN-Kubernetes, avec mode: NetworkPolicy set.
- Installation de l’OpenShift CLI (oc).
- Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.
- Dans l’espace de noms où existe la stratégie réseau, vous travaillez.
Procédure
Facultatif: Pour énumérer les objets de stratégie réseau dans un espace de noms, entrez la commande suivante:
oc get networkpolicy
$ oc get networkpolicy
Copy to Clipboard Copied! Toggle word wrap Toggle overflow là où:
<namespace>
- Facultatif : Spécifie l’espace de noms si l’objet est défini dans un espace de noms différent de celui de l’espace de noms actuel.
Editez l’objet de stratégie réseau.
Lorsque vous enregistrez la définition de stratégie réseau dans un fichier, modifiez le fichier et apportez les modifications nécessaires, puis entrez la commande suivante.
oc apply -n <namespace> -f <policy_file>.yaml
$ oc apply -n <namespace> -f <policy_file>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow là où:
<namespace>
- Facultatif : Spécifie l’espace de noms si l’objet est défini dans un espace de noms différent de celui de l’espace de noms actuel.
<policy_file>
- Indique le nom du fichier contenant la stratégie réseau.
Lorsque vous devez mettre à jour l’objet de stratégie réseau directement, entrez la commande suivante:
oc edit networkpolicy <policy_name> -n <namespace>
$ oc edit networkpolicy <policy_name> -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow là où:
<policy_name>
- Indique le nom de la stratégie réseau.
<namespace>
- Facultatif : Spécifie l’espace de noms si l’objet est défini dans un espace de noms différent de celui de l’espace de noms actuel.
Confirmez que l’objet de stratégie réseau est mis à jour.
oc describe networkpolicy <policy_name> -n <namespace>
$ oc describe networkpolicy <policy_name> -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow là où:
<policy_name>
- Indique le nom de la stratégie réseau.
<namespace>
- Facultatif : Spécifie l’espace de noms si l’objet est défini dans un espace de noms différent de celui de l’espace de noms actuel.
Lorsque vous vous connectez à la console Web avec des privilèges cluster-admin, vous avez le choix d’éditer une stratégie réseau dans n’importe quel espace de noms du cluster directement dans YAML ou à partir de la stratégie de la console Web via le menu Actions.
6.3.4.2. Exemple d’objet NetworkPolicy Copier lienLien copié sur presse-papiers!
Ce qui suit annote un exemple d’objet NetworkPolicy:
- 1
- Le nom de l’objet NetworkPolicy.
- 2
- C) un sélecteur qui décrit les pods auxquels la politique s’applique. L’objet de stratégie ne peut sélectionner que des pods dans le projet qui définit l’objet NetworkPolicy.
- 3
- D’un sélecteur qui correspond aux pods à partir desquels l’objet de stratégie permet le trafic d’entrée. Le sélecteur correspond aux pods dans le même espace de noms que NetworkPolicy.
- 4
- Liste d’un ou de plusieurs ports de destination sur lesquels accepter le trafic.
6.3.5. La suppression d’une politique de réseau Copier lienLien copié sur presse-papiers!
En tant qu’utilisateur avec le rôle d’administrateur, vous pouvez supprimer une stratégie réseau d’un espace de noms.
6.3.5.1. La suppression d’une politique de réseau à l’aide du CLI Copier lienLien copié sur presse-papiers!
Il est possible de supprimer une stratégie réseau dans un espace de noms.
Lorsque vous vous connectez avec un utilisateur avec le rôle cluster-admin, vous pouvez supprimer n’importe quelle stratégie réseau dans le cluster.
Conditions préalables
- Le cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tels que le plugin réseau OVN-Kubernetes, avec mode: NetworkPolicy set.
- Installation de l’OpenShift CLI (oc).
- Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.
- Dans l’espace de noms où existe la stratégie réseau, vous travaillez.
Procédure
Afin de supprimer un objet de stratégie réseau, entrez la commande suivante:
oc delete networkpolicy <policy_name> -n <namespace>
$ oc delete networkpolicy <policy_name> -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow là où:
<policy_name>
- Indique le nom de la stratégie réseau.
<namespace>
- Facultatif : Spécifie l’espace de noms si l’objet est défini dans un espace de noms différent de celui de l’espace de noms actuel.
Exemple de sortie
networkpolicy.networking.k8s.io/default-deny deleted
networkpolicy.networking.k8s.io/default-deny deleted
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Lorsque vous vous connectez à la console Web avec des privilèges cluster-admin, vous avez le choix de supprimer une stratégie réseau dans n’importe quel espace de noms du cluster directement dans YAML ou à partir de la stratégie de la console Web via le menu Actions.
6.3.5.2. La suppression d’une stratégie réseau à l’aide d’OpenShift Cluster Manager Copier lienLien copié sur presse-papiers!
Il est possible de supprimer une stratégie réseau dans un espace de noms.
Conditions préalables
- Connectez-vous à OpenShift Cluster Manager.
- Création d’un Red Hat OpenShift Service sur AWS cluster.
- Configuration d’un fournisseur d’identité pour votre cluster.
- Ajout de votre compte utilisateur au fournisseur d’identité configuré.
Procédure
- Du point de vue administrateur dans la console Web OpenShift Cluster Manager, sous Networking, cliquez sur NetworkPolicies.
Employez l’une des méthodes suivantes pour supprimer votre politique de réseau:
Effacer la politique du tableau des politiques de réseau:
- Dans la table Politiques réseau, sélectionnez le menu de pile de la ligne de la stratégie réseau que vous souhaitez supprimer, puis cliquez sur Supprimer NetworkPolicy.
Supprimez la stratégie à l’aide du menu déroulant Actions des détails de la stratégie réseau:
- Cliquez sur Actions menu déroulant pour votre stratégie de réseau.
- Choisissez Supprimer NetworkPolicy dans le menu.
6.3.6. Définition d’une stratégie réseau par défaut pour les projets Copier lienLien copié sur presse-papiers!
En tant qu’administrateur de cluster, vous pouvez modifier le nouveau modèle de projet pour inclure automatiquement les stratégies réseau lorsque vous créez un nouveau projet. Lorsque vous n’avez pas encore de modèle personnalisé pour de nouveaux projets, vous devez d’abord en créer un.
6.3.6.1. La modification du modèle pour les nouveaux projets Copier lienLien copié sur presse-papiers!
En tant qu’administrateur de cluster, vous pouvez modifier le modèle de projet par défaut afin que de nouveaux projets soient créés en utilisant vos exigences personnalisées.
Créer votre propre modèle de projet personnalisé:
Conditions préalables
- Grâce à un compte doté d’autorisations d’administration dédiées, vous avez accès à un service Red Hat OpenShift sur AWS.
Procédure
- Connectez-vous en tant qu’utilisateur avec des privilèges cluster-admin.
Générer le modèle de projet par défaut:
oc adm create-bootstrap-project-template -o yaml > template.yaml
$ oc adm create-bootstrap-project-template -o yaml > template.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Créez un éditeur de texte pour modifier le fichier template.yaml généré en ajoutant des objets ou en modifiant des objets existants.
Le modèle de projet doit être créé dans l’espace de noms openshift-config. Chargez votre modèle modifié:
oc create -f template.yaml -n openshift-config
$ oc create -f template.yaml -n openshift-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Éditez la ressource de configuration du projet à l’aide de la console Web ou du CLI.
En utilisant la console web:
-
Accédez à la page Administration
Paramètres du cluster. - Cliquez sur Configuration pour afficher toutes les ressources de configuration.
- Cherchez l’entrée pour Projet et cliquez sur Modifier YAML.
-
Accédez à la page Administration
En utilisant le CLI:
Editez la ressource project.config.openshift.io/cluster:
oc edit project.config.openshift.io/cluster
$ oc edit project.config.openshift.io/cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Actualisez la section Spécifications pour inclure les paramètres projectRequestTemplate et nom, et définissez le nom de votre modèle de projet téléchargé. Le nom par défaut est project-request.
Configuration du projet ressource avec modèle de projet personnalisé
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Après avoir enregistré vos modifications, créez un nouveau projet pour vérifier que vos modifications ont été appliquées avec succès.
6.3.6.2. Ajout de stratégies réseau au nouveau modèle de projet Copier lienLien copié sur presse-papiers!
En tant qu’administrateur de cluster, vous pouvez ajouter des stratégies réseau au modèle par défaut pour les nouveaux projets. Le service Red Hat OpenShift sur AWS créera automatiquement tous les objets NetworkPolicy spécifiés dans le modèle du projet.
Conditions préalables
- Le cluster utilise un plugin réseau CNI par défaut qui prend en charge les objets NetworkPolicy, tels que les OVN-Kubernetes.
- Installation de l’OpenShift CLI (oc).
- Connectez-vous au cluster avec un utilisateur avec des privilèges cluster-admin.
- Il faut avoir créé un modèle de projet personnalisé par défaut pour de nouveaux projets.
Procédure
Éditez le modèle par défaut pour un nouveau projet en exécutant la commande suivante:
oc edit template <project_template> -n openshift-config
$ oc edit template <project_template> -n openshift-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <project_template> par le nom du modèle par défaut que vous avez configuré pour votre cluster. Le nom de modèle par défaut est project-request.
Dans le modèle, ajoutez chaque objet NetworkPolicy en tant qu’élément au paramètre objets. Le paramètre objets accepte une collection d’un ou plusieurs objets.
Dans l’exemple suivant, la collection de paramètres d’objets comprend plusieurs objets NetworkPolicy.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Facultatif: Créez un nouveau projet pour confirmer que vos objets de stratégie réseau sont créés avec succès en exécutant les commandes suivantes:
Créer un nouveau projet:
oc new-project <project>
$ oc new-project <project>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <project> par le nom du projet que vous créez.
Confirmez que les objets de stratégie réseau dans le nouveau modèle de projet existent dans le nouveau projet:
oc get networkpolicy
$ oc get networkpolicy NAME POD-SELECTOR AGE allow-from-openshift-ingress <none> 7s allow-from-same-namespace <none> 7s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.7. Configuration de l’isolement multilocataire avec la stratégie réseau Copier lienLien copié sur presse-papiers!
En tant qu’administrateur de clusters, vous pouvez configurer vos stratégies réseau pour fournir une isolation réseau multilocataire.
La configuration des stratégies réseau telles que décrites dans cette section fournit une isolation réseau similaire au mode multilocataires d’OpenShift SDN dans les versions précédentes de Red Hat OpenShift Service sur AWS.
6.3.7.1. Configuration de l’isolement multilocataire en utilisant la stratégie réseau Copier lienLien copié sur presse-papiers!
Configurez votre projet pour l’isoler des pods et services dans d’autres espaces de noms de projet.
Conditions préalables
- Le cluster utilise un plugin réseau qui prend en charge les objets NetworkPolicy, tels que le plugin réseau OVN-Kubernetes, avec mode: NetworkPolicy set.
- Installation de l’OpenShift CLI (oc).
- Il est connecté au cluster avec un utilisateur avec des privilèges d’administrateur.
Procédure
Créez les objets de NetworkPolicy suivants:
D’une politique nommée Autor-from-openshift-ingress.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Notele label policy-group.network.openshift.io/ingress: "" est l’étiquette de sélecteur d’espace de noms préférée pour OVN-Kubernetes.
D’une politique nommée Autorisation- from-openshift-monitoring:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow D’une politique nommée allow-same-namespace:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow D’une politique nommée Author-from-kube-apiserver-operator:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Consultez le nouveau contrôleur kube-apiserver-operator webhook pour valider la santé du webhook.
Facultatif : Pour confirmer que les stratégies réseau existent dans votre projet actuel, entrez la commande suivante:
oc describe networkpolicy
$ oc describe networkpolicy
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow