Résumé

  • Kubernetes décrit NetworkPolicy comme le comportement désiré pour des Pods sélectionnés. Les règles d’entrée et de sortie s’additionnent, et un flux entre Pods exige l’autorisation de la sortie à la source et de l’entrée à la destination.
  • La documentation fixe aussi les limites: sans contrôleur réseau qui l’implémente, l’objet n’a aucun effet; son traitement est éventuel, l’API ne dit pas à quel instant il est achevé, et l’effet sur une connexion existante dépend de l’implémentation.
  • Pour affirmer quelque chose sur un flux, il faut conserver séparément la révision de politique, l’état des sélecteurs et extrémités, l’implémentation réseau, l’observation horodatée de la connexion et toute décision distincte d’identité ou d’application.

L’expression « refus par défaut » peut faire croire qu’un manifeste YAML est déjà un résultat de sécurité. Ce raccourci est trompeur. La valeur de NetworkPolicy est déclarative: elle permet d’isoler, pour l’entrée, la sortie ou les deux, des Pods choisis et de définir les connexions qui restent admises. C’est une décision sur la frontière voulue. Ce n’est pas la preuve qu’un flux concret a été refusé, qu’un flux permis s’est établi, ni qu’une charge de travail est devenue sûre.

Le modèle de ressource pose la première limite. NetworkPolicySpec représente le comportement désiré. La politique sélectionne des Pods, indique l’isolement Ingress ou Egress et énumère des règles. Les effets ne sont pas une suite de refus qui se remplacent; ils sont additifs. Lorsqu’un Pod est isolé dans une direction, l’ensemble permis est l’union des règles de toutes les politiques applicables. Pour qu’un Pod source joigne un Pod destination, la sortie de la source et l’entrée de la destination doivent toutes deux l’autoriser. Cette règle explique un ensemble de politiques; elle ne donne ni adresse réellement observée, ni port, ni protocole, ni heure, ni chemin de paquet, ni résultat.

L’état des sélecteurs reste un fait distinct. Un podSelector, un namespaceSelector ou un ipBlock n’est pas une liste permanente d’extrémités. Les labels évoluent, les Pods sont remplacés et le routage de Service peut modifier le chemin. Kubernetes prévient aussi que les mécanismes d’entrée ou de sortie peuvent réécrire des adresses. Dans ce cas, l’ordre entre cette réécriture et le traitement de NetworkPolicy n’est pas défini et peut varier selon le plugin, le fournisseur cloud, l’implémentation de Service ou leur combinaison. Le manifeste décrit donc un périmètre attendu; il ne tranche pas la manière dont un paquet observé a été représenté au point de contrôle.

L’implémentation est une autre surface de preuve. Kubernetes indique que NetworkPolicy est mise en œuvre par le plugin réseau. Créer une ressource sans contrôleur qui la met en œuvre n’a aucun effet, même si l’API demeure disponible. Cette distinction n’accuse ni un administrateur ni un produit: elle réduit simplement ce que l’on peut déduire d’un objet accepté par l’API. Cet objet prouve une acceptation par le plan de contrôle, non la capacité, la configuration, la santé ou l’activité d’un composant de plan de données.

Le temps rend la conclusion encore plus étroite. Kubernetes indique que chaque politique créée sera finalement traitée, sans que l’API permette de savoir exactement quand. La documentation décrit aussi des vues légèrement incohérentes pendant les changements de Pods ou de politiques. Si une politique modifiée affecte une connexion déjà établie, le comportement relève de l’implémentation. Ce ne sont pas des échappatoires: ce sont des raisons de ne pas demander à une photographie de configuration de raconter une exécution qu’elle ne conserve pas.

La portée protocolaire a sa propre limite. NetworkPolicy est définie pour les connexions TCP, UDP et, selon le plugin, SCTP de couche 4. Pour d’autres protocoles, le comportement peut varier. Une frontière apparente ne doit donc pas devenir une affirmation universelle sur chaque paquet, chaque trajet hostNetwork, chaque mesh, ni sur le chiffrement, l’identité, l’authentification, le DNS, l’autorisation applicative ou la livraison. Ces décisions nécessitent leurs propres preuves.

Daniel Kade propose une quittance de flux en cinq parties. Elle conserve d’abord la révision de politique: espace de noms, identité de l’objet, génération ou capture immuable, sélecteurs, direction, règles et heure. Elle conserve ensuite l’état des sélecteurs et extrémités: labels de Pods et de Namespace, mappage IP ou endpoint, à l’heure précise de lecture. Troisièmement, elle nomme l’implémentation réseau, sa capacité déclarée, sa version, sa configuration pertinente et les éléments de santé.

Quatrièmement, elle journalise une observation de connexion bornée dans le temps, avec source et destination telles qu’observées, protocole, port, direction, résultat, collecteur et limites de visibilité. Enfin, elle lie séparément toute preuve d’identité de charge, d’autorisation, de TLS, de DNS, de réponse applicative ou de déploiement. Protéger les détails sensibles reste compatible avec cette séparation.

Cette méthode décrit aussi des résultats ordinaires. Une politique peut être correcte tandis qu’une panne indépendante bloque une connexion. Un flux permis dans les deux directions peut échouer au DNS, au TLS, à l’authentification ou à l’application. Une politique peut être acceptée avant qu’un plugin précis l’ait rendue effective. Aucun de ces cas ne démontre un défaut ou un incident. Ils montrent pourquoi un manifeste ne doit pas porter seul l’histoire d’un flux.

Sources

  1. Kubernetes — Network Policies
  2. Kubernetes — Services, Load Balancing, and Networking
  3. Référence API Kubernetes — NetworkPolicy v1