Règles de pare-feu des conteneurs

Le pare-feu de conteneur contrôle les connexions que chaque conteneur accepte ou rejette. Il évalue quatre propriétés sur chaque paquet entrant ou sortant : la source de la requête, le protocole, le port cible et l’origine (toute IP, une IP ou un bloc CIDR précis, ou une couche d’environnement). Les règles sont traitées dans l’ordre de priorité et la première correspondance l’emporte.

Ce que couvre cette page

• La relation entre le pare-feu et l’isolation réseau, et quand utiliser l’un ou l’autre.
• Accéder à la section pare-feu dans le tableau de bord.
• La structure des règles par défaut et le modèle de priorité.
• Ajouter des ports au moment du provisionnement avec OPEN_INBOUND_PORTS.
• Gérer les règles via la barre d’outils du tableau de bord.
• Bloquer une IP — exemple détaillé via le tableau de bord.
• Modifier les règles directement par SSH avec nftables (ou iptables sur les conteneurs hérités).
• La référence complète des méthodes API sous environment > Security.

Pare-feu et isolation réseau — quand utiliser quoi

L’isolation réseau restreint le trafic entre environnements d’un même compte au niveau de l’environnement. C’est le bon outil quand vous voulez qu’un environnement soit inaccessible depuis un autre.

Le pare-feu de conteneur offre un contrôle par conteneur : quelles IPs peuvent se connecter, sur quel protocole, vers quel port. Utilisez-le quand vous avez besoin de règles plus précises que l’isolation environnement-à-environnement — par exemple, permettre uniquement à votre agent CI d’atteindre le port 22, ou bloquer une IP spécifique sur un conteneur qui possède une IP publique.

Consultez Isolation réseau pour le contrôle au niveau de l’environnement.

Accéder au pare-feu dans le tableau de bord

Ouvrez Paramètres > Pare-feu sur n’importe quel environnement pour gérer ses règles.

Chaque conteneur — sauf les conteneurs personnalisés basés sur Docker et Windows — est provisionné avec un ensemble initial de règles de pare-feu modifiables via le tableau de bord.

Note sur la disponibilité : la section pare-feu peut ne pas être visible dans tous les comptes. Si vous ne la voyez pas sous Paramètres, contactez le support Stack Harbor pour demander l’activation du pare-feu sur votre compte.

La section Pare-feu expose trois onglets : Aperçu, Règles entrantes et Règles sortantes.

• Règles entrantes — refus par défaut. Seul le trafic explicitement autorisé par une règle atteint le conteneur.
• Règles sortantes — autorisation par défaut. Le trafic quitte le conteneur sauf si une règle de refus explicite correspond.

Structure des règles par défaut

Quand un conteneur est créé, la plateforme remplit les deux listes de règles avec les règles dont le conteneur a besoin pour fonctionner. Si des règles par défaut sont absentes, la plateforme les réajoute au prochain redémarrage du pare-feu.

Les affectations de ports par défaut proviennent des directives EXPOSE dans le Dockerfile de l’image du conteneur.

Les règles sont regroupées par couche et suivent toujours la même structure à trois bandes :

Les règles par défaut sont ajoutées par pas de 10 points de priorité, laissant de la place pour insérer des règles personnalisées entre elles.

Quand vous ajoutez un point de montage, installez un module FTP ou effectuez d’autres opérations nécessitant une connectivité supplémentaire, la plateforme étend automatiquement les règles par défaut.

Ne modifiez pas les règles grises d’infrastructure plateforme sauf si vous comprenez la conséquence précise — elles sont requises pour l’orchestration, l’accès SSH et le répartiteur de charge infogéré.

Ajouter des ports au provisionnement : OPEN_INBOUND_PORTS

Pour les scénarios d’automatisation, définissez la variable d’environnement OPEN_INBOUND_PORTS dans l’assistant de topologie avant de créer le conteneur. Elle ouvre des ports entrants supplémentaires à travers le pare-feu au moment du provisionnement.

1. Dans l’assistant de topologie, sélectionnez votre pile logicielle et ouvrez le cadre de configuration Variables.
2. Ajoutez OPEN_INBOUND_PORTS avec une liste de ports ou de plages de ports séparée par des virgules :

"OPEN_INBOUND_PORTS": "1234, 33062-34000"

Chaque port ou plage est ouvert à la fois sur TCP et UDP à la création du conteneur.

Important : OPEN_INBOUND_PORTS s’applique une seule fois lors de l’installation. Après le provisionnement, gérez les règles de pare-feu via le tableau de bord, SSH ou l’API — la variable n’a aucun effet sur un conteneur en cours d’exécution.

Gérer les règles dans le tableau de bord

Au-dessus de la liste de règles, la barre d’outils propose : Ajouter, Modifier, Retirer, Désactiver / Activer et Rafraîchir.

Lors de l’ajout ou de la modification d’une règle, configurez ces champs :

Types de source :

• Adresse(s) IP personnalisée(s) — adresses IPv4/IPv6 et blocs CIDR séparés par des virgules, par exemple 10.0.0.1, 10.0.0.0/24.
• Plages prédéfinies — Toutes, Toutes IPv4, Toutes IPv6, Réseau local, Internet (accès public).
• Nœuds d’environnement — une couche dans n’importe quel environnement du compte. La règle est mise à jour automatiquement à mesure que la couche est étendue ou réduite.

Notes sur la barre d’outils :

• Désactiver / Activer — désactive temporairement une règle sans la supprimer. Utile pour les tests : désactivez, observez, réactivez.
• Rafraîchir — relit la liste de règles après un changement de topologie sans rien redémarrer.
• Modifier — tous les champs sont ajustables sauf Nœuds. Pour appliquer une règle identique à une couche différente, créez une nouvelle règle pour cette couche.

Bloquer une IP précise — pas à pas dans le tableau de bord

Ce scénario s’applique quand un conteneur possède une IP publique et que vous devez rejeter le trafic d’une source problématique. Sans IP publique, l’infrastructure plateforme médiatise déjà le trafic externe au niveau du répartiteur de charge.

1. Ouvrez Paramètres > Pare-feu pour l’environnement.
2. Basculez vers Règles entrantes et cliquez sur Ajouter. (Pour restreindre la sortie, utilisez Règles sortantes — les champs sont identiques.)
3. Remplissez la règle :
   • Nœuds — le conteneur à restreindre, par exemple tomcat.
   • Nom — une étiquette descriptive, par exemple block-bad-ip.
   • Protocole — TCP.
   • Plage de ports — laissez vide pour couvrir tous les ports.
   • Source — Adresse(s) IP personnalisée(s), puis saisissez l’IP, par exemple 111.111.111.111.
   • Priorité — 900 (évaluée avant les règles d’autorisation par défaut à la priorité ≥ 1000, donc cette règle l’emporte).
   • Action — Refuser.
4. Cliquez sur Ajouter pour enregistrer et appliquer.

La règle prend effet immédiatement. Un client se connectant depuis l’adresse bloquée reçoit une réponse de connexion refusée.

Modifier les règles par SSH

Pour les types de règles que le tableau de bord n’expose pas — redirections NAT, chaînes complexes, conditions de correspondance avec état — connectez-vous au conteneur via Web SSH et modifiez les fichiers de pare-feu directement. Les règles ajoutées de cette façon prennent effet indépendamment de la liste de règles de l’interface et n’y apparaissent pas.

user@container-prod-01:~$ sudo jem firewall list

# nftables · chain: inbound (filter)

  1  chain inbound {
  2    # priority 1 — platform infrastructure (locked)
  3    ip saddr 10.0.0.0/8    tcp dport 0-65535 accept
  4    # priority 100
  5    tcp dport 443                           accept
  6    # priority 110
  7    ip saddr 203.0.113.10/32 tcp dport 22   accept
  8    # priority 120
  9    tcp dport 3306                          drop
 10    # priority 65535 — default catch-all (locked)
 11    counter                                   drop
 12  }

user@container-prod-01:~$  

Étapes

1. Ouvrez Web SSH sur le conteneur cible depuis le tableau de bord.

2. Vérifiez que le pare-feu du conteneur est activé :

   cat /etc/jelastic/metainf.conf

   Cherchez FIREWALL_ENABLED=1. Si l’indicateur est absent ou défini à 0, le pare-feu est inactif — contactez le support Stack Harbor pour demander l’activation du pare-feu.

3. Modifiez le fichier des règles définies par l’utilisateur :

   vim /etc/nftables/user-defined.nft

   Ajoutez votre règle en syntaxe nftables. Pour refuser le trafic TCP depuis 111.111.111.111 vers le port 1111 :

   insert rule ip filter INPUT ip saddr 111.111.111.111 ct state new tcp dport 1111 counter drop

   Conteneurs CentOS 7 hérités — ils utilisent iptables plutôt que nftables. Modifiez plutôt /etc/sysconfig/iptables-custom ou /etc/sysconfig/ip6tables-custom, en format iptables-save :

   *filter
   :INPUT DROP [0:0]
   :FORWARD DROP [0:0]
   :OUTPUT ACCEPT [0:0]
   -I INPUT -s 111.111.111.111 -p tcp -m state --state NEW -m tcp --dport 1111 -j DROP
   COMMIT

4. Appliquez vos règles personnalisées :

   sudo /usr/bin/jem firewall fwstart

5. Confirmez que la règle est active :

   sudo jem firewall list

   Votre règle devrait apparaître dans la sortie, confirmant qu’elle est chargée dans l’ensemble de règles actif.

Référence des méthodes API — environment > Security

L’API de la plateforme expose la gestion du pare-feu sous l’espace de noms environment > Security. Ces méthodes sont disponibles au même titre que toutes les autres surfaces d’automatisation d’environnement — utilisez-les depuis des pipelines CI, des manifestes de provisionnement ou vos propres outils.

Scénarios d’automatisation courants :

• Un pipeline CI ajoute l’IP d’un nouvel agent de build à la liste blanche avant un déploiement et la retire ensuite, via AddRule + RemoveRule.
• Un manifeste de démarrage d’environnement appelle SetRules pour établir la posture de sécurité complète avant d’autoriser le trafic.
• Un travail planifié appelle GetRules pour auditer l’ensemble de règles et alerter sur les ajouts inattendus.

Contraintes et cas limites

• Conteneurs Docker personnalisés et Windows — les règles de pare-feu ne peuvent pas être gérées via le tableau de bord pour ces types de conteneurs. Utilisez des contrôles au niveau réseau à la place.
• Conteneurs sans IP publique — le répartiteur de charge partagé de la plateforme médiatise tout le trafic externe, donc un blocage d’IP au niveau conteneur n’est observable de l’extérieur du cluster que si le conteneur a sa propre IP publique rattachée.
• Collisions de priorité — si deux règles partagent la même priorité, l’ordre d’évaluation entre elles n’est pas garanti. Utilisez des valeurs de priorité distinctes.
• Le champ Nœuds est immuable — vous ne pouvez pas déplacer une règle existante vers une couche différente après sa création. Créez une nouvelle règle pour la couche cible, puis supprimez l’ancienne.
• Règles SSH vs règles interface — les règles écrites directement dans /etc/nftables/user-defined.nft (ou les fichiers iptables-custom hérités) prennent effet indépendamment et n’apparaissent pas dans la liste du tableau de bord. Suivez-les séparément si vous mélangez les deux méthodes.

Dépannage

La section Pare-feu n’est pas visible dans les Paramètres Le pare-feu peut ne pas être activé pour votre compte. Contactez le support Stack Harbor et demandez l’activation du pare-feu.

La règle ne semble pas prendre effet Exécutez sudo jem firewall list via Web SSH pour confirmer que la règle est chargée dans l’ensemble de règles actif. Si elle est absente, réappliquez avec sudo /usr/bin/jem firewall fwstart.

Un client peut toujours atteindre un port bloqué Vérifiez que le conteneur possède une IP publique — sans elle, le trafic externe entre par le répartiteur de charge partagé et le blocage au niveau conteneur peut ne pas l’intercepter. Vérifiez également que la priorité de la règle est inférieure à toute règle d’autorisation couvrant la même source et le même port.

Les règles SSH personnalisées disparaissent après un redémarrage Les règles écrites dans /etc/nftables/user-defined.nft (ou les fichiers iptables-custom hérités) devraient persister entre les redémarrages du pare-feu car les fichiers sont relus au fwstart. Si les règles disparaissent, vérifiez que le chemin du fichier est correct pour votre image de conteneur et que fwstart le lit bien.

Voir aussi

• Ports des conteneurs
• Configuration des conteneurs
• Paramètres applicatifs