K8s Network Policy

Générateur de Règles de Sécurité Kubernetes NetworkPolicy YAML

Référence technique pour générer des manifestes Kubernetes NetworkPolicy déclaratifs, l'isolation de pods zero-trust, les règles d'ingress/egress, les blocs CIDR et les ports multiples.

Préréglages:
Types de politique appliqués (spec.policyTypes)
Sélecteur de pods cibles (spec.podSelector)

Définissez les pods du namespace "production" que cette politique de sécurité restreint.

Faire correspondre les labels (clé = valeur) :
=
=
Labels de métadonnées de la politique
:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-api-netpol
  namespace: production
  labels:
    tier: api
spec:
  podSelector:
    matchLabels:
      app: backend-api
      tier: api
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - # Allow HTTP from Frontend Pods
      from:
        - podSelector:
            matchLabels:
              app: web-frontend
      ports:
        - protocol: TCP
          port: 8080
    - # Allow Metrics Scraping from Monitoring Namespace
      from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: monitoring
          podSelector:
            matchLabels:
              app: prometheus
      ports:
        - protocol: TCP
          port: 9090
  egress:
    - # Allow CoreDNS Resolution in kube-system
      to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
    - # Allow PostgreSQL Connection
      to:
        - podSelector:
            matchLabels:
              app: postgres
      ports:
        - protocol: TCP
          port: 5432
    - # Allow Redis Cluster Egress
      to:
        - podSelector:
            matchLabels:
              app: redis
      ports:
        - protocol: TCP
          port: 6379
Pods Cibles
2 Label Selectors
Règles Actives
2 Ingress • 3 Egress (6 Ports)
Niveau de Sécurité
100% Zero-Trust Compliant

Microségmentation Zero-Trust

Générez des politiques réseau Kubernetes conformes avec podSelector, blocs CIDR et restriction de ports.

100% Confidentialité Navigateur

La topologie de votre cluster et les sous-réseaux IP restent strictement locaux sans aucun transfert réseau.

Export Prêt pour GitOps

Manifestes standard prêts pour la production accompagnés de modèles Helm et fichiers Kustomize.

Référence technique et guide d'architecture

Générateur de NetworkPolicy K8S Guide Développeur — Guide de référence

Référence technique pour générer des manifestes Kubernetes NetworkPolicy déclaratifs, l'isolation de pods zero-trust, les règles d'ingress/egress, les blocs CIDR et les ports multiples.

Paramètres clés et contrôles

metadata.namestring (RFC 1123)

Identifiant unique de la ressource NetworkPolicy au sein du namespace. Doit respecter la norme DNS RFC 1123 en utilisant des caractères alphanumériques minuscules, tirets ou points jusqu'à 253 caractères.

Par défaut : "app-network-policy"
metadata.namespacestring (DNS Label)

Namespace Kubernetes cible dans lequel la stratégie est appliquée. Les NetworkPolicies isolent les pods exclusivement au sein de leur propre namespace.

Par défaut : "default"
spec.podSelector.matchLabelsobject (key-value)

Sélecteurs de labels désignant les pods ciblés par la règle. Lorsque matchAllPods est activé, un sélecteur vide {} est généré pour appliquer la politique à tous les pods du namespace.

Par défaut : {"app": "backend"}
spec.policyTypesstring[] (Ingress | Egress)

Directions de trafic filtrées (Ingress, Egress ou les deux). Déclarer une direction sans définir de règles associées active un blocage systématique par défaut (Default-Deny).

Par défaut : ["Ingress"]
spec.ingress[*].from[*]array of PeerEntry

Origines de trafic autorisées en entrée. Prend en charge podSelector, namespaceSelector, l'association des deux (logique ET) et les blocs ipBlock CIDR avec exclusions.

Par défaut : []
spec.ingress[*].ports[*]array of PortEntry

Ports de destination et protocoles de niveau 4 (TCP, UDP, SCTP). Supporte les numéros de ports, les ports nommés des conteneurs et les plages de ports contiguës via endPort.

Par défaut : []
spec.egress[*].to[*].ipBlockobject (cidr, except)

Plage CIDR d'adresses IPv4 ou IPv6 externes au cluster autorisées en sortie, permettant d'exclure les réseaux internes ou sous-réseaux via le tableau except.

Par défaut : {"cidr": "0.0.0.0/0", "except": ["10.0.0.0/8"]}

Conseils de pro et bonnes practices

Appliquer la règle Default Deny

Déployez une politique d'interdiction par défaut dans tout le namespace en spécifiant podSelector: {} avec policyTypes: ['Ingress', 'Egress'] sans règles actives. Cela instaure une isolation zero-trust empêchant tout mouvement latéral tant que des accès explicites ne sont pas accordés.

Isoler les pods inter namespaces

Pour filtrer le trafic venant d'un autre namespace, distinguez des éléments de liste séparés (logique OU) d'un objet peer combinant namespaceSelector et podSelector (logique ET). Cette combinaison limite l'accès uniquement aux pods ciblés dans le namespace distant.

Autoriser CoreDNS sur port 53

Lors de la configuration de règles Egress, autorisez impérativement le trafic UDP et TCP sur le port 53 vers les pods CoreDNS dans kube-system. Oublier la sortie DNS casse la résolution des noms de services internes et génère des timeouts applicatifs immédiats.

Plages de ports avec endPort

Exploitez le champ endPort introduit dans Kubernetes 1.22+ pour regrouper des plages de ports contiguës (par exemple 30000 à 32767 pour WebRTC ou FTP passif) dans une seule directive réseau au lieu de répéter des dizaines de blocs de ports identiques.

Pièges courants et dépannage

La ressource NetworkPolicy est créée avec succès mais aucun flux réseau n'est filtré.

Vérifiez que le cluster Kubernetes dispose d'un plugin CNI prenant en charge l'application des NetworkPolicies (comme Calico, Cilium ou AWS VPC CNI avec le contrôleur de stratégies activé). Les CNI de base comme Flannel ignorent silencieusement ces ressources, laissant passer tous les flux malgré la validation de kubectl.

Les pods perdent la résolution DNS interne dès l'activation des règles de filtrage Egress.

L'activation de 'Egress' dans policyTypes bloque par défaut tous les flux sortants non déclarés. Vous devez ajouter une règle de sortie explicite autorisant les ports UDP et TCP 53 à destination des pods CoreDNS situés dans le namespace kube-system ('k8s-app: kube-dns').

La combinaison de podSelector et namespaceSelector autorise par erreur des pods non ciblés.

Assurez-vous que 'podSelector' et 'namespaceSelector' soient regroupés sous le même tiret dans la section 'from:' ou 'to:'. Définir des tirets distincts active une logique OU, autorisant ainsi tous les pods du namespace ou tous les pods du cluster correspondant au label.

Foire aux questions (FAQ)

Quels sont les plugins CNI Kubernetes assurant l'application native des NetworkPolicies ?▼

Calico, Cilium, Kube-router et VMware Antrea appliquent nativement les NetworkPolicies. Flannel standard ne prend pas en charge les politiques sans être couplé à Calico (Canal). Sur AWS EKS, l'Amazon Network Policy Controller doit être installé, tandis que sur Azure CNI et GKE Dataplane V2, l'option doit être activée lors de la configuration du cluster.

Quelle est la différence entre une liste ingress vide ([]) et l'omission du champ ingress ?▼

Lorsque 'Ingress' est listé dans policyTypes, spécifier 'ingress: []' (liste vide) bloque la totalité des connexions entrantes vers les pods ciblés (Default-Deny). À l'inverse, omettre la clé ou renseigner 'ingress: [{}]' crée une règle permissive autorisant tous les flux entrants depuis n'importe quelle source. La syntaxe YAML conditionne directement la sécurité.

Une NetworkPolicy standard de Kubernetes peut-elle inspecter ou filtrer les requêtes HTTP (Couche 7) ?▼

Non. Les NetworkPolicies Kubernetes fonctionnent strictement aux Couches 3 (adresses IP et sous-réseaux CIDR) et 4 (ports TCP, UDP, SCTP). Pour filtrer des URL, des méthodes HTTP ou des en-têtes mTLS applicatifs, il est impératif de mettre en place un maillage de services (Service Mesh comme Istio ou Linkerd) ou des CRD CiliumNetworkPolicy.

Pourquoi ipBlock ne doit-il pas être utilisé pour cibler l'adresse IP d'un pod interne du cluster ?▼

D'après la spécification Kubernetes, ipBlock est exclusivement réservé au trafic vers ou depuis des plages d'adresses IP extérieures au cluster. Comme les adresses IP des pods sont volatiles et modifiées par la translation d'adresses (SNAT) de kube-proxy et du CNI, l'application d'un ipBlock sur des adresses internes génère des dysfonctionnements majeurs.

Comment le générateur produit-il des fichiers Helm et Kustomize sans traitement serveur ?▼

Le générateur exécute l'intégralité de ses transformations via du code TypeScript local dans le navigateur, sans envoyer la moindre donnée vers des serveurs externes. Il produit instantanément des manifestes YAML purs, des gabarits Helm injectant les variables de release et des ressources kustomization.yaml directement téléchargeables.

Outils et utilitaires connexes

Tous les outils →
Guide Développeur : Générateur YAML Kubernetes RBAC Role & ClusterRoleBindingDéveloppement

Concevez des manifestes Kubernetes RBAC pour Role, ClusterRole, RoleBinding et ClusterRoleBinding avec groupes d'API, verbes de ressources et comptes de service.

Ouvrir l'outil→
Guide du Développeur du Générateur de YAML Kubernetes StatefulSet & Headless ServiceDéveloppement

Générez des manifestes Kubernetes StatefulSet de qualité production avec Headless Service associé, volumeClaimTemplates persistants, réplicas et podManagementPolicy.

Ouvrir l'outil→
Référence Développeur Nginx Location Match TesterDéveloppement

Guide technique pour tester les directives location Nginx et analyser l'ordre de priorité des modificateurs.

Ouvrir l'outil→
Référence Développeur Cloudflare Headers et RedirectsDéveloppement

Guide technique et aide-mémoire de syntaxe pour configurer les fichiers _headers et _redirects de Cloudflare Pages, stratégies de sécurité et réécritures edge.

Ouvrir l'outil→
Vercel構成ファイル (vercel.json) ビルダーDéveloppement

Référence technique pour vercel.json : routage edge, réécritures, en-têtes de sécurité, fonctions serverless et planification cron en production.

Ouvrir l'outil→
Guide Développeur : Générateur Interactif ESLint Flat Config (eslint.config.mjs)Développement

Générez des fichiers de configuration moderne pour ESLint 9+ (eslint.config.mjs / .js) avec prise en charge de TypeScript, React, Next.js, Vue, Prettier et de règles sur mesure.

Ouvrir l'outil→