Exposer un service via un NodePort

Date	14 septembre 2026

Sur les clusters KaaS Ziosting, le réseau est géré par Calico. Les NodePorts sont fermés par défaut : aucune connexion externe n'atteint vos services tant que vous n'avez pas explicitement créé une règle d'autorisation.

Cette politique deny-by-default garantit que seuls les flux que vous avez validés pénètrent dans le cluster, et que les firewalls applicatifs de vos services (PostgreSQL, Redis, etc.) restent efficaces.

Pourquoi les NodePorts sont-ils fermés par défaut ?

Jusqu'en septembre 2026, les NodePorts étaient ouverts automatiquement par des GlobalNetworkPolicy (GNP) Ziosting. Cela posait deux problèmes :

Contournement du firewall applicatif : un flux pouvait atteindre un service (ex. PostgreSQL) directement via le NodePort, en ignorant les règles firewall configurées sur ce service.
Surface d'attaque étendue : tout port exposé sur tous les nœuds du cluster était accessible depuis Internet, sans contrôle explicite.

Désormais, les GNP gérées par Ziosting qui ouvraient les NodePorts sont retirées.

Services gérés par Ziosting

Les services managés par Ziosting (ZiServices) continuent de fonctionner normalement : leurs règles réseau sont gérées automatiquement et ne nécessitent aucune action de votre part.

Comment ouvrir un NodePort ?

Les NodePorts s'ouvrent via des GlobalNetworkPolicies (GNP) Calico. Les GNP sont des ressources globales au cluster (non-namespacées) : elles ne se créent pas dans un namespace et s'appliquent à tous les nœuds. La création d'une GNP nécessite donc un kubeconfig avec des droits administrateur sur le cluster.

Pré-requis

Kubeconfig admin requis

Les GNP sont des ressources globales, non-namespacées. Un kubeconfig de namespace (voir Gestion des namespaces) ne permet pas de les manipuler. Vous devez disposer d'un kubeconfig admin du cluster pour appliquer ces règles.

Un kubeconfig admin du cluster (récupérable via la console Ziosting)
kubectl (le CLI calicoctl n'est pas nécessaire, les GNP s'appliquent via kubectl directement)

Exemple de GlobalNetworkPolicy

La GNP suivante ouvre les NodePorts 30000 à 32767 (la plage standard Kubernetes) en TCP, depuis n'importe quelle source. C'est l'équivalent de l'ancienne règle Ziosting 108-nodeports-tcp-gnp :

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: 108-nodeports-tcp-gnp
spec:
  applyOnForward: true
  order: 108
  preDNAT: true
  selector: all()
  tier: default
  types:
    - Ingress
  ingress:
    - action: Allow
      protocol: TCP
      destination:
        ports:
          - "30000:32767"

Restreindre l'accès à des IP précises

Dans la majorité des cas, vous ne souhaitez pas ouvrir les NodePorts à tout Internet. Ajoutez un champ source.nets pour restreindre les IP autorisées :

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: 108-nodeports-tcp-gnp
spec:
  applyOnForward: true
  order: 108
  preDNAT: true
  selector: all()
  tier: default
  types:
    - Ingress
  ingress:
    - action: Allow
      protocol: TCP
      destination:
        ports:
          - "30000:32767"
      source:
        nets:
          - 203.0.113.0/24   # Remplacez par votre plage d'IP autorisée

Sécurité

N'utilisez jamais 0.0.0.0/0 (absence de source.nets) sur des NodePorts exposant des services sensibles (base de données, panneau admin…). Restreignez toujours aux IP strictement nécessaires.

Ouvrir un port unique

Pour n'ouvrir qu'un seul NodePort (ex. 32000) plutôt que toute la plage :

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: allow-nodeport-32000
spec:
  applyOnForward: true
  order: 108
  preDNAT: true
  selector: all()
  tier: default
  types:
    - Ingress
  ingress:
    - action: Allow
      protocol: TCP
      destination:
        ports:
          - 32000
      source:
        nets:
          - 203.0.113.0/24

Champs importants

Champ	Rôle
`apiVersion`	`crd.projectcalico.org/v1` — version de la CRD Calico installée sur les clusters Ziosting
`metadata.name`	Nom unique de la GNP (ex. `108-nodeports-tcp-gnp`)
`spec.order`	Priorité d'évaluation. Plus le chiffre est petit, plus la règle est évaluée tôt. Les GNP Ziosting internes utilisent l'ordre 108.
`spec.preDNAT`	`true` — la règle est évaluée avant le DNAT Kubernetes, indispensable pour filtrer sur le NodePort (et non le port interne du pod).
`spec.applyOnForward`	`true` — la règle s'applique au trafic transmis (forwarded) vers les pods, pas seulement au trafic local du nœud.
`spec.selector`	`all()` — la GNP s'applique à tous les nœuds du cluster.
`spec.tier`	`default` — tier Calico standard.
`spec.types`	Type de trafic contrôlé (`Ingress` pour le trafic entrant).
`spec.ingress[].destination.ports`	Le ou les NodePorts à ouvrir. Un seul port (`32000`) ou une plage (`"30000:32767"`).
`spec.ingress[].source.nets`	Liste des plages CIDR autorisées. L'omettre ouvre le port à tout Internet (`0.0.0.0/0`).

Appliquer la GNP

kubectl apply -f 108-nodeports-tcp-gnp.yaml

Vérifiez que la politique est bien active :

kubectl get globalnetworkpolicy 108-nodeports-tcp-gnp

Ouvrir les NodePorts en UDP

Si vos services exposent des NodePorts en UDP (ex. DNS, voix), créez une GNP dédiée :

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: 108-nodeports-udp-gnp
spec:
  applyOnForward: true
  order: 108
  preDNAT: true
  selector: all()
  tier: default
  types:
    - Ingress
  ingress:
    - action: Allow
      protocol: UDP
      destination:
        ports:
          - "30000:32767"
      source:
        nets:
          - 203.0.113.0/24

TCP et UDP séparés

Créez une GNP par protocole (108-nodeports-tcp-gnp et 108-nodeports-udp-gnp) plutôt qu'une seule. Cela facilite les audits et les suppressions ciblées.

Bonnes pratiques

Restreignez les sources : utilisez des CIDR aussi précis que possible (/32 pour une IP unique).
N'ouvrez que ce qui est nécessaire : un NodePort exposé sur tous les nœuds augmente la surface d'attaque.
Documentez chaque GNP : nommez-la clairement (ex. 108-nodeports-tcp-gnp) pour faciliter les audits.
Préférez les Ingress : pour exposer du HTTP/HTTPS, un Ingress Controller est plus adapté qu'un NodePort.

Récapitulatif

Besoin	Solution
Exposer du HTTP/HTTPS	Ingress Controller (Traefik / NGINX)
Exposer un port TCP/UDP à des IP précises	GlobalNetworkPolicy (kubeconfig admin requis) sur le NodePort
ZiServices managés	Aucune action, géré automatiquement

Si vous avez un doute sur la configuration à adopter, contactez le support Ziosting.

Pourquoi les NodePorts sont-ils fermés par défaut ?​

Comment ouvrir un NodePort ?​

Pré-requis​

Exemple de GlobalNetworkPolicy​

Restreindre l'accès à des IP précises​

Ouvrir un port unique​

Champs importants​

Appliquer la GNP​

Ouvrir les NodePorts en UDP​

Bonnes pratiques​

Récapitulatif​