Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

24.10. Configuration d'un pare-feu de sortie pour un projet

En tant qu'administrateur de cluster, vous pouvez créer un pare-feu de sortie pour un projet qui restreint le trafic de sortie de votre cluster OpenShift Container Platform.

24.10.1. Fonctionnement d'un pare-feu de sortie dans un projet
Copier lien

En tant qu'administrateur de cluster, vous pouvez utiliser un egress firewall pour limiter les hôtes externes auxquels certains ou tous les pods peuvent accéder depuis le cluster. Un pare-feu de sortie prend en charge les scénarios suivants :

  • Un pod ne peut se connecter qu'à des hôtes internes et ne peut pas établir de connexions avec l'internet public.
  • Un pod ne peut se connecter qu'à l'internet public et ne peut pas initier de connexions vers des hôtes internes qui sont en dehors du cluster OpenShift Container Platform.
  • Un pod ne peut pas atteindre les sous-réseaux internes spécifiés ou les hôtes en dehors du cluster OpenShift Container Platform.
  • Un pod ne peut se connecter qu'à des hôtes externes spécifiques.

Par exemple, vous pouvez autoriser un projet à accéder à une plage d'adresses IP donnée, mais refuser le même accès à un autre projet. Vous pouvez également empêcher les développeurs d'applications d'effectuer des mises à jour à partir des miroirs de Python Pip et exiger que les mises à jour proviennent uniquement de sources approuvées.

Note

Le pare-feu de sortie ne s'applique pas à l'espace de noms du réseau hôte. Les pods dont le réseau d'hôtes est activé ne sont pas affectés par les règles de pare-feu de sortie.

Vous configurez une stratégie de pare-feu de sortie en créant un objet de ressource personnalisée (CR) EgressFirewall. Le pare-feu de sortie correspond au trafic réseau qui répond à l'un des critères suivants :

  • Une plage d'adresses IP au format CIDR
  • Un nom DNS qui se résout en une adresse IP
  • Un numéro de port
  • Un protocole qui est l'un des protocoles suivants : TCP, UDP et SCTP
Important

Si votre pare-feu de sortie comprend une règle de refus pour 0.0.0.0/0, l'accès à vos serveurs API OpenShift Container Platform est bloqué. Vous devez soit ajouter des règles d'autorisation pour chaque adresse IP, soit utiliser la règle d'autorisation de type nodeSelector dans vos règles de stratégie de sortie pour vous connecter aux serveurs API.

L'exemple suivant illustre l'ordre des règles de pare-feu de sortie nécessaires pour garantir l'accès au serveur API : 

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
  namespace: <namespace>
1 

spec:
  egress:
  - to:
      cidrSelector: <api_server_address_range>
2 

    type: Allow
# ...
  - to:
      cidrSelector: 0.0.0.0/0
3 

    type: Deny
Copy to Clipboard Toggle word wrap
1
L'espace de noms pour le pare-feu de sortie.
2
La plage d'adresses IP qui comprend vos serveurs API OpenShift Container Platform.
3
Une règle de refus globale empêche l'accès aux serveurs API de OpenShift Container Platform.

Pour trouver l'adresse IP de vos serveurs API, exécutez oc get ep kubernetes -n default.

Pour plus d'informations, voir BZ#1988324.

Avertissement

Les règles de pare-feu de sortie ne s'appliquent pas au trafic qui passe par les routeurs. Tout utilisateur autorisé à créer un objet Route CR peut contourner les règles du pare-feu de sortie en créant une route qui pointe vers une destination interdite.

24.10.1.1. Limites d'un pare-feu de sortie
Copier lien

Un pare-feu de sortie présente les limitations suivantes :

  • Aucun projet ne peut avoir plus d'un objet EgressFirewall.
  • Un maximum d'un objet EgressFirewall avec un maximum de 8 000 règles peut être défini par projet.
  • Si vous utilisez le plugin réseau OVN-Kubernetes avec le mode passerelle partagée dans Red Hat OpenShift Networking, les réponses de retour d'entrée sont affectées par les règles de pare-feu de sortie. Si les règles de pare-feu de sortie éliminent l'IP de destination de la réponse d'entrée, le trafic est éliminé.

La violation de l'une ou l'autre de ces restrictions a pour effet de briser le pare-feu de sortie du projet et peut entraîner l'interruption de tout le trafic du réseau externe.

Une ressource Egress Firewall peut être créée dans les projets kube-node-lease, kube-public, kube-system, openshift et openshift-.

Les règles de pare-feu de sortie sont évaluées dans l'ordre où elles sont définies, de la première à la dernière. La première règle qui correspond à une connexion de sortie d'un pod s'applique. Les règles suivantes sont ignorées pour cette connexion.

Si vous utilisez des noms DNS dans l'une de vos règles de stratégie de pare-feu de sortie, la résolution correcte des noms de domaine est soumise aux restrictions suivantes :

  • Les mises à jour de noms de domaine sont interrogées sur la base d'une durée de vie (TTL). Par défaut, cette durée est de 30 minutes. Lorsque le contrôleur du pare-feu de sortie interroge les serveurs de noms locaux pour un nom de domaine, si la réponse inclut un TTL et que celui-ci est inférieur à 30 minutes, le contrôleur définit la durée pour ce nom DNS à la valeur renvoyée. Chaque nom DNS est interrogé après l'expiration du TTL de l'enregistrement DNS.
  • Le pod doit résoudre le domaine à partir des mêmes serveurs de noms locaux si nécessaire. Sinon, les adresses IP du domaine connues par le contrôleur du pare-feu de sortie et le module peuvent être différentes. Si les adresses IP d'un nom d'hôte diffèrent, le pare-feu de sortie risque de ne pas être appliqué de manière cohérente.
  • Étant donné que le contrôleur de pare-feu de sortie et les modules interrogent de manière asynchrone le même serveur de noms local, le module peut obtenir l'adresse IP mise à jour avant le contrôleur de sortie, ce qui provoque une situation de course. En raison de cette limitation actuelle, l'utilisation de noms de domaine dans les objets EgressFirewall n'est recommandée que pour les domaines dont les changements d'adresse IP sont peu fréquents.
Note

Le pare-feu de sortie permet toujours aux pods d'accéder à l'interface externe du nœud sur lequel le pod se trouve pour la résolution DNS.

Si vous utilisez des noms de domaine dans votre stratégie de pare-feu de sortie et que votre résolution DNS n'est pas gérée par un serveur DNS sur le nœud local, vous devez ajouter des règles de pare-feu de sortie qui autorisent l'accès aux adresses IP de votre serveur DNS. si vous utilisez des noms de domaine dans vos modules.

24.10.2. Objet de ressource personnalisée (CR) EgressFirewall
Copier lien

Vous pouvez définir une ou plusieurs règles pour un pare-feu de sortie. Une règle est soit une règle Allow, soit une règle Deny, avec une spécification du trafic auquel la règle s'applique.

Le fichier YAML suivant décrit un objet CR EgressFirewall :

Objet EgressFirewall

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: <name>
1 

spec:
  egress:
2 

    ...
Copy to Clipboard Toggle word wrap

1
Le nom de l'objet doit être default.
2
Ensemble d'une ou de plusieurs règles de politique de réseau de sortie, comme décrit dans la section suivante.

24.10.2.1. Règles EgressFirewall
Copier lien

Le fichier YAML suivant décrit un objet de règle de pare-feu de sortie. L'utilisateur peut sélectionner une plage d'adresses IP au format CIDR, un nom de domaine ou utiliser nodeSelector pour autoriser ou refuser le trafic de sortie. La strophe egress attend un tableau d'un ou plusieurs objets.

Règles de politique de sortie (Egress policy rule stanza)

egress:
- type: <type>
1 

  to:
2 

    cidrSelector: <cidr>
3 

    dnsName: <dns_name>
4 

    nodeSelector: <label_name>: <label_value>
5 

  ports:
6 

      ...
Copy to Clipboard Toggle word wrap

1
Le type de règle. La valeur doit être Allow ou Deny.
2
Une strophe décrivant une règle de correspondance du trafic de sortie qui spécifie le champ cidrSelector ou le champ dnsName. Vous ne pouvez pas utiliser les deux champs dans la même règle.
3
Une plage d'adresses IP au format CIDR.
4
Un nom de domaine DNS.
5
Les étiquettes sont des paires clé/valeur définies par l'utilisateur. Les étiquettes sont attachées à des objets, tels que les nacelles. Le site nodeSelector permet de sélectionner un ou plusieurs labels de nœuds et de les attacher aux nacelles.
6
Facultatif : Une strophe décrivant une collection de ports réseau et de protocoles pour la règle.

Strophe portuaire

ports:
- port: <port>
1 

  protocol: <protocol>
2
Copy to Clipboard Toggle word wrap

1
Un port réseau, tel que 80 ou 443. Si vous spécifiez une valeur pour ce champ, vous devez également spécifier une valeur pour protocol.
2
Un protocole de réseau. La valeur doit être soit TCP, UDP, soit SCTP.

24.10.2.2. Exemple d'objets CR EgressFirewall
Copier lien

L'exemple suivant définit plusieurs règles de stratégie de pare-feu de sortie : 

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress:
1 

  - type: Allow
    to:
      cidrSelector: 1.2.3.0/24
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0
Copy to Clipboard Toggle word wrap
1
Une collection d'objets de règles de stratégie de pare-feu de sortie.

L'exemple suivant définit une règle de stratégie qui refuse le trafic vers l'hôte à l'adresse IP 172.16.1.1, si le trafic utilise le protocole TCP et le port de destination 80 ou n'importe quel protocole et le port de destination 443. 

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress:
  - type: Deny
    to:
      cidrSelector: 172.16.1.1
    ports:
    - port: 80
      protocol: TCP
    - port: 443
Copy to Clipboard Toggle word wrap

24.10.2.3. Exemple de nodeSelector pour EgressFirewall
Copier lien

En tant qu'administrateur de cluster, vous pouvez autoriser ou refuser le trafic de sortie vers les nœuds de votre cluster en spécifiant une étiquette à l'aide de nodeSelector. Les étiquettes peuvent être appliquées à un ou plusieurs nœuds. Voici un exemple avec l'étiquette region=east: 

apiVersion: v1
kind: Pod
metadata:
  name: default
spec:
    egress:
    - to:
        nodeSelector:
          matchLabels:
            region: east
      type: Allow
Copy to Clipboard Toggle word wrap
Astuce

Au lieu d'ajouter des règles manuelles par adresse IP de nœud, utilisez les sélecteurs de nœuds pour créer une étiquette qui permet aux pods situés derrière un pare-feu de sortie d'accéder aux pods du réseau hôte.

En tant qu'administrateur de cluster, vous pouvez créer un objet de stratégie de pare-feu de sortie pour un projet.

Important

Si le projet a déjà un objet EgressFirewall défini, vous devez modifier la stratégie existante pour apporter des changements aux règles du pare-feu de sortie.

Conditions préalables

  • Un cluster qui utilise le plugin réseau OVN-Kubernetes.
  • Installez le CLI OpenShift (oc).
  • Vous devez vous connecter au cluster en tant qu'administrateur du cluster.

Procédure

  1. Créer une règle de politique :

    1. Créez un fichier <policy_name>.yaml dans lequel <policy_name> décrit les règles de la politique de sortie.
    2. Dans le fichier que vous avez créé, définissez un objet de politique de sortie.

  2. Entrez la commande suivante pour créer l'objet de politique. Remplacez <policy_name> par le nom de la politique et <project> par le projet auquel la règle s'applique. 

    oc create -f <policy_name>.yaml -n <project>
    Copy to Clipboard Toggle word wrap

    Dans l'exemple suivant, un nouvel objet EgressFirewall est créé dans un projet nommé project1: 

    $ oc create -f default.yaml -n project1
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    egressfirewall.k8s.ovn.org/v1 created
    Copy to Clipboard Toggle word wrap

  3. Facultatif : Enregistrez le fichier <policy_name>.yaml pour pouvoir le modifier ultérieurement.
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat