Rechercher
SupportConsoleDéveloppeursCommencer un essaiContact

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

download PDF

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.

25.3.1. Fonctionnement d'un pare-feu de sortie dans un projet

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) EgressNetworkPolicy. 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
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: network.openshift.io/v1
kind: EgressNetworkPolicy
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
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.

Important

Vous devez avoir OpenShift SDN configuré pour utiliser soit la politique de réseau, soit le mode multitenant pour configurer un pare-feu de sortie.

Si vous utilisez le mode stratégie réseau, un pare-feu de sortie n'est compatible qu'avec une seule stratégie par espace de noms et ne fonctionnera pas avec les projets qui partagent un réseau, tels que les projets globaux.

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.

25.3.1.1. Limites d'un pare-feu de sortie

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

  • Aucun projet ne peut avoir plus d'un objet EgressNetworkPolicy.
  • Un maximum d'un objet EgressNetworkPolicy avec un maximum de 1 000 règles peut être défini par projet.
  • Le projet default ne peut pas utiliser de pare-feu de sortie.

  • Lors de l'utilisation du plugin réseau OpenShift SDN en mode multitenant, les limitations suivantes s'appliquent :

    • Les projets globaux ne peuvent pas utiliser de pare-feu de sortie. Vous pouvez rendre un projet global en utilisant la commande oc adm pod-network make-projects-global.
    • Les projets fusionnés à l'aide de la commande oc adm pod-network join-projects ne peuvent utiliser un pare-feu de sortie dans aucun des projets fusionnés.

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

25.3.1.2. Ordre de correspondance pour les règles de politique de pare-feu de sortie

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.

25.3.1.3. Fonctionnement de la résolution des serveurs de noms de domaine (DNS)

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 secondes. Lorsque le contrôleur du pare-feu de sortie interroge les serveurs de noms locaux pour un nom de domaine, si la réponse comprend un TTL inférieur à 30 secondes, le contrôleur définit la durée sur la valeur renvoyée. Si le TTL de la réponse est supérieur à 30 minutes, le contrôleur fixe la durée à 30 minutes. Si le TTL est compris entre 30 secondes et 30 minutes, le contrôleur ignore la valeur et fixe la durée à 30 secondes.
  • 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 EgressNetworkPolicy 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.

25.3.2. Objet de ressource personnalisée (CR) EgressNetworkPolicy

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 EgressNetworkPolicy :

Objet EgressNetworkPolicy

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: <name> 1
spec:
  egress: 2
    ...

1
Un nom pour votre politique de pare-feu de sortie.
2
Ensemble d'une ou de plusieurs règles de politique de réseau de sortie, comme décrit dans la section suivante.

25.3.2.1. Règles de politique de réseau de sortie (EgressNetworkPolicy)

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

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. Une valeur pour le champ cidrSelector ou le champ dnsName de la règle. 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.

25.3.2.2. Exemple d'objets CR EgressNetworkPolicy

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

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: default
spec:
  egress: 1
  - type: Allow
    to:
      cidrSelector: 1.2.3.0/24
  - type: Allow
    to:
      dnsName: www.example.com
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0
1
Une collection d'objets de règles de stratégie de pare-feu de sortie.

25.3.3. Création d'un objet de stratégie de pare-feu de sortie

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 EgressNetworkPolicy 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 OpenShift SDN.
  • 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>

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

    $ oc create -f default.yaml -n project1

    Exemple de sortie

    egressnetworkpolicy.network.openshift.io/v1 created

  3. Facultatif : Enregistrez le fichier <policy_name>.yaml pour pouvoir le modifier ultérieurement.
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.

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

© 2024 Red Hat, Inc.